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.41
Beitrag von: noansi am 09 Juni 2014, 19:16:01
*************************************************************************************************************
*************************************************************************************************************

Hier https://forum.fhem.de/index.php?msg=1297324 (https://forum.fhem.de/index.php?msg=1297324) geht es zur aktuellen Version 0.41 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.

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

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

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


ZitatApropos 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.  :(


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


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


ZitatHabe 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
 
ZitatDen Empfang stört es jedenfalls erkennbar nicht.
Es geht mir eher darum, ob es hilft, und weniger, ob es stoert :)


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


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

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

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

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

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

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

Zitatein 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
ZitatDas 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
Zitatkannst 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.


ZitatUnd 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
Zitat von: noansi am 03 November 2014, 22:31:41
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

Zitat von: noansi am 06 November 2014, 21:20:03
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
ZitatAls erstes ein Änderungswunsch in clock.c

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

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

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

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

ZitatDann 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


Zitat von: noansi am 07 Januar 2015, 01:09:43
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
Zitat von: noansi am 15 Januar 2015, 01:00:00

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ZitatEs 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

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

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

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

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

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

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

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

ZitatGut, 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?

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


Zitataber 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?  ;)


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


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

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

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

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

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

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

ZitatHast 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
ZitatGut, 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
Zitatbleibt 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
ReadyNanoCul
leider 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). Malformed
Was 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?

ZitatWas 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:0
Die 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.


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

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

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

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

Zitattemp/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,

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

ZitatZudem 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
Zitat 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.
Die ARM Variante ist inzwischen in der a-culfw enthalten. Es gibt also so wie ich es sehen nur diese zwei Varianten.
Zitat 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?
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.

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

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

Zitateinige 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 CUL868
Ist 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,

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

ZitatAber 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
Zitat von: noansi am 01 März 2016, 19:58:07Das 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
Zitat 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 ...

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

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

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


ZitatWä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
Zitat von: noansi am 18 April 2016, 21:52:33
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,

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

ZitatUnd 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.  :) )

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

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

ZitatNur eine neuere Version von 00_CUL.pm

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

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

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

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

Zitatpinbelegung 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_buf
musst 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.

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

ZitatLeider 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. :)

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

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

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

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

ZitatDann 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
lsusb
ausfü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
dmesg
zeigt 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!
Zitat von: noansi am 03 September 2016, 15:50:18
DevIo.pm und 10_CUL_HM.pm müssen für Homematic auch minimal mit getauscht werden.
Ja, hatte ich natürlich auch mitgenommen...
Zitatdmesg
zeigt 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,

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

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

ZitatMerkwü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?

ZitatEin 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 1
verbose 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

ZitatGibt es eine Doku,
Es gibt diesen Thread und den Code.

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

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

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

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

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

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

ZitatEDIT: folgende habe ich nach /opt/fhem/FHEM/ kopiert:
Du hast die richtigen Dateien kopiert.

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

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

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

Zitat von: MadMax-FHEM am 17 September 2016, 20:12:44
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

Zitatset 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
ZitatDerzeit 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,

ZitatWenn 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
Zitat von: noansi am 19 Oktober 2016, 21:42:56
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.


Zitat von: noansi am 19 Oktober 2016, 21:42:56
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...


Zitat von: noansi am 19 Oktober 2016, 21:42:56
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"  ;-)   )


Zitat von: noansi am 19 Oktober 2016, 21:42:56
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
ZitatHmmm, 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
Zitat von: weini am 19 Oktober 2016, 23:05:13
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 1234
bzw.
define CUL_433 TSCUL /dev/CUL433_0@12000000 0000
definiert 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
Zitat von: klausw am 29 November 2016, 00:45: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,

ZitatEs 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 1034
wä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
dmesg
ein. 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,

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

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,

Zitat von: noansi am 01 Dezember 2016, 01:05:48
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
Zitat von: Maxl am 01 Dezember 2016, 17:58:37
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
Zitat 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?

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

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

Zitatwie 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

ZitatWird 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 :-)

ZitatMal 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 entities (fhem.pl:12463/2016-10-29 perl:5.014002 os:linux user:fhem pid:2388)
2016.12.04 20:32:52.095 1: HM_LAN_WIRED: HM485d already running with PID  2359. We are using this process.
2016.12.04 20:32:52.756 4: CUL_Parse: nanoCUL A 0F 81 8610 3549DB 000000 0A50AF0A0040F7 -78.5
2016.12.04 20:32:52.917 4: CUL_Parse: nanoCUL A 0F 13 8610 3547BF 000000 0A94C60A32401C -60
2016.12.04 20:33:13.493 4: CUL_send:  nanoCULV     
2016.12.04 20:33:13.504 4: CUL_Parse: nanoCUL VTS 0.02 nanoCUL868
2016.12.04 20:33:16.508 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL00UB0Z-if00-port0 disconnected, waiting to reappear (nanoCUL)
2016.12.04 20:33:16.638 3: Setting nanoCUL serial parameters to 38400,8,N,1
2016.12.04 20:33:16.748 4: CUL_send:  nanoCULV     
2016.12.04 20:33:18.100 4: CUL_Parse: nanoCUL C _R ea dyna noCUL8 68
2016.12.04 20:33:18.112 2: nanoCUL: unknown message C_ReadynanoCUL868
2016.12.04 20:33:21.116 4: CUL_send:  nanoCULV     
2016.12.04 20:33:21.128 4: CUL_send:  nanoCUL?     
2016.12.04 20:33:21.161 3: nanoCUL: Possible commands: ABCFGMRTUVWXYefilmtx
2016.12.04 20:33:21.161 4: CUL_send:  nanoCULX2 1     
2016.12.04 20:33:21.173 4: CUL_send:  nanoCULAr     
2016.12.04 20:33:21.183 4: CUL_send:  nanoCULT0 1     
2016.12.04 20:33:21.206 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL00UB0Z-if00-port0 reappeared (nanoCUL)
2016.12.04 20:33:21.223 4: CUL_send:  nanoCULV     
2016.12.04 20:33:21.234 4: CUL_Parse: nanoCUL VTS 0.02 nanoCUL868
2016.12.04 20:33:24.238 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL00UB0Z-if00-port0 disconnected, waiting to reappear (nanoCUL)
2016.12.04 20:33:24.363 3: Setting nanoCUL serial parameters to 38400,8,N,1
2016.12.04 20:33:24.474 4: CUL_send:  nanoCULV     
2016.12.04 20:33:25.826 4: CUL_Parse: nanoCUL C _R ea dyna noCUL8 68
2016.12.04 20:33:25.837 2: nanoCUL: unknown message C_ReadynanoCUL868
2016.12.04 20:33:28.842 4: CUL_send:  nanoCULV     
2016.12.04 20:33:28.853 4: CUL_send:  nanoCUL?     
2016.12.04 20:33:28.886 3: nanoCUL: Possible commands: ABCFGMRTUVWXYefilmtx
2016.12.04 20:33:28.887 4: CUL_send:  nanoCULX2 1     
2016.12.04 20:33:28.897 4: CUL_send:  nanoCULAr     
2016.12.04 20:33:28.908 4: CUL_send:  nanoCULT0 1     
2016.12.04 20:33:28.931 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL00UB0Z-if00-port0 reappeared (nanoCUL)
2016.12.04 20:33:38.798 4: CUL_Parse: nanoCUL A 0D 23 8410 461413 F11234 0601250009 -69.5
2016.12.04 20:33:45.782 4: CUL_Parse: nanoCUL A 0F 10 8610 3549DE 000000 0A8CAC0A0E4014 -64
2016.12.04 20:33:52.169 4: CUL_Parse: nanoCUL A 0D 4B 8410 4F9EC9 F11234 06012A00F4 -80
2016.12.04 20:33:56.829 4: CUL_Parse: nanoCUL A 0F 45 8610 3547BB 000000 0A98CF09004025 -55.5

2016.12.04 21:41:37.392 1: usb create starting
2016.12.04 21:41:50.616 1: usb create end
2016.12.04 21:41:50.626 0: Featurelevel: 5.7
2016.12.04 21:41:50.627 0: Server started with 246 defined entities (fhem.pl:12463/2016-10-29 perl:5.014002 os:linux user:fhem pid:3120)
2016.12.04 21:41:51.596 4: CUL_Parse: nanoCUL A 0F 2B 8610 3549DE 000000 0A8CA90A18400C -68
2016.12.04 21:41:51.765 4: CUL_Parse: nanoCUL A 0F 60 8610 3547BB 000000 0A98CC09004023 -56.5
2016.12.04 21:41:52.129 1: HM485d: Server started ...
2016.12.04 21:41:58.885 4: CUL_Parse: nanoCUL A 0F AF 8610 3549E1 000000 0A28CB0B004009 -69.5
2016.12.04 21:42:03.326 4: CUL_send:  nanoCULV     
2016.12.04 21:42:03.338 4: CUL_Parse: nanoCUL VTS 0.02 nanoCUL868
2016.12.04 21:42:06.342 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL00UB0Z-if00-port0 disconnected, waiting to reappear (nanoCUL)
2016.12.04 21:42:06.409 3: Setting nanoCUL serial parameters to 38400,8,N,1
2016.12.04 21:42:06.520 4: CUL_send:  nanoCULV     
2016.12.04 21:42:07.870 4: CUL_Parse: nanoCUL C _R ea dyna noCUL8 68
2016.12.04 21:42:07.884 2: nanoCUL: unknown message C_ReadynanoCUL868
2016.12.04 21:42:10.887 4: CUL_send:  nanoCULV     
2016.12.04 21:42:10.899 4: CUL_send:  nanoCUL?     
2016.12.04 21:42:10.932 3: nanoCUL: Possible commands: ABCFGMRTUVWXYefilmtx
2016.12.04 21:42:10.932 4: CUL_send:  nanoCULX2 1     
2016.12.04 21:42:10.943 4: CUL_send:  nanoCULAr     
2016.12.04 21:42:10.954 4: CUL_send:  nanoCULT0 1     
2016.12.04 21:42:10.977 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL00UB0Z-if00-port0 reappeared (nanoCUL)
2016.12.04 21:42:11.336 4: CUL_send:  nanoCULV     
2016.12.04 21:42:11.348 4: CUL_Parse: nanoCUL VTS 0.02 nanoCUL868
2016.12.04 21:42:14.352 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL00UB0Z-if00-port0 disconnected, waiting to reappear (nanoCUL)
2016.12.04 21:42:14.468 4: CUL_send:  nanoCULV     
2016.12.04 21:42:14.502 3: Setting nanoCUL serial parameters to 38400,8,N,1
2016.12.04 21:42:14.612 4: CUL_send:  nanoCULV     
2016.12.04 21:42:15.964 4: CUL_Parse: nanoCUL C _R ea dyna noCUL8 68
2016.12.04 21:42:15.976 2: nanoCUL: unknown message C_ReadynanoCUL868
2016.12.04 21:42:18.980 4: CUL_send:  nanoCULV     
2016.12.04 21:42:18.992 4: CUL_send:  nanoCUL?     
2016.12.04 21:42:19.025 3: nanoCUL: Possible commands: ABCFGMRTUVWXYefilmtx
2016.12.04 21:42:19.026 4: CUL_send:  nanoCULX2 1     
2016.12.04 21:42:19.037 4: CUL_send:  nanoCULAr     
2016.12.04 21:42:19.047 4: CUL_send:  nanoCULT0 1     
2016.12.04 21:42:19.070 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL00UB0Z-if00-port0 reappeared (nanoCUL)
2016.12.04 21:43:02.377 1: PERL WARNING: Argument "" isn't numeric in int at ./FHEM/99_myUtils.pm line 99.
2016.12.04 21:43:05.394 4: CUL_Parse: nanoCUL A 0D 57 8410 4F9EC9 F11234 06012900F4 -80
2016.12.04 21:43:06.929 4: CUL_Parse: nanoCUL A 0F 9D 8610 3549DB 000000 0A50B30A0040F9 -77.5
2016.12.04 21:43:25.211 4: CUL_Parse: nanoCUL A 0F 0A 8610 354555 000000 0A28900A00402B -52.5
2016.12.04 21:43:28.919 4: CUL_Parse: nanoCUL A 0F 2F 8610 3547BF 000000 0A94C80A28401C -60
2016.12.04 21:43:45.264 4: CUL_Parse: nanoCUL A 0F D8 8610 3547BA 000000 0A289F0A00401B -60.5
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 04 Dezember 2016, 21:54:56
Hast du auch die Module eingespielt?

Und auf TSCUL umgestellt?

Im Log steht CUL_parse...
...bei mir steht TSCUL_parse...

Weiß zwar nicht, ob die "Originalmodule" mit einem Timestamp-CUL zurecht kommen, müsste Ansgar beantworten können...

Trotzdem mal 'lsusb' wenn beide (du hast doch 2? Es ist nur einer definiert??
(Nur um zu sehen was für FTDI du hast bzw. der nano hat)

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 05 Dezember 2016, 00:31:05
Hallo Mario,

Du musst erst mal die aktuelle Version nehmen. Du bist noch auf VTS 0.02. Version VTS 0.03 wäre aktuell. Und das auf dem nanoCUL, mit dem Du Homematic nutzen möchtest.
2016.12.04 21:42:19.047 4: CUL_send:  nanoCULT0 1
Anscheinend gibt es bei FHT Probleme, kann ich leider nicht testen, da ich keine FHT Komponenten habe. Aber das T01 ist dort nicht sinnvoll für einen HM CUL???

Dann im FHEM Verzeichnis erst mal die alten Dateien sichern und dann alle neuen Module dort hin kopieren.

Dann in der fhem.cfg CUL durch TSCUL bei dem nanoCUL ersetzen, den Du mit Homematic nutzen möchtest, damit das TSCUL Modul benutzt wird (das CUL Modul ist ungeeignet).
Beispiel:
define nanoCUL TSCUL/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL00UB0Z-if00-port0@38400 0000
attr nanoCUL event-on-change-reading cond
attr nanoCUL hmLanQlen 2_low
attr nanoCUL hmId F11234
attr nanoCUL rfmode HomeMatic


Die letzten beiden Attribute werden bei Nutzung einer VCCU nicht benötigt, macht die VCCU.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Maxl am 05 Dezember 2016, 08:23:23
Hallo,

denke ich habe nun richtig umgestellt, jetzt mit 0.03 .
Anbei ein Auszug aus dem Logfile nach Server Neustart:

2016.12.05 20:38:28.759 0: Server shutdown
2016.12.05 20:40:30.513 1: Including fhem.cfg
2016.12.05 20:40:34.325 1: nanoCUL is VERSION_TS, VTS 0.03 nanoCUL868, nanoCUL_V1.x
2016.12.05 20:40:37.476 1: Including ./log/fhem.save
2016.12.05 20:40:39.876 1: usb create starting
2016.12.05 20:40:53.040 1: usb create end
2016.12.05 20:40:53.071 0: Featurelevel: 5.7
2016.12.05 20:40:53.072 0: Server started with 245 defined entities (fhem.pl:12463/2016-10-29 perl:5.014002 os:linux user:fhem pid:5243)
2016.12.05 20:40:53.211 1: HM_LAN_WIRED: HM485d already running with PID  4291. We are using this process.
2016.12.05 20:40:53.401 2: TSCUL_Parse: nanoCUL new condition ok
2016.12.05 20:40:53.411 4: TSCUL_Parse: nanoCUL  054027 A FF51 00001764 00 0F 81 8610 3547BB 000000 0A98CD090040 -68.5
2016.12.05 20:40:53.548 4: TSCUL_send:  nanoCUL                         As 0B 02 A001 F11234 383FB5 010E
2016.12.05 20:40:53.607 4: TSCUL_Parse: nanoCUL  054240 A FF52 00019396 00 01 C3 _ping -138
2016.12.05 20:40:53.609 4: TSCUL_Parse: nanoCUL  054232 A FF52 00019440 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2016.12.05 20:40:53.614 0: HM485d: Server stopped ...
2016.12.05 20:40:53.628 4: TSCUL_Parse: nanoCUL  054257 A FF53 00019712 00 0B 02 A001 F11234 383FB5 01 -138
2016.12.05 20:40:54.287 4: TSCUL_Parse: nanoCUL  054915 A FF53 00019956 00 0B 02 A001 F11234 383FB5 01 -138
2016.12.05 20:40:54.289 4: TSCUL_Parse: nanoCUL  054918 A FF53 00020196 00 0B 02 A001 F11234 383FB5 01 -138
2016.12.05 20:40:54.290 1: TSCUL_ParseTsHM nanoCUL HM repeat failed or AES Device Authentication error: AFF50000013F5000B02A001F11234383FB501
2016.12.05 20:40:54.291 4: TSCUL_Parse: nanoCUL  054919 A FF50 00020436 00 0B 02 A001 F11234 383FB5 01 _sfail -138
2016.12.05 20:40:55.733 1: HM485d: Server started ...
2016.12.05 20:40:57.664 4: TSCUL_send:  nanoCUL                         As 0B 02 A001 F11234 383FB5 010E
2016.12.05 20:40:57.773 4: TSCUL_Parse: nanoCUL  058402 A FF53 00023832 00 0B 02 A001 F11234 383FB5 01 -138
2016.12.05 20:40:58.012 4: TSCUL_Parse: nanoCUL  058640 A FF53 00024072 00 0B 02 A001 F11234 383FB5 01 -138
2016.12.05 20:40:58.121 4: TSCUL_send:  nanoCUL                         As 0B 02 B001 F11234 353C4B 010E
2016.12.05 20:40:58.212 2: TSCUL_Parse: nanoCUL new condition ERROR-Overload
2016.12.05 20:40:58.223 4: TSCUL_Parse: nanoCUL  058839 A FFF3 00024312 00 0B 02 A001 F11234 383FB5 01 -138
2016.12.05 20:40:58.459 1: TSCUL_ParseTsHM nanoCUL HM repeat failed or AES Device Authentication error: AFFF0000017FA000B02A001F11234383FB501
2016.12.05 20:40:58.459 4: TSCUL_Parse: nanoCUL  059087 A FFF0 00024552 00 0B 02 A001 F11234 383FB5 01 _sfail -138
2016.12.05 20:40:58.830 2: TSCUL_Parse: nanoCUL new condition ok
2016.12.05 20:40:58.841 4: TSCUL_Parse: nanoCUL  059457 A FF63 00024556 00 0B 02 B001 F11234 353C4B 01 _bst -138
2016.12.05 20:40:58.928 4: TSCUL_Parse: nanoCUL  059554 A FF61 00025040 00 0E 02 A410 353C4B F11234 0601000000 -58
2016.12.05 20:40:58.948 4: TSCUL_send:  nanoCUL                         As 0A 02 8002 F11234 353C4B 00
2016.12.05 20:40:58.949 3: TSCUL_XmitDlyHM:  nanoCUL  id:353C4B dDly:89 toms:72
2016.12.05 20:40:59.068 4: TSCUL_Parse: nanoCUL  059696 A FF63 00025160 00 0A 02 8002 F11234 353C4B 00 _dhmSt:120 -138
2016.12.05 20:40:59.177 4: TSCUL_send:  nanoCUL                         As 0B 03 B001 F11234 353C4B 020E
2016.12.05 20:40:59.625 4: TSCUL_Parse: nanoCUL  060253 A FF63 00025348 00 0B 03 B001 F11234 353C4B 02 _bst _dhmSt:308 -138
2016.12.05 20:40:59.709 4: TSCUL_Parse: nanoCUL  060335 A FF61 00025832 00 0E 03 A410 353C4B F11234 0602000000 -58
2016.12.05 20:40:59.729 4: TSCUL_send:  nanoCUL                         As 0A 03 8002 F11234 353C4B 00
2016.12.05 20:40:59.730 3: TSCUL_XmitDlyHM:  nanoCUL  id:353C4B dDly:89 toms:72
2016.12.05 20:40:59.850 4: TSCUL_Parse: nanoCUL  060478 A FF63 00025952 00 0A 03 8002 F11234 353C4B 00 _dhmSt:120 -138
2016.12.05 20:41:00.290 4: TSCUL_send:  nanoCUL                         As 0B 04 B001 F11234 353C4B 030E
2016.12.05 20:41:00.727 4: TSCUL_Parse: nanoCUL  061355 A FF63 00026460 00 0B 04 B001 F11234 353C4B 03 _bst _dhmSt:628 -138
2016.12.05 20:41:00.812 4: TSCUL_Parse: nanoCUL  061438 A FF61 00026948 00 0E 04 A410 353C4B F11234 0603000000 -58
2016.12.05 20:41:00.831 4: TSCUL_send:  nanoCUL                         As 0A 04 8002 F11234 353C4B 00
2016.12.05 20:41:00.831 3: TSCUL_XmitDlyHM:  nanoCUL  id:353C4B dDly:90 toms:72
2016.12.05 20:41:00.945 4: TSCUL_Parse: nanoCUL  061574 A FF63 00027068 00 0A 04 8002 F11234 353C4B 00 _dhmSt:120 -138
2016.12.05 20:41:01.366 4: TSCUL_send:  nanoCUL                         As 0B 05 B001 F11234 353C4B 040E
2016.12.05 20:41:01.808 4: TSCUL_Parse: nanoCUL  062436 A FF63 00027536 00 0B 05 B001 F11234 353C4B 04 _bst _dhmSt:588 -138
2016.12.05 20:41:01.892 4: TSCUL_Parse: nanoCUL  062518 A FF61 00028024 00 0E 05 A410 353C4B F11234 0604000000 -57.5
2016.12.05 20:41:01.911 4: TSCUL_send:  nanoCUL                         As 0A 05 8002 F11234 353C4B 00
2016.12.05 20:41:01.911 3: TSCUL_XmitDlyHM:  nanoCUL  id:353C4B dDly:85 toms:72


bei "get nanoCUL version" bekomme ich aber trotzdem noch den Fehler "--> no answer" der Rest geht :-)

Noch was bei dem HM-MOD-RE8 erscheinen Fehler mit OVERLOAD und ich muß öfters drücken bevor etwas geschiet:

2016-12-05 16:26:23.796 CUL_HM HM_381468 battery: ok
2016-12-05 16:26:23.796 CUL_HM HM_381468 CMDs_done
2016-12-05 16:26:23.796 CUL_HM HM_381468 Schalter_Haustuer_innen Short
2016-12-05 16:26:23.811 CUL_HM CUL_HM_HM_MOD_Re_8_353C4B CMDs_pending
2016-12-05 16:26:23.820 CUL_HM Licht_Haustuer set_on-for-timer 30
2016-12-05 16:26:23.849 CUL_HM Schalter_Haustuer_innen Short (to nanoCUL)
2016-12-05 16:26:23.849 CUL_HM Schalter_Haustuer_innen trigDst_F11234: noConfig
2016-12-05 16:26:23.849 CUL_HM Schalter_Haustuer_innen trigger: Short_49
2016-12-05 16:26:23.849 CUL_HM Schalter_Haustuer_innen trigger_cnt: 49
2016-12-05 16:26:23.918 TSCUL nanoCUL cond: ERROR-Overload
2016-12-05 16:26:24.339 TSCUL nanoCUL cond: Warning-HighLoad
2016-12-05 16:26:25.636 CUL_HM CUL_HM_HM_MOD_Re_8_353C4B NACK
2016-12-05 16:26:27.238 CUL_HM HM_381468 battery: ok
2016-12-05 16:26:27.238 CUL_HM HM_381468 CMDs_done
2016-12-05 16:26:27.238 CUL_HM HM_381468 Schalter_Haustuer_innen Short
2016-12-05 16:26:27.252 CUL_HM Licht_Haustuer set_on-for-timer 30
2016-12-05 16:26:27.265 CUL_HM Schalter_Haustuer_innen Short (to nanoCUL)
2016-12-05 16:26:27.265 CUL_HM Schalter_Haustuer_innen trigDst_F11234: noConfig
2016-12-05 16:26:27.265 CUL_HM Schalter_Haustuer_innen trigger: Short_51
2016-12-05 16:26:27.265 CUL_HM Schalter_Haustuer_innen trigger_cnt: 51
2016-12-05 16:26:27.820 CUL_HM HM_381468 battery: ok
2016-12-05 16:26:27.820 CUL_HM HM_381468 CMDs_done
2016-12-05 16:26:27.820 CUL_HM HM_381468 Schalter_Haustuer_innen Short
2016-12-05 16:26:27.834 CUL_HM Licht_Haustuer set_on-for-timer 30
2016-12-05 16:26:27.847 CUL_HM Schalter_Haustuer_innen Short (to nanoCUL)
2016-12-05 16:26:27.847 CUL_HM Schalter_Haustuer_innen trigDst_F11234: noConfig
2016-12-05 16:26:27.847 CUL_HM Schalter_Haustuer_innen trigger: Short_52
2016-12-05 16:26:27.847 CUL_HM Schalter_Haustuer_innen trigger_cnt: 52
2016-12-05 16:26:28.358 TSCUL nanoCUL cond: ERROR-Overload
2016-12-05 16:26:29.078 CUL_HM Licht_Haustuer deviceMsg: on (to nanoCUL)
2016-12-05 16:26:29.078 CUL_HM Licht_Haustuer level: 100
2016-12-05 16:26:29.078 CUL_HM Licht_Haustuer pct: 100
2016-12-05 16:26:29.078 CUL_HM Licht_Haustuer on
2016-12-05 16:26:29.078 CUL_HM Licht_Haustuer timedOn: running
2016-12-05 16:26:29.146 TSCUL nanoCUL cond: Warning-HighLoad
2016-12-05 16:26:32.118 CUL_HM CUL_HM_HM_MOD_Re_8_353C4B ResndFail
2016-12-05 16:26:32.128 CUL_HM CUL_HM_HM_MOD_Re_8_353C4B CMDs_done_Errors:1
2016-12-05 16:26:32.139 CUL_HM CUL_HM_HM_MOD_Re_8_353C4B MISSING ACK
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bastel-Frank am 06 Dezember 2016, 07:41:36
Bei mir läuft die TSCUL-Firmware und die Module.

Im Log findet ich nun massenhaft folgendes:
TSCUL_ParseTsHM CUL_01 HM repeat failed or AES Device Authentication error: AFF1005574219000B1BA00173839652D24A01

Hinweis: Ich nutze kein AES.

Was bedeutet die Meldung? und wie bekomme ich sie wieder weg?
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bastel-Frank am 07 Dezember 2016, 21:05:48
@Ansgar: Darf ich fragen, was in der Version 0.03 neu ist? und welche Dateien sich geändert haben? Muss man die Firmware updaten?
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 09 Dezember 2016, 00:49:05
Hallo Frank,

bei der 0.03 ist die Firmware geändert. Beim Message Nummer Handling war das Überlaufproblem in 0.02 nicht sauber gelöst. -> Update sinnvoll.
Und ich hatte noch für Burst devices bezüglich der Wiederholung nach fehlgeschlagenem AES gehofft, dass das device vom vorherigen Burst noch wach ist und den Burst bei der Wiederholung einzusparen versucht.
Schien bei meinen Tests wohl nicht so zu sein, weswegen ich das wieder raus genommen habe. Mir fehlt eine zuverlässige Info, wie lange Burst devices nach dem letzten Empfang oder Senden wach bleiben.
Außerdem habe ich für nanoCUL die board.h etwas angepasst bezüglich der nicht ASKSIN Funktionen, die mit rein compiliert werden.
Bei 00_TSCUL.pm habe ich Klaus Hinweis eingebaut und den condition status bezüglich disconnect Zählung verbessert.

ZitatTSCUL_ParseTsHM CUL_01 HM repeat failed or AES Device Authentication error
Wenn kein AES benutzt wird, dann sind Sendeversuche (3 Stück) an ein device fehlgeschlagen, sprich das device hat nicht innerhalb der erwarten Zeit geantwortet, wenn es laut Sendebefehl soll, z.B. kein ACK.

ZitatWas bedeutet die Meldung? und wie bekomme ich sie wieder weg?
Mit mehr Log bei verbose 4 lässt sich vielleicht mehr sagen. eventuell ist mein timeout noch zu knapp für diese devices.
Ansonsten verbose 0 vei TS_CUL.  ;)

Mich würde noch interessieren, wie wiel bei den ASKSIN_SEND_BUFS (in board.h) noch geht, bevor die Firmware crashed. 9 ist Maximum. Also schrittweise Erhöhung würde Erkenntniss bringen.

Hallo Maxl,

Zitatbei "get nanoCUL version" bekomme ich aber trotzdem noch den Fehler "--> no answer"
Danke für den Hinweis, das ist noch ein kleiner Bug in 00_TSCUL.pm, behebe ich noch.

Das device mit der ID 383FB5 antwortet nicht. Warum? Ist es nicht erreichbar? Die Sendeversuche scheinen unnötig credits aufzubrauchen, so dass Du eher in die Sendezeitbeschränkungläufst!?!
HM-MOD-RE8 ID 353C4B wird mit burst angesprochen und braucht dementsprechend viele credits zum Aufwecken (_bst = Burst Befehl). Bei häufigem Senden hohe Chance auf Sendezeitbeschränkung.
Warten bringt credits.  :)

Ansonsten schön, dass es läuft.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bastel-Frank am 09 Dezember 2016, 09:55:39
Hallo Ansgar,

vielen Dank für deine Infos.

Ich würde gerne dabei helfen:
Zitat von: noansi am 09 Dezember 2016, 00:49:05
Mich würde noch interessieren, wie wiel bei den ASKSIN_SEND_BUFS (in board.h) noch geht, bevor die Firmware crashed. 9 ist Maximum. Also schrittweise Erhöhung würde Erkenntnisse bringen.
Hierzu müsste man die Firmware jeweils neu compilieren - oder? Compilieren habe ich bisher noch nicht gelernt. Wenn Du bitte einen kleinen Crash-Kurs geben könntest, würde ich dabei gerne unterstützen.

Frank
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Maxl am 09 Dezember 2016, 16:58:28
Hallo Ansgar,

ZitatDas device mit der ID 383FB5 antwortet nicht. Warum? Ist es nicht erreichbar? Die Sendeversuche scheinen unnötig credits aufzubrauchen, so dass Du eher in die Sendezeitbeschränkungläufst!?!
HM-MOD-RE8 ID 353C4B wird mit burst angesprochen und braucht dementsprechend viele credits zum Aufwecken (_bst = Burst Befehl). Bei häufigem Senden hohe Chance auf Sendezeitbeschränkung.
Warten bringt credits.

Wie könnte ich mein Problem umgehen, das eine ist ein Funkbewegungsmelder, das andere der 8 Kanalempfänger, sobald der eine eine Bewegung erkennt soll das Licht angehen. Eigentlich habe ich sowieso Wartezeiten von 30s im Bewegungsmelder. Trotzdem reagiert der 8 Kanal Empfänger zum Schalten der Lampen des öfteren nicht. Erreichbar ist er, sobald ich einen set Befehl direkt unter FHEM antriggere funktiioniert dieser immer, nur in Verbindung mit dem Funk Bewegungsmelder will er nicht. Kann es sein das zu viele Telegramme anstehen und diese Kollidieren?

Gruß
Mario
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bastel-Frank am 09 Dezember 2016, 18:26:56
Zitat von: noansi am 09 Dezember 2016, 00:49:05
Mit mehr Log bei verbose 4 lässt sich vielleicht mehr sagen. eventuell ist mein timeout noch zu knapp für diese devices.
Ansonsten verbose 0 vei TS_CUL.  ;)

Mit verbose=4 erhalte ich folgenden Log (Was mich wundert ist, dass die AES-Fehler nicht mehr erscheinen):
2016.12.09 18:09:38.361 4: TSCUL_Parse: CUL_KG  510387 A FF81 00224620 00 14 4B 845E 2B3660 000000 83A63C000958009808DC01 -40.5
2016.12.09 18:09:47.461 4: TSCUL_Parse: CUL_KG  519489 A FF81 00233724 00 0C CB 8470 4DE827 000000 00A344 -104
2016.12.09 18:09:49.583 4: TSCUL_Parse: CUL_KG  521611 A FF81 00235844 00 0C 48 8470 4DE828 000000 00BB3A -68.5
2016.12.09 18:09:53.567 4: TSCUL_Parse: CUL_KG  001305 A FF82 00239820 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2016.12.09 18:09:54.505 4: TSCUL_Parse: CUL_KG  002244 A FF81 00240768 00 0C AB 865A 4DE81E 000000 90C145 -63
2016.12.09 18:09:55.603 4: TSCUL_Parse: CUL_KG  003342 A FF81 00241864 00 14 9B 845E 3703D4 000000 800A4600012B002308EAFF -95.5
2016.12.09 18:10:14.505 2: TSCUL_Parse: CUL_KG new condition ok
2016.12.09 18:10:14.507 4: TSCUL_Parse: CUL_KG  022245 A FF71 00260768 00 0C AB 8470 4DE81E 000000 00C145 -62.5
2016.12.09 18:10:17.790 4: TSCUL_Parse: CUL_KG  025529 A FF71 00263864 00 14 63 845E 3426D2 000000 800085000064000908E101 -82
2016.12.09 18:10:22.638 4: TSCUL_Parse: CUL_KG  030377 A FF71 00268900 00 0C 31 8470 3032E1 000000 00AB32 -107
2016.12.09 18:10:24.476 4: TSCUL_Parse: CUL_KG  032214 A FF72 00270732 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2016.12.09 18:10:31.532 4: TSCUL_Parse: CUL_KG  039272 A FF71 00277796 00 0C 0C 865A 2710FA 000000 ACDD34 -33
2016.12.09 18:10:39.456 4: TSCUL_Parse: CUL_KG  047196 A FF71 00285720 00 0D 9F 8041 271127 2E517A 07E6C880 -50
2016.12.09 18:10:41.046 4: TSCUL_Parse: CUL_KG  048786 A FF71 00287308 00 0C 27 865A 31CF9D 000000 B0F22E -86.5
2016.12.09 18:10:42.346 4: TSCUL_Parse: CUL_KG  050086 A FF71 00288608 00 0C CE 865A 271127 000000 B4D637 -50
2016.12.09 18:10:50.850 4: TSCUL_Parse: CUL_KG  058588 A FF71 00297112 00 14 58 845E 370A61 000000 80007800005B000908EAFF -84.5
2016.12.09 18:10:51.048 4: TSCUL_Parse: CUL_KG  058787 A FF71 00297312 00 0E 83 8410 31CF9D 000000 0BB0F20D40 -87
2016.12.09 18:10:51.532 4: TSCUL_Parse: CUL_KG  059272 A FF71 00297796 00 0C 0C 8470 2710FA 000000 00DD34 -32.5
2016.12.09 18:10:56.714 4: TSCUL_Parse: CUL_KG  064452 A FF72 00302968 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2016.12.09 18:10:59.237 4: TSCUL_Parse: CUL_KG  066977 A FF71 00305500 00 0D 36 8041 31CF9A 2E517A 0736C880 -82.5
2016.12.09 18:11:01.046 4: TSCUL_Parse: CUL_KG  068786 A FF71 00307308 00 0C 27 8470 31CF9D 000000 00F22E -86.5
2016.12.09 18:11:02.798 4: TSCUL_Parse: CUL_KG  070538 A FF71 00308608 00 0C CE 8470 271127 000000 00D637 -50
2016.12.09 18:11:28.225 4: TSCUL_Parse: CUL_KG  095963 A FF72 00334480 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2016.12.09 18:11:31.378 4: TSCUL_Parse: CUL_KG  099117 A FF71 00337644 00 0C A9 865A 31CF9A 000000 A0BE40 -83.5
2016.12.09 18:11:31.722 4: TSCUL_Parse: CUL_KG  099461 A FF71 00337988 00 14 7F 845E 34264B 000000 80244F000119002108DF01 -67
2016.12.09 18:11:42.392 4: TSCUL_Parse: CUL_KG  110131 A FF71 00348656 00 0D 5F 8041 2710FA 254AE9 07DD0080 -32.5
2016.12.09 18:11:51.378 4: TSCUL_Parse: CUL_KG  119118 A FF71 00357644 00 0C A9 8470 31CF9A 000000 00BE40 -82.5
2016.12.09 18:11:53.624 4: TSCUL_Parse: CUL_KG  121364 A FF71 00359888 00 0D 6C 8410 24917F 219045 06012000 -40.5
2016.12.09 18:12:02.804 4: TSCUL_Parse: CUL_KG  130542 A FF72 00369060 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2016.12.09 18:12:10.790 4: TSCUL_Parse: CUL_KG  138528 A FF71 00376628 00 14 4C 845E 2B3660 000000 83A646000964009908DBFF -41
2016.12.09 18:12:14.104 4: TSCUL_Parse: CUL_KG  141842 A FF71 00380368 00 14 9C 845E 3703D4 000000 800A4700012C002308E9FF -100
2016.12.09 18:12:18.788 4: TSCUL_Parse: CUL_KG  146526 A FF71 00384476 00 14 D1 845E 2B36E4 000000 8012AD000098001208E3FF -92.5
2016.12.09 18:12:19.692 4: TSCUL_Parse: CUL_KG  147432 A FF71 00385960 00 0D 6B 8041 4DE828 2E517A 07CC0080 -68.5
2016.12.09 18:12:21.332 4: TSCUL_Parse: CUL_KG  149072 A FF71 00387600 00 0C 49 865A 4DE828 000000 90BB3A -68.5
2016.12.09 18:12:22.256 4: TSCUL_Parse: CUL_KG  149996 A FF71 00388524 00 0C AC 865A 4DE81E 000000 90C145 -63
2016.12.09 18:12:27.365 4: TSCUL_Parse: CUL_KG  155105 A FF71 00393632 00 0D 27 8041 4DE81E 2E517A 07CF0080 -63.5
2016.12.09 18:12:29.962 4: TSCUL_Parse: CUL_KG  157701 A FF71 00396228 00 0C CC 865A 4DE827 000000 A8A344 -106.5
2016.12.09 18:12:30.353 4: TSCUL_Parse: CUL_KG  158091 A FF71 00396620 00 14 64 845E 3426D2 000000 800085000063000908E2FF -84
2016.12.09 18:12:34.383 4: TSCUL_Parse: CUL_KG  162121 A FF72 00400640 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2016.12.09 18:12:41.332 4: TSCUL_Parse: CUL_KG  169072 A FF71 00407600 00 0C 49 8470 4DE828 000000 00BB3A -69
2016.12.09 18:12:42.256 4: TSCUL_Parse: CUL_KG  169996 A FF71 00408524 00 0C AC 8470 4DE81E 000000 00C145 -63
2016.12.09 18:12:49.962 4: TSCUL_Parse: CUL_KG  177702 A FF71 00416228 00 0C CC 8470 4DE827 000000 00A344 -103
2016.12.09 18:12:59.850 4: TSCUL_Parse: CUL_KG  187589 A FF71 00426116 00 14 59 845E 370A61 000000 80007800005B000908EBFF -85
2016.12.09 18:13:05.768 4: TSCUL_Parse: CUL_KG  193506 A FF62 00432028 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2016.12.09 18:13:09.297 4: TSCUL_Parse: CUL_KG  197037 A FF61 00435564 00 0C 28 865A 31CF9D 000000 B0F22E -87
2016.12.09 18:13:16.033 4: TSCUL_Parse: CUL_KG  203772 A FF61 00442300 00 0C 0D 865A 2710FA 000000 ACDD34 -32.5
2016.12.09 18:13:29.297 4: TSCUL_Parse: CUL_KG  217037 A FF61 00455564 00 0C 28 8470 31CF9D 000000 00F22E -87.5
2016.12.09 18:13:30.846 4: TSCUL_Parse: CUL_KG  218586 A FF61 00457116 00 0C CF 865A 271127 000000 B4D637 -49.5
2016.12.09 18:13:36.033 4: TSCUL_Parse: CUL_KG  223773 A FF61 00462300 00 0C 0D 8470 2710FA 000000 00DD34 -33
2016.12.09 18:13:36.662 4: TSCUL_Parse: CUL_KG  224400 A FF62 00462924 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2016.12.09 18:13:45.878 4: TSCUL_Parse: CUL_KG  233618 A FF61 00472148 00 0C AA 865A 31CF9A 000000 A0BE40 -83.5
2016.12.09 18:13:50.846 4: TSCUL_Parse: CUL_KG  238586 A FF61 00477116 00 0C CF 8470 271127 000000 00D637 -49.5
2016.12.09 18:14:05.878 4: TSCUL_Parse: CUL_KG  253618 A FF61 00492148 00 0C AA 8470 31CF9A 000000 00BE40 -83
2016.12.09 18:14:05.973 4: TSCUL_Parse: CUL_KG  253711 A FF61 00492244 00 14 80 845E 34264B 000000 80245000011B002108E501 -67
2016.12.09 18:14:10.909 4: TSCUL_Parse: CUL_KG  258647 A FF62 00497172 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2016.12.09 18:14:18.787 4: TSCUL_Parse: CUL_KG  266526 A FF61 00504624 00 14 9D 845E 3703D4 000000 800A4800012E002308F1FF -101.5
2016.12.09 18:14:27.863 4: TSCUL_Parse: CUL_KG  275602 A FF61 00514132 00 14 4D 845E 2B3660 000000 83A64F000958009808E6FF -41.5
2016.12.09 18:14:35.507 4: TSCUL_Parse: CUL_KG  283247 A FF61 00521776 00 0C AD 865A 4DE81E 000000 90C145 -62.5
2016.12.09 18:14:39.457 4: TSCUL_Parse: CUL_KG  287196 A FF61 00525728 00 0D 9F 8041 271127 2E517A 07E7C880 -49
2016.12.09 18:14:44.503 4: TSCUL_Parse: CUL_KG  292241 A FF62 00530764 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2016.12.09 18:14:55.507 4: TSCUL_Parse: CUL_KG  303247 A FF61 00541780 00 0C AD 8470 4DE81E 000000 00C145 -63
2016.12.09 18:14:58.581 4: TSCUL_Parse: CUL_KG  306321 A FF61 00544852 00 0C 4A 865A 4DE828 000000 90BB3A -68
2016.12.09 18:14:59.238 4: TSCUL_Parse: CUL_KG  306977 A FF61 00545508 00 0D 36 8041 31CF9A 2E517A 0737C880 -83
2016.12.09 18:15:05.462 4: TSCUL_Parse: CUL_KG  313201 A FF61 00551732 00 14 D2 845E 2B36E4 000000 8012AE000095001108E2FF -94.5
2016.12.09 18:15:16.138 4: TSCUL_Parse: CUL_KG  323876 A FF62 00562400 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2016.12.09 18:15:18.789 4: TSCUL_Parse: CUL_KG  326529 A FF61 00564484 00 0C CD 865A 4DE827 000000 A8A344 -102.5
2016.12.09 18:15:18.794 4: TSCUL_Parse: CUL_KG  326534 A FF61 00564852 00 0C 4A 8470 4DE828 000000 00BB3A -68.5
2016.12.09 18:15:23.298 4: TSCUL_Parse: CUL_KG  331038 A FF61 00569568 00 0C 29 865A 31CF9D 000000 B0F22E -86.5
2016.12.09 18:15:32.853 4: TSCUL_Parse: CUL_KG  340591 A FF61 00579124 00 14 65 845E 3426D2 000000 800086000063000908DDFE -82.5
2016.12.09 18:15:42.393 4: TSCUL_Parse: CUL_KG  350132 A FF61 00588664 00 0D 5F 8041 2710FA 254AE9 07DE0080 -32
2016.12.09 18:15:43.298 4: TSCUL_Parse: CUL_KG  351038 A FF61 00589572 00 0C 29 8470 31CF9D 000000 00F22E -87
2016.12.09 18:15:45.878 4: TSCUL_Parse: CUL_KG  353618 A FF61 00592152 00 0C AB 865A 31CF9A 000000 A0BF40 -83
2016.12.09 18:15:46.033 4: TSCUL_Parse: CUL_KG  353773 A FF61 00592308 00 0C 0E 865A 2710FA 000000 ACDD34 -32
2016.12.09 18:15:47.057 4: TSCUL_Parse: CUL_KG  354796 A FF62 00593320 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2016.12.09 18:15:55.888 4: TSCUL_Parse: CUL_KG  363627 A FF61 00602160 00 0E E4 8410 31CF9A 000000 0BA0BF0D40 -83
2016.12.09 18:15:58.351 4: TSCUL_Parse: CUL_KG  366089 A FF61 00604624 00 14 5A 845E 370A61 000000 80007900005B000908E9FE -85
2016.12.09 18:16:05.097 4: TSCUL_Parse: CUL_KG  372836 A FF51 00611368 00 0C D0 865A 271127 000000 B4D637 -50
2016.12.09 18:16:05.878 4: TSCUL_Parse: CUL_KG  373618 A FF51 00612152 00 0C AB 8470 31CF9A 000000 00BF40 -83
2016.12.09 18:16:06.797 4: TSCUL_Parse: CUL_KG  374537 A FF51 00612308 00 0C 0E 8470 2710FA 000000 00DD34 -32.5
2016.12.09 18:16:19.690 4: TSCUL_Parse: CUL_KG  387430 A FF51 00625964 00 0D 6B 8041 4DE828 2E517A 07CD0080 -69
2016.12.09 18:16:20.331 4: TSCUL_Parse: CUL_KG  388069 A FF52 00626596 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2016.12.09 18:16:25.097 4: TSCUL_Parse: CUL_KG  392836 A FF51 00631372 00 0C D0 8470 271127 000000 00D637 -49.5
2016.12.09 18:16:25.723 4: TSCUL_Parse: CUL_KG  393462 A FF51 00631996 00 14 81 845E 34264B 000000 80245100011A002108E4FE -67
2016.12.09 18:16:27.367 4: TSCUL_Parse: CUL_KG  395107 A FF51 00633640 00 0D 27 8041 4DE81E 2E517A 07D00080 -63
2016.12.09 18:16:30.864 4: TSCUL_Parse: CUL_KG  398603 A FF51 00637140 00 14 4E 845E 2B3660 000000 83A657000958009808E3FF -41.5
2016.12.09 18:16:33.137 4: TSCUL_Parse: CUL_KG  400876 A FF51 00639412 00 0D 6D 8410 24917F 219045 06012000 -41

Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 09 Dezember 2016, 22:08:15
Hallo Frank,

im Anhang mal HEX Filles mit 4, 6 und 9 HM Sendebuffern für nanoCUL, wenn Du testen möchtest. Ich bin gespannt.

ZitatMit verbose=4 erhalte ich folgenden Log (Was mich wundert ist, dass die AES-Fehler nicht mehr erscheinen):
Es ist auch kein Sendebefehl dabei. Er hat nur empfangen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bastel-Frank am 10 Dezember 2016, 10:39:49
Hallo Ansgar,

ich habe den CUL_V3.4. Könntest Du dafür die Firmware-Dateien bitte erstellen?

Frank
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 10 Dezember 2016, 11:34:39
Hallo Frank,

hier eine Firmware Version für CUL V3.4 mit 9 HM Buffern.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 10 Dezember 2016, 12:04:38
Hallo Mario,

ZitatWie könnte ich mein Problem umgehen, das eine ist ein Funkbewegungsmelder, das andere der 8 Kanalempfänger, sobald der eine eine Bewegung erkennt soll das Licht angehen. Eigentlich habe ich sowieso Wartezeiten von 30s im Bewegungsmelder. Trotzdem reagiert der 8 Kanal Empfänger zum Schalten der Lampen des öfteren nicht. Erreichbar ist er, sobald ich einen set Befehl direkt unter FHEM antriggere funktiioniert dieser immer, nur in Verbindung mit dem Funk Bewegungsmelder will er nicht. Kann es sein das zu viele Telegramme anstehen und diese Kollidieren?

In dem oberen Log sehe ich nur, dass der 353C4B auf Sendebefehle schön aufwacht und antwortet, wie es sein soll.
Der 383FB5 antwortet nicht. Von dem wurde in Deinem Log nichts empfangen. Umgekehrt kann das auch bedeuten, dass die Funksitutation für den miserabel ist, um den zu empfangen?

Das untere Log sagt mir in dem Zusammenhang gar nichts, außer das um 2016-12-05 16:26:23.918 () und 2016-12-05 16:26:28.358 die credits aufgebraucht sind und Dein nanoCUL erst mal eine Pause braucht um wieder Senden zu können. An CUL_HM Licht_Haustuer kann dann folglich nicht gesendet werden.

Wenn Du beim FHEM Start von jedem device den Konfiguration und Status abfragst, gehen die Credits erst mal runter. Dann direkt zu spielen/testen ist ungünstig.
Bei jedem device sollte das Attribut autoReadReg auf 5_readMissing stehen, damit nur die fehlenden gelesen werden. Das zusammen mit HM_Info und dort autoArchive.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bastel-Frank am 10 Dezember 2016, 20:22:12
Hallo Ansgar,

ich habe die 9 HM Buffer-Firmware seit 10 Minuten "am Laufen"  :D. Bisher nichts auffälliges zu beobachten. Warauf soll ich besonders achten?

Frank
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 10 Dezember 2016, 20:44:09
Hallo Frank,

ZitatWarauf soll ich besonders achten?
Unmotivierte TSCUL Neustarts oder sonstiges merkwürdiges Verhalten von TSCUL.

Du kannst außerdem das Atrribut hmLanQlen vom default 1_min auf 4_high stellen und schauen wie es mit Resends oder Resend Fail ausschaut, die nicht mit credits Mangel zusammen hängen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bastel-Frank am 11 Dezember 2016, 10:45:54
Hallo Ansgar,

anbei der Log der letzten Stunden. Zur Erläuterung: Ich habe zwei CULs V3.4 (CUL_EG und CUL_KG). Für CUL_KG habe ich verbose=4 einstellt, das dort immer die AES-Fehler kamen. Jetzt sind im Log auch anscheinend AES-Sende-Kommandos mit drin. Für beide CULs habe ich die Firmware mit den 9 HM Puffern installiert.

Viele Grüße
Frank
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 11 Dezember 2016, 13:49:45
Hallo Frank,

da Du AES nicht nutzt, sind das ausschließlich fehlgeschlagene Sende-Wiederholversuche, bei denen das device nicht antwortet.

52D24A kann von CUL_EG nicht (immer) erreicht werden. CUL_EG steht nicht auf verbose 4, von daher Glaskugel.  ;) Aber CUL_KG empfängt von dem, wenn auch sehr schwach mit -100 dB.

341CED kann von CUL_KG nicht (immer) erreicht werden. Schlechte Empfangslage? Empfang vom device im Log nicht zu sehen.
254AE9 kann von CUL_KG nicht (immer) erreicht werden. Schlechte Empfangslage? Empfang vom device im Log nicht zu sehen.
35994A kann von CUL_KG nicht (immer) erreicht werden. Schlechte Empfangslage? Empfang vom device im Log nicht zu sehen.

Tote devices? Nicht angelernt? ...

Überlässt Du der VCCU die Wahl des IO devices oder hast Du es händisch per Attribut beim device erzwungen?


Was Du (und Mario und andere) noch versuchen kannst bezüglich Empfangsoptimierung:

get ccconf  an CUL im HM Modus -> Ausgabe sichern (wennd Du wieder zurück willst  ;) )
am Ende steht freq_offs:xxx.xxxkHz, das ist der Sende-/Empfangsfrequenz Offset

Ich habe bei mir als guten Offset freq_offs:-22.217kHz gefunden.

Den Wert kannst Du mit set raw e  durch EEPROM Rücksetzen einstellen. Oder auch mit  set hmFreqOffs  individuell.

Die Optimierung ist allerding ein mühsames Geschäft, da nur durch schrittweise Änderung und Beobachtung der RSSI Werte aller Geräte zu optimieren.
Mit einem Spectrum Analyser geht es flotter, dennoch muss die Mitte zwischen allen devices gefunden werden.


Ansonsten optimale Positionssuche für CUL und Antennenoptimierung.

Die Firmware scheint prima zu laufen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 12 Dezember 2016, 15:02:18
Hallo Testwillige,

es gibt hier https://forum.fhem.de/index.php/topic,24436.msg529649.html#msg529649 (https://forum.fhem.de/index.php/topic,24436.msg529649.html#msg529649) an gewohnter Stelle wieder ein Update.

Die Firmware ist auf VTS 0.04 geändert und 00_TSCUL.pm hat dazu eine Aktualisierung erfahren.
Ich habe das CCA (Clear Channel Assessment) Verhalten geändert. Vor jedem Umschalten auf Senden wird nun 4ms geprüft, ob der Kanal frei ist.

Der Gedanke dazu ist, nicht am Ende einer andersartigen Fremdtransmission direkt zu senden und damit andere Protokolle ab und zu zu stören (SlowRF ist z.B. auf eine bestimmte Zeit Funkstille angeweisen, um das Ende einer Transmission zu erkennen). Der Unterschied dürfte aber nicht drastisch auffallen.  Höchstens in einer gestörten Umgebung, so dass immer ein belegter Kanal erkannt wird. ;)

Ich habe auch das "factory-reset" bei Versionsänderung der Firmware aktiviert. D.h. vor dem Firmware Update ggf. an CUL getätige Einstellungen sichern, um sie nachher wieder einstellen zu können.

Gruß, Ansgar.

EDIT: Eine kleine Änderung habe ich noch nachgeschoben, um Repeat fail besser von AES Athentification error unterscheiden zu können (Firmware + 00_TSCUL.pm)
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bastel-Frank am 12 Dezember 2016, 21:02:00
Zitat von: noansi am 11 Dezember 2016, 13:49:45
Tote devices? Nicht angelernt? ...
Überlässt Du der VCCU die Wahl des IO devices oder hast Du es händisch per Attribut beim device erzwungen?

Vielen Dank für die Hinweise auf die Devices. Es sind tatsächlich meine Test-Devices, die nicht immer zur Verfügung stehen. Besteht eine Möglichkeit, nur diese Meldungen zur unterdrücken?

Ich überlasse der VCCU die Wahl des IO-Devices.

Die Firmware läuft sehr sehr gut  :). Vielen Dank nochmal für deinen tollen Einsatz. Ich habe schon viel Zeit mit Devices verplempert, die ein Kommunikationsproblem hatten. Dank deiner Firmware ist dies nun Geschichte.

Frank
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 12 Dezember 2016, 22:21:27
Hallo Frank,

ZitatVielen Dank für die Hinweise auf die Devices. Es sind tatsächlich meine Test-Devices, die nicht immer zur Verfügung stehen. Besteht eine Möglichkeit, nur diese Meldungen zur unterdrücken?
Ich habe diesen Meldungen extra den Log Level 1 gegeben, damit ich das mitbekomme, auch als Feedback! Daher werde ich das erst ändern, wenn ich zu der Überzeugung gekommen bin, dass die Logeinträge nicht mehr so wichtig sind. Ich möchte im Normalbetrieb möglicht gar keine davon sehen, wenn alle device normal funktionieren. (Aber ist halt Funk...)

Variante 1: Du lässt die Testdevices an. Erweitert den Testraum. ;)

Variante 2: Du stellst den LogLevel für TSCUL auf 0. Nur kommen dann keine Logeinträge mehr von TSCUL.

Variante 3: Du kannst den 00_TSCUL.pm Code editieren. In Zeile 917 der neuesten Version findest Du:
      Log3 ${$pname}, 1, $loge;
Aus der 1 kannst Du z.B. eine 2 machen, wenn Du diese Meldung erst ab Loglevel 2 sehen willst. Das gilt dann natürlich für jeden dieser Log Einträge, auch zu "wichtigen" devices.

Variante 4: Kenne ich noch nicht, aber vielleicht jemand anderes. FHEM ist immer für ein Überraschung gut.

ZitatVielen Dank nochmal für deinen tollen Einsatz.
Vergiss Martin und Rudolf und die vielen andere Entwickler nicht. Ohne super FHEM Grundlage und super CUL_HM nutzt die beste Firmware nichts. ;)

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Maxl am 13 Dezember 2016, 18:31:55
Hallo Ansgar,

habe ein Problem mit der V3, das Licht schaltet sich aus und ein und aus,... siehe das Log-File.
Der CUL brigtr auch eine Menge Fehler mit OVERLOAD und HIGHLOAD. Erst nach einem Serverneustart
ging alles wieder wie gehabt. Habe ich etwas falsch konfiguriert?

2016-12-13 18:23:17.303 ECMDDevice Relais9 off: ok
2016-12-13 18:23:17.303 ECMDDevice Relais9 off ok
2016-12-13 18:23:17.311 dummy Test off
2016-12-13 18:23:17.313 dummy Test2 toggle
2016-12-13 18:23:17.322 at Test3 Next: 18:23:27
2016-12-13 18:23:26.444 TSCUL nanoCUL cond: Warning-HighLoad
2016-12-13 18:23:26.487 CUL_HM CUL_HM_HM_CC_RT_DN_3549DE actuator: 0
2016-12-13 18:23:26.487 CUL_HM CUL_HM_HM_CC_RT_DN_3549DE battery: ok
2016-12-13 18:23:26.487 CUL_HM CUL_HM_HM_CC_RT_DN_3549DE batteryLevel: 2.5
2016-12-13 18:23:26.487 CUL_HM CUL_HM_HM_CC_RT_DN_3549DE desired-temp: 18.0
2016-12-13 18:23:26.487 CUL_HM CUL_HM_HM_CC_RT_DN_3549DE measured-temp: 21.1
2016-12-13 18:23:26.487 CUL_HM CUL_HM_HM_CC_RT_DN_3549DE motorErr: ok
2016-12-13 18:23:26.498 CUL_HM CUL_HM_HM_CC_RT_DN_3549DE_Weather measured-temp: 21.1
2016-12-13 18:23:26.498 CUL_HM CUL_HM_HM_CC_RT_DN_3549DE_Weather 21.1
2016-12-13 18:23:26.522 CUL_HM Thermostat_Zimmer_Korbinian_Clima ValvePosition: 0
2016-12-13 18:23:26.522 CUL_HM Thermostat_Zimmer_Korbinian_Clima boostTime: -
2016-12-13 18:23:26.522 CUL_HM Thermostat_Zimmer_Korbinian_Clima controlMode: manual
2016-12-13 18:23:26.522 CUL_HM Thermostat_Zimmer_Korbinian_Clima desired-temp: 18.0
2016-12-13 18:23:26.522 CUL_HM Thermostat_Zimmer_Korbinian_Clima measured-temp: 21.1
2016-12-13 18:23:26.522 CUL_HM Thermostat_Zimmer_Korbinian_Clima partyEnd: -
2016-12-13 18:23:26.522 CUL_HM Thermostat_Zimmer_Korbinian_Clima partyStart: -
2016-12-13 18:23:26.522 CUL_HM Thermostat_Zimmer_Korbinian_Clima partyTemp: -
2016-12-13 18:23:26.522 CUL_HM Thermostat_Zimmer_Korbinian_Clima T: 21.1 desired: 18.0 valve: 0
2016-12-13 18:23:27.017 TSCUL nanoCUL cond: ERROR-Overload
2016-12-13 18:23:27.310 ECMDDevice Relais9 on: ok
2016-12-13 18:23:27.310 ECMDDevice Relais9 on ok
2016-12-13 18:23:27.327 dummy Test on
2016-12-13 18:23:27.329 dummy Test2 toggle
2016-12-13 18:23:27.340 at Test3 Next: 18:23:37
2016-12-13 18:23:27.353 HM485 HMW_IO_12_Sw14_DR_LEQ1322965_01 set_off
2016-12-13 18:23:27.406 HM485 HMW_IO_12_Sw14_DR_LEQ1322965 ACK
2016-12-13 18:23:27.417 HM485 HMW_IO_12_Sw14_DR_LEQ1322965_01 off
2016-12-13 18:23:32.261 at checkNETIO1 Next: 18:23:57
2016-12-13 18:23:32.274 at checkNETIO2 Next: 18:23:57
2016-12-13 18:23:37.051 TSCUL nanoCUL cond: Warning-HighLoad
2016-12-13 18:23:37.094 CUL_HM CUL_HM_HM_CC_RT_DN_3547BA actuator: 0
2016-12-13 18:23:37.094 CUL_HM CUL_HM_HM_CC_RT_DN_3547BA battery: ok
2016-12-13 18:23:37.094 CUL_HM CUL_HM_HM_CC_RT_DN_3547BA batteryLevel: 2.5
2016-12-13 18:23:37.094 CUL_HM CUL_HM_HM_CC_RT_DN_3547BA desired-temp: 18.0
2016-12-13 18:23:37.094 CUL_HM CUL_HM_HM_CC_RT_DN_3547BA measured-temp: 20.7
2016-12-13 18:23:37.094 CUL_HM CUL_HM_HM_CC_RT_DN_3547BA motorErr: ok
2016-12-13 18:23:37.106 CUL_HM CUL_HM_HM_CC_RT_DN_3547BA_Weather measured-temp: 20.7
2016-12-13 18:23:37.106 CUL_HM CUL_HM_HM_CC_RT_DN_3547BA_Weather 20.7
2016-12-13 18:23:37.129 CUL_HM Thermostat_Zimmer_Haushalt_Clima ValvePosition: 0
2016-12-13 18:23:37.129 CUL_HM Thermostat_Zimmer_Haushalt_Clima boostTime: -
2016-12-13 18:23:37.129 CUL_HM Thermostat_Zimmer_Haushalt_Clima controlMode: manual
2016-12-13 18:23:37.129 CUL_HM Thermostat_Zimmer_Haushalt_Clima desired-temp: 18.0
2016-12-13 18:23:37.129 CUL_HM Thermostat_Zimmer_Haushalt_Clima measured-temp: 20.7
2016-12-13 18:23:37.129 CUL_HM Thermostat_Zimmer_Haushalt_Clima partyEnd: -
2016-12-13 18:23:37.129 CUL_HM Thermostat_Zimmer_Haushalt_Clima partyStart: -
2016-12-13 18:23:37.129 CUL_HM Thermostat_Zimmer_Haushalt_Clima partyTemp: -
2016-12-13 18:23:37.129 CUL_HM Thermostat_Zimmer_Haushalt_Clima T: 20.7 desired: 18.0 valve: 0
2016-12-13 18:23:37.310 ECMDDevice Relais9 off: ok
2016-12-13 18:23:37.310 ECMDDevice Relais9 off ok
2016-12-13 18:23:37.319 dummy Test off
2016-12-13 18:23:37.321 dummy Test2 toggle
2016-12-13 18:23:37.333 at Test3 Next: 18:23:47
2016-12-13 18:23:37.623 TSCUL nanoCUL cond: ERROR-Overload
2016-12-13 18:23:37.837 TSCUL nanoCUL cond: Warning-HighLoad
2016-12-13 18:23:39.636 CUL_HM CUL_HM_HM_CC_RT_DN_3547BB actuator: 46
2016-12-13 18:23:39.636 CUL_HM CUL_HM_HM_CC_RT_DN_3547BB battery: ok
2016-12-13 18:23:39.636 CUL_HM CUL_HM_HM_CC_RT_DN_3547BB batteryLevel: 2.4
2016-12-13 18:23:39.636 CUL_HM CUL_HM_HM_CC_RT_DN_3547BB desired-temp: 21.0
2016-12-13 18:23:39.636 CUL_HM CUL_HM_HM_CC_RT_DN_3547BB measured-temp: 22.9
2016-12-13 18:23:39.636 CUL_HM CUL_HM_HM_CC_RT_DN_3547BB motorErr: ok
2016-12-13 18:23:39.647 CUL_HM CUL_HM_HM_CC_RT_DN_3547BB_Weather measured-temp: 22.9
2016-12-13 18:23:39.647 CUL_HM CUL_HM_HM_CC_RT_DN_3547BB_Weather 22.9
2016-12-13 18:23:39.669 CUL_HM Thermostat_Zimmer_Bad_Clima ValvePosition: 46
2016-12-13 18:23:39.669 CUL_HM Thermostat_Zimmer_Bad_Clima boostTime: -
2016-12-13 18:23:39.669 CUL_HM Thermostat_Zimmer_Bad_Clima controlMode: manual
2016-12-13 18:23:39.669 CUL_HM Thermostat_Zimmer_Bad_Clima desired-temp: 21.0
2016-12-13 18:23:39.669 CUL_HM Thermostat_Zimmer_Bad_Clima measured-temp: 22.9
2016-12-13 18:23:39.669 CUL_HM Thermostat_Zimmer_Bad_Clima partyEnd: -
2016-12-13 18:23:39.669 CUL_HM Thermostat_Zimmer_Bad_Clima partyStart: -
2016-12-13 18:23:39.669 CUL_HM Thermostat_Zimmer_Bad_Clima partyTemp: -
2016-12-13 18:23:39.669 CUL_HM Thermostat_Zimmer_Bad_Clima T: 22.9 desired: 21.0 valve: 46
2016-12-13 18:23:41.284 TSCUL nanoCUL cond: ERROR-Overload
2016-12-13 18:23:41.427 CUL_HM Licht_Garten deviceMsg: on (to nanoCUL)
2016-12-13 18:23:41.427 CUL_HM Licht_Garten level: 100
2016-12-13 18:23:41.427 CUL_HM Licht_Garten pct: 100
2016-12-13 18:23:41.427 CUL_HM Licht_Garten on
2016-12-13 18:23:41.427 CUL_HM Licht_Garten timedOn: running
2016-12-13 18:23:47.308 ECMDDevice Relais9 on: ok
2016-12-13 18:23:47.308 ECMDDevice Relais9 on ok
2016-12-13 18:23:47.325 dummy Test on
2016-12-13 18:23:47.327 dummy Test2 toggle
2016-12-13 18:23:47.338 at Test3 Next: 18:23:57
2016-12-13 18:23:47.370 at mycall Next: 18:25:17
2016-12-13 18:23:47.380 HM485 HMW_IO_12_Sw14_DR_LEQ1322965_01 set_on
2016-12-13 18:23:47.436 HM485 HMW_IO_12_Sw14_DR_LEQ1322965 ACK
2016-12-13 18:23:47.447 HM485 HMW_IO_12_Sw14_DR_LEQ1322965_01 on
2016-12-13 18:23:54.395 CUL_HM CUL_HM_HM_CC_RT_DN_3547B5 actuator: 0
2016-12-13 18:23:54.395 CUL_HM CUL_HM_HM_CC_RT_DN_3547B5 battery: ok
2016-12-13 18:23:54.395 CUL_HM CUL_HM_HM_CC_RT_DN_3547B5 batteryLevel: 2.5
2016-12-13 18:23:54.395 CUL_HM CUL_HM_HM_CC_RT_DN_3547B5 desired-temp: off
2016-12-13 18:23:54.395 CUL_HM CUL_HM_HM_CC_RT_DN_3547B5 measured-temp: 20.3
2016-12-13 18:23:54.395 CUL_HM CUL_HM_HM_CC_RT_DN_3547B5 motorErr: ok
2016-12-13 18:23:54.407 CUL_HM CUL_HM_HM_CC_RT_DN_3547B5_Weather measured-temp: 20.3
2016-12-13 18:23:54.407 CUL_HM CUL_HM_HM_CC_RT_DN_3547B5_Weather 20.3
2016-12-13 18:23:54.427 CUL_HM Thermostat_Kilian_Clima ValvePosition: 0
2016-12-13 18:23:54.427 CUL_HM Thermostat_Kilian_Clima boostTime: -
2016-12-13 18:23:54.427 CUL_HM Thermostat_Kilian_Clima controlMode: manual
2016-12-13 18:23:54.427 CUL_HM Thermostat_Kilian_Clima desired-temp: off
2016-12-13 18:23:54.427 CUL_HM Thermostat_Kilian_Clima measured-temp: 20.3
2016-12-13 18:23:54.427 CUL_HM Thermostat_Kilian_Clima partyEnd: -
2016-12-13 18:23:54.427 CUL_HM Thermostat_Kilian_Clima partyStart: -
2016-12-13 18:23:54.427 CUL_HM Thermostat_Kilian_Clima partyTemp: -
2016-12-13 18:23:54.427 CUL_HM Thermostat_Kilian_Clima T: 20.3 desired: off valve: 0
2016-12-13 18:23:55.962 CUL_HM CUL_HM_HM_CC_RT_DN_354555 actuator: 0
2016-12-13 18:23:55.962 CUL_HM CUL_HM_HM_CC_RT_DN_354555 battery: ok
2016-12-13 18:23:55.962 CUL_HM CUL_HM_HM_CC_RT_DN_354555 batteryLevel: 2.5
2016-12-13 18:23:55.962 CUL_HM CUL_HM_HM_CC_RT_DN_354555 desired-temp: 5.0
2016-12-13 18:23:55.962 CUL_HM CUL_HM_HM_CC_RT_DN_354555 measured-temp: 16.6
2016-12-13 18:23:55.962 CUL_HM CUL_HM_HM_CC_RT_DN_354555 motorErr: ok
2016-12-13 18:23:55.974 CUL_HM CUL_HM_HM_CC_RT_DN_354555_Weather measured-temp: 16.6
2016-12-13 18:23:55.974 CUL_HM CUL_HM_HM_CC_RT_DN_354555_Weather 16.6
2016-12-13 18:23:55.996 CUL_HM Thermostat_Zimmer_Schlafen_Clima ValvePosition: 0
2016-12-13 18:23:55.996 CUL_HM Thermostat_Zimmer_Schlafen_Clima boostTime: -
2016-12-13 18:23:55.996 CUL_HM Thermostat_Zimmer_Schlafen_Clima controlMode: manual
2016-12-13 18:23:55.996 CUL_HM Thermostat_Zimmer_Schlafen_Clima desired-temp: 5.0
2016-12-13 18:23:55.996 CUL_HM Thermostat_Zimmer_Schlafen_Clima measured-temp: 16.6
2016-12-13 18:23:55.996 CUL_HM Thermostat_Zimmer_Schlafen_Clima partyEnd: -
2016-12-13 18:23:55.996 CUL_HM Thermostat_Zimmer_Schlafen_Clima partyStart: -
2016-12-13 18:23:55.996 CUL_HM Thermostat_Zimmer_Schlafen_Clima partyTemp: -
2016-12-13 18:23:55.996 CUL_HM Thermostat_Zimmer_Schlafen_Clima T: 16.6 desired: 5.0 valve: 0
2016-12-13 18:23:57.265 at checkNETIO1 Next: 18:24:22
2016-12-13 18:23:57.280 at checkNETIO2 Next: 18:24:22
2016-12-13 18:23:57.329 ECMDDevice Relais9 off: ok
2016-12-13 18:23:57.329 ECMDDevice Relais9 off ok
2016-12-13 18:23:57.338 dummy Test off
2016-12-13 18:23:57.340 dummy Test2 toggle
2016-12-13 18:23:57.351 at Test3 Next: 18:24:07
2016-12-13 18:24:07.310 ECMDDevice Relais9 on: ok
2016-12-13 18:24:07.310 ECMDDevice Relais9 on ok
2016-12-13 18:24:07.327 dummy Test on
2016-12-13 18:24:07.329 dummy Test2 toggle
2016-12-13 18:24:07.340 at Test3 Next: 18:24:17
2016-12-13 18:24:07.353 HM485 HMW_IO_12_Sw14_DR_LEQ1322965_01 set_off
2016-12-13 18:24:07.410 HM485 HMW_IO_12_Sw14_DR_LEQ1322965 ACK
2016-12-13 18:24:07.421 HM485 HMW_IO_12_Sw14_DR_LEQ1322965_01 off
2016-12-13 18:24:17.309 ECMDDevice Relais9 off: ok
2016-12-13 18:24:17.309 ECMDDevice Relais9 off ok
2016-12-13 18:24:17.319 dummy Test off
2016-12-13 18:24:17.320 dummy Test2 toggle
2016-12-13 18:24:17.331 at Test3 Next: 18:24:27
2016-12-13 18:24:22.265 at checkNETIO1 Next: 18:24:47
2016-12-13 18:24:22.280 at checkNETIO2 Next: 18:24:47
2016-12-13 18:24:27.311 ECMDDevice Relais9 on: ok
2016-12-13 18:24:27.311 ECMDDevice Relais9 on ok
2016-12-13 18:24:27.328 dummy Test on
2016-12-13 18:24:27.330 dummy Test2 toggle
2016-12-13 18:24:27.341 at Test3 Next: 18:24:37
2016-12-13 18:24:27.353 HM485 HMW_IO_12_Sw14_DR_LEQ1322965_01 set_on
2016-12-13 18:24:27.405 HM485 HMW_IO_12_Sw14_DR_LEQ1322965 ACK
2016-12-13 18:24:27.415 HM485 HMW_IO_12_Sw14_DR_LEQ1322965_01 on
2016-12-13 18:24:28.297 TSCUL nanoCUL cond: Warning-HighLoad
2016-12-13 18:24:28.337 CUL_HM Licht_Garten deviceMsg: off (to nanoCUL)
2016-12-13 18:24:28.337 CUL_HM Licht_Garten level: 0
2016-12-13 18:24:28.337 CUL_HM Licht_Garten pct: 0
2016-12-13 18:24:28.337 CUL_HM Licht_Garten off
2016-12-13 18:24:28.337 CUL_HM Licht_Garten timedOn: off
2016-12-13 18:24:28.439 TSCUL nanoCUL cond: ERROR-Overload
2016-12-13 18:24:28.528 TSCUL nanoCUL cond: Warning-HighLoad
2016-12-13 18:24:28.683 CUL_HM Licht_Garten deviceMsg: on (to nanoCUL)
2016-12-13 18:24:28.683 CUL_HM Licht_Garten level: 100
2016-12-13 18:24:28.683 CUL_HM Licht_Garten pct: 100
2016-12-13 18:24:28.683 CUL_HM Licht_Garten on
2016-12-13 18:24:28.683 CUL_HM Licht_Garten timedOn: running
2016-12-13 18:24:28.959 CUL_HM Licht_Garten deviceMsg: on (to nanoCUL)
2016-12-13 18:24:28.959 CUL_HM Licht_Garten level: 100
2016-12-13 18:24:28.959 CUL_HM Licht_Garten pct: 100
2016-12-13 18:24:28.959 CUL_HM Licht_Garten on
2016-12-13 18:24:28.959 CUL_HM Licht_Garten timedOn: running
2016-12-13 18:24:29.235 CUL_HM Licht_Garten deviceMsg: on (to nanoCUL)
2016-12-13 18:24:29.235 CUL_HM Licht_Garten level: 100
2016-12-13 18:24:29.235 CUL_HM Licht_Garten pct: 100
2016-12-13 18:24:29.235 CUL_HM Licht_Garten on
2016-12-13 18:24:29.235 CUL_HM Licht_Garten timedOn: running
2016-12-13 18:24:29.511 CUL_HM Licht_Garten deviceMsg: on (to nanoCUL)
2016-12-13 18:24:29.511 CUL_HM Licht_Garten level: 100
2016-12-13 18:24:29.511 CUL_HM Licht_Garten pct: 100
2016-12-13 18:24:29.511 CUL_HM Licht_Garten on
2016-12-13 18:24:29.511 CUL_HM Licht_Garten timedOn: running
2016-12-13 18:24:29.631 TSCUL nanoCUL cond: ERROR-Overload
2016-12-13 18:24:29.774 CUL_HM Licht_Garten deviceMsg: on (to nanoCUL)
2016-12-13 18:24:29.774 CUL_HM Licht_Garten level: 100
2016-12-13 18:24:29.774 CUL_HM Licht_Garten pct: 100
2016-12-13 18:24:29.774 CUL_HM Licht_Garten on
2016-12-13 18:24:29.774 CUL_HM Licht_Garten timedOn: running
2016-12-13 18:24:36.233 TSCUL nanoCUL cond: Warning-HighLoad
2016-12-13 18:24:36.276 CUL_HM CUL_HM_HM_CC_RT_DN_3547BF actuator: 34
2016-12-13 18:24:36.276 CUL_HM CUL_HM_HM_CC_RT_DN_3547BF battery: ok
2016-12-13 18:24:36.276 CUL_HM CUL_HM_HM_CC_RT_DN_3547BF batteryLevel: 2.5
2016-12-13 18:24:36.276 CUL_HM CUL_HM_HM_CC_RT_DN_3547BF desired-temp: 19.5
2016-12-13 18:24:36.276 CUL_HM CUL_HM_HM_CC_RT_DN_3547BF measured-temp: 21.4
2016-12-13 18:24:36.276 CUL_HM CUL_HM_HM_CC_RT_DN_3547BF motorErr: ok
2016-12-13 18:24:36.288 CUL_HM CUL_HM_HM_CC_RT_DN_3547BF_Weather measured-temp: 21.4
2016-12-13 18:24:36.288 CUL_HM CUL_HM_HM_CC_RT_DN_3547BF_Weather 21.4
2016-12-13 18:24:36.310 CUL_HM Thermostat_Zimmer_Buero_Clima ValvePosition: 34
2016-12-13 18:24:36.310 CUL_HM Thermostat_Zimmer_Buero_Clima boostTime: -
2016-12-13 18:24:36.310 CUL_HM Thermostat_Zimmer_Buero_Clima controlMode: manual
2016-12-13 18:24:36.310 CUL_HM Thermostat_Zimmer_Buero_Clima desired-temp: 19.5
2016-12-13 18:24:36.310 CUL_HM Thermostat_Zimmer_Buero_Clima measured-temp: 21.4
2016-12-13 18:24:36.310 CUL_HM Thermostat_Zimmer_Buero_Clima partyEnd: -
2016-12-13 18:24:36.310 CUL_HM Thermostat_Zimmer_Buero_Clima partyStart: -
2016-12-13 18:24:36.310 CUL_HM Thermostat_Zimmer_Buero_Clima partyTemp: -
2016-12-13 18:24:36.310 CUL_HM Thermostat_Zimmer_Buero_Clima T: 21.4 desired: 19.5 valve: 34
2016-12-13 18:24:36.564 TSCUL nanoCUL cond: ERROR-Overload
2016-12-13 18:24:37.309 ECMDDevice Relais9 off: ok
2016-12-13 18:24:37.309 ECMDDevice Relais9 off ok
2016-12-13 18:24:37.319 dummy Test off
2016-12-13 18:24:37.320 dummy Test2 toggle
2016-12-13 18:24:37.332 at Test3 Next: 18:24:47
2016-12-13 18:24:47.265 at checkNETIO1 Next: 18:25:12
2016-12-13 18:24:47.280 at checkNETIO2 Next: 18:25:12
2016-12-13 18:24:47.327 ECMDDevice Relais9 on: ok
2016-12-13 18:24:47.327 ECMDDevice Relais9 on ok
2016-12-13 18:24:47.344 dummy Test on
2016-12-13 18:24:47.346 dummy Test2 toggle
2016-12-13 18:24:47.357 at Test3 Next: 18:24:57
2016-12-13 18:24:47.369 HM485 HMW_IO_12_Sw14_DR_LEQ1322965_01 set_off
2016-12-13 18:24:47.427 HM485 HMW_IO_12_Sw14_DR_LEQ1322965 ACK
2016-12-13 18:24:47.439 HM485 HMW_IO_12_Sw14_DR_LEQ1322965_01 off
2016-12-13 18:24:48.077 TSCUL nanoCUL cond: Warning-HighLoad
2016-12-13 18:24:48.120 CUL_HM CUL_HM_HM_CC_RT_DN_3549DB actuator: 0
2016-12-13 18:24:48.120 CUL_HM CUL_HM_HM_CC_RT_DN_3549DB battery: ok
2016-12-13 18:24:48.120 CUL_HM CUL_HM_HM_CC_RT_DN_3549DB batteryLevel: 2.5
2016-12-13 18:24:48.120 CUL_HM CUL_HM_HM_CC_RT_DN_3549DB desired-temp: off
2016-12-13 18:24:48.120 CUL_HM CUL_HM_HM_CC_RT_DN_3549DB measured-temp: 20.3
2016-12-13 18:24:48.120 CUL_HM CUL_HM_HM_CC_RT_DN_3549DB motorErr: ok
2016-12-13 18:24:48.131 CUL_HM CUL_HM_HM_CC_RT_DN_3549DB_Weather measured-temp: 20.3
2016-12-13 18:24:48.131 CUL_HM CUL_HM_HM_CC_RT_DN_3549DB_Weather 20.3
2016-12-13 18:24:48.155 CUL_HM Thermostat_Zimmer_Sebastian_Clima ValvePosition: 0
2016-12-13 18:24:48.155 CUL_HM Thermostat_Zimmer_Sebastian_Clima boostTime: -
2016-12-13 18:24:48.155 CUL_HM Thermostat_Zimmer_Sebastian_Clima controlMode: manual
2016-12-13 18:24:48.155 CUL_HM Thermostat_Zimmer_Sebastian_Clima desired-temp: off
2016-12-13 18:24:48.155 CUL_HM Thermostat_Zimmer_Sebastian_Clima measured-temp: 20.3
2016-12-13 18:24:48.155 CUL_HM Thermostat_Zimmer_Sebastian_Clima partyEnd: -
2016-12-13 18:24:48.155 CUL_HM Thermostat_Zimmer_Sebastian_Clima partyStart: -
2016-12-13 18:24:48.155 CUL_HM Thermostat_Zimmer_Sebastian_Clima partyTemp: -
2016-12-13 18:24:48.155 CUL_HM Thermostat_Zimmer_Sebastian_Clima T: 20.3 desired: off valve: 0
2016-12-13 18:24:51.691 TSCUL nanoCUL cond: ERROR-Overload
2016-12-13 18:24:51.833 CUL_HM Licht_Garten deviceMsg: on (to nanoCUL)
2016-12-13 18:24:51.833 CUL_HM Licht_Garten level: 100
2016-12-13 18:24:51.833 CUL_HM Licht_Garten pct: 100
2016-12-13 18:24:51.833 CUL_HM Licht_Garten on
2016-12-13 18:24:51.833 CUL_HM Licht_Garten timedOn: running
2016-12-13 18:24:57.305 ECMDDevice Relais9 off: ok
2016-12-13 18:24:57.305 ECMDDevice Relais9 off ok
2016-12-13 18:24:57.314 dummy Test off
2016-12-13 18:24:57.316 dummy Test2 toggle
2016-12-13 18:24:57.328 at Test3 Next: 18:25:07


hier das Log File nachdem Neustart:
2016-12-13 18:35:36.502 CUL_HM Thermostat_Zimmer_Korbinian_Clima measured-temp: 20.7
2016-12-13 18:35:36.502 CUL_HM Thermostat_Zimmer_Korbinian_Clima partyEnd: -
2016-12-13 18:35:36.502 CUL_HM Thermostat_Zimmer_Korbinian_Clima partyStart: -
2016-12-13 18:35:36.502 CUL_HM Thermostat_Zimmer_Korbinian_Clima partyTemp: -
2016-12-13 18:35:36.502 CUL_HM Thermostat_Zimmer_Korbinian_Clima T: 20.7 desired: 18.0 valve: 0
2016-12-13 18:35:36.976 CUL_HM HM_381468 battery: ok
2016-12-13 18:35:36.976 CUL_HM HM_381468 CMDs_done
2016-12-13 18:35:36.976 CUL_HM HM_381468 Schalter_Keller Short
2016-12-13 18:35:36.990 CUL_HM CUL_HM_HM_MOD_Re_8_353C4B CMDs_pending
2016-12-13 18:35:37.000 CUL_HM Licht_Garten set_on-for-timer 40
2016-12-13 18:35:37.027 CUL_HM Schalter_Keller Short (to nanoCUL)
2016-12-13 18:35:37.027 CUL_HM Schalter_Keller trigDst_F11234: noConfig
2016-12-13 18:35:37.027 CUL_HM Schalter_Keller trigger: Short_61
2016-12-13 18:35:37.027 CUL_HM Schalter_Keller trigger_cnt: 61
2016-12-13 18:35:37.095 TSCUL nanoCUL cond: ERROR-Overload
2016-12-13 18:35:37.517 TSCUL nanoCUL cond: ok
2016-12-13 18:35:37.657 CUL_HM CUL_HM_HM_MOD_Re_8_353C4B CMDs_done
2016-12-13 18:35:37.669 CUL_HM Licht_Garten deviceMsg: on (to nanoCUL)
2016-12-13 18:35:37.669 CUL_HM Licht_Garten level: 100
2016-12-13 18:35:37.669 CUL_HM Licht_Garten pct: 100
2016-12-13 18:35:37.669 CUL_HM Licht_Garten on
2016-12-13 18:35:37.669 CUL_HM Licht_Garten timedOn: running
2016-12-13 18:35:38.266 CUL_HM HM_381468 battery: ok
2016-12-13 18:35:38.266 CUL_HM HM_381468 CMDs_done
2016-12-13 18:35:38.266 CUL_HM HM_381468 Schalter_Keller Short
2016-12-13 18:35:38.280 CUL_HM CUL_HM_HM_MOD_Re_8_353C4B CMDs_pending
2016-12-13 18:35:38.290 CUL_HM Licht_Garten set_on-for-timer 40
2016-12-13 18:35:38.318 CUL_HM Schalter_Keller Short (to nanoCUL)
2016-12-13 18:35:38.318 CUL_HM Schalter_Keller trigDst_F11234: noConfig
2016-12-13 18:35:38.318 CUL_HM Schalter_Keller trigger: Short_62
2016-12-13 18:35:38.318 CUL_HM Schalter_Keller trigger_cnt: 62
2016-12-13 18:35:38.387 TSCUL nanoCUL cond: ERROR-Overload
2016-12-13 18:35:38.809 TSCUL nanoCUL cond: ok
2016-12-13 18:35:38.948 CUL_HM CUL_HM_HM_MOD_Re_8_353C4B CMDs_done
2016-12-13 18:35:38.961 CUL_HM Licht_Garten deviceMsg: on (to nanoCUL)
2016-12-13 18:35:38.961 CUL_HM Licht_Garten level: 100
2016-12-13 18:35:38.961 CUL_HM Licht_Garten pct: 100
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 13 Dezember 2016, 19:25:34
Ob etwas falsch konfiguriert ist kann ich (so) nicht sagen...
Aber mal ein paar Tips/Schlagworte:

attr <DeviceName> event-on-change-reading richtig (und ausreichend) gesetzt!? -> Eindämmen von (unnützer) Event-Flut...

Dann sind einige Test-Dummys, Timer und sicher auch notifies definiert...

Man müsste jetzt mal wissen welches von den vielen Dingen denn das Licht ist welches immer ein/aus geht...

Dann mal ein list/DEF der zugehörigen notifys etc.

Ein Toggle beispielsweise kann, wenn das entsprechende notify schlecht "formuliert" ist schon mal öfter als gewollt toggeln...

Es gibt also viele Ursachen für Licht ein/aus...

Overload ist aber mit sicherheit nicht gut!

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 13 Dezember 2016, 19:39:58
Hallo Mario,

welche Version der Firmware hast Du jetzt drauf und welche Module setzt Du jetzt ein? Die neuesten solltest Du nehmen.

2016-12-13 18:35:37.095 TSCUL nanoCUL cond: ERROR-Overload
2016-12-13 18:35:37.517 TSCUL nanoCUL cond: ok

Das deutet darauf hin, dass Du eine ältere Version mit wenigen Puffern nutzt und das Attribut hmLanQlen nicht entsprechend niedrig eingestellt hast. Das gibt auch ERROR-Overload, wenn kein Sendepuffer mehr frei ist.
Denn so schnell sollte ok nach ERROR-Overload wegen credits nicht wieder auftauchen. Oder nanoCUL startet neu wegen Stackoverflow.
Bitte logge auch mal mit verbose 4 bei nanoCUL. Und mal ein List von nanoCUL.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Maxl am 13 Dezember 2016, 21:00:18
Hi Ansgar,

habe die neue SW wie im Thread vorgeschlagen mit ASKSIN_BUF 9 compiliert und geladen, bis jetzt keine besonderen Vorkommnisse.

hier das List
Internals:
   CMDS       ABCFGMRTUVWXYefilmtx
   Clients    TSSTACKED:STACKABLE_CC:CUL_HM:HMS:CUL_IR
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL00UB0Z-if00-port0@38400 0000
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL00UB0Z-if00-port0@38400
   FD         10
   FHTID      0000
   NAME       nanoCUL
   NR         45
   PARTIAL
   RAWMSG     AFF6100009289000F1F86103547BF0000000A9CCE0A2C4011
   RSSI       -65.5
   STATE      Initialized
   TYPE       TSCUL
   VERSION    VTS 0.04 nanoCUL868
   VERSION_HW nanoCUL_V1.x
   VERSION_TS yes
   XmitOpen   1
   initString X21
Ar
At1
   nanoCUL_MSGCNT 19
   nanoCUL_TIME 2016-12-13 20:56:14
   Matchlist:
     1:TSSTACKED ^\*
     A:CUL_HM   ^A....................
     B:HMS      ^810e04....(1|5|9).a001
     C:CUL_IR   ^I............
   Readings:
     2016-12-13 20:54:04   Xmit-Events     ok:1 disconnected:1 init:2
     2016-12-04 21:21:58   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
     2016-12-13 20:53:45   cmds             A B C F G M R T U V W X Y e f i l m t x
     2016-12-13 20:54:04   cond            ok
     2016-12-05 08:25:39   fhtbuf          AE
     2016-12-13 18:42:48   prot_ERROR-Overload last
     2016-12-13 18:25:42   prot_Warning-HighLoad last
     2016-12-13 20:53:44   prot_disconnected last
     2016-12-13 20:53:45   prot_init       last
     2016-12-13 20:54:04   prot_ok         last
     2016-12-09 21:54:32   scF             0.999463180004529
     2016-12-13 20:53:45   state           Initialized
     2016-12-05 20:43:30   uptime          0 00:00:03
     2016-12-05 20:43:26   version         No answer
   Helper:
     Devio:
       NDisCon    0
       NRFail     0
       RXfailTS
     Hm:
       FUP        0
       hmCrdts    6
       hmSbusy    0
       Unknwn:
     Cnd:
       0          1
       253        1
       255        2
     Hmq:
     Hmqo:
     Q:
       HMcndN     0
       InQueues   0
       answerPend 0
       hmLanQlen  2
       Cap:
         sum        9000
     Ref:
       Sdly       1
       doNbyterate 96
       hmDstDly   120
       ioByteRate 3840
       ioByteRateMeas 3665.46779340314
       lHMt       118372
       lSys       968967565
       pTTu       1024
       pndAs      0
       pndCUAp    0
       pngLm      19
       pngMax     -200000
       pngMin     100000000
       pngRef     11
       pngtm      968880325
       pngtmBRs   1481658958.46085
       scF        0.999463180004529
       scFN       0
       scHT       31088
       scST       968880336
Attributes:
   event-on-change-reading cond
   hmId       F11234
   hmLanQlen  2_low
   rfmode     HomeMatic
   room       CUL_HM
   verbose    4


und die ersten Logs
2016.12.13 20:53:37.907 0: Server shutdown
2016.12.13 20:53:37.921 0: HM485d: Server stopped ...
2016.12.13 20:53:41.007 1: Including fhem.cfg
2016.12.13 20:53:42.727 2: eventTypes: loaded 988 events from ./log/eventTypes.txt
2016.12.13 20:53:44.110 2: TSCUL_Parse: nanoCUL new condition disconnected
2016.12.13 20:53:45.034 1: nanoCUL is VERSION_TS, VTS 0.04 nanoCUL868, nanoCUL_V1.x
2016.12.13 20:53:45.088 2: TSCUL_Parse: nanoCUL new condition init
2016.12.13 20:53:45.146 2: TSCUL_Parse: nanoCUL new condition init
2016.12.13 20:53:45.147 2: Switched nanoCUL rfmode to HomeMatic
2016.12.13 20:53:46.559 2: HM_LAN_WIRED: Assigned 00011169 as HMW_IO_12_Sw14_DR_LEQ1322965
2016.12.13 20:53:47.367 2: HM_LAN_WIRED: Assigned 00012465 as HMW_IO_12_Sw14_DR_MEQ0370281
2016.12.13 20:53:48.103 1: Including ./log/fhem.save
2016.12.13 20:53:50.395 1: usb create starting
2016.12.13 20:54:03.639 1: usb create end
2016.12.13 20:54:03.670 2: SecurityCheck:  WEB,WEBtablet has no associated allowed device with basicAuth. telnetPort has no associated allowed device with password/globalpassword.  Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2016.12.13 20:54:03.674 0: Featurelevel: 5.7
2016.12.13 20:54:03.675 0: Server started with 245 defined entities (fhem.pl:12463/2016-10-29 perl:5.014002 os:linux user:fhem pid:15883)
2016.12.13 20:54:04.784 2: TSCUL_Parse: nanoCUL new condition ok
2016.12.13 20:54:04.795 4: TSCUL_Parse: nanoCUL  509544 A FF52 00019400 00 01 C3 _ping -138
2016.12.13 20:54:05.145 1: HM485d: Server started ...
2016.12.13 20:54:05.266 4: TSCUL_Parse: nanoCUL  510017 A FF52 00020236 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2016.12.13 20:54:15.638 4: TSCUL_Parse: nanoCUL  520400 A FF52 00031088 00 01 C3 _ping -138
2016.12.13 20:54:18.760 4: TSCUL_Parse: nanoCUL  523515 A FF51 00033580 00 0D 08 A410 353C4B F11234 06070000 -58.5
2016.12.13 20:54:18.886 4: TSCUL_send:  nanoCUL                         As 0A 08 8002 F11234 353C4B 00
2016.12.13 20:54:18.913 4: TSCUL_Parse: nanoCUL  523668 A FF51 00034112 00 0D 09 A410 353C4B F11234 06070000 -59
2016.12.13 20:54:18.975 4: TSCUL_send:  nanoCUL                         As 0A 09 8002 F11234 353C4B 00
2016.12.13 20:54:18.978 4: TSCUL_Parse: nanoCUL  523734 A FF53 00034356 02 0A 08 8002 F11234 353C4B 00 _CCAdly:8 _dhmSt:244 -138
2016.12.13 20:54:19.032 4: TSCUL_Parse: nanoCUL  523789 A FF53 00034444 01 0A 09 8002 F11234 353C4B 00 _CCAdly:4 _dhmSt:332 -138
2016.12.13 20:54:25.457 4: TSCUL_Parse: nanoCUL  005922 A FF51 00040912 00 0F 99 8610 3549DB 000000 0A24CC0A0040 -61.5
2016.12.13 20:54:27.543 4: TSCUL_Parse: nanoCUL  008009 A FF51 00043000 00 0F 22 8610 3549DE 000000 0A90BC0A2240 -55
2016.12.13 20:54:32.775 4: TSCUL_Parse: nanoCUL  013241 A FF51 00048232 00 0F 98 8610 3549E1 000000 0A28D30B0040 -67
2016.12.13 20:54:36.330 4: TSCUL_Parse: nanoCUL  016793 A FF52 00051788 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2016.12.13 20:55:07.794 4: TSCUL_Parse: nanoCUL  048257 A FF52 00083268 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2016.12.13 20:55:17.017 1: PERL WARNING: Argument "" isn't numeric in int at ./FHEM/99_myUtils.pm line 99.
2016.12.13 20:55:23.102 4: TSCUL_Parse: nanoCUL  063568 A FF51 00098588 00 0F FC 8610 354555 000000 0A28A50A0040 -57.5
2016.12.13 20:55:26.344 4: TSCUL_Parse: nanoCUL  066810 A FF51 00101828 00 0F C0 8610 3547BA 000000 0A90C10A0F40 -48.5
2016.12.13 20:55:27.428 4: TSCUL_Parse: nanoCUL  067896 A FF51 00102916 00 0B 05 A240 381468 F11234 024D -55
2016.12.13 20:55:27.445 4: TSCUL_send:  nanoCUL                         As 0A 05 8002 F11234 381468 00
2016.12.13 20:55:27.446 3: TSCUL_XmitDlyHM:  nanoCUL  id:381468 dDly:92 toms:72
2016.12.13 20:55:27.497 4: TSCUL_send:  nanoCUL                         As 10 0A B011 F11234 353C4B 0207C800003200
2016.12.13 20:55:27.571 4: TSCUL_Parse: nanoCUL  068040 A FF53 00103036 01 0A 05 8002 F11234 381468 00 _CCAdly:4 _dhmSt:120 -138
2016.12.13 20:55:28.094 4: TSCUL_Parse: nanoCUL  068562 A FF53 00103124 01 10 0A B011 F11234 353C4B 02 _bst _CCAdly:4 -138
2016.12.13 20:55:28.192 4: TSCUL_Parse: nanoCUL  068658 A FF51 00103616 00 0E 0A 8002 353C4B F11234 0107C84000 -57.5
2016.12.13 20:55:28.709 4: TSCUL_Parse: nanoCUL  069177 A FF51 00104200 00 0B 06 A240 381468 F11234 024E -53.5
2016.12.13 20:55:28.726 4: TSCUL_send:  nanoCUL                         As 0A 06 8002 F11234 381468 00
2016.12.13 20:55:28.726 3: TSCUL_XmitDlyHM:  nanoCUL  id:381468 dDly:94 toms:72
2016.12.13 20:55:28.777 4: TSCUL_send:  nanoCUL                         As 10 0B B011 F11234 353C4B 0207C800003200
2016.12.13 20:55:28.855 4: TSCUL_Parse: nanoCUL  069323 A FF53 00104320 01 0A 06 8002 F11234 381468 00 _CCAdly:4 _dhmSt:120 -138
2016.12.13 20:55:29.281 4: TSCUL_Parse: nanoCUL  069750 A FF53 00104408 01 10 0B B011 F11234 353C4B 02 _bst _CCAdly:4 _dhmSt:792 -138
2016.12.13 20:55:29.410 4: TSCUL_Parse: nanoCUL  069876 A FF51 00104900 00 0E 0B 8002 353C4B F11234 0107C84000 -57.5
2016.12.13 20:55:33.559 4: TSCUL_Parse: nanoCUL  074025 A FF51 00109048 00 0D B8 8410 461413 F11234 06012600 -66.5
2016.12.13 20:55:33.700 4: TSCUL_Parse: nanoCUL  074166 A FF51 00109192 00 0F 9E 8610 3547B5 000000 0A24CE0A0040 -82
2016.12.13 20:55:42.175 4: TSCUL_Parse: nanoCUL  082643 A FF51 00117672 00 0B 07 A240 381468 F11234 024F -54
2016.12.13 20:55:42.191 4: TSCUL_send:  nanoCUL                         As 0A 07 8002 F11234 381468 00
2016.12.13 20:55:42.192 3: TSCUL_XmitDlyHM:  nanoCUL  id:381468 dDly:92 toms:72
2016.12.13 20:55:42.243 4: TSCUL_send:  nanoCUL                         As 10 0C B011 F11234 353C4B 0207C800003200
2016.12.13 20:55:42.385 4: TSCUL_Parse: nanoCUL  082854 A FF53 00117792 01 0A 07 8002 F11234 381468 00 _CCAdly:4 _dhmSt:120 -138
2016.12.13 20:55:42.746 4: TSCUL_Parse: nanoCUL  083214 A FF63 00117880 01 10 0C B011 F11234 353C4B 02 _bst _CCAdly:4 -138
2016.12.13 20:55:42.875 4: TSCUL_Parse: nanoCUL  083341 A FF61 00118372 00 0E 0C 8002 353C4B F11234 0107C84000 -58
2016.12.13 20:55:43.460 4: TSCUL_Parse: nanoCUL  083928 A FF61 00118956 00 0B 08 A240 381468 F11234 0250 -53.5
2016.12.13 20:55:43.477 4: TSCUL_send:  nanoCUL                         As 0A 08 8002 F11234 381468 00
2016.12.13 20:55:43.477 3: TSCUL_XmitDlyHM:  nanoCUL  id:381468 dDly:91 toms:72
2016.12.13 20:55:43.528 4: TSCUL_send:  nanoCUL                         As 10 0D B011 F11234 353C4B 0207C800003200
2016.12.13 20:55:43.631 4: TSCUL_Parse: nanoCUL  084099 A FF63 00119076 01 0A 08 8002 F11234 381468 00 _CCAdly:4 _dhmSt:120 -138
2016.12.13 20:55:44.029 4: TSCUL_Parse: nanoCUL  084497 A FF63 00119164 01 10 0D B011 F11234 353C4B 02 _bst _CCAdly:4 _dhmSt:792 -138
2016.12.13 20:55:44.159 4: TSCUL_Parse: nanoCUL  084625 A FF61 00119656 00 0E 0D 8002 353C4B F11234 0107C84000 -57.5
2016.12.13 20:55:58.491 4: TSCUL_Parse: nanoCUL  098954 A FF62 00133992 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2016.12.13 20:56:11.413 4: TSCUL_Parse: nanoCUL  111879 A FF61 00146924 00 0F 58 8610 3547BB 000000 0AA8DD093840 -49.5
2016.12.13 20:56:14.539 4: TSCUL_Parse: nanoCUL  115005 A FF61 00150052 00 0F 1F 8610 3547BF 000000 0A9CCE0A2C40 -65.5
2016.12.13 20:56:30.674 4: TSCUL_Parse: nanoCUL  131137 A FF52 00166192 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2016.12.13 20:56:31.057 4: TSCUL_Parse: nanoCUL  131524 A FF51 00166580 00 0D 0E A410 353C4B F11234 06070000 -59
2016.12.13 20:56:31.074 4: TSCUL_send:  nanoCUL                         As 0A 0E 8002 F11234 353C4B 00
2016.12.13 20:56:31.075 3: TSCUL_XmitDlyHM:  nanoCUL  id:353C4B dDly:92 toms:72
2016.12.13 20:56:31.201 4: TSCUL_Parse: nanoCUL  131669 A FF53 00166700 01 0A 0E 8002 F11234 353C4B 00 _CCAdly:4 _dhmSt:120 -138
2016.12.13 20:56:55.037 4: TSCUL_Parse: nanoCUL  155503 A FF51 00190572 00 0F 23 8610 3549DE 000000 0A90BB0A2240 -55
2016.12.13 20:57:01.326 4: TSCUL_Parse: nanoCUL  161789 A FF52 00196860 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2016.12.13 20:57:09.709 4: TSCUL_Parse: nanoCUL  170175 A FF51 00205252 00 0F 9A 8610 3549DB 000000 0A24CC0A0040 -62
2016.12.13 20:57:21.026 4: TSCUL_Parse: nanoCUL  181492 A FF51 00216576 00 0F 99 8610 3549E1 000000 0A28D30B0040 -66.5


2016-12-13 21:00:37.018 ECMDDevice Relais9 on: ok
2016-12-13 21:00:37.018 ECMDDevice Relais9 on ok
2016-12-13 21:00:37.035 dummy Test on
2016-12-13 21:00:37.037 dummy Test2 toggle
2016-12-13 21:00:37.048 at Test3 Next: 21:00:46
2016-12-13 21:00:37.060 HM485 HMW_IO_12_Sw14_DR_LEQ1322965_01 set_off
2016-12-13 21:00:37.116 HM485 HMW_IO_12_Sw14_DR_LEQ1322965 ACK
2016-12-13 21:00:37.127 HM485 HMW_IO_12_Sw14_DR_LEQ1322965_01 off
2016-12-13 21:00:46.978 ECMDDevice Relais9 off: ok
2016-12-13 21:00:46.978 ECMDDevice Relais9 off ok
2016-12-13 21:00:46.987 dummy Test off
2016-12-13 21:00:46.989 dummy Test2 toggle
2016-12-13 21:00:47.000 at Test3 Next: 21:00:56
2016-12-13 21:00:51.822 at checkNETIO1 Next: 21:01:16
2016-12-13 21:00:51.837 at checkNETIO2 Next: 21:01:16
2016-12-13 21:00:56.978 ECMDDevice Relais9 on: ok
2016-12-13 21:00:56.978 ECMDDevice Relais9 on ok
2016-12-13 21:00:56.995 dummy Test on
2016-12-13 21:00:56.997 dummy Test2 toggle
2016-12-13 21:00:57.008 at Test3 Next: 21:01:06
2016-12-13 21:00:57.020 HM485 HMW_IO_12_Sw14_DR_LEQ1322965_01 set_on
2016-12-13 21:00:57.076 HM485 HMW_IO_12_Sw14_DR_LEQ1322965 ACK
2016-12-13 21:00:57.087 HM485 HMW_IO_12_Sw14_DR_LEQ1322965_01 on
2016-12-13 21:01:03.014 CUL_HM CUL_HM_HM_MOD_Re_8_353C4B CMDs_pending
2016-12-13 21:01:03.029 CUL_HM Licht_Haustuer set_on-for-timer 40
2016-12-13 21:01:03.058 DOIF Licht_an_EG cmd_nr: 1
2016-12-13 21:01:03.058 DOIF Licht_an_EG cmd: 1
2016-12-13 21:01:03.058 DOIF Licht_an_EG cmd_event: Bewegungsmelder_EG
2016-12-13 21:01:03.058 DOIF Licht_an_EG cmd_1
2016-12-13 21:01:03.072 CUL_HM Bewegungsmelder_EG brightness: 38
2016-12-13 21:01:03.072 CUL_HM Bewegungsmelder_EG motion: on (to nanoCUL)
2016-12-13 21:01:03.072 CUL_HM Bewegungsmelder_EG motionCount: 129_next:15s
2016-12-13 21:01:03.072 CUL_HM Bewegungsmelder_EG motion
2016-12-13 21:01:03.072 CUL_HM Bewegungsmelder_EG trigDst_F11234: noConfig
2016-12-13 21:01:03.072 CUL_HM Bewegungsmelder_EG trigger_cnt: 129
2016-12-13 21:01:03.691 CUL_HM CUL_HM_HM_MOD_Re_8_353C4B CMDs_done
2016-12-13 21:01:03.711 DOIF Licht_an_EG cmd_nr: 2
2016-12-13 21:01:03.711 DOIF Licht_an_EG cmd: 2
2016-12-13 21:01:03.711 DOIF Licht_an_EG cmd_event: Licht_Haustuer
2016-12-13 21:01:03.711 DOIF Licht_an_EG cmd_2
2016-12-13 21:01:03.728 CUL_HM Licht_Haustuer deviceMsg: on (to nanoCUL)
2016-12-13 21:01:03.728 CUL_HM Licht_Haustuer level: 100
2016-12-13 21:01:03.728 CUL_HM Licht_Haustuer pct: 100
2016-12-13 21:01:03.728 CUL_HM Licht_Haustuer on
2016-12-13 21:01:03.728 CUL_HM Licht_Haustuer timedOn: running
2016-12-13 21:01:06.972 ECMDDevice Relais9 off: ok
2016-12-13 21:01:06.972 ECMDDevice Relais9 off ok
2016-12-13 21:01:06.981 dummy Test off
2016-12-13 21:01:06.983 dummy Test2 toggle
2016-12-13 21:01:06.995 at Test3 Next: 21:01:16
2016-12-13 21:01:12.373 CUL_HM CUL_HM_HM_CC_RT_DN_3547BA actuator: 15
2016-12-13 21:01:12.373 CUL_HM CUL_HM_HM_CC_RT_DN_3547BA battery: ok
2016-12-13 21:01:12.373 CUL_HM CUL_HM_HM_CC_RT_DN_3547BA batteryLevel: 2.5
2016-12-13 21:01:12.373 CUL_HM CUL_HM_HM_CC_RT_DN_3547BA desired-temp: 18.0
2016-12-13 21:01:12.373 CUL_HM CUL_HM_HM_CC_RT_DN_3547BA measured-temp: 19.2
2016-12-13 21:01:12.373 CUL_HM CUL_HM_HM_CC_RT_DN_3547BA motorErr: ok
2016-12-13 21:01:12.385 CUL_HM CUL_HM_HM_CC_RT_DN_3547BA_Weather measured-temp: 19.2
2016-12-13 21:01:12.385 CUL_HM CUL_HM_HM_CC_RT_DN_3547BA_Weather 19.2
2016-12-13 21:01:12.417 CUL_HM Thermostat_Zimmer_Haushalt_Clima ValvePosition: 15
2016-12-13 21:01:12.417 CUL_HM Thermostat_Zimmer_Haushalt_Clima boostTime: -
2016-12-13 21:01:12.417 CUL_HM Thermostat_Zimmer_Haushalt_Clima controlMode: manual
2016-12-13 21:01:12.417 CUL_HM Thermostat_Zimmer_Haushalt_Clima desired-temp: 18.0
2016-12-13 21:01:12.417 CUL_HM Thermostat_Zimmer_Haushalt_Clima measured-temp: 19.2
2016-12-13 21:01:12.417 CUL_HM Thermostat_Zimmer_Haushalt_Clima partyEnd: -
2016-12-13 21:01:12.417 CUL_HM Thermostat_Zimmer_Haushalt_Clima partyStart: -
2016-12-13 21:01:12.417 CUL_HM Thermostat_Zimmer_Haushalt_Clima partyTemp: -
2016-12-13 21:01:12.417 CUL_HM Thermostat_Zimmer_Haushalt_Clima T: 19.2 desired: 18.0 valve: 15
2016-12-13 21:01:16.823 at checkNETIO1 Next: 21:01:41
2016-12-13 21:01:16.837 at checkNETIO2 Next: 21:01:41
2016-12-13 21:01:16.972 ECMDDevice Relais9 on: ok
2016-12-13 21:01:16.972 ECMDDevice Relais9 on ok
2016-12-13 21:01:16.989 dummy Test on
2016-12-13 21:01:16.991 dummy Test2 toggle
2016-12-13 21:01:17.002 at Test3 Next: 21:01:26
2016-12-13 21:01:17.028 at mycall Next: 21:02:46
2016-12-13 21:01:17.040 HM485 HMW_IO_12_Sw14_DR_LEQ1322965_01 set_off
2016-12-13 21:01:17.101 HM485 HMW_IO_12_Sw14_DR_LEQ1322965 ACK
2016-12-13 21:01:17.111 HM485 HMW_IO_12_Sw14_DR_LEQ1322965_01 off
2016-12-13 21:01:19.995 CUL_HM Bewegungsmelder_EG motion: off
2016-12-13 21:01:19.995 CUL_HM Bewegungsmelder_EG motionDuration: 17
2016-12-13 21:01:19.995 CUL_HM Bewegungsmelder_EG noMotion
2016-12-13 21:01:24.697 CUL_HM CUL_HM_HM_CC_RT_DN_3547BB actuator: 56
2016-12-13 21:01:24.697 CUL_HM CUL_HM_HM_CC_RT_DN_3547BB battery: ok
2016-12-13 21:01:24.697 CUL_HM CUL_HM_HM_CC_RT_DN_3547BB batteryLevel: 2.4
2016-12-13 21:01:24.697 CUL_HM CUL_HM_HM_CC_RT_DN_3547BB desired-temp: 21.0
2016-12-13 21:01:24.697 CUL_HM CUL_HM_HM_CC_RT_DN_3547BB measured-temp: 22.1
2016-12-13 21:01:24.697 CUL_HM CUL_HM_HM_CC_RT_DN_3547BB motorErr: ok
2016-12-13 21:01:24.709 CUL_HM CUL_HM_HM_CC_RT_DN_3547BB_Weather measured-temp: 22.1
2016-12-13 21:01:24.709 CUL_HM CUL_HM_HM_CC_RT_DN_3547BB_Weather 22.1
2016-12-13 21:01:24.739 CUL_HM Thermostat_Zimmer_Bad_Clima ValvePosition: 56
2016-12-13 21:01:24.739 CUL_HM Thermostat_Zimmer_Bad_Clima boostTime: -
2016-12-13 21:01:24.739 CUL_HM Thermostat_Zimmer_Bad_Clima controlMode: manual
2016-12-13 21:01:24.739 CUL_HM Thermostat_Zimmer_Bad_Clima desired-temp: 21.0
2016-12-13 21:01:24.739 CUL_HM Thermostat_Zimmer_Bad_Clima measured-temp: 22.1
2016-12-13 21:01:24.739 CUL_HM Thermostat_Zimmer_Bad_Clima partyEnd: -
2016-12-13 21:01:24.739 CUL_HM Thermostat_Zimmer_Bad_Clima partyStart: -
2016-12-13 21:01:24.739 CUL_HM Thermostat_Zimmer_Bad_Clima partyTemp: -
2016-12-13 21:01:24.739 CUL_HM Thermostat_Zimmer_Bad_Clima T: 22.1 desired: 21.0 valve: 56
2016-12-13 21:01:26.975 ECMDDevice Relais9 off: ok
2016-12-13 21:01:26.975 ECMDDevice Relais9 off ok
2016-12-13 21:01:26.984 dummy Test off
2016-12-13 21:01:26.986 dummy Test2 toggle
2016-12-13 21:01:26.998 at Test3 Next: 21:01:36
2016-12-13 21:01:36.982 ECMDDevice Relais9 on: ok
2016-12-13 21:01:36.982 ECMDDevice Relais9 on ok
2016-12-13 21:01:36.999 dummy Test on
2016-12-13 21:01:37.001 dummy Test2 toggle
2016-12-13 21:01:37.013 at Test3 Next: 21:01:46
2016-12-13 21:01:37.025 HM485 HMW_IO_12_Sw14_DR_LEQ1322965_01 set_on
2016-12-13 21:01:37.070 CUL_HM CUL_HM_HM_CC_RT_DN_3547BF actuator: 44
2016-12-13 21:01:37.070 CUL_HM CUL_HM_HM_CC_RT_DN_3547BF battery: ok
2016-12-13 21:01:37.070 CUL_HM CUL_HM_HM_CC_RT_DN_3547BF batteryLevel: 2.5
2016-12-13 21:01:37.070 CUL_HM CUL_HM_HM_CC_RT_DN_3547BF desired-temp: 19.5
2016-12-13 21:01:37.070 CUL_HM CUL_HM_HM_CC_RT_DN_3547BF measured-temp: 20.6
2016-12-13 21:01:37.070 CUL_HM CUL_HM_HM_CC_RT_DN_3547BF motorErr: ok
2016-12-13 21:01:37.081 CUL_HM CUL_HM_HM_CC_RT_DN_3547BF_Weather measured-temp: 20.6
2016-12-13 21:01:37.081 CUL_HM CUL_HM_HM_CC_RT_DN_3547BF_Weather 20.6
2016-12-13 21:01:37.109 CUL_HM Thermostat_Zimmer_Buero_Clima ValvePosition: 44
2016-12-13 21:01:37.109 CUL_HM Thermostat_Zimmer_Buero_Clima boostTime: -
2016-12-13 21:01:37.109 CUL_HM Thermostat_Zimmer_Buero_Clima controlMode: manual
2016-12-13 21:01:37.109 CUL_HM Thermostat_Zimmer_Buero_Clima desired-temp: 19.5
2016-12-13 21:01:37.109 CUL_HM Thermostat_Zimmer_Buero_Clima measured-temp: 20.6
2016-12-13 21:01:37.109 CUL_HM Thermostat_Zimmer_Buero_Clima partyEnd: -
2016-12-13 21:01:37.109 CUL_HM Thermostat_Zimmer_Buero_Clima partyStart: -
2016-12-13 21:01:37.109 CUL_HM Thermostat_Zimmer_Buero_Clima partyTemp: -
2016-12-13 21:01:37.109 CUL_HM Thermostat_Zimmer_Buero_Clima T: 20.6 desired: 19.5 valve: 44
2016-12-13 21:01:37.132 HM485 HMW_IO_12_Sw14_DR_LEQ1322965 ACK
2016-12-13 21:01:37.141 HM485 HMW_IO_12_Sw14_DR_LEQ1322965_01 on
2016-12-13 21:01:41.818 at checkNETIO1 Next: 21:02:06
2016-12-13 21:01:41.831 at checkNETIO2 Next: 21:02:06
2016-12-13 21:01:46.970 ECMDDevice Relais9 off: ok
2016-12-13 21:01:46.970 ECMDDevice Relais9 off ok
2016-12-13 21:01:46.978 dummy Test off
2016-12-13 21:01:46.980 dummy Test2 toggle
2016-12-13 21:01:46.990 at Test3 Next: 21:01:56
2016-12-13 21:01:50.497 CUL_HM CUL_HM_HM_MOD_Re_8_353C4B CMDs_done
2016-12-13 21:01:50.520 CUL_HM Licht_Haustuer deviceMsg: off (to nanoCUL)
2016-12-13 21:01:50.520 CUL_HM Licht_Haustuer level: 0
2016-12-13 21:01:50.520 CUL_HM Licht_Haustuer pct: 0
2016-12-13 21:01:50.520 CUL_HM Licht_Haustuer off
2016-12-13 21:01:50.520 CUL_HM Licht_Haustuer timedOn: off
2016-12-13 21:01:54.585 CUL_HM Bewegungsmelder_EG battery: ok
2016-12-13 21:01:54.585 CUL_HM Bewegungsmelder_EG brightness: 38
2016-12-13 21:01:54.585 CUL_HM Bewegungsmelder_EG cover: closed
2016-12-13 21:01:54.742 CUL_HM CUL_HM_HM_CC_RT_DN_3549DB actuator: 0
2016-12-13 21:01:54.742 CUL_HM CUL_HM_HM_CC_RT_DN_3549DB battery: ok
2016-12-13 21:01:54.742 CUL_HM CUL_HM_HM_CC_RT_DN_3549DB batteryLevel: 2.5
2016-12-13 21:01:54.742 CUL_HM CUL_HM_HM_CC_RT_DN_3549DB desired-temp: off
2016-12-13 21:01:54.742 CUL_HM CUL_HM_HM_CC_RT_DN_3549DB measured-temp: 20.4
2016-12-13 21:01:54.742 CUL_HM CUL_HM_HM_CC_RT_DN_3549DB motorErr: ok
2016-12-13 21:01:54.755 CUL_HM CUL_HM_HM_CC_RT_DN_3549DB_Weather measured-temp: 20.4
2016-12-13 21:01:54.755 CUL_HM CUL_HM_HM_CC_RT_DN_3549DB_Weather 20.4
2016-12-13 21:01:54.787 CUL_HM Thermostat_Zimmer_Sebastian_Clima ValvePosition: 0
2016-12-13 21:01:54.787 CUL_HM Thermostat_Zimmer_Sebastian_Clima boostTime: -
2016-12-13 21:01:54.787 CUL_HM Thermostat_Zimmer_Sebastian_Clima controlMode: manual
2016-12-13 21:01:54.787 CUL_HM Thermostat_Zimmer_Sebastian_Clima desired-temp: off
2016-12-13 21:01:54.787 CUL_HM Thermostat_Zimmer_Sebastian_Clima measured-temp: 20.4
2016-12-13 21:01:54.787 CUL_HM Thermostat_Zimmer_Sebastian_Clima partyEnd: -
2016-12-13 21:01:54.787 CUL_HM Thermostat_Zimmer_Sebastian_Clima partyStart: -
2016-12-13 21:01:54.787 CUL_HM Thermostat_Zimmer_Sebastian_Clima partyTemp: -
2016-12-13 21:01:54.787 CUL_HM Thermostat_Zimmer_Sebastian_Clima T: 20.4 desired: off valve: 0
2016-12-13 21:01:56.974 ECMDDevice Relais9 on: ok
2016-12-13 21:01:56.974 ECMDDevice Relais9 on ok
2016-12-13 21:01:56.992 dummy Test on
2016-12-13 21:01:56.995 dummy Test2 toggle
2016-12-13 21:01:57.006 at Test3 Next: 21:02:06
2016-12-13 21:01:57.018 HM485 HMW_IO_12_Sw14_DR_LEQ1322965_01 set_off
2016-12-13 21:01:57.074 HM485 HMW_IO_12_Sw14_DR_LEQ1322965 ACK
2016-12-13 21:01:57.085 HM485 HMW_IO_12_Sw14_DR_LEQ1322965_01 off
2016-12-13 21:01:59.369 CUL_HM CUL_HM_HM_MOD_Re_8_353C4B CMDs_pending
2016-12-13 21:01:59.384 CUL_HM Licht_Haustuer set_on-for-timer 40
2016-12-13 21:01:59.412 DOIF Licht_an_EG cmd_nr: 1
2016-12-13 21:01:59.412 DOIF Licht_an_EG cmd: 1
2016-12-13 21:01:59.412 DOIF Licht_an_EG cmd_event: Bewegungsmelder_EG
2016-12-13 21:01:59.412 DOIF Licht_an_EG cmd_1
2016-12-13 21:01:59.427 CUL_HM Bewegungsmelder_EG brightness: 38
2016-12-13 21:01:59.427 CUL_HM Bewegungsmelder_EG motion: on (to nanoCUL)
2016-12-13 21:01:59.427 CUL_HM Bewegungsmelder_EG motionCount: 130_next:15s
2016-12-13 21:01:59.427 CUL_HM Bewegungsmelder_EG motion
2016-12-13 21:01:59.427 CUL_HM Bewegungsmelder_EG trigDst_F11234: noConfig
2016-12-13 21:01:59.427 CUL_HM Bewegungsmelder_EG trigger_cnt: 130
2016-12-13 21:02:00.050 CUL_HM CUL_HM_HM_MOD_Re_8_353C4B CMDs_done
2016-12-13 21:02:00.069 DOIF Licht_an_EG cmd_nr: 2
2016-12-13 21:02:00.069 DOIF Licht_an_EG cmd: 2
2016-12-13 21:02:00.069 DOIF Licht_an_EG cmd_event: Licht_Haustuer
2016-12-13 21:02:00.069 DOIF Licht_an_EG cmd_2
2016-12-13 21:02:00.087 CUL_HM Licht_Haustuer deviceMsg: on (to nanoCUL)
2016-12-13 21:02:00.087 CUL_HM Licht_Haustuer level: 100
2016-12-13 21:02:00.087 CUL_HM Licht_Haustuer pct: 100
2016-12-13 21:02:00.087 CUL_HM Licht_Haustuer on
2016-12-13 21:02:00.087 CUL_HM Licht_Haustuer timedOn: running
2016-12-13 21:02:06.823 at checkNETIO1 Next: 21:02:31
2016-12-13 21:02:06.837 at checkNETIO2 Next: 21:02:31
2016-12-13 21:02:06.972 ECMDDevice Relais9 off: ok
2016-12-13 21:02:06.972 ECMDDevice Relais9 off ok
2016-12-13 21:02:06.981 dummy Test off
2016-12-13 21:02:06.983 dummy Test2 toggle
2016-12-13 21:02:06.994 at Test3 Next: 21:02:16
2016-12-13 21:02:10.569 CUL_HM CUL_HM_HM_CC_RT_DN_3549DE actuator: 34
2016-12-13 21:02:10.569 CUL_HM CUL_HM_HM_CC_RT_DN_3549DE battery: ok
2016-12-13 21:02:10.569 CUL_HM CUL_HM_HM_CC_RT_DN_3549DE batteryLevel: 2.5
2016-12-13 21:02:10.569 CUL_HM CUL_HM_HM_CC_RT_DN_3549DE desired-temp: 18.0
2016-12-13 21:02:10.569 CUL_HM CUL_HM_HM_CC_RT_DN_3549DE measured-temp: 18.7
2016-12-13 21:02:10.569 CUL_HM CUL_HM_HM_CC_RT_DN_3549DE motorErr: ok
2016-12-13 21:02:10.581 CUL_HM CUL_HM_HM_CC_RT_DN_3549DE_Weather measured-temp: 18.7
2016-12-13 21:02:10.581 CUL_HM CUL_HM_HM_CC_RT_DN_3549DE_Weather 18.7
2016-12-13 21:02:10.613 CUL_HM Thermostat_Zimmer_Korbinian_Clima ValvePosition: 34
2016-12-13 21:02:10.613 CUL_HM Thermostat_Zimmer_Korbinian_Clima boostTime: -
2016-12-13 21:02:10.613 CUL_HM Thermostat_Zimmer_Korbinian_Clima controlMode: manual
2016-12-13 21:02:10.613 CUL_HM Thermostat_Zimmer_Korbinian_Clima desired-temp: 18.0
2016-12-13 21:02:10.613 CUL_HM Thermostat_Zimmer_Korbinian_Clima measured-temp: 18.7
2016-12-13 21:02:10.613 CUL_HM Thermostat_Zimmer_Korbinian_Clima partyEnd: -
2016-12-13 21:02:10.613 CUL_HM Thermostat_Zimmer_Korbinian_Clima partyStart: -
2016-12-13 21:02:10.613 CUL_HM Thermostat_Zimmer_Korbinian_Clima partyTemp: -
2016-12-13 21:02:10.613 CUL_HM Thermostat_Zimmer_Korbinian_Clima T: 18.7 desired: 18.0 valve: 34
2016-12-13 21:02:14.308 CUL_HM CUL_HM_HM_CC_RT_DN_3549E1 actuator: 0
2016-12-13 21:02:14.308 CUL_HM CUL_HM_HM_CC_RT_DN_3549E1 battery: ok
2016-12-13 21:02:14.308 CUL_HM CUL_HM_HM_CC_RT_DN_3549E1 batteryLevel: 2.6
2016-12-13 21:02:14.308 CUL_HM CUL_HM_HM_CC_RT_DN_3549E1 desired-temp: 5.0
2016-12-13 21:02:14.308 CUL_HM CUL_HM_HM_CC_RT_DN_3549E1 measured-temp: 21.0
2016-12-13 21:02:14.308 CUL_HM CUL_HM_HM_CC_RT_DN_3549E1 motorErr: ok
2016-12-13 21:02:14.320 CUL_HM CUL_HM_HM_CC_RT_DN_3549E1_Weather measured-temp: 21.0
2016-12-13 21:02:14.320 CUL_HM CUL_HM_HM_CC_RT_DN_3549E1_Weather 21.0
2016-12-13 21:02:14.351 CUL_HM Thermostat_Zimmer_Wohnen_Clima ValvePosition: 0
2016-12-13 21:02:14.351 CUL_HM Thermostat_Zimmer_Wohnen_Clima boostTime: -
2016-12-13 21:02:14.351 CUL_HM Thermostat_Zimmer_Wohnen_Clima controlMode: manual
2016-12-13 21:02:14.351 CUL_HM Thermostat_Zimmer_Wohnen_Clima desired-temp: 5.0
2016-12-13 21:02:14.351 CUL_HM Thermostat_Zimmer_Wohnen_Clima measured-temp: 21.0
2016-12-13 21:02:14.351 CUL_HM Thermostat_Zimmer_Wohnen_Clima partyEnd: -
2016-12-13 21:02:14.351 CUL_HM Thermostat_Zimmer_Wohnen_Clima partyStart: -
2016-12-13 21:02:14.351 CUL_HM Thermostat_Zimmer_Wohnen_Clima partyTemp: -
2016-12-13 21:02:14.351 CUL_HM Thermostat_Zimmer_Wohnen_Clima T: 21.0 desired: 5.0 valve: 0
2016-12-13 21:02:16.353 CUL_HM Bewegungsmelder_EG motion: off
2016-12-13 21:02:16.353 CUL_HM Bewegungsmelder_EG motionDuration: 17
2016-12-13 21:02:16.353 CUL_HM Bewegungsmelder_EG noMotion
2016-12-13 21:02:16.973 ECMDDevice Relais9 on: ok
2016-12-13 21:02:16.973 ECMDDevice Relais9 on ok
2016-12-13 21:02:16.990 dummy Test on
2016-12-13 21:02:16.992 dummy Test2 toggle
2016-12-13 21:02:17.004 at Test3 Next: 21:02:26
2016-12-13 21:02:17.016 HM485 HMW_IO_12_Sw14_DR_LEQ1322965_01 set_on
2016-12-13 21:02:17.072 HM485 HMW_IO_12_Sw14_DR_LEQ1322965 ACK
2016-12-13 21:02:17.082 HM485 HMW_IO_12_Sw14_DR_LEQ1322965_01 on

Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 13 Dezember 2016, 21:13:40
Hallo Mario,

Du hast die TSCUL_fwcode_00_04_FHEM_Modules_00_04_3.zip runter geladen und auch alle Module aus dem FHEM Ordner frisch in den FHEM Ordner von FHEM kopiert?
Mach mal ein neues get ccconf und nochmal das list bitte.

Das nanoCUL.hex in der zip ist bereits auf 9 Buffer compiliert.

Gruß, Ansgar
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Maxl am 13 Dezember 2016, 22:52:49
Hallo,

habe das neue zip aus dem Link runtergeladen und auch die FHEM Files kopiert, denke ich zumindest.

nanoCUL 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 CCAmode:3 csRelThr:dis csAbsThr:0dB

Internals:
   CMDS       ABCFGMRTUVWXYefilmtx
   Clients    TSSTACKED:STACKABLE_CC:CUL_HM:HMS:CUL_IR
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL00UB0Z-if00-port0@38400 0000
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL00UB0Z-if00-port0@38400
   FD         11
   FHTID      0000
   NAME       nanoCUL
   NR         45
   PARTIAL
   RAWMSG     AFF110012327B000FEE86103547BA0000000A90B00A234034
   RSSI       -48
   STATE      Initialized
   TYPE       TSCUL
   VERSION    VTS 0.04 nanoCUL868
   VERSION_HW nanoCUL_V1.x
   VERSION_TS yes
   XmitOpen   1
   initString X21
Ar
At1
   nanoCUL_MSGCNT 268
   nanoCUL_TIME 2016-12-13 22:51:58
   Matchlist:
     1:TSSTACKED ^\*
     A:CUL_HM   ^A....................
     B:HMS      ^810e04....(1|5|9).a001
     C:CUL_IR   ^I............
   Readings:
     2016-12-13 21:32:35   Xmit-Events     ok:1 disconnected:1 init:2
     2016-12-13 22:51:07   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 CCAmode:3 csRelThr:dis csAbsThr:0dB
     2016-12-13 21:32:31   cmds             A B C F G M R T U V W X Y e f i l m t x
     2016-12-13 21:32:35   cond            ok
     2016-12-05 08:25:39   fhtbuf          AE
     2016-12-13 18:42:48   prot_ERROR-Overload last
     2016-12-13 18:25:42   prot_Warning-HighLoad last
     2016-12-13 21:32:30   prot_disconnected last
     2016-12-13 21:32:31   prot_init       last
     2016-12-13 21:32:35   prot_ok         last
     2016-12-13 22:41:16   scF             0.999462794749614
     2016-12-13 21:32:31   state           Initialized
     2016-12-05 20:43:30   uptime          0 00:00:03
     2016-12-13 21:11:48   version         VTS 0.04 nanoCUL868
   Helper:
     Devio:
       NDisCon    0
       NRFail     0
       RXfailTS
     Hm:
       FUP        0
       hmCrdts    1
       hmSbusy    0
       Unknwn:
     Cnd:
       0          1
       253        1
       255        2
     Hmq:
     Hmqo:
     Q:
       HMcndN     0
       InQueues   0
       answerPend 0
       hmLanQlen  2
       Cap:
         sum        20250
     Ref:
       Sdly       1
       hmDstDly   120
       ioByteRate 3840
       ioByteRateMeas 3727.14561967031
       lHMt       4738400
       lSys       975911205
       pTTu       1024
       pndAs      0
       pndCUAp    0
       pngLm      13
       pngMax     6
       pngMin     5
       pngRef     6
       pngtm      975300862
       scErr      2.58100359607488
       scF        0.999462794749614
       scFN       4
       scHT       29520
       scST       971204855
Attributes:
   event-on-change-reading cond
   hmId       F11234
   hmLanQlen  2_low
   rfmode     HomeMatic
   room       CUL_HM
   verbose    4
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 14 Dezember 2016, 02:24:39
Hallo Mario,

sieht erst mal gut aus.
Treten die Probleme wieder auf?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Maxl am 14 Dezember 2016, 10:49:41
Hi,

bis jetzt funktioniert alles wunderbar.

Danke, gute Arbeit
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: DerFrickler am 16 Dezember 2016, 14:13:35
Hierzu bitte mal ein paar Fragen...

Hintergrund: Ich betreibe 2 CUBEs mit der 1.20.08 a-culfw und eine CUNX mit der V2.66 FW. Im Keller befinden sich 2 HM Wandthermostate die mir Probleme bereiten. Möglicherweise kann diese FW hier diese Probleme beheben.

Frage: Eignet sich diese Firmware auch für die CUBEs und dem CUNX? Müssen auf diese Firmware aktualisiert werden, oder geht auch ein Mischbetrieb? -> Die Wandthermostate befinden sich nur im Keller, prinzipiell sind die mit einem Funkmodul gut versorgt.

Gruß!
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 16 Dezember 2016, 15:36:24
Hallo Frickler,

ZitatEignet sich diese Firmware auch für die CUBEs und dem CUNX?

Leider so direkt leider nein.
Das fängt bei der Taktfrequenz an, wo bezüglich Timing sicherlich Anpassungen notwendig wären, wenn die nicht mit Prescaler auf 8MHz zu bekommen sind (wie bei nanoCUL 16MHz). Das ist ein springender Punkt, da Timertakt und 16Bit Timerwertlänge im Code deutlich genutzt werden. Mit verändertem Timertakt "knallts" sonst an diversen Ecken.

Und ohne die Prozessoren und die Schaltpläne intensiv betrachtet zu haben, kann ich auch nicht sagen, wie aufwändig eine Anpassung wäre.
Es gibt wohl auch nicht umsonst die V2.xx Firmware für CUNX. Zu CUBE habe ich derzeit gar keine Infos.

Einige Assembler Routinen habe ich auch drin um noch etwas Speed und Flashspeicher raus zu kitzlen, wo der Compiler die Hardware nicht entsprechend nutz.

Kann man sicherlich anpassen, aber ist eine Frage von Zeit und auch verfügbarer Hardware zum Testen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: chrille76 am 18 Dezember 2016, 11:01:58
Guten Morgen,

ich habe vorgestern auch auf TSCUL umgestellt, da bei mir die Kommunikation mit einem HM Bewegungsmelder nicht so recht wollte. Das funktioniert jetzt super.

Seit gestern ist mein Log allerdings voll mit folgenden Meldungen so ca. alle 20-30 min:
2016.12.18 08:22:03 2: TSCUL_ReceiveDelayed: CUL868  C 00=07 01=2E 02=01 03=41 04=E9
05=CA 06=3D 07=0C 08=45 09=00 0A=00 0B=06 0C=F2 0D=21 0E=65 0F=6A 10=C8 11=93 12=03
13=22 14=F8 15=34 16=07 17=3F 18=18 19=16 1A=6C 1B=43 1C=40 1D=91 1E=87 1F=6B 20=F8
21=56 22=10 23=AC 24=2B 25=16 26=11 27=41 28=00 29=59 2A=7F 2B=3E 2C=81 2D=35 2E=0B
2F=00 30=00 31=14 32=F6 33=00 34=CD 35=0D 36=00 37=00 38=30 39=CC 3A=00 3B=00 3C=00
3D=00
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 18 Dezember 2016, 11:19:03
Hallo chrille76,

das ist eine Art Alive Timer. Wenn für 900 Sekunden nichts empfangen wird (was normalerweise ungewöhnlich ist), dann werden alle Empfänger-Registerwerte mal vom CUL abgeholt und man kann das mit verbose 2 oder höher sichtbar machen, um zu schauen, ob es da einen Zusammenhang gibt.

Wenn Du sonst keine Probleme hast verbose 1 und Ruhe ist.

Oder Du musst mehr Action machen, damit der Bewegungsmelder öfter mal was sendet.  ;)

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: chrille76 am 18 Dezember 2016, 11:26:14
Danke! Ich beginne halt erst und außer dem Bewegungsmelder läuft noch nix weiter. Und gestern war halt ab nachmittags niemand zuhause  :D
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: scr3tchy am 18 Dezember 2016, 14:28:21
Hallo zusammen.

Ich habe jetzt auch auf die Firmware vom Ansgar zurück gegriffen, da meine Schalter mit Bewegungsmelder (HM-Sen-MDIR-WM55) nicht ordentlich gepaired werden konnten. Auch mit dem optischen Tür- und Fensterkontakt (HM-Sec-SCo) hatte ich so meine Probleme. Anfangs sah es sehr gut aus. Nachdem ich eine VCCU eingerichtet hatte und auf TSCUL umgestellt habe, konnte ich alles fast auf Anhieb pairen.

Doch ich habe Probleme damit, die Bewegungsmelder anzupassen. Also beispielsweise die Intervalle herunter zu stellen. Jetzt habe ich seit gestern folgende Einträge in meiner Log.


2016.12.17 22:30:24 1: TSCUL_ParseTsHM HM_CUL HM repeat failed sending to 4E62E2/wz.Bewegungsmelder: AFF1002CDFF020010C0A0012A4CC94E62E200
2016.12.17 22:30:31 1: TSCUL_ParseTsHM HM_CUL HM repeat failed sending to 4E5E9A/kueche.Bewegungsmelder: AFF1002CE068900100AA0012A4CC94E5E9A00
2016.12.17 22:35:09 1: TSCUL_ParseTsHM HM_CUL HM repeat failed sending to 4E5E9A/kueche.Bewegungsmelder: AFF1002CF15BD00100BA0012A4CC94E5E9A00
2016.12.17 22:35:30 1: TSCUL_ParseTsHM HM_CUL HM repeat failed sending to 4E62E2/wz.Bewegungsmelder: AFF1002CF2A220010C1A0012A4CC94E62E200
2016.12.17 23:34:29 1: TSCUL_ParseTsHM HM_CUL HM repeat failed sending to 4E62E2/wz.Bewegungsmelder: AFF1002DCAA070010C2A0012A4CC94E62E200
2016.12.17 23:44:52 1: TSCUL_ParseTsHM HM_CUL HM repeat failed sending to 4E62E2/wz.Bewegungsmelder: AFF1002DF0ABD0010C3A0012A4CC94E62E200
2016.12.17 23:45:16 1: TSCUL_ParseTsHM HM_CUL HM repeat failed sending to 4E5E9A/kueche.Bewegungsmelder: AFF1002DF21DB00100CA0012A4CC94E5E9A00
2016.12.18 01:52:29 1: TSCUL_ParseTsHM HM_CUL HM repeat failed sending to 4E5E9A/kueche.Bewegungsmelder: AFF1002FC40E400100DA0012A4CC94E5E9A00
2016.12.18 12:15:52 1: TSCUL_ParseTsHM HM_CUL HM repeat failed sending to 4E62E2/wz.Bewegungsmelder: AFF10038AF03600108EA0012A4CC94E62E200
2016.12.18 12:17:15 1: TSCUL_ParseTsHM HM_CUL HM repeat failed sending to 4E5E9A/kueche.Bewegungsmelder: AFF10038B40CC001019A0012A4CC94E5E9A00
2016.12.18 12:20:28 1: TSCUL_ParseTsHM HM_CUL HM repeat failed sending to 4E62E2/wz.Bewegungsmelder: AFF10038BFD8700108FA0012A4CC94E62E200
2016.12.18 12:36:12 1: TSCUL_ParseTsHM HM_CUL HM repeat failed sending to 4E62E2/wz.Bewegungsmelder: AFF10038F973D001090A0012A4CC94E62E200
2016.12.18 12:50:20 1: TSCUL_ParseTsHM HM_CUL HM repeat failed sending to 4E62E2/wz.Bewegungsmelder: AFF100392D312001091A0012A4CC94E62E200
2016.12.18 12:51:02 1: TSCUL_ParseTsHM HM_CUL HM repeat failed sending to 4E5E9A/kueche.Bewegungsmelder: AFF100392FC8B00101AA0012A4CC94E5E9A00
2016.12.18 13:04:34 1: TSCUL_ParseTsHM HM_CUL HM repeat failed sending to 4E5E9A/kueche.Bewegungsmelder: AFF100396157400102BA0012A4CC94E5E9A03
2016.12.18 13:08:37 1: TSCUL_ParseTsHM HM_CUL HM repeat failed sending to 4E5E9A/kueche.Bewegungsmelder: AFF1003970281001030A0012A4CC94E5E9A03
2016.12.18 13:12:40 1: TSCUL_ParseTsHM HM_CUL HM repeat failed sending to 4E5E9A/kueche.Bewegungsmelder: AFF100397F021001034A0012A4CC94E5E9A03
2016.12.18 13:16:43 1: TSCUL_ParseTsHM HM_CUL HM repeat failed sending to 4E5E9A/kueche.Bewegungsmelder: AFF100398DD2300103DA0012A4CC94E5E9A03


Jemand eine Idee?
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 18 Dezember 2016, 18:39:51
Hallo scr3tchy,

Dein mageres Log sagt, dass Dein CUL versucht, jeweils 3mal an die Bewegungsmelder zu senden, aber diese antworten nicht.
Angefortert wird allerding der aktuell Status, wenn ich das richtig sehe.

Da es bei anderen wohl funktioniert, könnte ich mir noch eine simple Fehlbedinung vorstellen.
Also, dass Du zum erfolgreichen Absetzen der Konfigurationsbefehle ebenfalls jeweils auch die Taste am Gerät mal kurz drücken musst, damit sie auch dafür aufwachen und zuhören.
Normalerweise sollten sie wohl extrem Strom sparend vor sich hin schlafen und dabei nur auf Bewegungtrigger überhaupt wach werden, denke ich.
Meine HM-SEN-MDIR-SM verhalten sich jedenfalls so, dass es nur mit Taste geht. Ein Bewegungstrigger reicht bei denen nicht, damit sie dafür noch etwas wach bleiben.

Ansonsten das Logging bitte mal mit verbose 4 beim CUL erweitern und mit einem jeweils gleichartigen Gerät Deine Versuche mitloggen und hier das Log posten.
Ansonsten bleibt die Glaskugel ziemlich finster. Ich habe leider keinen HM-Sen-MDIR-WM55 zum testen. ;)

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: scr3tchy am 19 Dezember 2016, 18:59:28
Hallo Ansgar.

Entschuldige. Dachte du könntest mit der Meldung schon etwas anfangen. :)
Also die HM-Sen-MDIR-WM55 sind gepaired, jedoch kann ich die Einstellungen am Bewegungsmelder nicht vornehmen. Wenn ich FHEM neu starte, dann sind die Register entsprechend weg. Ein getConfig reicht in dem Fall nicht aus. Ich muss in diesem Fall die Schalter in die Hand nehmen und den Anlernknopf drücken. Dann sind die Register auch entsprechend wieder da. Die Einstellungen zu dem Bewegungsmelder werden dabei jedoch nicht übernommen. Gleiches betrifft den Optischen Tür-/Fensterkontakt.

Ich habe folgendes aufgezeichnet.

2016.12.19 18:38:33.835 4: TSCUL_Parse: HM_CUL  122085 A FF01 11568484 00 0F A5 8610 4A6ED5 000000 0AA8B90F4B40 -40.5
2016.12.19 18:38:47.158 4: TSCUL_Parse: HM_CUL  135408 A FF01 11581808 00 0D F1 A241 4E62E2 2A4CC9 038B5380 -67.5
2016.12.19 18:38:47.179 4: TSCUL_send:  HM_CUL                         As 0D F1 8002 2A4CC9 4E62E2 01015300
2016.12.19 18:38:47.180 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:100 toms:77
2016.12.19 18:38:47.258 4: TSCUL_send:  HM_CUL                         As 0A F1 8002 2A4CC9 4E62E2 00
2016.12.19 18:38:47.259 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:142 toms:76
2016.12.19 18:38:47.303 4: TSCUL_Parse: HM_CUL  135554 A FF13 11581928 01 0A F1 8002 2A4CC9 4E62E2 00 _CCAdly:4 _dhmSt:120 -138
2016.12.19 18:38:47.393 4: TSCUL_Parse: HM_CUL  135644 A FF13 11582016 01 0D F1 8002 2A4CC9 4E62E2 01 _CCAdly:4 _dhmSt:208 -138
2016.12.19 18:39:02.645 4: TSCUL_Parse: HM_CUL  150896 A FF01 11597296 00 0B F2 8440 4E62E2 2A4CC9 4199 -64
2016.12.19 18:39:02.915 4: TSCUL_Parse: HM_CUL  151166 A FF01 11597564 00 0B F3 A240 4E62E2 2A4CC9 4199 -64.5
2016.12.19 18:39:02.931 4: TSCUL_send:  HM_CUL                         As 0A F3 8002 2A4CC9 4E62E2 00
2016.12.19 18:39:02.932 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:104 toms:76
2016.12.19 18:39:03.057 4: TSCUL_Parse: HM_CUL  151308 A FF13 11597684 01 0A F3 8002 2A4CC9 4E62E2 00 _CCAdly:4 _dhmSt:120 -138
2016.12.19 18:39:06.641 4: TSCUL_Parse: HM_CUL  154892 A FF01 11601292 00 0B F4 A240 4E62E2 2A4CC9 019A -64
2016.12.19 18:39:06.658 4: TSCUL_send:  HM_CUL                         As 0A F4 8002 2A4CC9 4E62E2 00
2016.12.19 18:39:06.659 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:105 toms:76
2016.12.19 18:39:06.786 4: TSCUL_Parse: HM_CUL  155037 A FF13 11601412 01 0A F4 8002 2A4CC9 4E62E2 00 _CCAdly:4 _dhmSt:120 -138
2016.12.19 18:39:09.922 4: TSCUL_Parse: HM_CUL  158169 A FF01 11604572 00 1A F5 8400 4E62E2 2A4CC9 1100DB4E45513039363332343681230000 -58.5
2016.12.19 18:39:46.501 4: TSCUL_Parse: HM_CUL  194748 A FF01 11641152 00 1A DB 8400 4F4978 000000 1000C74E45513131353430323180810101 -70
2016.12.19 18:39:46.524 4: TSCUL_send:  HM_CUL                         As 10 03 A001 2A4CC9 4F4978 00040000000000
2016.12.19 18:39:46.524 3: TSCUL_XmitDlyHM:  HM_CUL  id:4F4978 dDly:94 toms:79
2016.12.19 18:39:46.649 4: TSCUL_Parse: HM_CUL  194900 A FF13 11641272 01 10 03 A001 2A4CC9 4F4978 00 _CCAdly:4 _dhmSt:120 -138
2016.12.19 18:39:46.783 4: TSCUL_Parse: HM_CUL  195031 A FF11 11641436 00 1A DB 8400 4F4978 000000 1000C74E45513131353430323180810101 -70
2016.12.19 18:39:46.933 4: TSCUL_Parse: HM_CUL  195184 A FF13 11641556 01 10 03 A001 2A4CC9 4F4978 00 _CCAdly:4 _dhmSt:404 -138
2016.12.19 18:39:47.069 4: TSCUL_Parse: HM_CUL  195316 A FF11 11641720 00 1A 03 A010 4F4978 2A4CC9 02020109010A2A0B4C0CC9100114060000 -66.5
2016.12.19 18:39:47.093 4: TSCUL_send:  HM_CUL                         As 0A 03 8002 2A4CC9 4F4978 00
2016.12.19 18:39:47.093 3: TSCUL_XmitDlyHM:  HM_CUL  id:4F4978 dDly:94 toms:76
2016.12.19 18:39:47.171 4: TSCUL_send:  HM_CUL                         As 10 04 A001 2A4CC9 4F4978 01040000000001
2016.12.19 18:39:47.171 3: TSCUL_XmitDlyHM:  HM_CUL  id:4F4978 dDly:135 toms:79
2016.12.19 18:39:47.213 4: TSCUL_Parse: HM_CUL  195463 A FF13 11641840 01 0A 03 8002 2A4CC9 4F4978 00 _CCAdly:4 _dhmSt:120 -138
2016.12.19 18:39:47.305 4: TSCUL_Parse: HM_CUL  195556 A FF13 11641928 01 10 04 A001 2A4CC9 4F4978 01 _CCAdly:4 _dhmSt:208 -138
2016.12.19 18:39:47.434 4: TSCUL_Parse: HM_CUL  195682 A FF11 11642084 00 14 04 A010 4F4978 2A4CC9 020801209C210030060000 -67.5
2016.12.19 18:39:47.455 4: TSCUL_send:  HM_CUL                         As 0A 04 8002 2A4CC9 4F4978 00
2016.12.19 18:39:47.456 3: TSCUL_XmitDlyHM:  HM_CUL  id:4F4978 dDly:95 toms:76
2016.12.19 18:39:47.533 4: TSCUL_send:  HM_CUL                         As 0B 05 A001 2A4CC9 4F4978 0103
2016.12.19 18:39:47.533 3: TSCUL_XmitDlyHM:  HM_CUL  id:4F4978 dDly:137 toms:76
2016.12.19 18:39:47.577 4: TSCUL_Parse: HM_CUL  195828 A FF13 11642204 01 0A 04 8002 2A4CC9 4F4978 00 _CCAdly:4 _dhmSt:120 -138
2016.12.19 18:39:47.665 4: TSCUL_Parse: HM_CUL  195916 A FF13 11642292 01 0B 05 A001 2A4CC9 4F4978 01 _CCAdly:4 _dhmSt:208 -138
2016.12.19 18:39:47.793 4: TSCUL_Parse: HM_CUL  196042 A FF11 11642444 00 0E 05 A010 4F4978 2A4CC9 0100000000 -66
2016.12.19 18:39:47.811 4: TSCUL_send:  HM_CUL                         As 0A 05 8002 2A4CC9 4F4978 00
2016.12.19 18:39:47.812 3: TSCUL_XmitDlyHM:  HM_CUL  id:4F4978 dDly:99 toms:76
2016.12.19 18:39:47.937 4: TSCUL_Parse: HM_CUL  196188 A FF13 11642564 01 0A 05 8002 2A4CC9 4F4978 00 _CCAdly:4 _dhmSt:120 -138
2016.12.19 18:40:09.262 4: TSCUL_Parse: HM_CUL  217512 A FF01 11663916 00 0D 7B A241 4E5E9A 2A4CC9 03A50080 -78.5
2016.12.19 18:40:09.278 4: TSCUL_send:  HM_CUL                         As 0D 7B 8002 2A4CC9 4E5E9A 01010000
2016.12.19 18:40:09.278 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E5E9A dDly:103 toms:77
2016.12.19 18:40:09.402 4: TSCUL_send:  HM_CUL                         As 0A 7B 8002 2A4CC9 4E5E9A 00
2016.12.19 18:40:09.403 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E5E9A dDly:99 toms:76
2016.12.19 18:40:09.411 4: TSCUL_Parse: HM_CUL  217661 A FF13 11664036 01 0D 7B 8002 2A4CC9 4E5E9A 01 _CCAdly:4 _dhmSt:120 -138
2016.12.19 18:40:09.503 4: TSCUL_Parse: HM_CUL  217754 A FF13 11664132 02 0A 7B 8002 2A4CC9 4E5E9A 00 _CCAdly:8 _dhmSt:216 -138
2016.12.19 18:41:31.586 4: TSCUL_Parse: HM_CUL  299835 A FF01 11746240 00 0F A6 8610 4A6ED5 000000 0AA8B90F4B40 -42
2016.12.19 18:42:40.654 4: TSCUL_Parse: HM_CUL  368904 A FF01 11815312 00 0B F6 A240 4E62E2 2A4CC9 026A -65.5
2016.12.19 18:42:40.670 4: TSCUL_send:  HM_CUL                         As 0A F6 8002 2A4CC9 4E62E2 00
2016.12.19 18:42:40.671 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:106 toms:76
2016.12.19 18:42:40.800 4: TSCUL_Parse: HM_CUL  369050 A FF13 11815432 01 0A F6 8002 2A4CC9 4E62E2 00 _CCAdly:4 _dhmSt:120 -138
2016.12.19 18:42:43.893 4: TSCUL_Parse: HM_CUL  372143 A FF01 11818552 00 0B F7 A240 4E62E2 2A4CC9 019B -73.5
2016.12.19 18:42:43.909 4: TSCUL_send:  HM_CUL                         As 0A F7 8002 2A4CC9 4E62E2 00
2016.12.19 18:42:43.910 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:106 toms:76
2016.12.19 18:42:44.039 4: TSCUL_Parse: HM_CUL  372290 A FF13 11818672 01 0A F7 8002 2A4CC9 4E62E2 00 _CCAdly:4 _dhmSt:120 -138
2016.12.19 18:42:47.803 4: TSCUL_Parse: HM_CUL  376054 A FF01 11822460 00 0B F8 A240 4E62E2 2A4CC9 019C -68
2016.12.19 18:42:47.820 4: TSCUL_send:  HM_CUL                         As 0A F8 8002 2A4CC9 4E62E2 00
2016.12.19 18:42:47.820 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:103 toms:76
2016.12.19 18:42:47.947 4: TSCUL_Parse: HM_CUL  376198 A FF13 11822580 01 0A F8 8002 2A4CC9 4E62E2 00 _CCAdly:4 _dhmSt:120 -138
2016.12.19 18:42:48.824 4: TSCUL_Parse: HM_CUL  377075 A FF11 11823480 00 0B F9 A240 4E62E2 2A4CC9 026B -69
2016.12.19 18:42:48.840 4: TSCUL_send:  HM_CUL                         As 0A F9 8002 2A4CC9 4E62E2 00
2016.12.19 18:42:48.841 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:102 toms:76
2016.12.19 18:42:48.982 4: TSCUL_Parse: HM_CUL  377233 A FF13 11823600 01 0A F9 8002 2A4CC9 4E62E2 00 _CCAdly:4 _dhmSt:120 -138
2016.12.19 18:42:49.165 4: TSCUL_Parse: HM_CUL  377416 A FF11 11823824 00 0B FA A240 4E62E2 2A4CC9 019D -65
2016.12.19 18:42:49.182 4: TSCUL_send:  HM_CUL                         As 0A FA 8002 2A4CC9 4E62E2 00
2016.12.19 18:42:49.183 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:104 toms:76
2016.12.19 18:42:49.310 4: TSCUL_Parse: HM_CUL  377561 A FF13 11823944 01 0A FA 8002 2A4CC9 4E62E2 00 _CCAdly:4 _dhmSt:120 -138
2016.12.19 18:42:49.545 4: TSCUL_Parse: HM_CUL  377796 A FF11 11824204 00 0B FB A240 4E62E2 2A4CC9 019E -64.5
2016.12.19 18:42:49.560 4: TSCUL_send:  HM_CUL                         As 0A FB 8002 2A4CC9 4E62E2 00
2016.12.19 18:42:49.561 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:106 toms:76
2016.12.19 18:42:49.690 4: TSCUL_Parse: HM_CUL  377942 A FF13 11824324 01 0A FB 8002 2A4CC9 4E62E2 00 _CCAdly:4 _dhmSt:120 -138
2016.12.19 18:42:52.589 4: TSCUL_Parse: HM_CUL  380839 A FF11 11827248 00 0D FC A241 4E62E2 2A4CC9 038C5380 -74
2016.12.19 18:42:52.606 4: TSCUL_send:  HM_CUL                         As 0D FC 8002 2A4CC9 4E62E2 01015300
2016.12.19 18:42:52.606 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:104 toms:77
2016.12.19 18:42:52.685 4: TSCUL_send:  HM_CUL                         As 0A FC 8002 2A4CC9 4E62E2 00
2016.12.19 18:42:52.686 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:145 toms:76
2016.12.19 18:42:52.735 4: TSCUL_Parse: HM_CUL  380986 A FF13 11827368 01 0A FC 8002 2A4CC9 4E62E2 00 _CCAdly:4 _dhmSt:120 -138
2016.12.19 18:42:52.766 4: TSCUL_send:  HM_CUL                         As 10 FD A001 2A4CC9 4E62E2 00040000000000
2016.12.19 18:42:52.766 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:64 toms:79
2016.12.19 18:42:52.825 4: TSCUL_Parse: HM_CUL  381076 A FF13 11827456 01 0D FC 8002 2A4CC9 4E62E2 01 _CCAdly:4 _dhmSt:208 -138
2016.12.19 18:42:52.919 4: TSCUL_Parse: HM_CUL  381170 A FF13 11827548 01 10 FD A001 2A4CC9 4E62E2 00 _CCAdly:4 _dhmSt:300 -138
2016.12.19 18:42:53.172 4: TSCUL_Parse: HM_CUL  381423 A FF13 11827800 01 10 FD A001 2A4CC9 4E62E2 00 _CCAdly:4 _dhmSt:552 -138
2016.12.19 18:42:53.388 1: TSCUL_ParseTsHM HM_CUL HM repeat failed sending to 4E62E2/wz.Bewegungsmelder: AFF10052D1ED40010FDA0012A4CC94E62E200
2016.12.19 18:42:53.389 4: TSCUL_Parse: HM_CUL  381639 A FF10 11828048 00 10 FD A001 2A4CC9 4E62E2 00 _sfail -138
2016.12.19 18:43:01.926 4: TSCUL_Parse: HM_CUL  390177 A FF11 11836584 00 0B FD 8440 4E62E2 2A4CC9 426C -72.5
2016.12.19 18:43:02.197 4: TSCUL_Parse: HM_CUL  390448 A FF11 11836856 00 0B FE A240 4E62E2 2A4CC9 426C -69
2016.12.19 18:43:02.214 4: TSCUL_send:  HM_CUL                         As 0A FE 8002 2A4CC9 4E62E2 00
2016.12.19 18:43:02.214 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:104 toms:76
2016.12.19 18:43:02.342 4: TSCUL_Parse: HM_CUL  390593 A FF13 11836976 01 0A FE 8002 2A4CC9 4E62E2 00 _CCAdly:4 _dhmSt:120 -138
2016.12.19 18:43:05.781 4: TSCUL_Parse: HM_CUL  394031 A FF11 11840436 00 0B FF 8440 4E62E2 2A4CC9 426D -68.5
2016.12.19 18:43:06.051 4: TSCUL_Parse: HM_CUL  394301 A FF11 11840708 00 0B 00 A240 4E62E2 2A4CC9 426D -70.5
2016.12.19 18:43:06.067 4: TSCUL_send:  HM_CUL                         As 0A 00 8002 2A4CC9 4E62E2 00
2016.12.19 18:43:06.067 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:104 toms:76
2016.12.19 18:43:06.194 4: TSCUL_Parse: HM_CUL  394445 A FF13 11840828 01 0A 00 8002 2A4CC9 4E62E2 00 _CCAdly:4 _dhmSt:120 -138
2016.12.19 18:43:10.888 4: TSCUL_Parse: HM_CUL  399139 A FF11 11845544 00 0B 01 8440 4E62E2 2A4CC9 419F -68.5
2016.12.19 18:43:11.159 4: TSCUL_Parse: HM_CUL  399410 A FF11 11845816 00 0B 02 8440 4E62E2 2A4CC9 419F -66.5
2016.12.19 18:43:11.431 4: TSCUL_Parse: HM_CUL  399681 A FF11 11846088 00 0B 03 A240 4E62E2 2A4CC9 419F -64.5
2016.12.19 18:43:11.447 4: TSCUL_send:  HM_CUL                         As 0A 03 8002 2A4CC9 4E62E2 00
2016.12.19 18:43:11.448 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:102 toms:76
2016.12.19 18:43:11.574 4: TSCUL_Parse: HM_CUL  399825 A FF13 11846208 01 0A 03 8002 2A4CC9 4E62E2 00 _CCAdly:4 _dhmSt:120 -138
2016.12.19 18:44:14.834 4: TSCUL_Parse: HM_CUL  463084 A FF01 11909496 00 0F A7 8610 4A6ED5 000000 0AA8BA0F4B40 -39.5


Nachfolgend die Konfigurationen zu den Geräten

Internals:
   DEF        4E62E2
   HM_CUL_MSGCNT 431
   HM_CUL_RAWMSG A0B03A2404E62E22A4CC9419F::-64.5:HM_CUL
   HM_CUL_RSSI -64.5
   HM_CUL_TIME 2016-12-19 18:43:11
   IODev      HM_CUL
   LASTInputDev HM_CUL
   MSGCNT     431
   NAME       wz.Bewegungsmelder
   NOTIFYDEV  global
   NR         35
   NTFY_ORDER 50-wz.Bewegungsmelder
   STATE      CMDs_pending
   TYPE       CUL_HM
   channel_01 wz.Bewegungsmelder_Btn_01
   channel_02 wz.Bewegungsmelder_Btn_02
   channel_03 wz.Bewegungsmelder_Motion
   lastMsg    No:03 - t:40 s:4E62E2 d:2A4CC9 419F
   protCmdDel 21
   protCmdPend 7 CMDs pending
   protLastRcv 2016-12-19 18:43:11
   protResnd  10 last_at:2016-12-19 18:42:58
   protResndFail 3 last_at:2016-12-18 22:31:48
   protSnd    387 last_at:2016-12-19 18:43:11
   protState  CMDs_pending
   rssi_at_HM_CUL min:-84.5 max:-53.5 cnt:431 avg:-63.4 lst:-64.5
   Helper:
     Dblog:
       State:
         Logdb:
           TIME       1482169378.62407
           VALUE      CMDs_pending
   Readings:
     2016-12-12 18:46:47   CommandAccepted yes
     2016-12-19 18:39:09   D-firmware      1.1
     2016-12-19 18:39:09   D-serialNr      NEQ0963246
     2016-12-15 21:18:53   PairedTo        0x2A4CC9
     2016-12-15 18:35:43   R-pairCentral   0x2A4CC9
     2016-12-19 18:45:10   RegL_00.
     2016-12-19 18:42:58   state           CMDs_pending
   cmdStack:
     ++A0012A4CC94E62E200040000000000
     ++A0012A4CC94E62E201040000000001
     ++A0012A4CC94E62E20103
     ++A0012A4CC94E62E202040000000001
     ++A0012A4CC94E62E20203
     ++A0012A4CC94E62E203040000000001
     ++A0012A4CC94E62E20303
   Helper:
     HM_CMDNR   3
     cSnd       012A4CC94E62E200040000000000,012A4CC94E62E200040000000000
     mId        00DB
     rxType     28
     supp_Pair_Rep 0
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       dwoCAA     116
       lRcTm      347390408
       lstRecType 40
       lstSnd     1482169391.54229
       lstSndTgd  120
       newChn     +4E62E2,02,01,00
       nextSend   1482169391.54229
       nxtSndMcnt 03
       rxt        2
       tgtDly     120
       vccu       VCCU
       p:
         4E62E2
         00
         01
         00
       prefIO:
         HM_CUL
     Mrssi:
       mNo        03
       Io:
         HM_CUL     -62.5
     Prt:
       bErr       0
       sProc      2
       wuReSent   2
     Q:
       qReqConf
       qReqStat
     Role:
       dev        1
     Rpt:
       IO         HM_CUL
       flg        A
       ts         1482169391.43591
       ack:
         HASH(0x2f65218)
         0380022A4CC94E62E200
     Rssi:
       At_hm_cul:
         avg        -63.4060324825986
         cnt        431
         lst        -64.5
         max        -53.5
         min        -84.5
     Tmpl:
Attributes:
   IODev      HM_CUL
   IOgrp      VCCU:HM_CUL
   autoReadReg 4_reqStatus
   event-on-change-reading .*
   expert     2_raw
   firmware   1.1
   group      Bewegungserkennung
   model      HM-Sen-MDIR-WM55
   room       Wohnzimmer
   serialNr   NEQ0963246
   subType    motionAndBtn
   webCmd     getConfig:clear msgEvents


Internals:
   CHANGED
   DEF        4E5E9A
   HM_CUL_MSGCNT 171
   HM_CUL_RAWMSG A0D7BA2414E5E9A2A4CC903A50080::-78.5:HM_CUL
   HM_CUL_RSSI -78.5
   HM_CUL_TIME 2016-12-19 18:40:09
   IODev      HM_CUL
   LASTInputDev HM_CUL
   MSGCNT     171
   NAME       kueche.Bewegungsmelder
   NOTIFYDEV  global
   NR         39
   NTFY_ORDER 50-kueche.Bewegungsmelder
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 kueche.Bewegungsmelder_Btn_01
   channel_02 kueche.Bewegungsmelder_Btn_02
   channel_03 kueche.Bewegungsmelder_Motion
   lastMsg    No:7B - t:41 s:4E5E9A d:2A4CC9 03A50080
   protCmdDel 10
   protLastRcv 2016-12-19 18:40:09
   protResnd  8 last_at:2016-12-18 13:12:44
   protResndFail 2 last_at:2016-12-18 13:16:45
   protSnd    213 last_at:2016-12-19 18:40:09
   protState  CMDs_done
   rssi_at_HM_CUL max:-65.5 min:-105 cnt:171 lst:-78.5 avg:-75.74
   Helper:
     Dblog:
       State:
         Logdb:
           TIME       1482063644.93189
           VALUE      CMDs_done
   Readings:
     2016-12-15 19:44:20   CommandAccepted yes
     2016-12-18 12:52:37   D-firmware      1.1
     2016-12-18 12:52:37   D-serialNr      NEQ0964342
     2016-12-18 12:52:37   PairedTo        0x2A4CC9
     2016-12-15 19:45:03   R-pairCentral   0x2A4CC9
     2016-12-18 12:52:37   RegL_00.          02:01 0A:2A 0B:4C 0C:C9 14:03 18:00 00:00
     2016-12-19 18:40:09   state           CMDs_done
   Helper:
     HM_CMDNR   123
     cSnd       012A4CC94E5E9A03050000000001,012A4CC94E5E9A03050000000001
     mId        00DB
     rxType     28
     supp_Pair_Rep 0
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       dwoCAA     116
       lRcTm      347208236
       lstRecType 41
       lstSnd     1482169209.37404
       lstSndTgd  240
       newChn     +4E5E9A,00,01,00
       nextSend   1482169209.37404
       nxtSndMcnt 7B
       rxt        2
       tgtDly     120
       vccu       VCCU
       p:
         4E5E9A
         00
         01
         00
       prefIO:
         HM_CUL
     Mrssi:
       mNo        7B
       Io:
         HM_CUL     -76.5
     Prt:
       bErr       0
       sProc      0
       sleeping   1
       Rspwait:
     Q:
       qReqConf   03
       qReqStat
     Role:
       dev        1
     Rpt:
       IO         HM_CUL
       flg        A
       ts         1482169209.2666
       ack:
         HASH(0x30ccaa8)
         7B80022A4CC94E5E9A01010000
         HASH(0x30ccaa8)
         7B80022A4CC94E5E9A00
     Rssi:
       At_hm_cul:
         avg        -75.7426900584795
         cnt        171
         lst        -78.5
         max        -65.5
         min        -105
     Shadowreg:
     Tmpl:
Attributes:
   IODev      HM_CUL
   IOgrp      VCCU:HM_CUL
   autoReadReg 4_reqStatus
   event-on-change-reading .*
   expert     2_raw
   firmware   1.1
   group      Bewegungserkennung
   model      HM-Sen-MDIR-WM55
   room       Küche
   serialNr   NEQ0964342
   subType    motionAndBtn
   webCmd     getConfig:clear msgEvents


Internals:
   CHANGED
   DEF        4F4978
   HM_CUL_MSGCNT 74
   HM_CUL_RAWMSG A0D06A6104F49782A4CC906010000::-68.5:HM_CUL
   HM_CUL_RSSI -68.5
   HM_CUL_TIME 2016-12-19 18:56:50
   IODev      HM_CUL
   LASTInputDev HM_CUL
   MSGCNT     74
   NAME       flur.Kontakt_Eingangstuer
   NOTIFYDEV  global
   NR         34
   NTFY_ORDER 50-flur.Kontakt_Eingangstuer
   STATE      closed
   TYPE       CUL_HM
   lastMsg    No:06 - t:10 s:4F4978 d:2A4CC9 06010000
   protCmdPend 3 CMDs pending
   protLastRcv 2016-12-19 18:56:50
   protSnd    75 last_at:2016-12-19 18:56:50
   protState  CMDs_pending
   rssi_at_HM_CUL lst:-68.5 avg:-66.71 cnt:74 max:-64 min:-71.5
   Helper:
     Dblog:
       Contact:
         Logdb:
           TIME       1482166184.82987
           VALUE      closed (to VCCU)
       State:
         Logdb:
           TIME       1482166184.82987
           VALUE      closed
       Trigger_cnt:
         Logdb:
           TIME       1482166184.82987
           VALUE      71
   Readings:
     2016-12-19 18:39:46   Activity        alive
     2016-12-12 18:37:27   CommandAccepted yes
     2016-12-19 18:39:46   D-firmware      1.0
     2016-12-19 18:39:46   D-serialNr      NEQ1154021
     2016-12-19 18:39:47   PairedTo        0x2A4CC9
     2016-12-12 18:37:27   R-cyclicInfoMsg on
     2016-12-12 18:37:28   R-eventDlyTime  0 s
     2016-12-15 19:41:33   R-pairCentral   0x2A4CC9
     2016-12-12 18:37:27   R-sabotageMsg   on
     2016-12-12 18:37:28   R-sign          on
     2016-12-12 18:35:45   aesCommToDev    ok
     2016-12-15 18:52:26   aesKeyNbr       02
     2016-12-19 18:56:50   alive           yes
     2016-12-19 18:56:50   battery         ok
     2016-12-19 18:56:50   contact         closed (to VCCU)
     2016-12-19 18:56:50   recentStateType info
     2016-12-19 18:56:50   sabotageError   off
     2016-12-19 18:56:50   state           closed
     2016-12-19 17:49:44   trigger_cnt     71
   cmdStack:
     ++A0012A4CC94F497800040000000000
     ++A0012A4CC94F497801040000000001
     ++A0012A4CC94F49780103
   Helper:
     HM_CMDNR   6
     cSnd       012A4CC94F497801040000000001,012A4CC94F49780103
     getCfgList all
     getCfgListNo ,4
     mId        00C7
     peerIDsRaw ,00000000
     rxType     28
     supp_Pair_Rep 0
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       dwoCAA     116
       lRcTm      348209932
       lstRecType 10
       lstSnd     1482170211.04291
       lstSndTgd  120
       newChn     +4F4978,02,01,00
       nextSend   1482170211.04291
       nxtSndMcnt 06
       rxt        2
       tgtDly     120
       vccu       VCCU
       p:
         4F4978
         00
         01
         00
       prefIO:
         HM_CUL
     Mrssi:
       mNo        06
       Io:
         HM_CUL     -66.5
     Prt:
       bErr       0
       sProc      2
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         HM_CUL
       flg        A
       ts         1482170210.93736
       ack:
         HASH(0x2f648a0)
         0680022A4CC94F497800
     Rssi:
       At_hm_cul:
         avg        -66.7162162162162
         cnt        74
         lst        -68.5
         max        -64
         min        -71.5
     Shadowreg:
     Tmpl:
Attributes:
   IODev      HM_CUL
   IOgrp      VCCU:HM_CUL
   actCycle   002:50
   actStatus  alive
   alias      Eingangstür
   autoReadReg 4_reqStatus
   event-on-change-reading .*
   expert     2_raw
   firmware   1.0
   group      Bewegungserkennung
   model      HM-SEC-SCo
   peerIDs    00000000,
   room       Sicherheit,Flur
   serialNr   NEQ1154021
   subType    threeStateSensor


So mehr Informationen kann ich dir glaube ich nicht liefern. :)
Kannst du daraus mehr erkennen? Oder kann ich dir noch etwas liefern?

Vielen Dank für deine Unterstützung! ;D
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 19 Dezember 2016, 21:03:27
Hallo scr3tchy,

danke für das Log. Damit kann ich schon etwas anfangen.

Hier
2016.12.19 18:42:52.589 4: TSCUL_Parse: HM_CUL  380839 A FF11 11827248 00 0D FC A241 4E62E2 2A4CC9 038C5380 -74
2016.12.19 18:42:52.606 4: TSCUL_send:  HM_CUL                         As 0D FC 8002 2A4CC9 4E62E2 01015300
2016.12.19 18:42:52.606 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:104 toms:77
2016.12.19 18:42:52.685 4: TSCUL_send:  HM_CUL                         As 0A FC 8002 2A4CC9 4E62E2 00
2016.12.19 18:42:52.686 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:145 toms:76
2016.12.19 18:42:52.735 4: TSCUL_Parse: HM_CUL  380986 A FF13 11827368 01 0A FC 8002 2A4CC9 4E62E2 00 _CCAdly:4 _dhmSt:120 -138
2016.12.19 18:42:52.766 4: TSCUL_send:  HM_CUL                         As 10 FD A001 2A4CC9 4E62E2 00040000000000
2016.12.19 18:42:52.766 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:64 toms:79
2016.12.19 18:42:52.825 4: TSCUL_Parse: HM_CUL  381076 A FF13 11827456 01 0D FC 8002 2A4CC9 4E62E2 01 _CCAdly:4 _dhmSt:208 -138
2016.12.19 18:42:52.919 4: TSCUL_Parse: HM_CUL  381170 A FF13 11827548 01 10 FD A001 2A4CC9 4E62E2 00 _CCAdly:4 _dhmSt:300 -138
2016.12.19 18:42:53.172 4: TSCUL_Parse: HM_CUL  381423 A FF13 11827800 01 10 FD A001 2A4CC9 4E62E2 00 _CCAdly:4 _dhmSt:552 -138
2016.12.19 18:42:53.388 1: TSCUL_ParseTsHM HM_CUL HM repeat failed sending to 4E62E2/wz.Bewegungsmelder: AFF10052D1ED40010FDA0012A4CC94E62E200

geht was schief, weil die zweite Sendenachricht vor der ersten raus geht.

Von FHEM kommt die zweite etwas unglücklich früh, so dass sie dann dummerweise zuerst beim Senden ran kommt da sie die gleiche Messagenummer hat.
Das habe ich in der Firmware so noch nicht berücksichtigt, weil es mir bisher noch nicht aufgefallen ist.
Mal schauen, wie ich das recourcenschonend noch einbauen kann. Das beißt sich leider mit meiner AES Antwortlogik, wo es im Pufferhandling genau so sein muss (das ist genauso ungeschickt mit gleicher Messagenummer im Protkoll eingbaut).

Gruß, Ansgar.

Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 20 Dezember 2016, 16:15:03
Hallo scr3tchy,

an bekannter Stelle https://forum.fhem.de/index.php/topic,24436.msg529649.html#msg529649 (https://forum.fhem.de/index.php/topic,24436.msg529649.html#msg529649) ein Update V0.05, was zumindest das Problem mit der Sendereihenfolge beheben sollte (+ ein weiterer Bug in der Nachrichtenwarteschlange ist auch behoben).

Kannst Du damit bitte nochmal testen und wieder Logs schicken?
Ich kann es bei mir nicht provozieren.

Übrigens gibt es mit HM_Info aut autosave die Möglichkeit, die Registerwerte über einen Neustart von FHEM zu retten. Dann müssen die nicht jedes mal per getConfig geholt werden.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Maxl am 20 Dezember 2016, 16:55:30
Hallo Ansgar,

ich hätte da auch ein kleines Problem mit der V0.4 und den Bewegungsmeldern.
Es sind zwei verbunden, welche verschwinden und dann wiederkommen. Der
Actiondetector erkennt sie immer als nicht vorhanden.

Was muß ich in der board.h ändern um diese Version zu probieren, aktuell kompiliert und eingespielt geht diese bei mir nicht.

2016-12-20_15:09:25 Bewegungsmelder_UG brightness: 195
2016-12-20_15:09:25 Bewegungsmelder_UG cover: closed
2016-12-20_15:25:00 Bewegungsmelder_UG battery: ok
2016-12-20_15:25:00 Bewegungsmelder_UG brightness: 190
2016-12-20_15:25:00 Bewegungsmelder_UG cover: closed
2016-12-20_15:35:08 Bewegungsmelder_UG Activity: dead
2016-12-20_15:37:29 Bewegungsmelder_UG battery: ok
2016-12-20_15:37:29 Bewegungsmelder_UG brightness: 183
2016-12-20_15:37:29 Bewegungsmelder_UG cover: closed
2016-12-20_15:42:54 Bewegungsmelder_UG battery: ok
2016-12-20_15:42:54 Bewegungsmelder_UG brightness: 180
2016-12-20_15:42:54 Bewegungsmelder_UG cover: closed
2016-12-20_15:45:09 Bewegungsmelder_UG Activity: alive
2016-12-20_15:55:09 Bewegungsmelder_UG Activity: dead
2016-12-20_16:06:23 Bewegungsmelder_UG battery: ok
2016-12-20_16:06:23 Bewegungsmelder_UG brightness: 159
2016-12-20_16:06:23 Bewegungsmelder_UG cover: closed
2016-12-20_16:15:09 Bewegungsmelder_UG Activity: alive
2016-12-20_16:25:09 Bewegungsmelder_UG Activity: dead
2016-12-20_16:28:27 Bewegungsmelder_UG battery: ok
2016-12-20_16:28:27 Bewegungsmelder_UG brightness: 132
2016-12-20_16:28:27 Bewegungsmelder_UG cover: closed
2016-12-20_16:35:09 Bewegungsmelder_UG Activity: alive
2016-12-20_16:45:09 Bewegungsmelder_UG Activity: dead
2016-12-20_16:51:25 Bewegungsmelder_UG battery: ok
2016-12-20_16:51:25 Bewegungsmelder_UG brightness: 78
2016-12-20_16:51:25 Bewegungsmelder_UG cover: closed


Gruß
Mario
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 20 Dezember 2016, 18:13:08
Hallo Maxl,

ZitatEs sind zwei verbunden, welche verschwinden und dann wiederkommen. Der
Dann musst Du den Aktivitätstimeout höher einstellen oder Dich mehr bewegen.  ;)
Wenn keine Bewegung, dann senden die wohl auch nichts, um Strom zu sparen.
attr HM_Bewegunsmelder actCycle 24:00

ZitatWas muß ich in der board.h ändern um diese Version zu probieren, aktuell kompiliert und eingespielt geht diese bei mir nicht.
Hast Du mal die vorcompilierte geflasht?
Was geht nicht?

Was sagt das Log? Meldet der nanoCUL sich gar nicht?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Maxl am 20 Dezember 2016, 19:37:54
Hallo,


ok probiere ich
Zitatattr HM_Bewegunsmelder actCycle 24:00
gleich mal

hier das Logfile
2016.12.20 19:35:30.469 2: eventTypes: loaded 995 events from ./log/eventTypes.txt
2016.12.20 19:35:30.489 2: TSCUL_Parse: nanoCUL new condition disconnected
2016.12.20 19:35:30.490 3: Opening nanoCUL device /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
2016.12.20 19:35:30.498 3: DevIoTS_OpenDev: Setting nanoCUL serial parameters to 38400,8,N,1
2016.12.20 19:35:31.302 1: nanoCUL is VERSION_TS, VTS 0.05 nanoCUL868, nanoCUL_V1.x
2016.12.20 19:35:31.330 3: nanoCUL: Possible commands: ABCEFGJKMRUVWXYZefilmtx
2016.12.20 19:35:31.362 2: TSCUL_Parse: nanoCUL new condition init
2016.12.20 19:35:31.393 2: nanoCUL: unknown message ? (T01 is unknown) Use one of A B C E F G J K M R U V W X Y Z e f i l m t x
2016.12.20 19:35:36.401 1: DevIoTS_OpenDev: Cannot init /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0, ignoring it (nanoCUL)
2016.12.20 19:35:36.458 2: TSCUL_Parse: nanoCUL new condition init
2016.12.20 19:35:36.459 2: Switched nanoCUL rfmode to HomeMatic
2016.12.20 19:35:36.468 3: Opening NETIO1 device 192.168.1.98:2701
2016.12.20 19:35:36.473 3: NETIO1 device opened
2016.12.20 19:35:36.517 3: Opening NETIO2 device 192.168.1.99:2701
2016.12.20 19:35:36.521 3: NETIO2 device opened
2016.12.20 19:35:36.569 2: HM_LAN_WIRED: Assigned 00011169 as HMW_IO_12_Sw14_DR_LEQ1322965
2016.12.20 19:35:37.174 2: HM_LAN_WIRED: Assigned 00012465 as HMW_IO_12_Sw14_DR_MEQ0370281
2016.12.20 19:35:37.940 1: Including ./log/fhem.save
2016.12.20 19:35:38.965 4: name: /fhem?cmd=style%20edit%20fhem.cfg&save=Save+fhem.cfg&saveName=fhem.cfg&cmd=style+save+fhem.cfg+&
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: scr3tchy am 20 Dezember 2016, 19:48:24
Moin Ansgar.

Gleich zwei Patienten was?  :P

Ich habe geflasht. Hier meine aktuelle Log.


2016.12.20 19:25:08 2: TSCUL_Parse: HM_CUL new condition disconnected
2016.12.20 19:25:09 1: HM_CUL is VERSION_TS, VTS 0.05 CUL868, CUL_V3.4
2016.12.20 19:25:09 2: TSCUL_Parse: HM_CUL new condition init
2016.12.20 19:25:09 2: TSCUL_Parse: HM_CUL new condition init
2016.12.20 19:25:09 2: Switched HM_CUL rfmode to HomeMatic
2016.12.20 19:25:12 1: Including ./log/fhem.save
2016.12.20 19:25:17 1: usb create starting
2016.12.20 19:25:18 1: usb create end
2016.12.20 19:25:18 2: SecurityCheck:  WEB,WEBphone,WEBtablet has no associated allowed device with basicAuth. telnetPort has no associated allowed device with password/globalpassword.  Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2016.12.20 19:25:18 0: Featurelevel: 5.7
2016.12.20 19:25:18 0: Server started with 81 defined entities (fhem.pl:12719/2016-12-06 perl:5.020002 os:linux user:fhem pid:25424)
2016.12.20 19:25:18 2: TSCUL_Parse: HM_CUL new condition ok
2016.12.20 19:35:45.638 4: TSCUL_Parse: HM_CUL  300640 A FF21 00701820 00 0D 61 A241 4E62E2 2A4CC9 03CA5480 -65.5
2016.12.20 19:35:45.655 4: TSCUL_send:  HM_CUL                         As 0D 61 8002 2A4CC9 4E62E2 01015400
2016.12.20 19:35:45.656 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:102 toms:77
2016.12.20 19:35:45.735 4: TSCUL_send:  HM_CUL                         As 0A 61 8002 2A4CC9 4E62E2 00
2016.12.20 19:35:45.735 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:144 toms:76
2016.12.20 19:35:45.783 4: TSCUL_Parse: HM_CUL  300786 A FF23 00701940 01 0D 61 8002 2A4CC9 4E62E2 01 _CCAdly:4 _dhmSt:120 -138
2016.12.20 19:35:45.812 4: TSCUL_send:  HM_CUL                         As 10 62 A001 2A4CC9 4E62E2 00040000000000
2016.12.20 19:35:45.813 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:65 toms:79
2016.12.20 19:35:45.873 4: TSCUL_Parse: HM_CUL  300876 A FF23 00702032 01 0A 61 8002 2A4CC9 4E62E2 00 _CCAdly:4 _dhmSt:212 -138
2016.12.20 19:35:45.965 4: TSCUL_Parse: HM_CUL  300968 A FF23 00702120 01 10 62 A001 2A4CC9 4E62E2 00 _CCAdly:4 _dhmSt:300 -138
2016.12.20 19:35:46.217 4: TSCUL_Parse: HM_CUL  301220 A FF23 00702372 01 10 62 A001 2A4CC9 4E62E2 00 _CCAdly:4 _dhmSt:552 -138
2016.12.20 19:35:46.469 4: TSCUL_Parse: HM_CUL  301472 A FF23 00702624 01 10 62 A001 2A4CC9 4E62E2 00 _CCAdly:4 _dhmSt:804 -138
2016.12.20 19:35:46.685 1: TSCUL_ParseTsHM HM_CUL HM repeat failed sending to 4E62E2/wz.Bewegungsmelder: AFF200002AE66001062A0012A4CC94E62E200
2016.12.20 19:35:46.686 4: TSCUL_Parse: HM_CUL  301689 A FF20 00702872 00 10 62 A001 2A4CC9 4E62E2 00 _sfail -138
2016.12.20 19:35:58.080 4: TSCUL_Parse: HM_CUL  313080 A FF21 00714264 00 1A 27 8400 4F4978 000000 1000C74E45513131353430323180810101 -70
2016.12.20 19:35:58.102 4: TSCUL_send:  HM_CUL                         As 10 4F A001 2A4CC9 4F4978 00040000000000
2016.12.20 19:35:58.102 3: TSCUL_XmitDlyHM:  HM_CUL  id:4F4978 dDly:96 toms:79
2016.12.20 19:35:58.229 4: TSCUL_Parse: HM_CUL  313232 A FF23 00714384 01 10 4F A001 2A4CC9 4F4978 00 _CCAdly:4 _dhmSt:120 -138
2016.12.20 19:35:58.363 4: TSCUL_Parse: HM_CUL  313363 A FF21 00714548 00 1A 4F A010 4F4978 2A4CC9 02020109010A2A0B4C0CC9100114060000 -68
2016.12.20 19:35:58.384 4: TSCUL_send:  HM_CUL                         As 0A 4F 8002 2A4CC9 4F4978 00
2016.12.20 19:35:58.384 3: TSCUL_XmitDlyHM:  HM_CUL  id:4F4978 dDly:98 toms:76
2016.12.20 19:35:58.461 4: TSCUL_send:  HM_CUL                         As 10 50 A001 2A4CC9 4F4978 01040000000001
2016.12.20 19:35:58.462 3: TSCUL_XmitDlyHM:  HM_CUL  id:4F4978 dDly:139 toms:79
2016.12.20 19:35:58.508 4: TSCUL_Parse: HM_CUL  313511 A FF23 00714668 01 0A 4F 8002 2A4CC9 4F4978 00 _CCAdly:4 _dhmSt:120 -138
2016.12.20 19:35:58.601 4: TSCUL_Parse: HM_CUL  313604 A FF23 00714756 01 10 50 A001 2A4CC9 4F4978 01 _CCAdly:4 _dhmSt:208 -138
2016.12.20 19:35:58.729 4: TSCUL_Parse: HM_CUL  313729 A FF21 00714912 00 14 50 A010 4F4978 2A4CC9 020801209C210030060000 -69
2016.12.20 19:35:58.748 4: TSCUL_send:  HM_CUL                         As 0A 50 8002 2A4CC9 4F4978 00
2016.12.20 19:35:58.749 3: TSCUL_XmitDlyHM:  HM_CUL  id:4F4978 dDly:99 toms:76
2016.12.20 19:35:58.826 4: TSCUL_send:  HM_CUL                         As 0B 51 A001 2A4CC9 4F4978 0103
2016.12.20 19:35:58.826 3: TSCUL_XmitDlyHM:  HM_CUL  id:4F4978 dDly:141 toms:76
2016.12.20 19:35:58.872 4: TSCUL_Parse: HM_CUL  313875 A FF23 00715032 01 0A 50 8002 2A4CC9 4F4978 00 _CCAdly:4 _dhmSt:120 -138
2016.12.20 19:35:58.961 4: TSCUL_Parse: HM_CUL  313964 A FF23 00715120 01 0B 51 A001 2A4CC9 4F4978 01 _CCAdly:4 _dhmSt:208 -138
2016.12.20 19:35:59.088 4: TSCUL_Parse: HM_CUL  314090 A FF21 00715272 00 0E 51 A010 4F4978 2A4CC9 0100000000 -68.5
2016.12.20 19:35:59.104 4: TSCUL_send:  HM_CUL                         As 0A 51 8002 2A4CC9 4F4978 00
2016.12.20 19:35:59.105 3: TSCUL_XmitDlyHM:  HM_CUL  id:4F4978 dDly:102 toms:76
2016.12.20 19:35:59.231 4: TSCUL_Parse: HM_CUL  314234 A FF23 00715392 01 0A 51 8002 2A4CC9 4F4978 00 _CCAdly:4 _dhmSt:120 -138
2016.12.20 19:36:05.549 4: TSCUL_Parse: HM_CUL  320550 A FF22 00721724 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2016.12.20 19:36:19.709 4: TSCUL_Parse: HM_CUL  334709 A FF21 00735892 00 1A 62 8400 4E62E2 2A4CC9 1100DB4E45513039363332343681230000 -50
2016.12.20 19:36:19.725 4: TSCUL_send:  HM_CUL                         As 10 8A A001 2A4CC9 4E62E2 00040000000000
2016.12.20 19:36:19.725 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:99 toms:79
2016.12.20 19:36:19.856 4: TSCUL_Parse: HM_CUL  334859 A FF23 00736012 01 10 8A A001 2A4CC9 4E62E2 00 _CCAdly:4 _dhmSt:120 -138
2016.12.20 19:36:19.989 4: TSCUL_Parse: HM_CUL  334989 A FF21 00736172 00 18 8A A010 4E62E2 2A4CC9 0202010A2A0B4C0CC9140318000000 -50.5
2016.12.20 19:36:20.008 4: TSCUL_send:  HM_CUL                         As 0A 8A 8002 2A4CC9 4E62E2 00
2016.12.20 19:36:20.009 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:97 toms:76
2016.12.20 19:36:20.085 4: TSCUL_send:  HM_CUL                         As 10 8B A001 2A4CC9 4E62E2 01040000000001
2016.12.20 19:36:20.085 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:139 toms:79
2016.12.20 19:36:20.131 4: TSCUL_Parse: HM_CUL  335134 A FF23 00736292 01 0A 8A 8002 2A4CC9 4E62E2 00 _CCAdly:4 _dhmSt:120 -138
2016.12.20 19:36:20.224 4: TSCUL_Parse: HM_CUL  335227 A FF23 00736380 01 10 8B A001 2A4CC9 4E62E2 01 _CCAdly:4 _dhmSt:208 -138
2016.12.20 19:36:20.355 4: TSCUL_Parse: HM_CUL  335355 A FF21 00736540 00 16 8B A010 4E62E2 2A4CC9 0204100900080022C830030000 -52.5
2016.12.20 19:36:20.375 4: TSCUL_send:  HM_CUL                         As 0A 8B 8002 2A4CC9 4E62E2 00
2016.12.20 19:36:20.376 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:98 toms:76
2016.12.20 19:36:20.453 4: TSCUL_send:  HM_CUL                         As 0B 8C A001 2A4CC9 4E62E2 0103
2016.12.20 19:36:20.453 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:140 toms:76
2016.12.20 19:36:20.499 4: TSCUL_Parse: HM_CUL  335502 A FF23 00736660 01 0A 8B 8002 2A4CC9 4E62E2 00 _CCAdly:4 _dhmSt:120 -138
2016.12.20 19:36:20.588 4: TSCUL_Parse: HM_CUL  335591 A FF23 00736748 01 0B 8C A001 2A4CC9 4E62E2 01 _CCAdly:4 _dhmSt:208 -138
2016.12.20 19:36:20.715 4: TSCUL_Parse: HM_CUL  335717 A FF21 00736900 00 0D 8C A010 4E62E2 2A4CC9 01000000 -57.5
2016.12.20 19:36:20.732 4: TSCUL_send:  HM_CUL                         As 0A 8C 8002 2A4CC9 4E62E2 00
2016.12.20 19:36:20.733 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:101 toms:76
2016.12.20 19:36:20.811 4: TSCUL_send:  HM_CUL                         As 10 8D A001 2A4CC9 4E62E2 02040000000001
2016.12.20 19:36:20.811 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:142 toms:79
2016.12.20 19:36:20.861 4: TSCUL_Parse: HM_CUL  335863 A FF23 00737020 01 0A 8C 8002 2A4CC9 4E62E2 00 _CCAdly:4 _dhmSt:120 -138
2016.12.20 19:36:20.952 4: TSCUL_Parse: HM_CUL  335955 A FF23 00737108 01 10 8D A001 2A4CC9 4E62E2 02 _CCAdly:4 _dhmSt:208 -138
2016.12.20 19:36:21.084 4: TSCUL_Parse: HM_CUL  336085 A FF21 00737268 00 16 8D A010 4E62E2 2A4CC9 0204100900080022C830030000 -58
2016.12.20 19:36:21.102 4: TSCUL_send:  HM_CUL                         As 0A 8D 8002 2A4CC9 4E62E2 00
2016.12.20 19:36:21.103 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:98 toms:76
2016.12.20 19:36:21.180 4: TSCUL_send:  HM_CUL                         As 0B 8E A001 2A4CC9 4E62E2 0203
2016.12.20 19:36:21.180 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:141 toms:76
2016.12.20 19:36:21.227 4: TSCUL_Parse: HM_CUL  336231 A FF23 00737388 01 0A 8D 8002 2A4CC9 4E62E2 00 _CCAdly:4 _dhmSt:120 -138
2016.12.20 19:36:21.315 4: TSCUL_Parse: HM_CUL  336318 A FF23 00737476 01 0B 8E A001 2A4CC9 4E62E2 02 _CCAdly:4 _dhmSt:208 -138
2016.12.20 19:36:21.442 4: TSCUL_Parse: HM_CUL  336444 A FF21 00737628 00 0D 8E A010 4E62E2 2A4CC9 01000000 -50.5
2016.12.20 19:36:21.457 4: TSCUL_send:  HM_CUL                         As 0A 8E 8002 2A4CC9 4E62E2 00
2016.12.20 19:36:21.457 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:104 toms:76
2016.12.20 19:36:21.534 4: TSCUL_send:  HM_CUL                         As 10 8F A001 2A4CC9 4E62E2 03040000000001
2016.12.20 19:36:21.534 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:146 toms:79
2016.12.20 19:36:21.587 4: TSCUL_Parse: HM_CUL  336590 A FF23 00737748 01 0A 8E 8002 2A4CC9 4E62E2 00 _CCAdly:4 _dhmSt:120 -138
2016.12.20 19:36:21.679 4: TSCUL_Parse: HM_CUL  336682 A FF23 00737836 01 10 8F A001 2A4CC9 4E62E2 03 _CCAdly:4 _dhmSt:208 -138
2016.12.20 19:36:21.812 4: TSCUL_Parse: HM_CUL  336813 A FF21 00737996 00 16 8F A010 4E62E2 2A4CC9 02011202740800220030030000 -48
2016.12.20 19:36:21.830 4: TSCUL_send:  HM_CUL                         As 0A 8F 8002 2A4CC9 4E62E2 00
2016.12.20 19:36:21.831 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:99 toms:76
2016.12.20 19:36:21.907 4: TSCUL_send:  HM_CUL                         As 0B 90 A001 2A4CC9 4E62E2 0303
2016.12.20 19:36:21.908 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:141 toms:76
2016.12.20 19:36:21.955 4: TSCUL_Parse: HM_CUL  336958 A FF23 00738116 01 0A 8F 8002 2A4CC9 4E62E2 00 _CCAdly:4 _dhmSt:120 -138
2016.12.20 19:36:22.044 4: TSCUL_Parse: HM_CUL  337047 A FF23 00738204 01 0B 90 A001 2A4CC9 4E62E2 03 _CCAdly:4 _dhmSt:208 -138
2016.12.20 19:36:22.170 4: TSCUL_Parse: HM_CUL  337173 A FF21 00738356 00 0D 90 A010 4E62E2 2A4CC9 01000000 -47
2016.12.20 19:36:22.185 4: TSCUL_send:  HM_CUL                         As 0A 90 8002 2A4CC9 4E62E2 00
2016.12.20 19:36:22.186 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:103 toms:76
2016.12.20 19:36:22.315 4: TSCUL_Parse: HM_CUL  337318 A FF23 00738476 01 0A 90 8002 2A4CC9 4E62E2 00 _CCAdly:4 _dhmSt:120 -138
2016.12.20 19:36:39.326 4: TSCUL_Parse: HM_CUL  354328 A FF22 00755504 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2016.12.20 19:37:14.207 4: TSCUL_Parse: HM_CUL  389208 A FF22 00790388 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2016.12.20 19:37:45.593 4: TSCUL_Parse: HM_CUL  420595 A FF11 00821780 00 0F F9 8610 4A6ED5 000000 0AA0BF0F3040 -38.5
2016.12.20 19:37:48.924 4: TSCUL_Parse: HM_CUL  423925 A FF12 00825104 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2016.12.20 19:38:19.481 4: TSCUL_Parse: HM_CUL  454484 A FF11 00855668 00 0D BF A241 4E5E9A 2A4CC9 03CE0080 -77
2016.12.20 19:38:19.497 4: TSCUL_send:  HM_CUL                         As 0D BF 8002 2A4CC9 4E5E9A 01010000
2016.12.20 19:38:19.497 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E5E9A dDly:103 toms:77
2016.12.20 19:38:19.603 4: TSCUL_send:  HM_CUL                         As 0A BF 8002 2A4CC9 4E5E9A 00
2016.12.20 19:38:19.604 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E5E9A dDly:118 toms:76
2016.12.20 19:38:19.626 4: TSCUL_Parse: HM_CUL  454629 A FF13 00855788 01 0D BF 8002 2A4CC9 4E5E9A 01 _CCAdly:4 _dhmSt:120 -138
2016.12.20 19:38:19.681 4: TSCUL_send:  HM_CUL                         As 10 C0 A001 2A4CC9 4E5E9A 00040000000000
2016.12.20 19:38:19.681 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E5E9A dDly:39 toms:79
2016.12.20 19:38:19.720 4: TSCUL_Parse: HM_CUL  454723 A FF13 00855880 01 10 C0 A001 2A4CC9 4E5E9A 00 _CCAdly:4 _dhmSt:212 -138
2016.12.20 19:38:19.972 4: TSCUL_Parse: HM_CUL  454976 A FF13 00856132 01 10 C0 A001 2A4CC9 4E5E9A 00 _CCAdly:4 _dhmSt:464 -138
2016.12.20 19:38:20.224 4: TSCUL_Parse: HM_CUL  455227 A FF13 00856384 01 10 C0 A001 2A4CC9 4E5E9A 00 _CCAdly:4 _dhmSt:716 -138
2016.12.20 19:38:20.442 1: TSCUL_ParseTsHM HM_CUL HM repeat failed sending to 4E5E9A/kueche.Bewegungsmelder: AFF100003448E0010C0A0012A4CC94E5E9A00
2016.12.20 19:38:20.442 4: TSCUL_Parse: HM_CUL  455445 A FF10 00856632 00 10 C0 A001 2A4CC9 4E5E9A 00 _sfail -138
2016.12.20 19:38:20.475 4: TSCUL_Parse: HM_CUL  455479 A FF13 00856640 01 0A BF 8002 2A4CC9 4E5E9A 00 _CCAdly:4 _dhmSt:972 -138
2016.12.20 19:38:23.242 4: TSCUL_Parse: HM_CUL  458243 A FF12 00859424 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2016.12.20 19:38:32.105 4: TSCUL_Parse: HM_CUL  467105 A FF11 00868292 00 1A C0 8400 4E5E9A 2A4CC9 1100DB4E45513039363433343281230000 -83.5
2016.12.20 19:38:32.123 4: TSCUL_send:  HM_CUL                         As 10 E8 A001 2A4CC9 4E5E9A 00040000000000
2016.12.20 19:38:32.123 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E5E9A dDly:100 toms:79
2016.12.20 19:38:32.253 4: TSCUL_Parse: HM_CUL  467256 A FF13 00868412 01 10 E8 A001 2A4CC9 4E5E9A 00 _CCAdly:4 _dhmSt:120 -138
2016.12.20 19:38:32.504 4: TSCUL_Parse: HM_CUL  467507 A FF13 00868664 01 10 E8 A001 2A4CC9 4E5E9A 00 _CCAdly:4 _dhmSt:372 -138
2016.12.20 19:38:32.757 4: TSCUL_Parse: HM_CUL  467760 A FF13 00868916 01 10 E8 A001 2A4CC9 4E5E9A 00 _CCAdly:4 _dhmSt:624 -138
2016.12.20 19:38:32.975 1: TSCUL_ParseTsHM HM_CUL HM repeat failed sending to 4E5E9A/kueche.Bewegungsmelder: AFF10000350CB0010E8A0012A4CC94E5E9A00
2016.12.20 19:38:32.976 4: TSCUL_Parse: HM_CUL  467978 A FF10 00869164 00 10 E8 A001 2A4CC9 4E5E9A 00 _sfail -138
2016.12.20 19:38:36.408 4: TSCUL_Parse: HM_CUL  471407 A FF11 00872596 00 1A C1 8400 4E5E9A 2A4CC9 1100DB4E45513039363433343281230000 -93.5
2016.12.20 19:38:57.001 4: TSCUL_Parse: HM_CUL  492002 A FF12 00893184 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2016.12.20 19:39:27.546 4: TSCUL_Parse: HM_CUL  522547 A FF12 00923728 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2016.12.20 19:40:01.448 4: TSCUL_Parse: HM_CUL  032163 A FF11 00957640 00 0D 63 A241 4E62E2 2A4CC9 03CB4280 -52
2016.12.20 19:40:01.467 4: TSCUL_send:  HM_CUL                         As 0D 63 8002 2A4CC9 4E62E2 01014200
2016.12.20 19:40:01.468 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:99 toms:77
2016.12.20 19:40:01.546 4: TSCUL_send:  HM_CUL                         As 0A 63 8002 2A4CC9 4E62E2 00
2016.12.20 19:40:01.547 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:141 toms:76
2016.12.20 19:40:01.596 4: TSCUL_Parse: HM_CUL  032310 A FF13 00957760 01 0D 63 8002 2A4CC9 4E62E2 01 _CCAdly:4 _dhmSt:120 -138
2016.12.20 19:40:01.624 4: TSCUL_send:  HM_CUL                         As 10 64 A001 2A4CC9 4E62E2 00040000000000
2016.12.20 19:40:01.624 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:62 toms:79
2016.12.20 19:40:01.684 4: TSCUL_Parse: HM_CUL  032399 A FF13 00957852 01 0A 63 8002 2A4CC9 4E62E2 00 _CCAdly:4 _dhmSt:212 -138
2016.12.20 19:40:01.777 4: TSCUL_Parse: HM_CUL  032492 A FF13 00957940 01 10 64 A001 2A4CC9 4E62E2 00 _CCAdly:4 _dhmSt:300 -138
2016.12.20 19:40:02.030 4: TSCUL_Parse: HM_CUL  032745 A FF13 00958192 01 10 64 A001 2A4CC9 4E62E2 00 _CCAdly:4 _dhmSt:552 -138
2016.12.20 19:40:02.281 4: TSCUL_Parse: HM_CUL  032996 A FF13 00958444 01 10 64 A001 2A4CC9 4E62E2 00 _CCAdly:4 _dhmSt:804 -138
2016.12.20 19:40:02.499 1: TSCUL_ParseTsHM HM_CUL HM repeat failed sending to 4E62E2/wz.Bewegungsmelder: AFF100003A839001064A0012A4CC94E62E200
2016.12.20 19:40:02.499 4: TSCUL_Parse: HM_CUL  033214 A FF10 00958692 00 10 64 A001 2A4CC9 4E62E2 00 _sfail -138
2016.12.20 19:40:06.914 4: TSCUL_Parse: HM_CUL  037629 A FF11 00963108 00 0B 64 8440 4E62E2 2A4CC9 41A6 -53.5
2016.12.20 19:40:07.185 4: TSCUL_Parse: HM_CUL  037900 A FF11 00963376 00 0B 65 A240 4E62E2 2A4CC9 41A6 -51
2016.12.20 19:40:07.201 4: TSCUL_send:  HM_CUL                         As 0A 65 8002 2A4CC9 4E62E2 00
2016.12.20 19:40:07.202 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:103 toms:76
2016.12.20 19:40:07.329 4: TSCUL_Parse: HM_CUL  038044 A FF13 00963496 01 0A 65 8002 2A4CC9 4E62E2 00 _CCAdly:4 _dhmSt:120 -138
2016.12.20 19:40:09.686 4: TSCUL_Parse: HM_CUL  040401 A FF11 00965880 00 0B 66 8440 4E62E2 2A4CC9 4276 -53.5
2016.12.20 19:40:09.958 4: TSCUL_Parse: HM_CUL  040673 A FF11 00966152 00 0B 67 8440 4E62E2 2A4CC9 4276 -53.5
2016.12.20 19:40:10.229 4: TSCUL_Parse: HM_CUL  040944 A FF11 00966420 00 0B 68 A240 4E62E2 2A4CC9 4276 -52.5
2016.12.20 19:40:10.245 4: TSCUL_send:  HM_CUL                         As 0A 68 8002 2A4CC9 4E62E2 00
2016.12.20 19:40:10.245 3: TSCUL_XmitDlyHM:  HM_CUL  id:4E62E2 dDly:104 toms:76
2016.12.20 19:40:10.372 4: TSCUL_Parse: HM_CUL  041087 A FF13 00966540 01 0A 68 8002 2A4CC9 4E62E2 00 _CCAdly:4 _dhmSt:120 -138
2016.12.20 19:40:17.588 4: TSCUL_Parse: HM_CUL  048302 A FF12 00973772 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2016.12.20 19:40:47.842 4: TSCUL_Parse: HM_CUL  078556 A FF11 01004036 00 0F FA 8610 4A6ED5 000000 0AA0C10F3040 -38
2016.12.20 19:40:47.972 4: TSCUL_Parse: HM_CUL  078685 A FF12 01004156 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138


Was mir direkt aufgefallen ist, dass es bei beiden WM55 zu Problemen kommt, wenn ich die Einstellungen am Bewegungsmelder ändern möchte. Ein getConfig ändert dabei leider nichts. Danke für dein Support.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 20 Dezember 2016, 20:14:33
Hallo Mario,

das ist es wohl.
nanoCUL: unknown message ? (T01 is unknown) Use one of A B C E F G J K M R U V W X Y Z e f i l m t x

Der nanoCUL hat kein FHT in der Firmware, um RAM zu sparen. Und in der 00_TSCUL.pm war das nicht abgefangen.

Hier https://forum.fhem.de/index.php/topic,24436.msg529649.html#msg529649 (https://forum.fhem.de/index.php/topic,24436.msg529649.html#msg529649) liegt ene neue zip. Daraus musst Du die 00_TSCUL.pm in Deinem FHEM Verzeichis aktualisieren. Nur die ist geändert.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 20 Dezember 2016, 20:59:00
Hallo scr3tchy,

die Reihenfolge des Sendens passt jetzt.  :)
Und das Timing sieht auch gut aus.

As 0A 61 8002 2A4CC9 4E62E2 00
zu dem 4E62E2 klappt das Senden und Empfangen eigentlich gut.
Ich habe nur den Eindruck, das obiger ACK den einschlafen läßt und es dann nicht mehr weiter geht. Das wäre eine Frage an Martin, ob das an der Stelle im Protkoll stört.
Das gehört dann ins Homematic Forum.

Die Befehlabsetz und Knopfchendrücksequenz kann auch noch fehlerhaft sein. Kann ich mangels Hardware nicht testen.

Ansonsten bräuchte ich mal ein WM55 Log, wo es funktioniert, um die Unterschiede zu sehen. Für das vollständige Protokollverständniss fehlt mir leider die Zeit.

Beim 4E5E9A ist der Empfang vielleicht nicht so gut.
Versuch mal hmFreqOffs (unter set) auf 0 zu stellen. Und von da aus +/- 50 kHz in 10kHz Schritten und beobachte insbesondere auch den RSSI zu und von den Geräten, ob es besser wird. Mein default Wert kann auch Serienstreuungsbeeinflusst sein.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: kaihs am 20 Dezember 2016, 21:42:19
Hallo Ansgar,

ich überlege diese culfw auf einem rpiaddon Device einzusetzen.
Es sieht erst mal so aus, als sei die board.h schon angepasst worden. Ist das eher Zufall, oder sind die Einstellungen schon auf den atmega644 abgestimmt der bei dem Device zum Einsatz kommt?

Gruß,

Kai
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 20 Dezember 2016, 22:03:10
Hallo Kai,

zum rapiaddon liegen mir weder Daten noch Erfahrungen vor. In sofern auch nicht, ob der Prozessor passt, aber Deine Augen werden es Dir verraten (haben).
Ich habe nur mal von Zeit zu Zeit die völlig ungestesteten im Source versucht nach zu ziehen. Ansonsten basieren sie auf der culfw Basis auf der ich mal aufgesetzt habe.

In der board.h ist bezüglich Hardware

SPI_CC1101_READ_SPECIAL_PIN
IRRX_SPECIAL_PIN

stets ein Fragezeichen ob die Pins wirklich ungenutzt sind (und in diesem Falle, ob IRRX relevant ist).
Ich benutze diese Pins jeweils als schnelles Speicherbit. Daher darf nichts angeschlossen sein, was damit nicht klar kommt.

Ansonsten bezüglich Konfiguration und rapiaddon.c im Zweifel mal mit SCC, COC, CUNO2, CUL und nanoCUL vergleichen. Zu den ersten 4 kann ich selbst was testen und zu nanoCUL gibt es schon Tester. Die Initialisierung und main loop müssen halt zur Hardware und auch zur gewählten Softwarekonfiguration passen (wo kein "Task", da passiert auch nichts).

Beim Compilieren immer darauf achten, dass es auch zuzüglich Bootloader (normalerweise wohl 4kB) in den Flash Speicher passt und bezüglich RAM, dass noch gut was für den Stack übrig bleibt.
Wo genau die Grenze beim Stack liegt erfährt man wohl erst, wenn man sie gefunden hat. ;)

Viel Erfolg beim Testen!

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: kaihs am 20 Dezember 2016, 22:08:17
Danke, für die Info.
Der atmega644 hat ja im Vergleich zu den anderen Devices reichlich Flash und RAM, da wird es wohl keine Probleme geben.

Ich werde aber nochmal alle Einstellungen mit dem Datenblatt des Prozessors und dem Schaltplan des Board abgleichen.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 20 Dezember 2016, 22:21:08
Hallo Kai,

wenn Du Deine Ergebnisse hier postest, dann kann ich sie in den Source einfließen lassen.

Danke!

Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: kaihs am 20 Dezember 2016, 22:22:46
Ja, wenn ich fertig bin werde ich die Ergebnisse posten.

Die Einstellungen der Pins passen schon mal.
Allerdings ist

#define HAS_ASKSIN_FUP

nicht aktiviert. Wird OTA Firmwareupdate von deiner culfw unterstützt?

Ich habe zwei von den Boards. Eines direkt im Haupt-FHEM, ein zweites ist über WLAN per ser2net angebunden.
Beide sind einer vccu zugeordnet.
Verursachen die damit wahrscheinlich einhergehenden Latenzen wohl Probleme oder werden die durch die Timestamps eher verringert?
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 21 Dezember 2016, 01:23:09
Hallo Kai,

Zitatnicht aktiviert. Wird OTA Firmwareupdate von deiner culfw unterstützt?]nicht aktiviert. Wird OTA Firmwareupdate von deiner culfw unterstützt?

Das ist richtig so, weil man es bei mir gar nicht weglassen kann!

Nun, theoretisch läuft es, also es wird auf 100kbit/s hochgeschaltet und das Timing wird angepasst.
Testen kann ich es leider nicht, mangels Hardware die sich updaten ließe. Beschwert hat sich auch noch keiner, dass es nicht ginge oder ginge.
Ich habe die Preamble für den FUP Modus von 10ms auf 1ms runtergesetzt und hoffe das reicht aus. Außerdem sind die Sendeabstände veringert.
Wenn Du testen möchtest, gerne. Da ich aber auch mit credits in der Firmware arbeite (mit Subaufösung eben wegen FUP) macht ein FUP Versuch nur Sinn, wenn Du vorher die Credits auf 1800 "aufgeladen" hast, sprich ggf. erst mal sendearm wartest.

ZitatIch habe zwei von den Boards. Eines direkt im Haupt-FHEM, ein zweites ist über WLAN per ser2net angebunden.
Beide sind einer vccu zugeordnet.
Verursachen die damit wahrscheinlich einhergehenden Latenzen wohl Probleme oder werden die durch die Timestamps eher verringert?
Wenn die Latenzen zo groß werden, dann gibt es nur eventuell Probleme bei Antworten auf messages vom Device. Die müssen schnell genug von FHEM, bzw. CUL_HM kommen. Ich habe nur eine "Unterhaltung" eingeführt, sprich wenn tsculfw eine message empfängt, die das Antwortflag gesetzt hat, dann werden andere Sendeaktionen für eine gewisse Zeit (etwa 400ms) nicht ausgeführt, sondern auf die Sendeantwort von FHEM gewartet. Wenn allerdings schon eine "Unterhaltung" läuft, wird diese nicht unterbrochen, warum auch, wenn einer dazwischen quasselt. Wenn natürlich ein Paket mit Antwortflag für ein device reinkommt, dem nicht über dieses IO geantwortet wird, kann das andere Unterhaltungen aufhalten. Das ist der kleine Haken an der Sache für einen Mehrempfänger/-sender Betrieb.
In die andere Richtung, also Sendetiming und ggf. AES Signing zum device ausführen ist in der Firmware.
So lange die Sendedaten rechtzeitig vorliegen, kümmert sich die Firmware um die (nach bisheriger Erfahrung) korrekte Antwortzeit und versucht 3 Wiederholungen, wenn eine Antwort erwartet wird. Das entschärft wiederum Timingengpässe.

Ich habe das Timing in die Firmware gebracht, weil ich einen COC (HM) auf einem SCC 433MHz sitzen habe. Und da spielt das schon etwas rein, weil die Kommunikation durch den SCC durch muss, sprich über dessen beide serielle Schnittstellen. Und wenn SCC einen dickeren packen an RasPi schickt, dann kann COC so lange nur in den Puffer auf SCC schreiben und es gibt extra Verzögerungen zur ohnehin schon doppelten Übertragungszeit. Die andere Richtung habe ich noch optimieren können, da in dieser Richtung zu SCC nicht viel los ist. Dann ist die Latenz nur 1 Byte + ein bischen zu COC (oder allgemein für jedes zwischengeschaltete SCC).

Nutzung der FHEM Module nicht vergessen! Mit den Standart Modulen geht es nicht.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Maxl am 21 Dezember 2016, 18:58:40
Hallo Ansgar,

mir ist aufgefallen, das ich keine Aktoren mehr mit der neuen V0.5 pairen kann, unter V0.3 gab es noch keine Probleme. Evtl. stimmen auch ein paar Einstellungen unter der board.h nicht, die habe ich so genommen wie im zip-File. Könntest du das prüfen?

so sah es unter V0.3 aus:

2016.12.21 18:52:49.187 4: TSCUL_Parse: nanoCUL  238095 A FF51 00047868 00 1A 06 8400 461413 000000 16005D4E45513031313830363481110100 -78
2016.12.21 18:52:49.196 3: Device Bewegungsmelder_EG added to ActionDetector with 024:00 time
2016.12.21 18:52:49.201 4: Device CUL_HM_HM_CC_RT_DN_3549E1 is alive
2016.12.21 18:52:49.202 4: Device Bewegungsmelder_EG is alive
2016.12.21 18:52:49.204 3: CUL_HM pair: Bewegungsmelder_EG motionDetector, model HM-Sen-MDIR-O serialNr NEQ0118064
2016.12.21 18:52:49.224 4: TSCUL_send:  nanoCUL                         As 10 2E A001 F11234 461413 00050000000000
2016.12.21 18:52:49.224 3: TSCUL_XmitDlyHM:  nanoCUL  id:461413 dDly:62 toms:73
2016.12.21 18:52:49.327 4: TSCUL_Parse: nanoCUL  238243 A FF53 00047988 00 10 2E A001 F11234 461413 00 _dhmSt:120 -138
2016.12.21 18:52:49.445 4: TSCUL_Parse: nanoCUL  238362 A FF51 00048136 00 0A 2E 8002 461413 F11234 00 -74
2016.12.21 18:52:49.461 4: TSCUL_send:  nanoCUL                         As 13 2F A001 F11234 461413 000802010AF10B120C34
2016.12.21 18:52:49.462 3: TSCUL_XmitDlyHM:  nanoCUL  id:461413 dDly:91 toms:74
2016.12.21 18:52:49.597 4: TSCUL_Parse: nanoCUL  238514 A FF53 00048256 00 13 2F A001 F11234 461413 00 _dhmSt:120 -138
2016.12.21 18:52:49.713 4: TSCUL_Parse: nanoCUL  238630 A FF51 00048404 00 0A 2F 8002 461413 F11234 00 -71.5
2016.12.21 18:52:49.730 4: TSCUL_send:  nanoCUL                         As 0B 30 A001 F11234 461413 0006
2016.12.21 18:52:49.730 3: TSCUL_XmitDlyHM:  nanoCUL  id:461413 dDly:95 toms:72
2016.12.21 18:52:49.859 4: TSCUL_Parse: nanoCUL  238775 A FF53 00048524 00 0B 30 A001 F11234 461413 00 _dhmSt:120 -138
2016.12.21 18:52:49.982 4: TSCUL_Parse: nanoCUL  238898 A FF51 00048672 00 0A 30 8002 461413 F11234 00 -69.5
2016.12.21 18:52:53.772 4: dummy set Test2 toggle
2016.12.21 18:52:53.786 4: nty_Test exec IF ([Test:&STATE] eq "on") (set Test off) ELSE (set Test on)
2016.12.21 18:52:53.792 4: dummy set Test off
2016.12.21 18:52:53.795 4: Dummy_Aus exec { fhem "set Relais9 off" }
2016.12.21 18:52:55.808 4: TSCUL_Parse: nanoCUL  244719 A FF52 00054496 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2016.12.21 18:53:00.587 4: Connection closed for WEB_192.168.1.28_63455: EOF
2016.12.21 18:53:00.591 4: WEB_192.168.1.28_63456 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2016-12.log; BUFLEN:0


Gruß
Mario
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 22 Dezember 2016, 01:56:27
Hallo Mario,

Zitatso sah es unter V0.3 aus:
Und jetzt?

Bei mir läuft das mit meinen devices absolut sauber durch, sofern Autocreate aktiviert ist.

Du nutzt noch die 10_CUL_HM.pm aus der zip und hast Dich nicht etwa zu einem update von FHEM verleiten lassen, ohne die vor update zu schützen?

Gruß,

Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Maxl am 22 Dezember 2016, 13:23:12
Hallo Ansgar,

anbei nochmals das Log nach dem Neustart mit der V0.5, habe sicherheitshalber nochmals alle pm-Files nach FHEM kopiert. Zum Schluß hätte ich versucht einen HM-SEN-MDIR-O zu pairen, dieser blinkt gelb mit dieser Version und geht dann in das Timeout, blinkt rot. Bei den anderen hat es noch funktioniert, weiß leider nicht genau was der Unterschied zwischen den Versionen ist. Mir fiel nur auf, das sich das board.h zw. V3, V4 und V5 geändert hat.
Das das Pairen seit V4 bei mir nicht mehr geht fiel nicht auf, da alles passte.

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

steht in der cfg.

2016.12.22 13:16:20.311 1: Including fhem.cfg
2016.12.22 13:16:20.410 3: telnetPort: port 7072 opened
2016.12.22 13:16:20.821 3: WEB: port 8083 opened
2016.12.22 13:16:20.825 3: WEBphone: port 8084 opened
2016.12.22 13:16:20.850 3: WEBtablet: port 8085 opened
2016.12.22 13:16:21.802 2: eventTypes: loaded 995 events from ./log/eventTypes.txt
2016.12.22 13:16:23.224 2: TSCUL_Parse: nanoCUL new condition disconnected
2016.12.22 13:16:23.225 3: Opening nanoCUL device /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
2016.12.22 13:16:23.357 3: DevIoTS_OpenDev: Setting nanoCUL serial parameters to 38400,8,N,1
2016.12.22 13:16:24.174 1: nanoCUL is VERSION_TS, VTS 0.05 nanoCUL868, nanoCUL_V1.x
2016.12.22 13:16:25.072 3: nanoCUL: Possible commands: ABCEFGJKMRUVWXYZefilmtx
2016.12.22 13:16:25.104 2: TSCUL_Parse: nanoCUL new condition init
2016.12.22 13:16:25.106 3: DevIoTS_OpenDev: nanoCUL device opened
2016.12.22 13:16:25.162 2: TSCUL_Parse: nanoCUL new condition init
2016.12.22 13:16:25.163 2: Switched nanoCUL rfmode to HomeMatic
2016.12.22 13:16:25.449 3: HM485: HM485: Loading available device files
2016.12.22 13:16:25.449 3: HM485: =====================================
2016.12.22 13:16:25.450 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw-sen-sc-12.pm
2016.12.22 13:16:25.456 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_central.pm
2016.12.22 13:16:25.460 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_generic.pm
2016.12.22 13:16:25.462 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io12_fm.pm
2016.12.22 13:16:25.493 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io12_sw14_dr.pm
2016.12.22 13:16:25.512 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io12_sw7_dr.pm
2016.12.22 13:16:25.552 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io12_sw7_dr_V3_02.pm
2016.12.22 13:16:25.592 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io12_sw7_dr_v3_02.pm
2016.12.22 13:16:25.622 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io_12_fm.pm
2016.12.22 13:16:25.669 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io_4_fm.pm
2016.12.22 13:16:25.713 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io_4_fm_V3_02.pm
2016.12.22 13:16:25.755 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io_4_fm_v3_02.pm
2016.12.22 13:16:25.786 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io_sr_fm.pm
2016.12.22 13:16:25.828 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_bl1_dr.pm
2016.12.22 13:16:25.889 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_bl1_dr_V3_02.pm
2016.12.22 13:16:25.948 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_bl1_dr_v3_02.pm
2016.12.22 13:16:25.990 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_dim1l_dr.pm
2016.12.22 13:16:26.051 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_sw2_dr.pm
2016.12.22 13:16:26.095 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_sw2_dr_V3_02.pm
2016.12.22 13:16:26.137 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_sw2_dr_v3_02.pm
2016.12.22 13:16:26.168 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_sen_sc_12_dr.pm
2016.12.22 13:16:26.176 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_virtual.pm
2016.12.22 13:16:26.288 3: Opening NETIO1 device 192.168.1.98:2701
2016.12.22 13:16:26.304 3: NETIO1 device opened
2016.12.22 13:16:26.379 3: Opening NETIO2 device 192.168.1.99:2701
2016.12.22 13:16:26.383 3: NETIO2 device opened
2016.12.22 13:16:26.637 2: HM_LAN_WIRED: Assigned 00011169 as HMW_IO_12_Sw14_DR_LEQ1322965
2016.12.22 13:16:27.475 2: HM_LAN_WIRED: Assigned 00012465 as HMW_IO_12_Sw14_DR_MEQ0370281
2016.12.22 13:16:28.241 1: Including ./log/fhem.save
2016.12.22 13:16:29.187 3: Device Bewegungsmelder_EG added to ActionDetector with 024:00 time
2016.12.22 13:16:29.200 4: Device Bewegungsmelder_EG is alive
2016.12.22 13:16:29.222 3: Device Bewegungsmelder_UG added to ActionDetector with 024:00 time
2016.12.22 13:16:29.233 4: Device Bewegungsmelder_UG is alive
2016.12.22 13:16:29.256 3: Device CUL_HM_HM_CC_RT_DN_354555 added to ActionDetector with 000:10 time
2016.12.22 13:16:29.265 4: Device CUL_HM_HM_CC_RT_DN_354555 is alive
2016.12.22 13:16:29.337 3: Device CUL_HM_HM_CC_RT_DN_3547B5 added to ActionDetector with 000:10 time
2016.12.22 13:16:29.347 4: Device CUL_HM_HM_CC_RT_DN_3547B5 is alive
2016.12.22 13:16:29.420 3: Device CUL_HM_HM_CC_RT_DN_3547BA added to ActionDetector with 000:10 time
2016.12.22 13:16:29.431 4: Device CUL_HM_HM_CC_RT_DN_3547BA is alive
2016.12.22 13:16:29.503 3: Device CUL_HM_HM_CC_RT_DN_3547BB added to ActionDetector with 000:10 time
2016.12.22 13:16:29.513 4: Device CUL_HM_HM_CC_RT_DN_3547BB is alive
2016.12.22 13:16:29.586 3: Device CUL_HM_HM_CC_RT_DN_3547BF added to ActionDetector with 000:10 time
2016.12.22 13:16:29.597 4: Device CUL_HM_HM_CC_RT_DN_3547BF is alive
2016.12.22 13:16:29.669 3: Device CUL_HM_HM_CC_RT_DN_3549DB added to ActionDetector with 000:10 time
2016.12.22 13:16:29.680 4: Device CUL_HM_HM_CC_RT_DN_3549DB is alive
2016.12.22 13:16:29.752 3: Device CUL_HM_HM_CC_RT_DN_3549DE added to ActionDetector with 000:10 time
2016.12.22 13:16:29.764 4: Device CUL_HM_HM_CC_RT_DN_3549DE is alive
2016.12.22 13:16:29.838 3: Device CUL_HM_HM_CC_RT_DN_3549E1 added to ActionDetector with 000:10 time
2016.12.22 13:16:29.849 4: Device CUL_HM_HM_CC_RT_DN_3549E1 is alive
2016.12.22 13:16:30.039 3: Device CUL_HM_HM_SEC_SD_2F361B added to ActionDetector with 099:00 time
2016.12.22 13:16:30.049 4: Device CUL_HM_HM_SEC_SD_2F361B is alive
2016.12.22 13:16:30.076 3: Device CUL_HM_HM_SEC_SD_2F3665 added to ActionDetector with 099:00 time
2016.12.22 13:16:30.086 4: Device CUL_HM_HM_SEC_SD_2F3665 is alive
2016.12.22 13:16:30.115 3: Device CUL_HM_HM_SEC_SD_2F36E2 added to ActionDetector with 099:00 time
2016.12.22 13:16:30.125 4: Device CUL_HM_HM_SEC_SD_2F36E2 is alive
2016.12.22 13:16:30.158 3: Device CUL_HM_HM_SEC_SD_2F387B added to ActionDetector with 099:00 time
2016.12.22 13:16:30.168 4: Device CUL_HM_HM_SEC_SD_2F387B is alive
2016.12.22 13:16:30.198 3: Device CUL_HM_HM_SEC_SD_2F387C added to ActionDetector with 099:00 time
2016.12.22 13:16:30.209 4: Device CUL_HM_HM_SEC_SD_2F387C is alive
2016.12.22 13:16:30.237 3: Device CUL_HM_HM_SEC_SD_2F389B added to ActionDetector with 099:00 time
2016.12.22 13:16:30.249 4: Device CUL_HM_HM_SEC_SD_2F389B is alive
2016.12.22 13:16:30.630 4: initialUsbCheck exec usb create
2016.12.22 13:16:30.631 1: usb create starting
2016.12.22 13:16:31.216 4: ### ttyAMA0: checking if it is a CUL
2016.12.22 13:16:31.220 3: Probing CUL device /dev/ttyAMA0
2016.12.22 13:16:31.431 4: got wrong answer for a CUL
2016.12.22 13:16:31.432 4: ### ttyAMA0: checking if it is a TCM_ESP3
2016.12.22 13:16:31.434 3: Probing TCM_ESP3 device /dev/ttyAMA0
2016.12.22 13:16:31.643 4: got wrong answer for a TCM_ESP3
2016.12.22 13:16:31.645 4: ### ttyAMA0: checking if it is a FRM
2016.12.22 13:16:31.647 3: Probing FRM device /dev/ttyAMA0
2016.12.22 13:16:36.863 4: got wrong answer for a FRM
2016.12.22 13:16:36.864 4: ### ttyUSB0: checking if it is a TCM_ESP3
2016.12.22 13:16:36.865 4: ttyUSB0 is already used by the fhem device nanoCUL
2016.12.22 13:16:36.866 4: ### ttyUSB1: checking if it is a TCM_ESP3
2016.12.22 13:16:36.868 3: Probing TCM_ESP3 device /dev/ttyUSB1
2016.12.22 13:16:37.086 4: got wrong answer for a TCM_ESP3
2016.12.22 13:16:37.087 4: ### ttyUSB1: checking if it is a TCM_ESP2
2016.12.22 13:16:37.089 3: Probing TCM_ESP2 device /dev/ttyUSB1
2016.12.22 13:16:37.306 4: got wrong answer for a TCM_ESP2
2016.12.22 13:16:37.307 4: ### ttyUSB1: checking if it is a FHZ
2016.12.22 13:16:37.309 3: Probing FHZ device /dev/ttyUSB1
2016.12.22 13:16:37.526 4: got wrong answer for a FHZ
2016.12.22 13:16:37.527 4: ### ttyUSB1: checking if it is a TRX
2016.12.22 13:16:37.529 3: Probing TRX device /dev/ttyUSB1
2016.12.22 13:16:38.255 4: got wrong answer for a TRX
2016.12.22 13:16:38.256 4: ### ttyUSB1: checking if it is a ZWDongle
2016.12.22 13:16:38.259 3: Probing ZWDongle device /dev/ttyUSB1
2016.12.22 13:16:38.479 4: got wrong answer for a ZWDongle
2016.12.22 13:16:38.480 4: ### ttyUSB1: checking if it is a FRM
2016.12.22 13:16:38.482 3: Probing FRM device /dev/ttyUSB1
2016.12.22 13:16:45.158 4: got wrong answer for a FRM
2016.12.22 13:16:45.191 1: usb create end
2016.12.22 13:16:45.221 2: SecurityCheck:  WEB,WEBtablet has no associated allowed device with basicAuth. telnetPort has no associated allowed device with password/globalpassword.  Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2016.12.22 13:16:45.223 0: Featurelevel: 5.7
2016.12.22 13:16:45.223 0: Server started with 245 defined entities (fhem.pl:12463/2016-10-29 perl:5.014002 os:linux user:fhem pid:26829)
2016.12.22 13:16:45.378 3: HM_LAN_WIRED: Start HM485d with command line: ./FHEM/lib/HM485/HM485d/HM485d.pl --hmwId 00000001 --serialNumber SGW0123456 --device 192.168.1.97:5000 --localPort 2000 --verbose 1
2016.12.22 13:16:45.462 3: HM_LAN_WIRED: HM485d was started with PID: 26840
2016.12.22 13:16:45.463 3: HM_LAN_WIRED: Connect to HM485d delayed for 4 seconds
2016.12.22 13:16:45.476 3: HM_LAN_WIRED: Warte auf Initialisierung Gateway
2016.12.22 13:16:45.488 3: HM_LAN_WIRED: Warte auf Initialisierung Gateway
2016.12.22 13:16:45.512 4: dummy set Test2 toggle
2016.12.22 13:16:45.523 4: nty_Test exec IF ([Test:&STATE] eq "on") (set Test off) ELSE (set Test on)
2016.12.22 13:16:45.594 4: dummy set Test off
2016.12.22 13:16:45.596 4: Dummy_Aus exec { fhem "set Relais9 off" }
2016.12.22 13:16:45.647 4: Connection accepted from WEB_192.168.1.20_51302
2016.12.22 13:16:45.651 2: TSCUL_Parse: nanoCUL new condition ok
2016.12.22 13:16:45.661 4: TSCUL_Parse: nanoCUL  414283 A FF52 00021824 00 01 C3 _ping -138
2016.12.22 13:16:45.663 4: TSCUL_Parse: nanoCUL  414286 A FF52 00021844 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2016.12.22 13:16:46.086 4: WEB_192.168.1.20_51302 GET /fhem?XHR=1&inform=type=status;filter=;since=1482408907.932;fmt=JSON&fw_id=513×tamp=1482408977144; BUFLEN:0
2016.12.22 13:16:46.094 4: Connection accepted from WEB_192.168.1.20_51303
2016.12.22 13:16:46.099 4: Connection closed for WEB_192.168.1.20_51302: EOF
2016.12.22 13:16:46.101 4: Connection accepted from WEB_192.168.1.20_51313
2016.12.22 13:16:46.103 4: Connection closed for WEB_192.168.1.20_51303: EOF
2016.12.22 13:16:46.106 4: WEB_192.168.1.20_51313 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2016-12.log; BUFLEN:0
2016.12.22 13:16:46.298 4: WEB_192.168.1.20_51313 GET /fhem/pgm2/style.css?v=1482408980; BUFLEN:0
2016.12.22 13:16:46.427 4: WEB_192.168.1.20_51313 GET /fhem/pgm2/hm485.js?1482408986.21393; BUFLEN:0
2016.12.22 13:16:46.653 1: HM485d: Server started ...
2016.12.22 13:16:46.937 4: WEB_192.168.1.20_51313 GET /fhem/FileLog_logWrapper?XHR=1&inform=type=status;filter=;since=1482409005;fmt=JSON&fw_id=491×tamp=1482409005173; BUFLEN:0
2016.12.22 13:16:47.022 4: dummy set Test2 toggle
2016.12.22 13:16:47.073 4: nty_Test exec IF ([Test:&STATE] eq "on") (set Test off) ELSE (set Test on)
2016.12.22 13:16:47.079 4: dummy set Test on
2016.12.22 13:16:47.081 4: Dummy_Ein exec { fhem "set Relais9 on";; fhem "set HMW_IO_12_Sw14_DR_LEQ1322965_01 toggle" }
2016.12.22 13:16:47.728 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (1) I[0](0,Y,F,B)(98) 00000001 -> 00011169 [6] 73(s) 000000
2016.12.22 13:16:48.793 3: HMW_IO_12_Sw14_DR_LEQ1322965: RESPONSE TIMEOUT for 00011169
2016.12.22 13:16:49.566 3: Opening HM_LAN_WIRED device localhost:2000
2016.12.22 13:16:49.573 3: HM_LAN_WIRED: connected to device localhost:2000
2016.12.22 13:16:49.574 3: HM_LAN_WIRED device opened
2016.12.22 13:16:49.576 3: HM_LAN_WIRED: Lan Device Information
2016.12.22 13:16:49.576 3: HM_LAN_WIRED: Protocol-Version: 01
2016.12.22 13:16:49.577 3: HM_LAN_WIRED: Interface-Type: HMW-SOFT-GW
2016.12.22 13:16:49.577 3: HM_LAN_WIRED: Firmware-Version: 0.2.2
2016.12.22 13:16:49.577 3: HM_LAN_WIRED: Serial-Number: SGW0123456
2016.12.22 13:16:49.578 3: HM_LAN_WIRED: Initialize the interface
2016.12.22 13:16:50.480 3: HM_LAN_WIRED: Initialisierung von Modul 00011169
2016.12.22 13:16:50.482 3: HM_LAN_WIRED: Initialisierung von Modul 00012465
2016.12.22 13:16:50.510 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (2) I[1](0,F,B)(1A) 00000001 -> 00011169 [3] 68(h)
2016.12.22 13:16:50.572 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (3) I[2](0,F,B)(1C) 00000001 -> 00011169 [3] 6E(n)
2016.12.22 13:16:50.637 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (4) I[3](0,F,B)(1E) 00000001 -> 00011169 [3] 76(v)
2016.12.22 13:16:50.680 3: HMW_IO_12_Sw14_DR_LEQ1322965: Request config for device 00011169
2016.12.22 13:16:50.696 3: HMW_IO_12_Sw14_DR_LEQ1322965: Lese Eeprom 00011169
2016.12.22 13:16:50.713 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (5) I[0](0,Y,F,B)(98) 00000001 -> 00012465 [3] 68(h)
2016.12.22 13:16:50.776 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (6) I[1](0,F,B)(1A) 00000001 -> 00012465 [3] 6E(n)
2016.12.22 13:16:50.841 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (7) I[2](0,F,B)(1C) 00000001 -> 00012465 [3] 76(v)
2016.12.22 13:16:50.884 3: HMW_IO_12_Sw14_DR_MEQ0370281: Request config for device 00012465
2016.12.22 13:16:50.898 3: HMW_IO_12_Sw14_DR_MEQ0370281: Lese Eeprom 00012465
2016.12.22 13:16:50.913 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (8) I[0](0,F,B)(18) 00000001 -> 00011169 [6] 52(R) 000010
2016.12.22 13:16:50.969 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (9) I[1](0,F,B)(1A) 00000001 -> 00011169 [6] 52(R) 001010
2016.12.22 13:16:51.016 4: HMW_IO_12_Sw14_DR_LEQ1322965: Channels initialisieren 00011169
2016.12.22 13:16:51.736 4: HMW_IO_12_Sw14_DR_LEQ1322965: HM485_UpdateConfigReadings called
2016.12.22 13:16:51.902 4: HMW_IO_12_Sw14_DR_LEQ1322965: State der Channels ermitteln 00011169
2016.12.22 13:16:51.923 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (10) I[3](0,F,B)(1E) 00000001 -> 00012465 [6] 52(R) 000010
2016.12.22 13:16:52.148 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (11) I[0](0,F,B)(18) 00000001 -> 00012465 [6] 52(R) 001010
2016.12.22 13:16:52.193 4: HMW_IO_12_Sw14_DR_MEQ0370281: Channels initialisieren 00012465
2016.12.22 13:16:52.918 4: HMW_IO_12_Sw14_DR_MEQ0370281: HM485_UpdateConfigReadings called
2016.12.22 13:16:53.086 4: HMW_IO_12_Sw14_DR_MEQ0370281: State der Channels ermitteln 00012465
2016.12.22 13:16:53.105 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (12) I[2](0,F,B)(1C) 00000001 -> 00011169 [4] 53(S) 00
2016.12.22 13:16:53.328 4: HMW_IO_12_Sw14_DR_LEQ1322965_01: HM485_ChannelDoUpdate
2016.12.22 13:16:53.329 4: HMW_IO_12_Sw14_DR_LEQ1322965_01: state -> on
2016.12.22 13:16:53.341 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (13) I[3](0,F,B)(1E) 00000001 -> 00011169 [4] 53(S) 01
2016.12.22 13:16:53.390 4: HMW_IO_12_Sw14_DR_LEQ1322965_02: HM485_ChannelDoUpdate
2016.12.22 13:16:53.391 4: HMW_IO_12_Sw14_DR_LEQ1322965_02: state -> off
2016.12.22 13:16:53.403 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (14) I[0](0,F,B)(18) 00000001 -> 00011169 [4] 53(S) 02
2016.12.22 13:16:53.452 4: HMW_IO_12_Sw14_DR_LEQ1322965_03: HM485_ChannelDoUpdate
2016.12.22 13:16:53.454 4: HMW_IO_12_Sw14_DR_LEQ1322965_03: state -> off
2016.12.22 13:16:53.466 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (15) I[1](0,F,B)(1A) 00000001 -> 00011169 [4] 53(S) 03
2016.12.22 13:16:53.515 4: HMW_IO_12_Sw14_DR_LEQ1322965_04: HM485_ChannelDoUpdate
2016.12.22 13:16:53.516 4: HMW_IO_12_Sw14_DR_LEQ1322965_04: state -> off
2016.12.22 13:16:53.530 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (16) I[2](0,F,B)(1C) 00000001 -> 00011169 [4] 53(S) 04
2016.12.22 13:16:53.575 4: HMW_IO_12_Sw14_DR_LEQ1322965_05: HM485_ChannelDoUpdate
2016.12.22 13:16:53.576 4: HMW_IO_12_Sw14_DR_LEQ1322965_05: state -> off
2016.12.22 13:16:53.588 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (17) I[3](0,F,B)(1E) 00000001 -> 00011169 [4] 53(S) 05
2016.12.22 13:16:53.638 4: HMW_IO_12_Sw14_DR_LEQ1322965_06: HM485_ChannelDoUpdate
2016.12.22 13:16:53.640 4: HMW_IO_12_Sw14_DR_LEQ1322965_06: state -> off
2016.12.22 13:16:53.652 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (18) I[0](0,F,B)(18) 00000001 -> 00011169 [4] 53(S) 06
2016.12.22 13:16:53.679 4: TSCUL_Parse: nanoCUL  422312 A FF52 00030004 00 01 C3 _ping -138
2016.12.22 13:16:53.714 4: HMW_IO_12_Sw14_DR_LEQ1322965_07: HM485_ChannelDoUpdate
2016.12.22 13:16:53.715 4: HMW_IO_12_Sw14_DR_LEQ1322965_07: state -> off
2016.12.22 13:16:53.726 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (19) I[1](0,F,B)(1A) 00000001 -> 00011169 [4] 53(S) 07
2016.12.22 13:16:53.789 4: HMW_IO_12_Sw14_DR_LEQ1322965_08: HM485_ChannelDoUpdate
2016.12.22 13:16:53.790 4: HMW_IO_12_Sw14_DR_LEQ1322965_08: state -> off
2016.12.22 13:16:53.801 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (20) I[2](0,F,B)(1C) 00000001 -> 00011169 [4] 53(S) 08
2016.12.22 13:16:53.867 4: HMW_IO_12_Sw14_DR_LEQ1322965_09: HM485_ChannelDoUpdate
2016.12.22 13:16:53.869 4: HMW_IO_12_Sw14_DR_LEQ1322965_09: state -> off
2016.12.22 13:16:53.881 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (21) I[3](0,F,B)(1E) 00000001 -> 00011169 [4] 53(S) 09
2016.12.22 13:16:53.946 4: HMW_IO_12_Sw14_DR_LEQ1322965_10: HM485_ChannelDoUpdate
2016.12.22 13:16:53.947 4: HMW_IO_12_Sw14_DR_LEQ1322965_10: state -> off
2016.12.22 13:16:53.963 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (22) I[0](0,F,B)(18) 00000001 -> 00011169 [4] 53(S) 0A
2016.12.22 13:16:54.027 4: HMW_IO_12_Sw14_DR_LEQ1322965_11: HM485_ChannelDoUpdate
2016.12.22 13:16:54.028 4: HMW_IO_12_Sw14_DR_LEQ1322965_11: state -> off
2016.12.22 13:16:54.040 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (23) I[1](0,F,B)(1A) 00000001 -> 00011169 [4] 53(S) 0B
2016.12.22 13:16:54.103 4: HMW_IO_12_Sw14_DR_LEQ1322965_12: HM485_ChannelDoUpdate
2016.12.22 13:16:54.104 4: HMW_IO_12_Sw14_DR_LEQ1322965_12: state -> off
2016.12.22 13:16:54.115 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (24) I[2](0,F,B)(1C) 00000001 -> 00011169 [4] 53(S) 0C
2016.12.22 13:16:54.182 4: HMW_IO_12_Sw14_DR_LEQ1322965_13: HM485_ChannelDoUpdate
2016.12.22 13:16:54.183 4: HMW_IO_12_Sw14_DR_LEQ1322965_13: state -> off
2016.12.22 13:16:54.195 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (25) I[3](0,F,B)(1E) 00000001 -> 00011169 [4] 53(S) 0D
2016.12.22 13:16:54.258 4: HMW_IO_12_Sw14_DR_LEQ1322965_14: HM485_ChannelDoUpdate
2016.12.22 13:16:54.260 4: HMW_IO_12_Sw14_DR_LEQ1322965_14: state -> off
2016.12.22 13:16:54.271 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (26) I[0](0,F,B)(18) 00000001 -> 00011169 [4] 53(S) 0E
2016.12.22 13:16:54.338 4: HMW_IO_12_Sw14_DR_LEQ1322965_15: HM485_ChannelDoUpdate
2016.12.22 13:16:54.339 4: HMW_IO_12_Sw14_DR_LEQ1322965_15: frequency -> 0.00
2016.12.22 13:16:54.353 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (27) I[1](0,F,B)(1A) 00000001 -> 00011169 [4] 53(S) 0F
2016.12.22 13:16:54.416 4: HMW_IO_12_Sw14_DR_LEQ1322965_16: HM485_ChannelDoUpdate
2016.12.22 13:16:54.417 4: HMW_IO_12_Sw14_DR_LEQ1322965_16: state -> on
2016.12.22 13:16:54.432 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (28) I[2](0,F,B)(1C) 00000001 -> 00011169 [4] 53(S) 10
2016.12.22 13:16:54.491 4: HMW_IO_12_Sw14_DR_LEQ1322965_17: HM485_ChannelDoUpdate
2016.12.22 13:16:54.492 4: HMW_IO_12_Sw14_DR_LEQ1322965_17: state -> on
2016.12.22 13:16:54.504 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (29) I[3](0,F,B)(1E) 00000001 -> 00011169 [4] 53(S) 11
2016.12.22 13:16:54.570 4: HMW_IO_12_Sw14_DR_LEQ1322965_18: HM485_ChannelDoUpdate
2016.12.22 13:16:54.571 4: HMW_IO_12_Sw14_DR_LEQ1322965_18: state -> on
2016.12.22 13:16:54.583 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (30) I[0](0,F,B)(18) 00000001 -> 00011169 [4] 53(S) 12
2016.12.22 13:16:54.646 4: HMW_IO_12_Sw14_DR_LEQ1322965_19: HM485_ChannelDoUpdate
2016.12.22 13:16:54.647 4: HMW_IO_12_Sw14_DR_LEQ1322965_19: state -> on
2016.12.22 13:16:54.658 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (31) I[1](0,F,B)(1A) 00000001 -> 00011169 [4] 53(S) 13
2016.12.22 13:16:54.725 4: HMW_IO_12_Sw14_DR_LEQ1322965_20: HM485_ChannelDoUpdate
2016.12.22 13:16:54.726 4: HMW_IO_12_Sw14_DR_LEQ1322965_20: state -> on
2016.12.22 13:16:54.742 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (32) I[2](0,F,B)(1C) 00000001 -> 00011169 [4] 53(S) 14
2016.12.22 13:16:54.805 4: HMW_IO_12_Sw14_DR_LEQ1322965_21: HM485_ChannelDoUpdate
2016.12.22 13:16:54.806 4: HMW_IO_12_Sw14_DR_LEQ1322965_21: state -> off
2016.12.22 13:16:54.822 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (33) I[3](0,F,B)(1E) 00000001 -> 00011169 [4] 53(S) 15
2016.12.22 13:16:54.884 4: HMW_IO_12_Sw14_DR_LEQ1322965_22: HM485_ChannelDoUpdate
2016.12.22 13:16:54.885 4: HMW_IO_12_Sw14_DR_LEQ1322965_22: state -> off
2016.12.22 13:16:54.901 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (34) I[0](0,F,B)(18) 00000001 -> 00011169 [4] 53(S) 16
2016.12.22 13:16:54.964 4: HMW_IO_12_Sw14_DR_LEQ1322965_23: HM485_ChannelDoUpdate
2016.12.22 13:16:54.965 4: HMW_IO_12_Sw14_DR_LEQ1322965_23: state -> off
2016.12.22 13:16:54.981 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (35) I[1](0,F,B)(1A) 00000001 -> 00011169 [4] 53(S) 17
2016.12.22 13:16:55.046 4: HMW_IO_12_Sw14_DR_LEQ1322965_24: HM485_ChannelDoUpdate
2016.12.22 13:16:55.047 4: HMW_IO_12_Sw14_DR_LEQ1322965_24: state -> off
2016.12.22 13:16:55.063 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (36) I[2](0,F,B)(1C) 00000001 -> 00011169 [4] 53(S) 18
2016.12.22 13:16:55.126 4: HMW_IO_12_Sw14_DR_LEQ1322965_25: HM485_ChannelDoUpdate
2016.12.22 13:16:55.127 4: HMW_IO_12_Sw14_DR_LEQ1322965_25: state -> off
2016.12.22 13:16:55.143 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (37) I[3](0,F,B)(1E) 00000001 -> 00011169 [4] 53(S) 19
2016.12.22 13:16:55.207 4: HMW_IO_12_Sw14_DR_LEQ1322965_26: HM485_ChannelDoUpdate
2016.12.22 13:16:55.208 4: HMW_IO_12_Sw14_DR_LEQ1322965_26: state -> off
2016.12.22 13:16:55.223 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (38) I[1](0,F,B)(1A) 00000001 -> 00012465 [4] 53(S) 00
2016.12.22 13:16:55.269 4: HMW_IO_12_Sw14_DR_MEQ0370281_01: HM485_ChannelDoUpdate
2016.12.22 13:16:55.270 4: HMW_IO_12_Sw14_DR_MEQ0370281_01: state -> off
2016.12.22 13:16:55.283 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (39) I[2](0,F,B)(1C) 00000001 -> 00012465 [4] 53(S) 01
2016.12.22 13:16:55.331 4: HMW_IO_12_Sw14_DR_MEQ0370281_02: HM485_ChannelDoUpdate
2016.12.22 13:16:55.333 4: HMW_IO_12_Sw14_DR_MEQ0370281_02: state -> off
2016.12.22 13:16:55.347 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (40) I[3](0,F,B)(1E) 00000001 -> 00012465 [4] 53(S) 02
2016.12.22 13:16:55.396 4: HMW_IO_12_Sw14_DR_MEQ0370281_03: HM485_ChannelDoUpdate
2016.12.22 13:16:55.397 4: HMW_IO_12_Sw14_DR_MEQ0370281_03: state -> off
2016.12.22 13:16:55.413 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (41) I[0](0,F,B)(18) 00000001 -> 00012465 [4] 53(S) 03
2016.12.22 13:16:55.460 4: HMW_IO_12_Sw14_DR_MEQ0370281_04: HM485_ChannelDoUpdate
2016.12.22 13:16:55.461 4: HMW_IO_12_Sw14_DR_MEQ0370281_04: state -> off
2016.12.22 13:16:55.473 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (42) I[1](0,F,B)(1A) 00000001 -> 00012465 [4] 53(S) 04
2016.12.22 13:16:55.521 4: HMW_IO_12_Sw14_DR_MEQ0370281_05: HM485_ChannelDoUpdate
2016.12.22 13:16:55.522 4: HMW_IO_12_Sw14_DR_MEQ0370281_05: state -> off
2016.12.22 13:16:55.533 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (43) I[2](0,F,B)(1C) 00000001 -> 00012465 [4] 53(S) 05
2016.12.22 13:16:55.585 4: HMW_IO_12_Sw14_DR_MEQ0370281_06: HM485_ChannelDoUpdate
2016.12.22 13:16:55.586 4: HMW_IO_12_Sw14_DR_MEQ0370281_06: state -> off
2016.12.22 13:16:55.598 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (44) I[3](0,F,B)(1E) 00000001 -> 00012465 [4] 53(S) 06
2016.12.22 13:16:55.661 4: HMW_IO_12_Sw14_DR_MEQ0370281_07: HM485_ChannelDoUpdate
2016.12.22 13:16:55.662 4: HMW_IO_12_Sw14_DR_MEQ0370281_07: state -> off
2016.12.22 13:16:55.673 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (45) I[0](0,F,B)(18) 00000001 -> 00012465 [4] 53(S) 07
2016.12.22 13:16:55.741 4: HMW_IO_12_Sw14_DR_MEQ0370281_08: HM485_ChannelDoUpdate
2016.12.22 13:16:55.742 4: HMW_IO_12_Sw14_DR_MEQ0370281_08: state -> off
2016.12.22 13:16:55.756 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (46) I[1](0,F,B)(1A) 00000001 -> 00012465 [4] 53(S) 08
2016.12.22 13:16:55.820 4: HMW_IO_12_Sw14_DR_MEQ0370281_09: HM485_ChannelDoUpdate
2016.12.22 13:16:55.821 4: HMW_IO_12_Sw14_DR_MEQ0370281_09: state -> off
2016.12.22 13:16:55.836 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (47) I[2](0,F,B)(1C) 00000001 -> 00012465 [4] 53(S) 09
2016.12.22 13:16:55.900 4: HMW_IO_12_Sw14_DR_MEQ0370281_10: HM485_ChannelDoUpdate
2016.12.22 13:16:55.901 4: HMW_IO_12_Sw14_DR_MEQ0370281_10: state -> off
2016.12.22 13:16:55.916 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (48) I[3](0,F,B)(1E) 00000001 -> 00012465 [4] 53(S) 0A
2016.12.22 13:16:55.981 4: HMW_IO_12_Sw14_DR_MEQ0370281_11: HM485_ChannelDoUpdate
2016.12.22 13:16:55.982 4: HMW_IO_12_Sw14_DR_MEQ0370281_11: state -> off
2016.12.22 13:16:55.996 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (49) I[0](0,F,B)(18) 00000001 -> 00012465 [4] 53(S) 0B
2016.12.22 13:16:56.062 4: HMW_IO_12_Sw14_DR_MEQ0370281_12: HM485_ChannelDoUpdate
2016.12.22 13:16:56.064 4: HMW_IO_12_Sw14_DR_MEQ0370281_12: state -> off
2016.12.22 13:16:56.080 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (50) I[1](0,F,B)(1A) 00000001 -> 00012465 [4] 53(S) 0C
2016.12.22 13:16:56.142 4: HMW_IO_12_Sw14_DR_MEQ0370281_13: HM485_ChannelDoUpdate
2016.12.22 13:16:56.143 4: HMW_IO_12_Sw14_DR_MEQ0370281_13: state -> off
2016.12.22 13:16:56.157 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (51) I[2](0,F,B)(1C) 00000001 -> 00012465 [4] 53(S) 0D
2016.12.22 13:16:56.222 4: HMW_IO_12_Sw14_DR_MEQ0370281_14: HM485_ChannelDoUpdate
2016.12.22 13:16:56.224 4: HMW_IO_12_Sw14_DR_MEQ0370281_14: state -> off
2016.12.22 13:16:56.240 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (52) I[3](0,F,B)(1E) 00000001 -> 00012465 [4] 53(S) 0E
2016.12.22 13:16:56.302 4: HMW_IO_12_Sw14_DR_MEQ0370281_15: HM485_ChannelDoUpdate
2016.12.22 13:16:56.303 4: HMW_IO_12_Sw14_DR_MEQ0370281_15: state -> on
2016.12.22 13:16:56.316 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (53) I[0](0,F,B)(18) 00000001 -> 00012465 [4] 53(S) 0F
2016.12.22 13:16:56.379 4: HMW_IO_12_Sw14_DR_MEQ0370281_16: HM485_ChannelDoUpdate
2016.12.22 13:16:56.380 4: HMW_IO_12_Sw14_DR_MEQ0370281_16: state -> on
2016.12.22 13:16:56.384 4: Rollo_stopp_Zimmer2 exec {
  fhem "set HMW_IO_12_Sw14_DR_MEQ0370281_11 off";;
  fhem "set HMW_IO_12_Sw14_DR_MEQ0370281_12 off";;
  fhem "set HMW_IO_12_Sw14_DR_MEQ0370281_13 off";;
  fhem "set HMW_IO_12_Sw14_DR_MEQ0370281_14 off";; }
2016.12.22 13:16:57.011 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (54) I[1](0,F,B)(1A) 00000001 -> 00012465 [4] 53(S) 10
2016.12.22 13:16:57.068 4: dummy set Test2 toggle
2016.12.22 13:16:57.077 4: nty_Test exec IF ([Test:&STATE] eq "on") (set Test off) ELSE (set Test on)
2016.12.22 13:16:57.082 4: dummy set Test off
2016.12.22 13:16:57.084 4: Dummy_Aus exec { fhem "set Relais9 off" }
2016.12.22 13:16:57.152 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (55) I[2](0,F,B)(1C) 00000001 -> 00012465 [6] 73(s) 0A0000
2016.12.22 13:16:57.164 4: HMW_IO_12_Sw14_DR_MEQ0370281_17: HM485_ChannelDoUpdate
2016.12.22 13:16:57.165 4: HMW_IO_12_Sw14_DR_MEQ0370281_17: state -> on
2016.12.22 13:16:57.216 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (56) I[3](0,F,B)(1E) 00000001 -> 00012465 [6] 73(s) 0B0000
2016.12.22 13:16:57.228 4: HMW_IO_12_Sw14_DR_MEQ0370281_11: HM485_ChannelDoUpdate
2016.12.22 13:16:57.229 4: HMW_IO_12_Sw14_DR_MEQ0370281_11: state -> off
2016.12.22 13:16:57.273 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (57) I[0](0,F,B)(18) 00000001 -> 00012465 [6] 73(s) 0C0000
2016.12.22 13:16:57.284 4: HMW_IO_12_Sw14_DR_MEQ0370281_12: HM485_ChannelDoUpdate
2016.12.22 13:16:57.285 4: HMW_IO_12_Sw14_DR_MEQ0370281_12: state -> off
2016.12.22 13:16:57.332 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (58) I[1](0,F,B)(1A) 00000001 -> 00012465 [6] 73(s) 0D0000
2016.12.22 13:16:57.343 4: HMW_IO_12_Sw14_DR_MEQ0370281_13: HM485_ChannelDoUpdate
2016.12.22 13:16:57.345 4: HMW_IO_12_Sw14_DR_MEQ0370281_13: state -> off
2016.12.22 13:16:57.399 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (59) I[2](0,F,B)(1C) 00000001 -> 00012465 [4] 53(S) 11
2016.12.22 13:16:57.410 4: HMW_IO_12_Sw14_DR_MEQ0370281_14: HM485_ChannelDoUpdate
2016.12.22 13:16:57.412 4: HMW_IO_12_Sw14_DR_MEQ0370281_14: state -> off
2016.12.22 13:16:57.466 4: HMW_IO_12_Sw14_DR_MEQ0370281_18: HM485_ChannelDoUpdate
2016.12.22 13:16:57.467 4: HMW_IO_12_Sw14_DR_MEQ0370281_18: state -> on
2016.12.22 13:16:57.472 4: Rollo_stopp_Zimmer2 exec {
  fhem "set HMW_IO_12_Sw14_DR_MEQ0370281_11 off";;
  fhem "set HMW_IO_12_Sw14_DR_MEQ0370281_12 off";;
  fhem "set HMW_IO_12_Sw14_DR_MEQ0370281_13 off";;
  fhem "set HMW_IO_12_Sw14_DR_MEQ0370281_14 off";; }
2016.12.22 13:16:57.576 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (60) I[3](0,F,B)(1E) 00000001 -> 00012465 [4] 53(S) 12
2016.12.22 13:16:57.665 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (61) I[0](0,F,B)(18) 00000001 -> 00012465 [6] 73(s) 0A0000
2016.12.22 13:16:57.676 4: HMW_IO_12_Sw14_DR_MEQ0370281_19: HM485_ChannelDoUpdate
2016.12.22 13:16:57.678 4: HMW_IO_12_Sw14_DR_MEQ0370281_19: state -> on
2016.12.22 13:16:57.720 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (62) I[1](0,F,B)(1A) 00000001 -> 00012465 [6] 73(s) 0B0000
2016.12.22 13:16:57.731 4: HMW_IO_12_Sw14_DR_MEQ0370281_11: HM485_ChannelDoUpdate
2016.12.22 13:16:57.732 4: HMW_IO_12_Sw14_DR_MEQ0370281_11: state -> off
2016.12.22 13:16:57.784 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (63) I[2](0,F,B)(1C) 00000001 -> 00012465 [6] 73(s) 0C0000
2016.12.22 13:16:57.795 4: HMW_IO_12_Sw14_DR_MEQ0370281_12: HM485_ChannelDoUpdate
2016.12.22 13:16:57.796 4: HMW_IO_12_Sw14_DR_MEQ0370281_12: state -> off
2016.12.22 13:16:57.852 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (64) I[3](0,F,B)(1E) 00000001 -> 00012465 [6] 73(s) 0D0000
2016.12.22 13:16:57.863 4: HMW_IO_12_Sw14_DR_MEQ0370281_13: HM485_ChannelDoUpdate
2016.12.22 13:16:57.865 4: HMW_IO_12_Sw14_DR_MEQ0370281_13: state -> off
2016.12.22 13:16:57.906 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (65) I[0](0,F,B)(18) 00000001 -> 00012465 [4] 53(S) 13
2016.12.22 13:16:57.917 4: HMW_IO_12_Sw14_DR_MEQ0370281_14: HM485_ChannelDoUpdate
2016.12.22 13:16:57.918 4: HMW_IO_12_Sw14_DR_MEQ0370281_14: state -> off
2016.12.22 13:16:57.967 4: HMW_IO_12_Sw14_DR_MEQ0370281_20: HM485_ChannelDoUpdate
2016.12.22 13:16:57.969 4: HMW_IO_12_Sw14_DR_MEQ0370281_20: state -> on
2016.12.22 13:16:57.983 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (66) I[1](0,F,B)(1A) 00000001 -> 00012465 [4] 53(S) 14
2016.12.22 13:16:58.043 4: HMW_IO_12_Sw14_DR_MEQ0370281_21: HM485_ChannelDoUpdate
2016.12.22 13:16:58.045 4: HMW_IO_12_Sw14_DR_MEQ0370281_21: state -> off
2016.12.22 13:16:58.059 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (67) I[2](0,F,B)(1C) 00000001 -> 00012465 [4] 53(S) 15
2016.12.22 13:16:58.119 4: HMW_IO_12_Sw14_DR_MEQ0370281_22: HM485_ChannelDoUpdate
2016.12.22 13:16:58.120 4: HMW_IO_12_Sw14_DR_MEQ0370281_22: state -> off
2016.12.22 13:16:58.131 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (68) I[3](0,F,B)(1E) 00000001 -> 00012465 [4] 53(S) 16
2016.12.22 13:16:58.199 4: HMW_IO_12_Sw14_DR_MEQ0370281_23: HM485_ChannelDoUpdate
2016.12.22 13:16:58.200 4: HMW_IO_12_Sw14_DR_MEQ0370281_23: state -> off
2016.12.22 13:16:58.216 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (69) I[0](0,F,B)(18) 00000001 -> 00012465 [4] 53(S) 17
2016.12.22 13:16:58.279 4: HMW_IO_12_Sw14_DR_MEQ0370281_24: HM485_ChannelDoUpdate
2016.12.22 13:16:58.280 4: HMW_IO_12_Sw14_DR_MEQ0370281_24: state -> off
2016.12.22 13:16:58.293 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (70) I[1](0,F,B)(1A) 00000001 -> 00012465 [4] 53(S) 18
2016.12.22 13:16:58.360 4: HMW_IO_12_Sw14_DR_MEQ0370281_25: HM485_ChannelDoUpdate
2016.12.22 13:16:58.361 4: HMW_IO_12_Sw14_DR_MEQ0370281_25: state -> off
2016.12.22 13:16:58.377 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (71) I[2](0,F,B)(1C) 00000001 -> 00012465 [4] 53(S) 19
2016.12.22 13:16:58.440 4: HMW_IO_12_Sw14_DR_MEQ0370281_26: HM485_ChannelDoUpdate
2016.12.22 13:16:58.441 4: HMW_IO_12_Sw14_DR_MEQ0370281_26: state -> off
2016.12.22 13:16:59.216 4: Connection closed for WEB_192.168.1.20_51313: EOF
2016.12.22 13:16:59.245 4: Connection accepted from WEB_192.168.1.20_51340
2016.12.22 13:16:59.249 4: WEB_192.168.1.20_51340 GET /fhem?room=CUL%5fHM; BUFLEN:0
2016.12.22 13:16:59.414 4: name: /fhem?room=CUL%5fHM / RL:3025 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.12.22 13:16:59.699 4: WEB_192.168.1.20_51340 GET /fhem/images/default/off.png; BUFLEN:0
2016.12.22 13:16:59.701 4: WEB_192.168.1.20_51340 => 304 Not Modified
2016.12.22 13:16:59.710 4: WEB_192.168.1.20_51340 GET /fhem/images/default/on.png; BUFLEN:0
2016.12.22 13:16:59.712 4: WEB_192.168.1.20_51340 => 304 Not Modified
2016.12.22 13:17:00.495 4: WEB_192.168.1.20_51340 GET /fhem?XHR=1&inform=type=status;filter=room=CUL%5fHM;since=1482409018;fmt=JSON&fw_id=492×tamp=1482409018737; BUFLEN:0
2016.12.22 13:17:01.944 4: Connection closed for WEB_192.168.1.20_51340: EOF
2016.12.22 13:17:01.976 4: Connection accepted from WEB_192.168.1.20_51343
2016.12.22 13:17:01.979 4: WEB_192.168.1.20_51343 GET /fhem?detail=nanoCUL; BUFLEN:0
2016.12.22 13:17:02.035 4: name: /fhem?detail=nanoCUL / RL:4170 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.12.22 13:17:02.766 4: WEB_192.168.1.20_51343 GET /fhem?cmd={ReadingsVal(%22nanoCUL%22,%22CCAmode%22,%22%22)}&XHR=1; BUFLEN:0
2016.12.22 13:17:02.777 4: name: /fhem?cmd={ReadingsVal(%22nanoCUL%22,%22CCAmode%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.12.22 13:17:02.780 4: Connection accepted from WEB_192.168.1.20_51345
2016.12.22 13:17:02.783 4: WEB_192.168.1.20_51345 GET /fhem?cmd={AttrVal(%22nanoCUL%22,%22room%22,%22%22)}&XHR=1; BUFLEN:0
2016.12.22 13:17:02.793 4: name: /fhem?cmd={AttrVal(%22nanoCUL%22,%22room%22,%22%22)}&XHR=1 / RL:27 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.12.22 13:17:02.864 4: WEB_192.168.1.20_51343 GET /fhem?XHR=1&inform=type=status;filter=nanoCUL;since=1482409020;fmt=JSON&fw_id=493×tamp=1482409021092; BUFLEN:0
2016.12.22 13:17:06.758 4: WEB_192.168.1.20_51345 GET /fhem?cmd={ReadingsVal(%22nanoCUL%22,%22hmPairForSec%22,%22%22)}&XHR=1; BUFLEN:0
2016.12.22 13:17:06.768 4: name: /fhem?cmd={ReadingsVal(%22nanoCUL%22,%22hmPairForSec%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.12.22 13:17:07.022 4: dummy set Test2 toggle
2016.12.22 13:17:07.075 4: nty_Test exec IF ([Test:&STATE] eq "on") (set Test off) ELSE (set Test on)
2016.12.22 13:17:07.081 4: dummy set Test on
2016.12.22 13:17:07.083 4: Dummy_Ein exec { fhem "set Relais9 on";; fhem "set HMW_IO_12_Sw14_DR_LEQ1322965_01 toggle" }
2016.12.22 13:17:07.163 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (72) I[0](0,F,B)(18) 00000001 -> 00011169 [6] 73(s) 000000
2016.12.22 13:17:07.211 4: HMW_IO_12_Sw14_DR_LEQ1322965_01: HM485_ChannelDoUpdate
2016.12.22 13:17:07.212 4: HMW_IO_12_Sw14_DR_LEQ1322965_01: state -> off
2016.12.22 13:17:10.455 4: Connection closed for WEB_192.168.1.20_51343: EOF
2016.12.22 13:17:10.465 4: WEB_192.168.1.20_51345 POST /fhem&detail=nanoCUL&dev.setnanoCUL=nanoCUL&cmd.setnanoCUL=set&arg.setnanoCUL=hmPairForSec&val.setnanoCUL=30; BUFLEN:0
2016.12.22 13:17:10.495 4: WEB_192.168.1.20_51345 GET /fhem?detail=nanoCUL&fw_id=; BUFLEN:0
2016.12.22 13:17:10.550 4: name: /fhem?detail=nanoCUL&fw_id= / RL:4186 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.12.22 13:17:11.223 4: WEB_192.168.1.20_51345 GET /fhem?cmd={ReadingsVal(%22nanoCUL%22,%22CCAmode%22,%22%22)}&XHR=1; BUFLEN:0
2016.12.22 13:17:11.233 4: name: /fhem?cmd={ReadingsVal(%22nanoCUL%22,%22CCAmode%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.12.22 13:17:11.249 4: WEB_192.168.1.20_51345 GET /fhem?cmd={AttrVal(%22nanoCUL%22,%22room%22,%22%22)}&XHR=1; BUFLEN:0
2016.12.22 13:17:11.259 4: name: /fhem?cmd={AttrVal(%22nanoCUL%22,%22room%22,%22%22)}&XHR=1 / RL:27 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.12.22 13:17:11.307 4: WEB_192.168.1.20_51345 GET /fhem?XHR=1&inform=type=status;filter=nanoCUL;since=1482409029;fmt=JSON&fw_id=494×tamp=1482409029552; BUFLEN:0
2016.12.22 13:17:16.731 4: TSCUL_Parse: nanoCUL  445354 A FF52 00053064 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2016.12.22 13:17:17.022 4: dummy set Test2 toggle
2016.12.22 13:17:17.031 4: nty_Test exec IF ([Test:&STATE] eq "on") (set Test off) ELSE (set Test on)
2016.12.22 13:17:17.036 4: dummy set Test off
2016.12.22 13:17:17.038 4: Dummy_Aus exec { fhem "set Relais9 off" }
2016.12.22 13:17:27.029 4: dummy set Test2 toggle
2016.12.22 13:17:27.038 4: nty_Test exec IF ([Test:&STATE] eq "on") (set Test off) ELSE (set Test on)
2016.12.22 13:17:27.044 4: dummy set Test on
2016.12.22 13:17:27.047 4: Dummy_Ein exec { fhem "set Relais9 on";; fhem "set HMW_IO_12_Sw14_DR_LEQ1322965_01 toggle" }
2016.12.22 13:17:27.126 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (73) I[1](0,F,B)(1A) 00000001 -> 00011169 [6] 73(s) 0003FF
2016.12.22 13:17:27.176 4: HMW_IO_12_Sw14_DR_LEQ1322965_01: HM485_ChannelDoUpdate
2016.12.22 13:17:27.177 4: HMW_IO_12_Sw14_DR_LEQ1322965_01: state -> on
2016.12.22 13:17:35.911 4: TSCUL_Parse: nanoCUL  464537 A FF51 00072260 00 0F AE 8610 3547BB 000000 0AA0D5080D40 -50
2016.12.22 13:17:37.023 4: dummy set Test2 toggle
2016.12.22 13:17:37.032 4: nty_Test exec IF ([Test:&STATE] eq "on") (set Test off) ELSE (set Test on)
2016.12.22 13:17:37.038 4: dummy set Test off
2016.12.22 13:17:37.040 4: Dummy_Aus exec { fhem "set Relais9 off" }
2016.12.22 13:17:38.015 4: Connection closed for WEB_192.168.1.20_51345: EOF
2016.12.22 13:17:38.840 4: Connection accepted from WEB_192.168.1.20_51382
2016.12.22 13:17:38.844 4: WEB_192.168.1.20_51382 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2016-12.log; BUFLEN:0

Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 22 Dezember 2016, 13:41:57
Hallo Mario,

ich sehe in Deinem Log, keinen einzigen Versuch eines Anlernvorgangs mit TSCUL.
Es wird kein entsprechendes Paket empfangen.

Falls es ein Empfangsproblem ist, stell mal hmFreqOffs mit set auf 0.
Kontrolle ist über get ccconf möglich.

Wenn es dann geht, dann weicht Dein cc1101 Empfänger eher in Richtung 0+ ab, denke ich.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Maxl am 22 Dezember 2016, 14:29:15
Hi,

anbei das config des nanoCUL

nanoCUL 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 CCAmode:3 csRelThr:dis csAbsThr:0dB

und das Logfile
2016.12.22 14:26:53.162 1: Including fhem.cfg
2016.12.22 14:26:53.259 3: telnetPort: port 7072 opened
2016.12.22 14:26:53.675 3: WEB: port 8083 opened
2016.12.22 14:26:53.679 3: WEBphone: port 8084 opened
2016.12.22 14:26:53.706 3: WEBtablet: port 8085 opened
2016.12.22 14:26:54.637 2: eventTypes: loaded 1000 events from ./log/eventTypes.txt
2016.12.22 14:26:56.039 2: TSCUL_Parse: nanoCUL new condition disconnected
2016.12.22 14:26:56.040 3: Opening nanoCUL device /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
2016.12.22 14:26:56.170 3: DevIoTS_OpenDev: Setting nanoCUL serial parameters to 38400,8,N,1
2016.12.22 14:26:56.986 1: nanoCUL is VERSION_TS, VTS 0.05 nanoCUL868, nanoCUL_V1.x
2016.12.22 14:26:57.014 3: nanoCUL: Possible commands: ABCEFGJKMRUVWXYZefilmtx
2016.12.22 14:26:57.046 2: TSCUL_Parse: nanoCUL new condition init
2016.12.22 14:26:57.047 3: DevIoTS_OpenDev: nanoCUL device opened
2016.12.22 14:26:57.104 2: TSCUL_Parse: nanoCUL new condition init
2016.12.22 14:26:57.106 2: Switched nanoCUL rfmode to HomeMatic
2016.12.22 14:26:57.414 3: HM485: HM485: Loading available device files
2016.12.22 14:26:57.415 3: HM485: =====================================
2016.12.22 14:26:57.416 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw-sen-sc-12.pm
2016.12.22 14:26:57.422 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_central.pm
2016.12.22 14:26:57.427 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_generic.pm
2016.12.22 14:26:57.429 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io12_fm.pm
2016.12.22 14:26:57.462 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io12_sw14_dr.pm
2016.12.22 14:26:57.483 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io12_sw7_dr.pm
2016.12.22 14:26:57.528 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io12_sw7_dr_V3_02.pm
2016.12.22 14:26:57.570 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io12_sw7_dr_v3_02.pm
2016.12.22 14:26:57.602 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io_12_fm.pm
2016.12.22 14:26:57.648 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io_4_fm.pm
2016.12.22 14:26:57.695 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io_4_fm_V3_02.pm
2016.12.22 14:26:57.739 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io_4_fm_v3_02.pm
2016.12.22 14:26:57.774 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_io_sr_fm.pm
2016.12.22 14:26:57.820 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_bl1_dr.pm
2016.12.22 14:26:57.885 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_bl1_dr_V3_02.pm
2016.12.22 14:26:57.950 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_bl1_dr_v3_02.pm
2016.12.22 14:26:57.995 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_dim1l_dr.pm
2016.12.22 14:26:58.061 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_sw2_dr.pm
2016.12.22 14:26:58.108 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_sw2_dr_V3_02.pm
2016.12.22 14:26:58.150 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_lc_sw2_dr_v3_02.pm
2016.12.22 14:26:58.182 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_sen_sc_12_dr.pm
2016.12.22 14:26:58.190 3: HM485: Loading device file: ./FHEM/lib/HM485/Devices/hmw_virtual.pm
2016.12.22 14:26:58.326 3: Opening NETIO1 device 192.168.1.98:2701
2016.12.22 14:26:58.343 3: NETIO1 device opened
2016.12.22 14:26:58.417 3: Opening NETIO2 device 192.168.1.99:2701
2016.12.22 14:26:58.421 3: NETIO2 device opened
2016.12.22 14:26:58.676 2: HM_LAN_WIRED: Assigned 00011169 as HMW_IO_12_Sw14_DR_LEQ1322965
2016.12.22 14:26:59.508 2: HM_LAN_WIRED: Assigned 00012465 as HMW_IO_12_Sw14_DR_MEQ0370281
2016.12.22 14:27:00.269 1: Including ./log/fhem.save
2016.12.22 14:27:01.217 3: Device Bewegungsmelder_EG added to ActionDetector with 024:00 time
2016.12.22 14:27:01.228 4: Device Bewegungsmelder_EG is alive
2016.12.22 14:27:01.250 3: Device Bewegungsmelder_UG added to ActionDetector with 024:00 time
2016.12.22 14:27:01.260 4: Device Bewegungsmelder_UG is alive
2016.12.22 14:27:01.283 3: Device CUL_HM_HM_CC_RT_DN_354555 added to ActionDetector with 000:10 time
2016.12.22 14:27:01.293 4: Device CUL_HM_HM_CC_RT_DN_354555 is alive
2016.12.22 14:27:01.365 3: Device CUL_HM_HM_CC_RT_DN_3547B5 added to ActionDetector with 000:10 time
2016.12.22 14:27:01.375 4: Device CUL_HM_HM_CC_RT_DN_3547B5 is alive
2016.12.22 14:27:01.448 3: Device CUL_HM_HM_CC_RT_DN_3547BA added to ActionDetector with 000:10 time
2016.12.22 14:27:01.458 4: Device CUL_HM_HM_CC_RT_DN_3547BA is alive
2016.12.22 14:27:01.530 3: Device CUL_HM_HM_CC_RT_DN_3547BB added to ActionDetector with 000:10 time
2016.12.22 14:27:01.541 4: Device CUL_HM_HM_CC_RT_DN_3547BB is alive
2016.12.22 14:27:01.614 3: Device CUL_HM_HM_CC_RT_DN_3547BF added to ActionDetector with 000:10 time
2016.12.22 14:27:01.625 4: Device CUL_HM_HM_CC_RT_DN_3547BF is alive
2016.12.22 14:27:01.697 3: Device CUL_HM_HM_CC_RT_DN_3549DB added to ActionDetector with 000:10 time
2016.12.22 14:27:01.708 4: Device CUL_HM_HM_CC_RT_DN_3549DB is alive
2016.12.22 14:27:01.781 3: Device CUL_HM_HM_CC_RT_DN_3549DE added to ActionDetector with 000:10 time
2016.12.22 14:27:01.793 4: Device CUL_HM_HM_CC_RT_DN_3549DE is alive
2016.12.22 14:27:01.866 3: Device CUL_HM_HM_CC_RT_DN_3549E1 added to ActionDetector with 000:10 time
2016.12.22 14:27:01.878 4: Device CUL_HM_HM_CC_RT_DN_3549E1 is alive
2016.12.22 14:27:02.067 3: Device CUL_HM_HM_SEC_SD_2F361B added to ActionDetector with 099:00 time
2016.12.22 14:27:02.077 4: Device CUL_HM_HM_SEC_SD_2F361B is alive
2016.12.22 14:27:02.105 3: Device CUL_HM_HM_SEC_SD_2F3665 added to ActionDetector with 099:00 time
2016.12.22 14:27:02.115 4: Device CUL_HM_HM_SEC_SD_2F3665 is alive
2016.12.22 14:27:02.142 3: Device CUL_HM_HM_SEC_SD_2F36E2 added to ActionDetector with 099:00 time
2016.12.22 14:27:02.153 4: Device CUL_HM_HM_SEC_SD_2F36E2 is alive
2016.12.22 14:27:02.181 3: Device CUL_HM_HM_SEC_SD_2F387B added to ActionDetector with 099:00 time
2016.12.22 14:27:02.192 4: Device CUL_HM_HM_SEC_SD_2F387B is alive
2016.12.22 14:27:02.220 3: Device CUL_HM_HM_SEC_SD_2F387C added to ActionDetector with 099:00 time
2016.12.22 14:27:02.231 4: Device CUL_HM_HM_SEC_SD_2F387C is alive
2016.12.22 14:27:02.259 3: Device CUL_HM_HM_SEC_SD_2F389B added to ActionDetector with 099:00 time
2016.12.22 14:27:02.271 4: Device CUL_HM_HM_SEC_SD_2F389B is alive
2016.12.22 14:27:02.655 4: initialUsbCheck exec usb create
2016.12.22 14:27:02.656 1: usb create starting
2016.12.22 14:27:03.249 4: ### ttyAMA0: checking if it is a CUL
2016.12.22 14:27:03.252 3: Probing CUL device /dev/ttyAMA0
2016.12.22 14:27:03.467 4: got wrong answer for a CUL
2016.12.22 14:27:03.468 4: ### ttyAMA0: checking if it is a TCM_ESP3
2016.12.22 14:27:03.470 3: Probing TCM_ESP3 device /dev/ttyAMA0
2016.12.22 14:27:03.679 4: got wrong answer for a TCM_ESP3
2016.12.22 14:27:03.680 4: ### ttyAMA0: checking if it is a FRM
2016.12.22 14:27:03.683 3: Probing FRM device /dev/ttyAMA0
2016.12.22 14:27:08.895 4: got wrong answer for a FRM
2016.12.22 14:27:08.896 4: ### ttyUSB0: checking if it is a TCM_ESP3
2016.12.22 14:27:08.899 4: ttyUSB0 is already used by the fhem device nanoCUL
2016.12.22 14:27:08.900 4: ### ttyUSB1: checking if it is a TCM_ESP3
2016.12.22 14:27:08.902 3: Probing TCM_ESP3 device /dev/ttyUSB1
2016.12.22 14:27:09.121 4: got wrong answer for a TCM_ESP3
2016.12.22 14:27:09.122 4: ### ttyUSB1: checking if it is a TCM_ESP2
2016.12.22 14:27:09.124 3: Probing TCM_ESP2 device /dev/ttyUSB1
2016.12.22 14:27:09.344 4: got wrong answer for a TCM_ESP2
2016.12.22 14:27:09.345 4: ### ttyUSB1: checking if it is a FHZ
2016.12.22 14:27:09.347 3: Probing FHZ device /dev/ttyUSB1
2016.12.22 14:27:09.566 4: got wrong answer for a FHZ
2016.12.22 14:27:09.567 4: ### ttyUSB1: checking if it is a TRX
2016.12.22 14:27:09.569 3: Probing TRX device /dev/ttyUSB1
2016.12.22 14:27:10.300 4: got wrong answer for a TRX
2016.12.22 14:27:10.301 4: ### ttyUSB1: checking if it is a ZWDongle
2016.12.22 14:27:10.304 3: Probing ZWDongle device /dev/ttyUSB1
2016.12.22 14:27:10.524 4: got wrong answer for a ZWDongle
2016.12.22 14:27:10.525 4: ### ttyUSB1: checking if it is a FRM
2016.12.22 14:27:10.527 3: Probing FRM device /dev/ttyUSB1
2016.12.22 14:27:17.202 4: got wrong answer for a FRM
2016.12.22 14:27:17.234 1: usb create end
2016.12.22 14:27:17.264 2: SecurityCheck:  WEB,WEBtablet has no associated allowed device with basicAuth. telnetPort has no associated allowed device with password/globalpassword.  Restart FHEM for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2016.12.22 14:27:17.265 0: Featurelevel: 5.7
2016.12.22 14:27:17.265 0: Server started with 245 defined entities (fhem.pl:12463/2016-10-29 perl:5.014002 os:linux user:fhem pid:27914)
2016.12.22 14:27:17.405 1: HM_LAN_WIRED: HM485d already running with PID 27719. We are using this process.
2016.12.22 14:27:17.418 3: HM_LAN_WIRED: Warte auf Initialisierung Gateway
2016.12.22 14:27:17.428 3: HM_LAN_WIRED: Warte auf Initialisierung Gateway
2016.12.22 14:27:17.452 4: dummy set Test2 toggle
2016.12.22 14:27:17.461 4: nty_Test exec IF ([Test:&STATE] eq "on") (set Test off) ELSE (set Test on)
2016.12.22 14:27:17.530 4: dummy set Test off
2016.12.22 14:27:17.533 4: Dummy_Aus exec { fhem "set Relais9 off" }
2016.12.22 14:27:17.580 4: Connection accepted from WEB_192.168.1.20_54754
2016.12.22 14:27:17.583 2: TSCUL_Parse: nanoCUL new condition ok
2016.12.22 14:27:17.593 4: TSCUL_Parse: nanoCUL  451904 A FF51 00006384 00 0F FB 8610 3549E1 000000 0A24C70B0040 -72.5
2016.12.22 14:27:17.775 4: TSCUL_Parse: nanoCUL  452097 A FF51 00008092 00 0F 64 8610 354555 000000 0A28A80A0040 -59
2016.12.22 14:27:17.837 4: TSCUL_Parse: nanoCUL  452160 A FF51 00010552 00 0D DC A641 4F9EC9 F11234 012AB240 -84.5
2016.12.22 14:27:17.854 4: TSCUL_send:  nanoCUL                         As 0D DC 8002 F11234 4F9EC9 0101B200
2016.12.22 14:27:17.855 3: TSCUL_XmitDlyHM:  nanoCUL  id:4F9EC9 dDly:91 toms:72
2016.12.22 14:27:17.884 4: TSCUL_Parse: nanoCUL  452207 A FF51 00011220 00 0D DC A641 4F9EC9 F11234 012AB240 -84.5
2016.12.22 14:27:17.887 4: CUL_HM Bewegungsmelder_UG dupe: dont process
2016.12.22 14:27:17.890 4: TSCUL_Parse: nanoCUL  452213 A FF51 00011520 00 0D DC A641 4F9EC9 F11234 012AB240 -84
2016.12.22 14:27:17.893 4: CUL_HM Bewegungsmelder_UG dupe: dont process
2016.12.22 14:27:17.896 3: Opening HM_LAN_WIRED device localhost:2000
2016.12.22 14:27:17.904 3: Can't connect to localhost:2000: Connection reset by peer
2016.12.22 14:27:17.908 4: Connection accepted from WEB_192.168.1.20_54753
2016.12.22 14:27:17.911 4: TSCUL_Parse: nanoCUL  452233 A FF51 00016136 00 0D AB A641 461413 F11234 01176C40 -73
2016.12.22 14:27:17.928 4: TSCUL_send:  nanoCUL                         As 0D AB 8002 F11234 461413 01016C00
2016.12.22 14:27:17.928 3: TSCUL_XmitDlyHM:  nanoCUL  id:461413 dDly:91 toms:72
2016.12.22 14:27:17.955 4: TSCUL_Parse: nanoCUL  452278 A FF51 00016360 00 0D AB A641 461413 F11234 01176C40 -73
2016.12.22 14:27:17.958 4: CUL_HM Bewegungsmelder_EG dupe: dont process
2016.12.22 14:27:17.960 4: TSCUL_Parse: nanoCUL  452284 A FF51 00016848 00 0D AB A641 461413 F11234 01176C40 -73
2016.12.22 14:27:17.963 4: CUL_HM Bewegungsmelder_EG dupe: dont process
2016.12.22 14:27:17.966 4: TSCUL_Parse: nanoCUL  452295 A FF52 00020952 00 01 C3 _ping -138
2016.12.22 14:27:17.967 4: TSCUL_Parse: nanoCUL  452287 A FF52 00020972 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2016.12.22 14:27:18.341 4: WEB_192.168.1.20_54754 GET /fhem?XHR=1&inform=type=status;filter=nanoCUL;since=1482413146.362;fmt=JSON&fw_id=507×tamp=1482413211317; BUFLEN:0
2016.12.22 14:27:18.522 3: HM_LAN_WIRED: Start HM485d with command line: ./FHEM/lib/HM485/HM485d/HM485d.pl --hmwId 00000001 --serialNumber SGW0123456 --device 192.168.1.97:5000 --localPort 2000 --verbose 1
2016.12.22 14:27:18.613 3: HM_LAN_WIRED: HM485d was started with PID: 27930
2016.12.22 14:27:18.614 3: HM_LAN_WIRED: Connect to HM485d delayed for 4 seconds
2016.12.22 14:27:18.626 4: TSCUL_send:  nanoCUL                         As 0A DC 8002 F11234 4F9EC9 00
2016.12.22 14:27:18.638 4: TSCUL_send:  nanoCUL                         As 0A AB 8002 F11234 461413 00
2016.12.22 14:27:18.642 4: Connection accepted from WEB_192.168.1.20_54771
2016.12.22 14:27:18.643 4: Connection closed for WEB_192.168.1.20_54753: EOF
2016.12.22 14:27:18.646 4: TSCUL_Parse: nanoCUL  452970 A FF53 00021380 02 0D DC 8002 F11234 4F9EC9 01 _CCAdly:8 -138
2016.12.22 14:27:18.648 4: TSCUL_Parse: nanoCUL  452972 A FF53 00021472 01 0D AB 8002 F11234 461413 01 _CCAdly:4 -138
2016.12.22 14:27:18.652 4: Connection closed for WEB_192.168.1.20_54754: EOF
2016.12.22 14:27:18.743 4: WEB_192.168.1.20_54771 GET /fhem?room=CUL%5fHM; BUFLEN:0
2016.12.22 14:27:18.939 4: name: /fhem?room=CUL%5fHM / RL:3017 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.12.22 14:27:18.942 4: TSCUL_Parse: nanoCUL  453266 A FF53 00022152 02 0A DC 8002 F11234 4F9EC9 00 _CCAdly:8 -138
2016.12.22 14:27:18.944 4: TSCUL_Parse: nanoCUL  453269 A FF53 00022240 01 0A AB 8002 F11234 461413 00 _CCAdly:4 -138
2016.12.22 14:27:19.118 4: dummy set Test2 toggle
2016.12.22 14:27:19.170 4: nty_Test exec IF ([Test:&STATE] eq "on") (set Test off) ELSE (set Test on)
2016.12.22 14:27:19.176 4: dummy set Test on
2016.12.22 14:27:19.178 4: Dummy_Ein exec { fhem "set Relais9 on";; fhem "set HMW_IO_12_Sw14_DR_LEQ1322965_01 toggle" }
2016.12.22 14:27:19.827 4: Connection accepted from WEB_192.168.1.20_54779
2016.12.22 14:27:19.829 4: WEB_192.168.1.20_54771 GET /fhem/pgm2/style.css?v=1482413213; BUFLEN:0
2016.12.22 14:27:19.830 1: HM485d: Server started ...
2016.12.22 14:27:19.928 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (1) I[0](0,Y,F,B)(98) 00000001 -> 00011169 [6] 73(s) 0003FF
2016.12.22 14:27:19.932 4: WEB_192.168.1.20_54779 GET /fhem/pgm2/hm485.js?1482413218.25254; BUFLEN:0
2016.12.22 14:27:20.021 4: Connection accepted from WEB_192.168.1.20_54780
2016.12.22 14:27:20.104 4: WEB_192.168.1.20_54771 GET /fhem/images/default/off.png; BUFLEN:0
2016.12.22 14:27:20.106 4: WEB_192.168.1.20_54771 => 304 Not Modified
2016.12.22 14:27:20.109 4: WEB_192.168.1.20_54779 GET /fhem/images/default/on.png; BUFLEN:0
2016.12.22 14:27:20.110 4: WEB_192.168.1.20_54779 => 304 Not Modified
2016.12.22 14:27:20.679 4: WEB_192.168.1.20_54771 GET /fhem?XHR=1&inform=type=status;filter=room=CUL%5fHM;since=1482413237;fmt=JSON&fw_id=491×tamp=1482413238526; BUFLEN:0
2016.12.22 14:27:21.075 3: HMW_IO_12_Sw14_DR_LEQ1322965: RESPONSE TIMEOUT for 00011169
2016.12.22 14:27:22.501 3: HM_LAN_WIRED: Warte auf Initialisierung Gateway
2016.12.22 14:27:22.502 3: HM_LAN_WIRED: Warte auf Initialisierung Gateway
2016.12.22 14:27:22.801 3: Opening HM_LAN_WIRED device localhost:2000
2016.12.22 14:27:22.894 4: Connection closed for WEB_192.168.1.20_54771: EOF
2016.12.22 14:27:22.983 4: WEB_192.168.1.20_54779 GET /fhem?detail=nanoCUL; BUFLEN:0
2016.12.22 14:27:23.037 4: name: /fhem?detail=nanoCUL / RL:4270 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.12.22 14:27:23.787 4: WEB_192.168.1.20_54779 GET /fhem?cmd={ReadingsVal(%22nanoCUL%22,%22CCAmode%22,%22%22)}&XHR=1; BUFLEN:0
2016.12.22 14:27:23.798 4: name: /fhem?cmd={ReadingsVal(%22nanoCUL%22,%22CCAmode%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.12.22 14:27:23.888 4: WEB_192.168.1.20_54780 GET /fhem?cmd={AttrVal(%22nanoCUL%22,%22room%22,%22%22)}&XHR=1; BUFLEN:0
2016.12.22 14:27:23.899 4: name: /fhem?cmd={AttrVal(%22nanoCUL%22,%22room%22,%22%22)}&XHR=1 / RL:27 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.12.22 14:27:24.010 4: WEB_192.168.1.20_54779 GET /fhem?XHR=1&inform=type=status;filter=nanoCUL;since=1482413241;fmt=JSON&fw_id=492×tamp=1482413241756; BUFLEN:0
2016.12.22 14:27:26.069 4: TSCUL_Parse: nanoCUL  460398 A FF52 00029584 00 01 C3 _ping -138
2016.12.22 14:27:27.243 4: WEB_192.168.1.20_54780 GET /fhem?cmd={ReadingsVal(%22nanoCUL%22,%22hmPairForSec%22,%22%22)}&XHR=1; BUFLEN:0
2016.12.22 14:27:27.254 4: name: /fhem?cmd={ReadingsVal(%22nanoCUL%22,%22hmPairForSec%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.12.22 14:27:27.585 3: HM_LAN_WIRED: Warte auf Initialisierung Gateway
2016.12.22 14:27:27.588 3: HM_LAN_WIRED: Warte auf Initialisierung Gateway
2016.12.22 14:27:28.498 4: TSCUL_Parse: nanoCUL  462819 A FF51 00031932 00 0F 1E 8610 3547B5 000000 0A4CBD0A0040 -90
2016.12.22 14:27:29.142 4: dummy set Test2 toggle
2016.12.22 14:27:29.153 4: nty_Test exec IF ([Test:&STATE] eq "on") (set Test off) ELSE (set Test on)
2016.12.22 14:27:29.159 4: dummy set Test off
2016.12.22 14:27:29.161 4: Dummy_Aus exec { fhem "set Relais9 off" }
2016.12.22 14:27:29.506 4: TSCUL_Parse: nanoCUL  463829 A FF51 00032940 00 0D AC A641 461413 F11234 01186C40 -73
2016.12.22 14:27:29.525 4: TSCUL_send:  nanoCUL                         As 0D AC 8002 F11234 461413 01016C00
2016.12.22 14:27:29.525 3: TSCUL_XmitDlyHM:  nanoCUL  id:461413 dDly:13 toms:72
2016.12.22 14:27:29.648 4: TSCUL_send:  nanoCUL                         As 0A AC 8002 F11234 461413 00
2016.12.22 14:27:29.649 3: TSCUL_XmitDlyHM:  nanoCUL  id:461413 dDly:11 toms:72
2016.12.22 14:27:29.653 4: TSCUL_Parse: nanoCUL  463977 A FF53 00033060 01 0D AC 8002 F11234 461413 01 _CCAdly:4 _dhmSt:120 -138
2016.12.22 14:27:29.739 4: TSCUL_Parse: nanoCUL  464063 A FF53 00033180 01 0A AC 8002 F11234 461413 00 _CCAdly:4 _dhmSt:240 -138
2016.12.22 14:27:31.019 4: Connection closed for WEB_192.168.1.20_54779: EOF
2016.12.22 14:27:31.104 4: WEB_192.168.1.20_54780 POST /fhem&detail=nanoCUL&dev.setnanoCUL=nanoCUL&cmd.setnanoCUL=set&arg.setnanoCUL=hmPairForSec&val.setnanoCUL=30; BUFLEN:0
2016.12.22 14:27:31.207 4: WEB_192.168.1.20_54780 GET /fhem?detail=nanoCUL&fw_id=; BUFLEN:0
2016.12.22 14:27:31.267 4: name: /fhem?detail=nanoCUL&fw_id= / RL:4283 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.12.22 14:27:32.045 4: WEB_192.168.1.20_54780 GET /fhem?cmd={ReadingsVal(%22nanoCUL%22,%22CCAmode%22,%22%22)}&XHR=1; BUFLEN:0
2016.12.22 14:27:32.058 4: name: /fhem?cmd={ReadingsVal(%22nanoCUL%22,%22CCAmode%22,%22%22)}&XHR=1 / RL:21 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.12.22 14:27:32.142 4: Connection accepted from WEB_192.168.1.20_54791
2016.12.22 14:27:32.228 4: WEB_192.168.1.20_54791 GET /fhem?cmd={AttrVal(%22nanoCUL%22,%22room%22,%22%22)}&XHR=1; BUFLEN:0
2016.12.22 14:27:32.240 4: name: /fhem?cmd={AttrVal(%22nanoCUL%22,%22room%22,%22%22)}&XHR=1 / RL:27 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/
2016.12.22 14:27:32.243 4: WEB_192.168.1.20_54780 GET /fhem?XHR=1&inform=type=status;filter=nanoCUL;since=1482413250;fmt=JSON&fw_id=493×tamp=1482413250025; BUFLEN:0
2016.12.22 14:27:32.672 3: HM_LAN_WIRED: Warte auf Initialisierung Gateway
2016.12.22 14:27:32.673 3: HM_LAN_WIRED: Warte auf Initialisierung Gateway
2016.12.22 14:27:34.732 4: TSCUL_Parse: nanoCUL  469048 A FF51 00038168 00 1A AD 8400 461413 000000 16005D4E45513031313830363481110100 -77
2016.12.22 14:27:34.738 3: Device Bewegungsmelder_EG added to ActionDetector with 024:00 time
2016.12.22 14:27:34.744 4: Device Bewegungsmelder_EG is alive
2016.12.22 14:27:34.745 3: CUL_HM pair: Bewegungsmelder_EG motionDetector, model HM-Sen-MDIR-O serialNr NEQ0118064
2016.12.22 14:27:34.764 4: TSCUL_send:  nanoCUL                         As 10 D5 A001 F11234 461413 00050000000000
2016.12.22 14:27:34.938 4: TSCUL_Parse: nanoCUL  469263 A FF53 00038304 02 10 D5 A001 F11234 461413 00 _CCAdly:8 _dhmSt:136 -138
2016.12.22 14:27:34.941 4: TSCUL_Parse: nanoCUL  469265 A FF51 00038452 00 0A D5 8002 461413 F11234 00 -78
2016.12.22 14:27:34.958 4: TSCUL_send:  nanoCUL                         As 13 D6 A001 F11234 461413 000802010AF10B120C34
2016.12.22 14:27:34.958 3: TSCUL_XmitDlyHM:  nanoCUL  id:461413 dDly:85 toms:74
2016.12.22 14:27:35.165 4: TSCUL_Parse: nanoCUL  469489 A FF53 00038572 01 13 D6 A001 F11234 461413 00 _CCAdly:4 _dhmSt:120 -138
2016.12.22 14:27:35.251 4: TSCUL_Parse: nanoCUL  469575 A FF51 00038720 00 0A D6 8002 461413 F11234 00 -76.5
2016.12.22 14:27:35.269 4: TSCUL_send:  nanoCUL                         As 0B D7 A001 F11234 461413 0006
2016.12.22 14:27:35.270 3: TSCUL_XmitDlyHM:  nanoCUL  id:461413 dDly:46 toms:72
2016.12.22 14:27:35.358 4: TSCUL_Parse: nanoCUL  469682 A FF53 00038840 01 0B D7 A001 F11234 461413 00 _CCAdly:4 _dhmSt:120 -138
2016.12.22 14:27:35.549 4: TSCUL_Parse: nanoCUL  469873 A FF51 00038988 00 0A D7 8002 461413 F11234 00 -71.5
2016.12.22 14:27:37.760 3: HM_LAN_WIRED: Warte auf Initialisierung Gateway
2016.12.22 14:27:37.761 3: HM_LAN_WIRED: Warte auf Initialisierung Gateway
2016.12.22 14:27:39.142 4: dummy set Test2 toggle
2016.12.22 14:27:39.153 4: nty_Test exec IF ([Test:&STATE] eq "on") (set Test off) ELSE (set Test on)
2016.12.22 14:27:39.159 4: dummy set Test on
2016.12.22 14:27:39.162 4: Dummy_Ein exec { fhem "set Relais9 on";; fhem "set HMW_IO_12_Sw14_DR_LEQ1322965_01 toggle" }
2016.12.22 14:27:39.323 4: HM_LAN_WIRED: HM_LAN_WIRED: TX: (1) I[1](0,F,B)(1A) 00000001 -> 00011169 [6] 73(s) 000000
2016.12.22 14:27:39.957 4: Connection closed for WEB_192.168.1.20_54780: EOF
2016.12.22 14:27:40.043 4: WEB_192.168.1.20_54791 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2016-12.log; BUFLEN:0


sieht aus als hätte es jetzt funktioniert, zumindest hat der Melder OK gemeldet. Welche Frequenz haben die Aktoren genau und warum ist ein OFFSET defaultmäßig von 300kHz eingestellt?
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 22 Dezember 2016, 15:47:02
Hallo Mario,

seltsam, ein Offset auf 300kHz kann eingentlich nicht sein, weil der Range gar nicht ganz so groß ist.

Wenn Du neu compiliert hast und HAS_NO_VERSION_CHANGE_FACTORY_RESET in der board.h aktiviert hast, dann wird kein "factory_reset" des EEPROMs mit Versionsänderung ausgeführt und dann kann ziemlicher Quatsch drin stehen. Bei leerem EEPROM Speicherplatz müste es eigentlich FF sein als -1.6x kHz oder so was.
Ein set raw e führt den factory_reset auch aus.

Mein default mit factory Reset Wert ist -22.217kHz, weil es bei mir so gut passt und bei allen CULs die ich testen kann recht ähnlich ist.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Maxl am 22 Dezember 2016, 16:47:51
Hallo Ansgar,

nach dem Reset hatte ich deine erwähnten Werte, mal schaun wie sich nun alles verhält.

Danke
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Maxl am 23 Dezember 2016, 08:55:08
Hallo Ansgar,

es läuft mit 0kHz Offset wunderbar, hätte nur ein paar Fragen:
Welche Parameter muß der CC1102 Receiver bei Homematic eigentich haben, wie kann man diese verändern (Bandbreite,...)?
Was bedeuten eigentlich die Werte in den Botschaften am Ende, sind dies die Pegel?
Was ist eigentlich diese Ping Message?

2016.12.23 08:50:26.046 4: TSCUL_Parse: nanoCUL  055789 A FF52 00014888 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2016.12.23 08:50:36.837 4: TSCUL_Parse: nanoCUL  066583 A FF51 00025712 00 0F 80 8610 3547BB 000000 0AA0DB080040 -48
2016.12.23 08:50:39.276 4: TSCUL_Parse: nanoCUL  069022 A FF51 00028152 00 0F BE 8610 3549DB 000000 0A24C00A0040 -75.5
2016.12.23 08:50:50.035 4: TSCUL_Parse: nanoCUL  079781 A FF51 00038920 00 0F D3 8610 3547B5 000000 0A4CC10A0040 -86
2016.12.23 08:50:59.202 4: TSCUL_Parse: nanoCUL  088945 A FF52 00048088 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2016.12.23 08:51:20.891 4: TSCUL_Parse: nanoCUL  110637 A FF51 00069796 00 0F D6 8610 3547BA 000000 0A90C40A0040 -54
2016.12.23 08:51:29.746 4: TSCUL_Parse: nanoCUL  119489 A FF52 00078656 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138


Danke
Mario
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 23 Dezember 2016, 10:15:30
Hallo Mario,

Zitates läuft mit 0kHz Offset wunderbar,
Schön, dann merk Dir den Wert, denn mit der nächsten Firmware Update Version werden wieder automatisch die defaults gesetzt.

ZitatWelche Parameter muß der CC1101 Receiver bei Homematic eigentich haben, wie kann man diese verändern (Bandbreite,...)?
Außer dem Frequenz Offset sind die Werte für HM fest und bleiben es auch.
Optimieren geht nur mit Verändern und dann beobachten, wie sich die RSSI Werte aller Geräte ändern (HMInfo in der RSSI Statistik).
Oder Spektrum bei 868.3MHz sichtbar machen und die Frequenzmitte der Empfangspakete betrachten. Dann die Sendepakete mit dem Offset da hin schieben.

ZitatWas bedeuten eigentlich die Werte in den Botschaften am Ende, sind dies die Pegel?
Für Empfangsdaten ist es der Pegel (RSSI, wie auch in HMInfo in der RSSI Statistik schön zu sehen) und für sonstige ein dummy Pegel (-138) für das Protokoll von CUL zu FHEM.

ZitatWas ist eigentlich diese Ping Message?
Mit den langen Pings versuche ich die Übertragungszeit zu CUL zu bestimmen.
Die kurzen dienen der Aktualisierung der credits, auch wenn nichts empfangen wird.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: dog_martin am 28 Dezember 2016, 11:11:12
Hi Ansgar,

ich möchte mich bedanken!

Ich hatte mich eben endlich entschlossen Deine aktuelle Firmware zu flashen und Deine neuen TS-Module zu installieren...
Meine beiden Displays funktionieren auf Anhieb und werden sogar nach einem 'getconfig' als gepaired angezeigt.
8)

Nochmals DANKE!
:) :) :) :) :)
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: ms_steini am 30 Dezember 2016, 11:50:00
es tut mir leid, aber ich bin wohl zu blöd, was mache ich falsch ?

ich habe einen SCC (stapelbarer CC1101 Transceiver für Raspberry Pi)

noansi schrieb...
Zitat von: noansi am 27 November 2016, 18:19:57
........
Im Anhang ist in TSCUL_fwcode_00_05_01_FHEM_Modules_00_05_01.zip wieder die Timestamp Firmware zu finden. Getestet habe ich CUL_V3 und SCC.
Alle vorcompilierten .HEX Firmware Files haben 8 (+1) Sendepuffer konfiguriert.
..........

ich habe die TSCUL_fwcode_00_05_01_FHEM_Modules_00_05_01.zip heruntergeladen und die SCC.hex nach /opt/fhem/FHEM/firmware kopiert und die 98_CULflash.pm nach /opt/fhem/FHEM kopiert
in FHEM shutdown restart durchgeführt, danach CULflash SSC_CUL SCC eingegeben und erhalte dies MELDUNG: "Usage: CULflash [FHEM-Device|none] TYPE>, where TYPE is one of CUL_V2 CUL_V2_HM CUL_V3 CUL_V4"
OK, ich bin dann ins Verzeichnis /opt/cul_firmware/culfw/Devices/SCC gewechselt und habe "sudo make" eingegeben und erhalte diese Meldung:
Compiling C: ../../clib/stacking.c
sh: 1: avr-gcc: not found
makefile:410: recipe for target '../../clib/stacking.o' faild
make: *** [../../clib/stacking.o] Error 127


was mache ich falsch ?


Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: dog_martin am 30 Dezember 2016, 12:01:45
Hi Steini,

die SCC.hex Datei ist - soweit ich es richtig verstanden habe - bereits eine Firmwaredatei, die auf Deinen CC1101 geflasht werden muss.
Wenn der Versuch diese Datei aus fhem per culflash auf Deinen Transceiver zu bringen fehlschlägt, liegt es meist an fehlenden root-Rechten.
fhem.pl läuft NICHT als root!

Mein Vorschlag:
Beende fhem und starte den dfu-programmer manuell mit root-Rechten.
Dazu ist es evtl. notwendig, den CC1101 erst in den Programmiermodus zu bringen (Taster?!).

War bei meinem CUL jedenfalls notwendig UND erfolgreich.
Vielleicht hilfts...
;)
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: ms_steini am 30 Dezember 2016, 12:15:40
Hallo dog_Martin,

das ist das Ergebnis:

root@RasPi-3-FHEM:/opt/cul_firmware/culfw/Devices/SCC# make program
Compiling C: ../../clib/stacking.c
sh: 1: avr-gcc: not found
makefile:410: recipe for target '../../clib/stacking.o' failed
make: *** [../../clib/stacking.o] Error 127
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: dog_martin am 30 Dezember 2016, 12:30:12
Hi Steini,

ich bin jetzt nicht wirklich im Thema, mir scheint jedoch, Du hast Dich da ganz schön verlaufen.
Mit 'make program' wirst Du weniger eine vorbereitete Firmware auf Deinen Transceiver flashen!

Versuche bitte als root 'man dfu-programmer' auszuführen.
Wenn der 'dfu-programmer' bereits installiert ist, bekommst Du eine Anleitung erhalten wie dieser zu verwenden ist.
(falls nicht: 'apt install dfu-programmer')

Als kleine Hilfe hier meine Befehle, die ich verwendet habe um meinen CUL zu flashen:
root@fhem:~# dfu-programmer atmega32u4 erase
root@fhem:~# dfu-programmer atmega32u4 flash ./Firmware/tsculfw-code-459-trunk_lufa_00_05/CUL_V3.hex
root@fhem:~# dfu-programmer atmega32u4 start
(Du musst das natürlich an Deine Umgebung anpassen)
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: ms_steini am 30 Dezember 2016, 13:40:24
OK, verstehe ich nicht

dfu-programmer ist für microcontrollers mit USB  boot  loader
ich habe aber einen avr109-bootloader support using USART

das ist doch nicht das selbe?
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: dog_martin am 30 Dezember 2016, 14:05:45
Nein, definitiv nicht...

Wenn 'make program' tatsächlich richtig sein sollte (?!), dann kann lt. Fehlermeldung der Compiler nicht gefunden werden.
(noch nicht installiert oder nicht unter $PATH installiert?)
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: ms_steini am 30 Dezember 2016, 15:48:45
also unter http://culfw.de/culfw.html (http://culfw.de/culfw.html) steht u.a.
Step 1: flashing the firmware
rpiaddon: Install the package avrdude and then execute "make program".

wie soll ich das denn sonst verstehen ?
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: kaihs am 30 Dezember 2016, 16:17:39
RPi add-on ist nicht das gleiche wie SCC, du folgst der falschen Anleitung.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: ms_steini am 30 Dezember 2016, 18:46:01
ich glaube ich habs jetzt hinbekommen.... glaube ich zumindest.

im Beitrag https://forum.fhem.de/index.php/topic,38404.0.html (https://forum.fhem.de/index.php/topic,38404.0.html) habe ich eine Link gefunden unter dem eine uralte Version enthalten war, darin habe ich dann eine "flash.sh"
mit der ich dann die SCC.hex flashen konnte.

-------------------------------------------------------------
This program flash the cul device with new firmware.
Please change the device into the bootloader
-------------------------------------------------------------
Please insert the port for your device [default /dev/ttyAMA0]:

The device will now be flashed
KEEP THE MICRO BUTTON PRESSED AT DESIRED EXTENSION
Continue (y/n)?y

calling radio frontends bootloader ...

Call now avrdude -patmega1284p -cavr109 -P/dev/ttyAMA0 -b38400 -Uflash:w:./SCC.hex:i

Connecting to programmer: .
Found programmer: Id = "AVRBOOT"; type = S
    Software Version = 0.8; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=128 bytes.

Programmer supports the following devices:
    Device code: 0x46

avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e9705
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "./SCC.hex"
avrdude: writing flash (30324 bytes):

Writing | ################################################## | 100% 9.78s

avrdude: 30324 bytes of flash written
avrdude: verifying flash memory against ./SCC.hex:
avrdude: load data flash data from input file ./SCC.hex:
avrdude: input file ./SCC.hex contains 30324 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 8.44s

avrdude: verifying ...
avrdude: 30324 bytes of flash verified

avrdude done.  Thank you.



ich hoffe das es das jetzt war ???

könnt Ihr das bitte prüfen ob hier alles richtig ist?
Internals:
   CMDS       *ABCEFGJKMRTUVWXYZbefilmtx
   Clients    TSSTACKED:STACKABLE_CC:CUL_HM:HMS:CUL_IR
   DEF        /dev/ttyAMA0@38400 1267
   DeviceName /dev/ttyAMA0@38400
   FD         12
   FHTID      1267
   NAME       SCC
   NR         26
   PARTIAL
   RAWMSG     AFF1100037340000F6986104DDE460000000AA8E60F1B00F5
   RSSI       -79.5
   SCC_MSGCNT 31
   SCC_TIME   2016-12-30 18:40:19
   STATE      Initialized
   TYPE       TSCUL
   VERSION    VTS 0.05 SCC868
   VERSION_HW SCC_V1.2
   VERSION_TS yes
   XmitOpen   1
   initString X21
Ar
At1
   Matchlist:
     1:TSSTACKED ^\*
     A:CUL_HM   ^A....................
     B:HMS      ^810e04....(1|5|9).a001
     C:CUL_IR   ^I............
   Readings:
     2016-12-30 18:25:18   Xmit-Events     ok:1 disconnected:1 init:2
     2016-12-30 18:27:41   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 CCAmode:3 csRelThr:dis csAbsThr:0dB
     2016-12-30 18:25:15   cmds             * A B C E F G J K M R T U V W X Y Z b e f i l m t x
     2016-12-30 18:25:18   cond            ok
     2016-12-30 18:25:14   prot_disconnected last
     2016-12-30 18:25:15   prot_init       last
     2016-12-30 18:25:18   prot_ok         last
     2016-12-30 18:33:50   scF             1.0025355763884
     2016-12-30 18:25:15   state           Initialized
     2016-12-30 18:19:07   version         VTS 0.05 SCC868
   Helper:
     Devio:
       NDisCon    0
       NRFail     0
       RXfailTS
     Hm:
       FUP        0
       hmCrdts    1
       hmSbusy    0
       Unknwn:
         3ba87a:
           lRcTm      788608
           lstRecType 10
           nextSend   1483119503.61287
           nxtSndMcnt 4A
           tgtDly     120
         3bab23:
           lRcTm      860504
           lstRecType 10
           nextSend   1483119575.69078
           nxtSndMcnt 26
           tgtDly     120
         4dde36:
           lRcTm      844560
           lstRecType 10
           nextSend   1483119559.70693
           nxtSndMcnt 63
           tgtDly     120
         4dde46:
           lRcTm      904448
           lstRecType 10
           nextSend   1483119619.74723
           nxtSndMcnt 69
           tgtDly     120
         4de1be:
           lRcTm      882928
           lstRecType 10
           nextSend   1483119598.17207
           nxtSndMcnt 99
           tgtDly     120
         4de5f0:
           lRcTm      871376
           lstRecType 10
           nextSend   1483119586.59061
           nxtSndMcnt 71
           tgtDly     120
         Ff0712:
           lRcTm      751016
           lstRecType 12
           nextSend   1483119465.92466
           nxtSndMcnt 02
           tgtDly     120
     Cnd:
       0          1
       253        1
       255        2
     Hmq:
     Hmqo:
     Q:
       HMcndN     0
       InQueues   0
       answerPend 0
       hmLanQlen  1
       Cap:
         sum        20250
     Ref:
       Sdly       2
       doNbyterate 71
       hmDstDly   120
       ioByteRate 3840
       ioByteRateMeas 3714.06515345996
       lHMt       871376
       lSys       282127527
       pTTu       1024
       pndAs      0
       pndCUAp    0
       pngFrc     1
       pngLm      12
       pngMax     -300000
       pngMin     4
       pngRef     5
       pngtm      281771675
       pngtmBRs   1483119644.11805
       scErr      0
       scF        1.0025355763884
       scFN       0
       scHT       5696
       scST       281259653
Attributes:
   hmId       FF1267
   hmLanQlen  1_min
   model      CUL
   rfmode     HomeMatic
   room       System
   verbose    5



In der LOG taucht ab und an folgende Meldung auf:
2016.12.30 18:42:07 3: SCC: Unknown code A0F6486104DDE360000000AA8E90F1B00::-82:SCC, help me

Ich wäre froh wenns das jetzt gewesen ist.... und VIELEN DANK FÜR EUERE GEDULD
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 02 Januar 2017, 09:18:44
Hallo ms_steini,

Zitatkönnt Ihr das bitte prüfen ob hier alles richtig ist?
das sieht gut aus.
Eine VCCU benutzt Du wohl nicht. Über die Vorteile kann Dir das Homematic Forum Infos geben.

ZitatIn der LOG taucht ab und an folgende Meldung auf:
2016.12.30 18:42:07 3: SCC: Unknown code A0F6486104DDE360000000AA8E90F1B00::-82:SCC, help me
Du hast das device 4DDE36 noch nicht definiert bzw. mit aktivem autocreate gepaired !?

Zitatdfu-programmer ist für microcontrollers mit USB  boot  loader
ich habe aber einen avr109-bootloader support using USART
avrdude ist der programmer für SCC, der auch installiert sein muss.

Wenn das SCC HEX File im SCC Device Verzeichnis liegt, kann mit
sudo make do_program
SCC geflashed werden (sofern man das Knöpfchen drückt).

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 03 Januar 2017, 10:33:47
Hallo Testwillige,

10_CUL_HM.pm muss nicht mehr ausgetauscht werden ab Stand # $Id: 10_CUL_HM.pm 12943 2017-01-03 08:35:18Z martinp876 $

Martin hat dankenswerterweise die notwendigen Änderungen übernommen.
Bitte daran denken, ggf. attr global exclude_from_update entsprechend anzupassen, um 10_CUL_HM.pm wieder im automatischen Update zuzulassen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 03 Januar 2017, 11:21:19
@Martin, Ansgar: Super!!

Hmm, dann muss ich wohl mal alles auf den neuesten Stand bringen... ;)

Danke, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bastel-Frank am 03 Januar 2017, 12:07:06
Vielen herzlichen Dank an euch Beide !!!

@Ansgar: Seit der Version 0.03 läuft alles wie am Schnürchen. Ich habe 3x CUL, die über drei Etagen mit ser2net verbunden "am Laufen".

Vielen Dank nochmals
Frank
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: theophilou85 am 03 Januar 2017, 22:36:23
Hallo

Erstmal: tolle FW. HM-Geräte tun endlich was sie sollen.
Habe aber nun(!) ein Problem mit IT, dass ich unter der 1.67iger nicht hatte. CUL V3 mit FW aus Thread geflashed. Alle *.pm-Files in fhem/FHEM kopiert.

#----------Schnittstellengeräte--------------------------------------------#
define wz0_cul00 TSCUL com2@9600 0000
attr wz0_cul00 hmId 000001
attr wz0_cul00 rfmode HomeMatic

define wz0_del00_sch00 TSIT 00100000100001100110010110 0 0000
attr wz0_del00_sch00 IODev wz0_cul00
attr wz0_del00_sch00 alias Licht
attr wz0_del00_sch00 group [AC] Deckenleuchte
attr wz0_del00_sch00 room Geräte,Deckenleuchte

define wz0_sch00 TSIT 0000000000 FF F0
attr wz0_sch00 IODev wz0_cul00
attr wz0_sch00 alias LED Beleuchtung
attr wz0_sch00 devStateIcon on:lamp.on off:lamp.off
attr wz0_sch00 group [Intertechno] Schalter
attr wz0_sch00 model itswitch
attr wz0_sch00 room Geräte,Schalter


FHEM meint dazu:
2017.01.03 22:34:26 2: IT set wz0_sch00 on
2017.01.03 22:34:31 2: IT IODev device didn't answer is command correctly:   raw => NOCCA


Bei der Deckenleuchte meckert FHEM wegen dem Format. Dieses war notwendig um bei der 1.67iger FW ein AC-Telegramm in ein IT umzuwandeln. Kann ich das jetzt direkt als AC senden?
Bei dem Schalter meine ich alles richtig konfiguriert zu haben. Klappte unter der 1.67iger auch, jetzt nicht mehr.
Vielleicht kann mir ja jemand weiterhelfen. Danke.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 04 Januar 2017, 01:18:04
Hallo theophilou85,

Zitat2017.01.03 22:34:31 2: IT IODev device didn't answer is command correctly:   raw => NOCCA
Da ist wohl die CCA Einstellung für IT zu empfindlich ausgefallen. Ich habe das hier:
https://forum.fhem.de/index.php/topic,24436.msg529649.html#msg529649 (https://forum.fhem.de/index.php/topic,24436.msg529649.html#msg529649)
in der TSCUL_fwcode_00_05_02_FHEM_Modules_00_05_02.zip geändert. Hilft das bei wz0_sch00? Oder bleibt es bei NOCCA?

ZitatBei der Deckenleuchte meckert FHEM wegen dem Format.
Da hat sich einiges getan beim IT Modul. Da muss ich erst mal durch blicken, was, warum und wieso.

Zitatein AC-Telegramm in ein IT umzuwandeln
??? Kannst Du mal beschreiben, was Du senden möchtest?

Sendest Du mit einem zweiten CUL auf 433.9MHz? Dann kannst Du alterantiv auf dem CUL eine andere Firmware flashen und damit das IT Modul verwenden.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 04 Januar 2017, 04:11:34
Zitat von: noansi am 04 Januar 2017, 01:18:04
Sendest Du mit einem zweiten CUL auf 433.9MHz? Dann kannst Du alterantiv auf dem CUL eine andere Firmware flashen und damit das IT Modul verwenden.

Hallo Ansgar,

soweit ich in einem anderen Thread mitbekommen habe wird ein CUL für beides genutzt...

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

Ich habe dort den Hinweis auf diese FW und Module gegeben, da die Probleme (Missing ACK bzw. Timeout RegisterRead) evtl. mit Timing zu tun haben...

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bytechanger am 04 Januar 2017, 09:08:20
Hallo,

verfolge dieses Thema seit einiger Zeit sehr interessiert und habe auch schon einige Firmware-Versionen mitgemacht.
Bei mir bleibt leider das Problem, dass meine AES-Signierten Fensterkontakte nicht richtig mit dem CUL kommunizieren können!

Der CUL scheint die Signierung nicht zu aktzeptieren, denn in FHEM steht immer in den Readings "aesCommToDev pending" und der Statuswechsel wird nicht akzeptiert!
Der CUL ist mit einem HMLAN in einer vccu zusammengefasst. Kommuniziert der HMLAN mit den Fensterkontakten, geht es!
Es scheint also ein CUL Problem mit den HM-SEC-SC-2 zu sein!


Greets

Byte
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 04 Januar 2017, 10:50:09
Hallo Byte,

ZitatDer CUL scheint die Signierung nicht zu aktzeptieren, denn in FHEM steht immer in den Readings "aesCommToDev pending" und der Statuswechsel wird nicht akzeptiert!
Die Firmware adressiert nur AES Kommunikation zu devices, also Signierung von Kommandos an devices nach device Signierungsanforderung.
Die andere AES Richtung, also signiert zu FHEM geht weiterhin über CUL_HM und das kann ich mangels Speicher in CUL auch nicht ändern.

ZitatDer CUL ist mit einem HMLAN in einer vccu zusammengefasst. Kommuniziert der HMLAN mit den Fensterkontakten, geht es!
Es scheint also ein CUL Problem mit den HM-SEC-SC-2 zu sein!
Wenn Du die Aussage mal mit log der messages sowohl bei HMLAN Kommunikation als auch bei CUL Kommunikation ergänzen könntest...
Bei CUL bitte verbose 4.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: theophilou85 am 04 Januar 2017, 10:58:00
Wie Joachim bereits korrekt erwähnt hat nutzte ich bisher meinen CUL für Homematic und IT (im SlowRF). IT klappte mit der 1.67iger absolut einwandfrei (hatte nie einen Paketverlust), aber Probleme mit HM (Missing Timeout/ACK).
Bei deiner FW laufen alle meine HM-Devices einwandfrei, bis auf den HM-Sen-MDIR-WM55, aber da muss ich erst eingrenzen welche Probleme seine interne Firmware verursacht.

Den wz0_sch00 teste ich heute.

Bzgl.: wz0_del00_sch00 / AC Protokoll https://forum.fhem.de/index.php/topic,62538.0.html, zusammengefasst:
Habe eine Deckenleuchte die über 433Mhz mit AC-Telegrammen gesteuert wird. Die Fernbedienung habe ich mit einem RFXTRX und dem mitgelieferten Windowstool eingelesen z.B:

Packettype    = Lighting2
subtype       = AC
Sequence nbr  = 2
ID            = 0821996 decimal:8526230
Unit          = 1


Konvertiert mit: IT 00011011000100100100001010 0 1001 lies sich dieser Befehl auch erfolgreich absetzen und die Deckenleuchte schalten.



Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bytechanger am 04 Januar 2017, 12:18:56
Hier das Log,

mir viel auf, dass es manchmal auf OK -> dann auf pending -> dann auf fail ging....
Wird der Status mehrfach abgefragt??

Greets

Byte

1. Auf
2017.01.04 12:12:29.553 4: TSCUL_Parse: CUL0  403312 A FF01 11536140 00 0C C0 8470 2617F9 000000 00DA2A -84.5
2017.01.04 12:12:40.697 4: TSCUL_Parse: CUL0  414456 A FF01 11547292 00 0C 64 A641 278291 1DA462 0124C8 -46.5
2017.01.04 12:12:40.715 4: TSCUL_send:  CUL0                         As 0D 64 8002 1DA462 278291 0101C800
2017.01.04 12:12:41.381 4: TSCUL_send:  CUL0                         As 11 64 A002 1DA462 278291 0443B656770AD702
2017.01.04 12:12:41.385 4: TSCUL_Parse: CUL0  415144 A FF13 11547428 02 0D 64 8002 1DA462 278291 01 _CCAdly:8 _dhmSt:136 -138
2017.01.04 12:12:41.386 4: TSCUL_Parse: CUL0  415146 A FF11 11547676 00 0E 64 8002 1DA462 278291 00691A4923 -51
2017.01.04 12:12:41.649 4: TSCUL_Parse: CUL0  415408 A FF13 11548092 02 11 64 A002 1DA462 278291 04 _CCAdly:8 _dhmSt:800 -138
2017.01.04 12:12:41.909 4: TSCUL_Parse: CUL0  415668 A FF13 11548344 01 11 64 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:1052 -138
2017.01.04 12:12:42.169 4: TSCUL_Parse: CUL0  415929 A FF13 11548596 01 11 64 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:1304 -138
2017.01.04 12:12:42.171 1: TSCUL_ParseTsHM CUL0 HM repeat failed sending to 278291/EG_FensterBuero: AFF10002C0E2B001164A0021DA46227829104
2017.01.04 12:12:42.171 4: TSCUL_Parse: CUL0  415930 A FF10 11548844 00 11 64 A002 1DA462 278291 04 _sfail -138
2017.01.04 12:12:44.477 4: TSCUL_send:  CUL0                         As 11 64 A002 1DA462 278291 0443B656770AD702
2017.01.04 12:12:44.738 4: TSCUL_Parse: CUL0  418497 A FF13 11551184 01 11 64 A002 1DA462 278291 04 _CCAdly:4 -138
2017.01.04 12:12:44.996 4: TSCUL_Parse: CUL0  418756 A FF13 11551436 01 11 64 A002 1DA462 278291 04 _CCAdly:4 -138
2017.01.04 12:12:45.257 4: TSCUL_Parse: CUL0  419016 A FF13 11551688 01 11 64 A002 1DA462 278291 04 _CCAdly:4 -138
2017.01.04 12:12:45.258 1: TSCUL_ParseTsHM CUL0 HM repeat failed sending to 278291/EG_FensterBuero: AFF10002C1130001164A0021DA46227829104
2017.01.04 12:12:45.259 4: TSCUL_Parse: CUL0  419018 A FF10 11551936 00 11 64 A002 1DA462 278291 04 _sfail -138
2017.01.04 12:12:47.133 4: TSCUL_Parse: CUL0  420892 A FF11 11553604 00 0C 64 8670 20DACE 000000 00385C -95

1. Zu
2017.01.04 12:13:46.084 4: TSCUL_Parse: CUL0  479843 A FF01 11612548 00 0C 65 A641 278291 1DA462 012500 -47.5
2017.01.04 12:13:46.097 4: TSCUL_send:  CUL0                         As 11 65 A002 1DA462 278291 0443B656770AD702
2017.01.04 12:13:46.483 4: TSCUL_Parse: CUL0  480242 A FF13 11612808 01 11 65 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:260 -138
2017.01.04 12:13:46.485 4: TSCUL_Parse: CUL0  480244 A FF13 11613060 01 11 65 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:512 -138
2017.01.04 12:13:46.743 4: TSCUL_Parse: CUL0  480502 A FF13 11613312 01 11 65 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:764 -138
2017.01.04 12:13:47.012 4: TSCUL_send:  CUL0                         As 11 65 A002 1DA462 278291 0443B656770AD702
2017.01.04 12:13:47.012 4: TSCUL_Parse: CUL0  480760 A FF11 11613468 00 0C 65 A241 278291 1DA462 012500 -47
2017.01.04 12:13:47.361 4: TSCUL_Parse: CUL0  481120 A FF13 11613724 01 11 65 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:1176 -138
2017.01.04 12:13:47.363 4: TSCUL_Parse: CUL0  481122 A FF13 11613976 01 11 65 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:1428 -138
2017.01.04 12:13:47.621 4: TSCUL_Parse: CUL0  481380 A FF13 11614228 01 11 65 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:1680 -138
2017.01.04 12:13:47.927 1: TSCUL_ParseTsHM CUL0 HM repeat failed sending to 278291/EG_FensterBuero: AFF10002C4E43001165A0021DA46227829104
2017.01.04 12:13:47.928 4: TSCUL_Parse: CUL0  481685 A FF10 11614476 00 11 65 A002 1DA462 278291 04 _sfail -138
2017.01.04 12:13:47.943 4: TSCUL_send:  CUL0                         As 11 65 A002 1DA462 278291 0443B656770AD702
2017.01.04 12:13:47.943 4: TSCUL_Parse: CUL0  481689 A FF11 11614488 00 0C 65 A241 278291 1DA462 012500 -48
2017.01.04 12:13:48.305 4: TSCUL_Parse: CUL0  482065 A FF13 11614656 02 11 65 A002 1DA462 278291 04 _CCAdly:8 _dhmSt:2108 -138
2017.01.04 12:13:48.307 4: TSCUL_Parse: CUL0  482066 A FF13 11614904 01 11 65 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:2356 -138
2017.01.04 12:13:48.570 4: TSCUL_Parse: CUL0  482329 A FF13 11615156 01 11 65 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:2608 -138
2017.01.04 12:13:48.837 1: TSCUL_ParseTsHM CUL0 HM repeat failed sending to 278291/EG_FensterBuero: AFF10002C4F2B001165A0021DA46227829104
2017.01.04 12:13:48.838 4: TSCUL_Parse: CUL0  482597 A FF10 11615404 00 11 65 A002 1DA462 278291 04 _sfail -138
2017.01.04 12:13:49.919 4: TSCUL_send:  CUL0                         As 11 65 A002 1DA462 278291 0443B656770AD702
2017.01.04 12:13:49.920 4: TSCUL_Parse: CUL0  483667 A FF11 11616524 00 0C 65 A241 278291 1DA462 012500 -47.5
2017.01.04 12:13:50.227 4: TSCUL_Parse: CUL0  483986 A FF13 11616644 01 11 65 A002 1DA462 278291 04 _CCAdly:4 -138
2017.01.04 12:13:50.240 4: TSCUL_send:  CUL0                         As 11 65 A002 1DA462 278291 0443B656770AD702
2017.01.04 12:13:50.240 4: TSCUL_Parse: CUL0  483988 A FF11 11616804 00 19 65 A203 278291 1DA462 124B13598AB1CE5031C1E751D6D11F70 -47.5
2017.01.04 12:13:50.656 4: TSCUL_Parse: CUL0  484415 A FF13 11616952 01 11 65 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:148 -138
2017.01.04 12:13:50.658 4: TSCUL_Parse: CUL0  484417 A FF13 11617204 01 11 65 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:400 -138
2017.01.04 12:13:50.916 4: TSCUL_Parse: CUL0  484675 A FF13 11617456 01 11 65 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:652 -138
2017.01.04 12:13:51.172 1: TSCUL_ParseTsHM CUL0 HM repeat failed sending to 278291/EG_FensterBuero: AFF10002C516A001165A0021DA46227829104
2017.01.04 12:13:51.173 4: TSCUL_Parse: CUL0  484932 A FF10 11617704 00 11 65 A002 1DA462 278291 04 _sfail -138
2017.01.04 12:13:53.265 4: TSCUL_send:  CUL0                         As 11 65 A002 1DA462 278291 0443B656770AD702
2017.01.04 12:13:53.531 4: TSCUL_Parse: CUL0  487291 A FF13 11619976 01 11 65 A002 1DA462 278291 04 _CCAdly:4 -138
2017.01.04 12:13:53.789 4: TSCUL_Parse: CUL0  487548 A FF13 11620228 01 11 65 A002 1DA462 278291 04 _CCAdly:4 -138
2017.01.04 12:13:54.049 4: TSCUL_Parse: CUL0  487809 A FF13 11620480 01 11 65 A002 1DA462 278291 04 _CCAdly:4 -138
2017.01.04 12:13:54.051 1: TSCUL_ParseTsHM CUL0 HM repeat failed sending to 278291/EG_FensterBuero: AFF10002C545E001165A0021DA46227829104
2017.01.04 12:13:54.051 4: TSCUL_Parse: CUL0  487810 A FF10 11620728 00 11 65 A002 1DA462 278291 04 _sfail -138
2017.01.04 12:13:54.359 4: TSCUL_send:  CUL0                         As 11 65 A002 1DA462 278291 0443B656770AD702
2017.01.04 12:13:54.360 4: TSCUL_Parse: CUL0  488107 A FF11 11620868 00 0C 65 A241 278291 1DA462 012500 -47.5
2017.01.04 12:13:54.660 4: TSCUL_Parse: CUL0  488419 A FF13 11621072 02 11 65 A002 1DA462 278291 04 _CCAdly:8 _dhmSt:204 -138
2017.01.04 12:13:54.661 4: TSCUL_Parse: CUL0  488421 A FF13 11621324 01 11 65 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:456 -138
2017.01.04 12:13:54.919 4: TSCUL_Parse: CUL0  488678 A FF13 11621576 01 11 65 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:708 -138
2017.01.04 12:13:55.180 1: TSCUL_ParseTsHM CUL0 HM repeat failed sending to 278291/EG_FensterBuero: AFF10002C5570001165A0021DA46227829104
2017.01.04 12:13:55.180 4: TSCUL_Parse: CUL0  488939 A FF10 11621824 00 11 65 A002 1DA462 278291 04 _sfail -138

2. Auf
2017.01.04 12:13:57.367 4: TSCUL_send:  CUL0                         As 11 65 A002 1DA462 278291 0443B656770AD702
2017.01.04 12:13:57.710 4: TSCUL_Parse: CUL0  491469 A FF13 11624080 01 11 65 A002 1DA462 278291 04 _CCAdly:4 -138
2017.01.04 12:13:57.712 4: TSCUL_Parse: CUL0  491471 A FF13 11624332 01 11 65 A002 1DA462 278291 04 _CCAdly:4 -138
2017.01.04 12:13:57.988 4: TSCUL_Parse: CUL0  491747 A FF13 11624584 01 11 65 A002 1DA462 278291 04 _CCAdly:4 -138
2017.01.04 12:13:58.274 1: TSCUL_ParseTsHM CUL0 HM repeat failed sending to 278291/EG_FensterBuero: AFF10002C5860001165A0021DA46227829104
2017.01.04 12:13:58.274 4: TSCUL_Parse: CUL0  492033 A FF10 11624832 00 11 65 A002 1DA462 278291 04 _sfail -138
2017.01.04 12:13:59.068 4: TSCUL_Parse: CUL0  492827 A FF11 11625556 00 11 8A A002 17E2BB 1C5801 047F51A4AA998D02 -86
2017.01.04 12:13:59.330 4: TSCUL_Parse: CUL0  493089 A FF11 11625812 00 0E 8A 8002 17E2BB 1C5801 004D0CEE19 -85.5
2017.01.04 12:14:00.524 4: TSCUL_send:  CUL0                         As 11 65 A002 1DA462 278291 0443B656770AD702
2017.01.04 12:14:00.554 4: TSCUL_Parse: CUL0  494314 A FF13 11627236 01 11 65 A002 1DA462 278291 04 _CCAdly:4 -138
2017.01.04 12:14:00.809 4: TSCUL_Parse: CUL0  494568 A FF13 11627488 01 11 65 A002 1DA462 278291 04 _CCAdly:4 -138
2017.01.04 12:14:01.069 4: TSCUL_Parse: CUL0  494829 A FF13 11627740 01 11 65 A002 1DA462 278291 04 _CCAdly:4 -138
2017.01.04 12:14:01.331 1: TSCUL_ParseTsHM CUL0 HM repeat failed sending to 278291/EG_FensterBuero: AFF10002C5B75001165A0021DA46227829104
2017.01.04 12:14:01.331 4: TSCUL_Parse: CUL0  495090 A FF10 11627988 00 11 65 A002 1DA462 278291 04 _sfail -138
2017.01.04 12:14:03.565 4: TSCUL_send:  CUL0                         As 11 65 8002 1DA462 278291 0101C8005324f47b
2017.01.04 12:14:03.837 4: TSCUL_send:  CUL0                         As 11 65 A002 1DA462 278291 04D2CB26916CD402
2017.01.04 12:14:03.840 4: TSCUL_Parse: CUL0  497599 A FF13 11630276 01 11 65 8002 1DA462 278291 01 _CCAdly:4 -138
2017.01.04 12:14:04.102 4: TSCUL_Parse: CUL0  497862 A FF13 11630548 01 11 65 A002 1DA462 278291 04 _CCAdly:4 -138
2017.01.04 12:14:04.361 4: TSCUL_Parse: CUL0  498120 A FF13 11630800 01 11 65 A002 1DA462 278291 04 _CCAdly:4 -138
2017.01.04 12:14:04.622 4: TSCUL_Parse: CUL0  498381 A FF13 11631052 01 11 65 A002 1DA462 278291 04 _CCAdly:4 -138
2017.01.04 12:14:04.623 1: TSCUL_ParseTsHM CUL0 HM repeat failed sending to 278291/EG_FensterBuero: AFF10002C5EB1001165A0021DA46227829104
2017.01.04 12:14:04.623 4: TSCUL_Parse: CUL0  498382 A FF10 11631300 00 11 65 A002 1DA462 278291 04 _sfail -138
2017.01.04 12:14:07.076 4: TSCUL_send:  CUL0                         As 11 65 A002 1DA462 278291 04D2CB26916CD402
2017.01.04 12:14:07.105 4: TSCUL_Parse: CUL0  500864 A FF13 11633788 01 11 65 A002 1DA462 278291 04 _CCAdly:4 -138
2017.01.04 12:14:07.359 4: TSCUL_Parse: CUL0  501118 A FF13 11634040 01 11 65 A002 1DA462 278291 04 _CCAdly:4 -138
2017.01.04 12:14:07.618 4: TSCUL_Parse: CUL0  501377 A FF13 11634292 01 11 65 A002 1DA462 278291 04 _CCAdly:4 -138
2017.01.04 12:14:07.876 1: TSCUL_ParseTsHM CUL0 HM repeat failed sending to 278291/EG_FensterBuero: AFF10002C61DB001165A0021DA46227829104
2017.01.04 12:14:07.876 4: TSCUL_Parse: CUL0  501635 A FF10 11634540 00 11 65 A002 1DA462 278291 04 _sfail -138
2017.01.04 12:14:23.593 4: TSCUL_Parse: CUL0  517352 A FF11 11650304 00 0C 66 A641 278291 1DA462 0126C8 -46
2017.01.04 12:14:23.607 4: TSCUL_send:  CUL0                         As 11 66 A002 1DA462 278291 04D2CB26916CD402
2017.01.04 12:14:23.607 3: TSCUL_XmitDlyHM:  CUL0  id:278291 dDly:112 toms:84
2017.01.04 12:14:23.909 4: TSCUL_Parse: CUL0  517668 A FF13 11650424 01 11 66 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:120 -138
2017.01.04 12:14:23.911 4: TSCUL_Parse: CUL0  517670 A FF11 11650584 00 19 66 A203 278291 1DA462 8150419F19627C366C8B73422608A0BB -45.5
2017.01.04 12:14:23.928 4: TSCUL_send:  CUL0                         As 11 66 8002 1DA462 278291 0101C8001f130f2f
2017.01.04 12:14:23.929 3: TSCUL_XmitDlyHM:  CUL0  id:278291 dDly:73 toms:84
2017.01.04 12:14:24.322 4: TSCUL_send:  CUL0                         As 11 66 A002 1DA462 278291 04AE9B9E6A71C002
2017.01.04 12:14:24.326 4: TSCUL_Parse: CUL0  518085 A FF13 11650704 01 11 66 8002 1DA462 278291 01 _CCAdly:4 _dhmSt:120 -138
2017.01.04 12:14:24.329 4: TSCUL_Parse: CUL0  518087 A FF11 11650828 00 0C 66 A241 278291 1DA462 0126C8 -47.5
2017.01.04 12:14:24.342 4: TSCUL_send:  CUL0                         As 11 66 A002 1DA462 278291 04AE9B9E6A71C002
2017.01.04 12:14:24.655 4: TSCUL_Parse: CUL0  518414 A FF13 11651036 02 11 66 A002 1DA462 278291 04 _CCAdly:8 _dhmSt:208 -138
2017.01.04 12:14:24.657 4: TSCUL_Parse: CUL0  518416 A FF13 11651132 01 11 66 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:304 -138
2017.01.04 12:14:24.659 4: TSCUL_Parse: CUL0  518418 A FF11 11651340 00 0C 66 A241 278291 1DA462 0126C8 -46
2017.01.04 12:14:24.672 4: TSCUL_send:  CUL0                         As 11 66 A002 1DA462 278291 04AE9B9E6A71C002
2017.01.04 12:14:25.031 4: TSCUL_Parse: CUL0  518790 A FF13 11651460 01 11 66 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:632 -138
2017.01.04 12:14:25.044 4: TSCUL_send:  CUL0                         As 11 66 A002 1DA462 278291 04AE9B9E6A71C002
2017.01.04 12:14:25.045 4: TSCUL_Parse: CUL0  518792 A FF11 11651620 00 19 66 A203 278291 1DA462 B1CEA71E7661219C7270A4B51F100A10 -46.5
2017.01.04 12:14:25.365 4: TSCUL_Parse: CUL0  519124 A FF13 11651756 01 11 66 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:136 -138
2017.01.04 12:14:25.367 4: TSCUL_Parse: CUL0  519126 A FF13 11652008 01 11 66 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:388 -138
2017.01.04 12:14:25.626 4: TSCUL_Parse: CUL0  519385 A FF13 11652260 01 11 66 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:640 -138
2017.01.04 12:14:25.885 1: TSCUL_ParseTsHM CUL0 HM repeat failed sending to 278291/EG_FensterBuero: AFF10002C7367001166A0021DA46227829104
2017.01.04 12:14:25.885 4: TSCUL_Parse: CUL0  519644 A FF10 11652508 00 11 66 A002 1DA462 278291 04 _sfail -138
2017.01.04 12:14:26.154 4: TSCUL_send:  CUL0                         As 11 66 8002 1DA462 278291 0101C80093ad6d0d
2017.01.04 12:14:26.154 4: TSCUL_Parse: CUL0  519901 A FF11 11652628 00 0C 66 A241 278291 1DA462 0126C8 -46
2017.01.04 12:14:26.526 4: TSCUL_send:  CUL0                         As 11 66 A002 1DA462 278291 04CC4E12729E3002
2017.01.04 12:14:26.531 4: TSCUL_Parse: CUL0  520290 A FF13 11652868 02 11 66 8002 1DA462 278291 01 _CCAdly:8 _dhmSt:240 -138
2017.01.04 12:14:26.839 4: TSCUL_Parse: CUL0  520598 A FF13 11653240 01 11 66 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:612 -138
2017.01.04 12:14:26.841 4: TSCUL_Parse: CUL0  520600 A FF13 11653492 01 11 66 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:864 -138
2017.01.04 12:14:27.107 4: TSCUL_Parse: CUL0  520866 A FF13 11653744 01 11 66 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:1116 -138
2017.01.04 12:14:27.366 1: TSCUL_ParseTsHM CUL0 HM repeat failed sending to 278291/EG_FensterBuero: AFF10002C74DA001166A0021DA46227829104
2017.01.04 12:14:27.367 4: TSCUL_Parse: CUL0  521125 A FF10 11653992 00 11 66 A002 1DA462 278291 04 _sfail -138
2017.01.04 12:14:27.963 4: TSCUL_send:  CUL0                         As 11 66 A002 1DA462 278291 04CC4E12729E3002
2017.01.04 12:14:27.963 4: TSCUL_Parse: CUL0  521711 A FF11 11654664 00 0C 66 A241 278291 1DA462 0126C8 -46
2017.01.04 12:14:28.280 4: TSCUL_Parse: CUL0  522039 A FF13 11654784 01 11 66 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:2156 -138
2017.01.04 12:14:28.293 4: TSCUL_send:  CUL0                         As 11 66 A002 1DA462 278291 04CC4E12729E3002
2017.01.04 12:14:28.293 3: TSCUL_XmitDlyHM:  CUL0  id:278291 dDly:67 toms:84
2017.01.04 12:14:28.294 4: TSCUL_Parse: CUL0  522041 A FF11 11654944 00 19 66 A203 278291 1DA462 800F8360770A495608DD248C394C138C -46
2017.01.04 12:14:28.661 4: TSCUL_Parse: CUL0  522420 A FF13 11655064 01 11 66 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:120 -138
2017.01.04 12:14:28.663 4: TSCUL_Parse: CUL0  522422 A FF13 11655316 01 11 66 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:372 -138
2017.01.04 12:14:28.926 4: TSCUL_Parse: CUL0  522685 A FF13 11655568 01 11 66 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:624 -138
2017.01.04 12:14:29.188 1: TSCUL_ParseTsHM CUL0 HM repeat failed sending to 278291/EG_FensterBuero: AFF10002C76A2001166A0021DA46227829104
2017.01.04 12:14:29.189 4: TSCUL_Parse: CUL0  522947 A FF10 11655816 00 11 66 A002 1DA462 278291 04 _sfail -138
2017.01.04 12:14:31.532 4: TSCUL_send:  CUL0                         As 11 66 8002 1DA462 278291 0101C800ed6f68a6
2017.01.04 12:14:31.562 4: TSCUL_Parse: CUL0  001033 A FF13 11658244 01 11 66 8002 1DA462 278291 01 _CCAdly:4 -138
2017.01.04 12:14:31.826 4: TSCUL_send:  CUL0                         As 11 66 A002 1DA462 278291 045D00C5DFE0BC02
2017.01.04 12:14:32.092 4: TSCUL_Parse: CUL0  001563 A FF13 11658540 01 11 66 A002 1DA462 278291 04 _CCAdly:4 -138
2017.01.04 12:14:32.352 4: TSCUL_Parse: CUL0  001823 A FF13 11658792 01 11 66 A002 1DA462 278291 04 _CCAdly:4 -138
2017.01.04 12:14:32.355 4: TSCUL_Parse: CUL0  001825 A FF11 11659008 00 0C 66 A241 278291 1DA462 0126C8 -46.5
2017.01.04 12:14:32.367 4: TSCUL_send:  CUL0                         As 11 66 A002 1DA462 278291 045D00C5DFE0BC02
2017.01.04 12:14:32.368 3: TSCUL_XmitDlyHM:  CUL0  id:278291 dDly:57 toms:84
2017.01.04 12:14:32.722 4: TSCUL_Parse: CUL0  002193 A FF13 11659128 01 11 66 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:120 -138
2017.01.04 12:14:32.735 4: TSCUL_send:  CUL0                         As 11 66 A002 1DA462 278291 045D00C5DFE0BC02
2017.01.04 12:14:32.736 4: TSCUL_Parse: CUL0  002195 A FF11 11659292 00 19 66 A203 278291 1DA462 F4F3A0D67A6CA79C7A406E65DA4EB4F7 -46.5
2017.01.04 12:14:33.060 4: TSCUL_Parse: CUL0  002531 A FF13 11659448 01 11 66 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:156 -138
2017.01.04 12:14:33.062 4: TSCUL_Parse: CUL0  002533 A FF13 11659700 01 11 66 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:408 -138
2017.01.04 12:14:33.321 4: TSCUL_Parse: CUL0  002792 A FF13 11659952 01 11 66 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:660 -138
2017.01.04 12:14:33.580 1: TSCUL_ParseTsHM CUL0 HM repeat failed sending to 278291/EG_FensterBuero: AFF10002C7AEA001166A0021DA46227829104
2017.01.04 12:14:33.580 4: TSCUL_Parse: CUL0  003051 A FF10 11660200 00 11 66 A002 1DA462 278291 04 _sfail -138
2017.01.04 12:14:34.493 4: TSCUL_Parse: CUL0  003963 A FF11 11661204 00 0F 7A 865E 3BD2E7 000000 ED43ED00EA60 -85.5
2017.01.04 12:14:35.749 4: TSCUL_send:  CUL0                         As 11 66 8002 1DA462 278291 0101C8009ea0faf4
2017.01.04 12:14:36.359 4: TSCUL_Parse: CUL0  005830 A FF13 11662464 02 11 66 8002 1DA462 278291 01 _CCAdly:8 -138

2. Zu
2017.01.04 12:15:00.931 4: TSCUL_Parse: CUL0  030402 A FF11 11687644 00 0C C1 865A 2617F9 000000 88DA2A -84.5
2017.01.04 12:15:11.899 4: TSCUL_Parse: CUL0  041370 A FF11 11698616 00 0C 65 8670 20DACE 000000 00385C -96
2017.01.04 12:15:20.932 4: TSCUL_Parse: CUL0  050402 A FF11 11707648 00 0C C1 8470 2617F9 000000 00DA2A -84.5
2017.01.04 12:15:39.850 4: TSCUL_Parse: CUL0  069320 A FF11 11726564 00 0C 67 A641 278291 1DA462 012700 -47
2017.01.04 12:15:39.865 4: TSCUL_send:  CUL0                         As 11 67 A002 1DA462 278291 04E7F1F7C2674802
2017.01.04 12:15:39.865 3: TSCUL_XmitDlyHM:  CUL0  id:278291 dDly:110 toms:84
2017.01.04 12:15:40.199 4: TSCUL_Parse: CUL0  069668 A FF13 11726684 01 11 67 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:120 -138
2017.01.04 12:15:40.203 4: TSCUL_Parse: CUL0  069672 A FF11 11726844 00 19 67 A203 278291 1DA462 2304EE120333EA6A9828B112D943B1F5 -47
2017.01.04 12:15:40.228 4: TSCUL_send:  CUL0                         As 11 67 8002 1DA462 278291 0101C800b093e2f5
2017.01.04 12:15:40.228 3: TSCUL_XmitDlyHM:  CUL0  id:278291 dDly:28 toms:84
2017.01.04 12:15:40.652 4: TSCUL_send:  CUL0                         As 11 67 A002 1DA462 278291 04639C7C15453302
2017.01.04 12:15:40.657 4: TSCUL_Parse: CUL0  070127 A FF13 11726964 01 11 67 8002 1DA462 278291 01 _CCAdly:4 _dhmSt:120 -138
2017.01.04 12:15:40.659 4: TSCUL_Parse: CUL0  070130 A FF11 11727088 00 0C 67 A241 278291 1DA462 012700 -46.5
2017.01.04 12:15:40.672 4: TSCUL_send:  CUL0                         As 11 67 A002 1DA462 278291 04639C7C15453302
2017.01.04 12:15:41.088 4: TSCUL_Parse: CUL0  070559 A FF13 11727368 01 11 67 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:280 -138
2017.01.04 12:15:41.089 4: TSCUL_Parse: CUL0  070560 A FF13 11727464 01 11 67 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:376 -138
2017.01.04 12:15:41.102 4: TSCUL_send:  CUL0                         As 11 67 A002 1DA462 278291 04639C7C15453302
2017.01.04 12:15:41.102 4: TSCUL_Parse: CUL0  070562 A FF11 11727600 00 0C 67 A241 278291 1DA462 012700 -47
2017.01.04 12:15:41.438 4: TSCUL_Parse: CUL0  070909 A FF13 11727820 02 11 67 A002 1DA462 278291 04 _CCAdly:8 _dhmSt:732 -138
2017.01.04 12:15:41.440 4: TSCUL_Parse: CUL0  070911 A FF13 11728068 01 11 67 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:980 -138
2017.01.04 12:15:41.774 4: TSCUL_Parse: CUL0  071245 A FF13 11728320 01 11 67 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:1232 -138
2017.01.04 12:15:42.081 1: TSCUL_ParseTsHM CUL0 HM repeat failed sending to 278291/EG_FensterBuero: AFF10002CBDAE001167A0021DA46227829104
2017.01.04 12:15:42.082 4: TSCUL_Parse: CUL0  071552 A FF10 11728568 00 11 67 A002 1DA462 278291 04 _sfail -138
2017.01.04 12:15:42.094 4: TSCUL_send:  CUL0                         As 11 67 A002 1DA462 278291 04639C7C15453302
2017.01.04 12:15:42.095 4: TSCUL_Parse: CUL0  071554 A FF11 11728616 00 0C 67 A241 278291 1DA462 012700 -47
2017.01.04 12:15:42.411 4: TSCUL_Parse: CUL0  071882 A FF13 11728812 02 11 67 A002 1DA462 278291 04 _CCAdly:8 _dhmSt:1724 -138
2017.01.04 12:15:42.412 4: TSCUL_Parse: CUL0  071884 A FF13 11729060 01 11 67 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:1972 -138
2017.01.04 12:15:42.726 4: TSCUL_Parse: CUL0  072197 A FF13 11729312 01 11 67 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:2224 -138
2017.01.04 12:15:42.985 1: TSCUL_ParseTsHM CUL0 HM repeat failed sending to 278291/EG_FensterBuero: AFF10002CBEA6001167A0021DA46227829104
2017.01.04 12:15:42.985 4: TSCUL_Parse: CUL0  072456 A FF10 11729560 00 11 67 A002 1DA462 278291 04 _sfail -138
2017.01.04 12:15:44.070 4: TSCUL_send:  CUL0                         As 11 67 A002 1DA462 278291 04639C7C15453302
2017.01.04 12:15:44.071 4: TSCUL_Parse: CUL0  073530 A FF11 11730656 00 0C 67 A241 278291 1DA462 012700 -47.5
2017.01.04 12:15:44.379 4: TSCUL_Parse: CUL0  073850 A FF13 11730788 02 11 67 A002 1DA462 278291 04 _CCAdly:8 -138
2017.01.04 12:15:44.392 4: TSCUL_send:  CUL0                         As 11 67 A002 1DA462 278291 04639C7C15453302
2017.01.04 12:15:44.393 4: TSCUL_Parse: CUL0  073852 A FF11 11730948 00 19 67 A203 278291 1DA462 104BE342533CAC42BEE9220463E5A9DF -47.5
2017.01.04 12:15:44.714 4: TSCUL_Parse: CUL0  074185 A FF13 11731108 01 11 67 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:160 -138
2017.01.04 12:15:44.715 4: TSCUL_Parse: CUL0  074187 A FF13 11731360 01 11 67 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:412 -138
2017.01.04 12:15:44.975 4: TSCUL_Parse: CUL0  074446 A FF13 11731612 01 11 67 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:664 -138
2017.01.04 12:15:45.233 1: TSCUL_ParseTsHM CUL0 HM repeat failed sending to 278291/EG_FensterBuero: AFF10002CC0E5001167A0021DA46227829104
2017.01.04 12:15:45.233 4: TSCUL_Parse: CUL0  074704 A FF10 11731860 00 11 67 A002 1DA462 278291 04 _sfail -138
2017.01.04 12:15:47.555 4: TSCUL_send:  CUL0                         As 11 67 A002 1DA462 278291 04639C7C15453302
2017.01.04 12:15:47.826 4: TSCUL_Parse: CUL0  077297 A FF13 11734272 01 11 67 A002 1DA462 278291 04 _CCAdly:4 -138
2017.01.04 12:15:48.087 4: TSCUL_Parse: CUL0  077558 A FF13 11734524 01 11 67 A002 1DA462 278291 04 _CCAdly:4 -138
2017.01.04 12:15:48.395 4: TSCUL_Parse: CUL0  077867 A FF13 11734776 01 11 67 A002 1DA462 278291 04 _CCAdly:4 -138
2017.01.04 12:15:48.408 4: TSCUL_send:  CUL0                         As 11 67 A002 1DA462 278291 04639C7C15453302
2017.01.04 12:15:48.409 3: TSCUL_XmitDlyHM:  CUL0  id:278291 dDly:15 toms:84
2017.01.04 12:15:48.409 4: TSCUL_Parse: CUL0  077868 A FF11 11735012 00 0C 67 A241 278291 1DA462 012700 -47.5
2017.01.04 12:15:48.717 4: TSCUL_Parse: CUL0  078189 A FF13 11735132 01 11 67 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:120 -138
2017.01.04 12:15:48.730 4: TSCUL_send:  CUL0                         As 11 67 A002 1DA462 278291 04639C7C15453302
2017.01.04 12:15:48.731 4: TSCUL_Parse: CUL0  078190 A FF11 11735292 00 19 67 A203 278291 1DA462 9875C286AB24C3E2FAB1543DF2C1937E -47.5
2017.01.04 12:15:49.050 4: TSCUL_Parse: CUL0  078522 A FF13 11735448 02 11 67 A002 1DA462 278291 04 _CCAdly:8 _dhmSt:156 -138
2017.01.04 12:15:49.052 4: TSCUL_Parse: CUL0  078523 A FF13 11735696 01 11 67 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:404 -138
2017.01.04 12:15:49.317 4: TSCUL_Parse: CUL0  078788 A FF13 11735948 01 11 67 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:656 -138
2017.01.04 12:15:49.572 1: TSCUL_ParseTsHM CUL0 HM repeat failed sending to 278291/EG_FensterBuero: AFF10002CC521001167A0021DA46227829104
2017.01.04 12:15:49.572 4: TSCUL_Parse: CUL0  079043 A FF10 11736196 00 11 67 A002 1DA462 278291 04 _sfail -138
2017.01.04 12:15:51.861 4: TSCUL_send:  CUL0                         As 11 67 8002 1DA462 278291 0101C80071030387
2017.01.04 12:15:51.891 4: TSCUL_Parse: CUL0  081362 A FF13 11738576 01 11 67 8002 1DA462 278291 01 _CCAdly:4 -138
2017.01.04 12:15:52.156 4: TSCUL_send:  CUL0                         As 11 67 A002 1DA462 278291 04E878A7A41F8602
2017.01.04 12:15:52.424 4: TSCUL_Parse: CUL0  081895 A FF13 11738872 01 11 67 A002 1DA462 278291 04 _CCAdly:4 -138
2017.01.04 12:15:52.683 4: TSCUL_Parse: CUL0  082155 A FF13 11739124 01 11 67 A002 1DA462 278291 04 _CCAdly:4 -138
2017.01.04 12:15:52.942 4: TSCUL_Parse: CUL0  082413 A FF13 11739376 01 11 67 A002 1DA462 278291 04 _CCAdly:4 -138
2017.01.04 12:15:52.944 1: TSCUL_ParseTsHM CUL0 HM repeat failed sending to 278291/EG_FensterBuero: AFF10002CC87A001167A0021DA46227829104
2017.01.04 12:15:52.944 4: TSCUL_Parse: CUL0  082415 A FF10 11739624 00 11 67 A002 1DA462 278291 04 _sfail -138
2017.01.04 12:15:55.375 4: TSCUL_send:  CUL0                         As 11 67 A002 1DA462 278291 04E878A7A41F8602
2017.01.04 12:15:55.406 4: TSCUL_Parse: CUL0  084877 A FF13 11742092 01 11 67 A002 1DA462 278291 04 _CCAdly:4 -138
2017.01.04 12:15:55.665 4: TSCUL_Parse: CUL0  085136 A FF13 11742344 01 11 67 A002 1DA462 278291 04 _CCAdly:4 -138
2017.01.04 12:15:55.928 4: TSCUL_Parse: CUL0  085399 A FF13 11742596 01 11 67 A002 1DA462 278291 04 _CCAdly:4 -138
2017.01.04 12:15:56.190 1: TSCUL_ParseTsHM CUL0 HM repeat failed sending to 278291/EG_FensterBuero: AFF10002CCB9F001167A0021DA46227829104
2017.01.04 12:15:56.191 4: TSCUL_Parse: CUL0  085661 A FF10 11742844 00 11 67 A002 1DA462 278291 04 _sfail -138


Auffalend sind auc die "failed sending to" was immer das bedeuten soll ..

Greets

Byte
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 04 Januar 2017, 13:06:43
Hallo Byte,

der Fensterkontakt antwortet nicht mit Signing response auf die von CUL gesendeten Signing requests (das sind die fails, da keine Antwort kommt).

CUL sendet das, was von CUL_HM kommt.

Wenn Du jetzt auch noch das gewünschte Vergleichslog mit HMLAN posten würdest, dann könnte ich vergleichen, was schief geht (wenn möglich mit CUL auf verbose 4 mitgelauscht, da dann das Timing direkt klar wird).
Ansonsten musst Du im Homematic Forum weiter fragen.

Sind keys und Einstellungen korrekt?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bytechanger am 04 Januar 2017, 13:13:43
Hallo

danke für die Hilfe, ich kann mit den Logs nichts anfangen:
auf
2017.01.04 13:10:15.857 4: TSCUL_Parse: CUL0  199600 A FF01 15002696 00 0C 6A A641 278291 1DA462 012AC8 -46
2017.01.04 13:10:15.871 4: TSCUL_send:  CUL0                         As 11 6A A002 1DA462 278291 04E5E1D057955002
2017.01.04 13:10:15.872 3: TSCUL_XmitDlyHM:  CUL0  id:278291 dDly:115 toms:84
2017.01.04 13:10:16.407 4: TSCUL_Parse: CUL0  200150 A FF13 15002816 01 11 6A A002 1DA462 278291 04 _CCAdly:4 _dhmSt:120 -138
2017.01.04 13:10:16.409 4: TSCUL_Parse: CUL0  200152 A FF11 15002976 00 19 6A A203 278291 1DA462 B61C66D681A89657ABE84F4D98EE3495 -46
2017.01.04 13:10:16.416 0: HMLAN_Send:  HMLAN1 I:+278291,00,00,
2017.01.04 13:10:16.417 0: HMLAN_Send:  HMLAN1 S:+278291,03,01,02
2017.01.04 13:10:16.417 0: HMLAN_Send:  HMLAN1 S:S69630F3A stat:  00 t:00000000 d:01 r:69630F3A m:6A 8002 1DA462 278291 0101C800e03a6925
2017.01.04 13:10:16.492 4: TSCUL_Parse: CUL0  200235 A FF11 15003224 00 0C 6A A241 278291 1DA462 012AC8 -46
2017.01.04 13:10:16.497 0: HMLAN_Parse: HMLAN1 R:E278291   stat:0000 t:00DD270D d:FF r:FFC2     m:6A A641 278291 1DA462 012AC8
2017.01.04 13:10:16.501 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:00DD27A4 d:FF r:FFCC     m:6A A002 1DA462 278291 04E5E1D057955002
2017.01.04 13:10:16.507 0: HMLAN_Parse: HMLAN1 R:E278291   stat:0000 t:00DD291D d:FF r:FFC0     m:6A A241 278291 1DA462 012AC8
2017.01.04 13:10:16.511 0: HMLAN_Parse: HMLAN1 R:R69630F3A stat:0002 t:00000000 d:FF r:7FFF     m:6A 8002 1DA462 278291 0101C800E03A6925
2017.01.04 13:10:16.769 4: TSCUL_Parse: CUL0  200512 A FF11 15003288 00 11 6A 8002 1DA462 278291 0101C800E03A6925 -50.5
2017.01.04 13:10:18.306 0: HMLAN_Send:  HMLAN1 I:K
2017.01.04 13:10:18.310 0: HMLAN_Parse: HMLAN1 V:03C5 sNo:LEQ0640815 d:2CD8CE O:1DA462 t:00DD30A4 IDcnt:001D L:1 %
2017.01.04 13:10:22.261 4: TSCUL_Parse: CUL0  206004 A FF01 15009036 00 0C D7 865A 2617F9 000000 88DA2A -85
2017.01.04 13:10:22.304 0: HMLAN_Parse: HMLAN1 R:E2617F9   stat:0000 t:00DD3FD4 d:FF r:FFA4     m:D7 865A 2617F9 000000 88DA2A
2017.01.04 13:10:28.984 4: TSCUL_Parse: CUL0  212726 A FF01 15015820 00 0C 7B 8670 20DACE 000000 003B59 -93.5
2017.01.04 13:10:29.242 0: HMLAN_Parse: HMLAN1 R:E20DACE   stat:0000 t:00DD5A55 d:FF r:FFA0     m:7B 8670 20DACE 000000 003B59
2017.01.04 13:10:33.570 0: HMLAN_Send:  HMLAN1 I:K
2017.01.04 13:10:33.574 0: HMLAN_Parse: HMLAN1 V:03C5 sNo:LEQ0640815 d:2CD8CE O:1DA462 t:00DD6C47 IDcnt:001D L:1 %


zu
2017.01.04 13:10:42.459 0: HMLAN_Parse: HMLAN1 R:E2617F9   stat:0000 t:00DD8DF8 d:FF r:FFA5     m:D7 8470 2617F9 000000 00DA2A
2017.01.04 13:10:42.464 4: TSCUL_Parse: CUL0  226207 A FF01 15029036 00 0C D7 8470 2617F9 000000 00DA2A -84.5
2017.01.04 13:10:48.805 0: HMLAN_Send:  HMLAN1 I:K
2017.01.04 13:10:48.810 0: HMLAN_Parse: HMLAN1 V:03C5 sNo:LEQ0640815 d:2CD8CE O:1DA462 t:00DDA7CC IDcnt:001D L:1 %
2017.01.04 13:10:54.117 0: HMLAN_Parse: HMLAN1 R:E17E2BB   stat:0000 t:00DDBC30 d:FF r:FFAE     m:95 A002 17E2BB 1C5801 04052F3571655902
2017.01.04 13:10:54.122 4: TSCUL_Parse: CUL0  237865 A FF01 15040868 00 11 95 A002 17E2BB 1C5801 04052F3571655902 -85.5
2017.01.04 13:10:54.377 0: HMLAN_Parse: HMLAN1 R:E17E2BB   stat:0000 t:00DDBD32 d:FF r:FFAE     m:95 8002 17E2BB 1C5801 001BE985BA
2017.01.04 13:10:54.382 4: TSCUL_Parse: CUL0  238125 A FF01 15041128 00 0E 95 8002 17E2BB 1C5801 001BE985BA -87
2017.01.04 13:11:03.987 0: HMLAN_Send:  HMLAN1 I:K
2017.01.04 13:11:03.993 0: HMLAN_Parse: HMLAN1 V:03C5 sNo:LEQ0640815 d:2CD8CE O:1DA462 t:00DDE31C IDcnt:001D L:1 %
2017.01.04 13:11:05.613 4: TSCUL_Parse: CUL0  249356 A FF01 15052452 00 0C 6B A641 278291 1DA462 012B00 -47.5
2017.01.04 13:11:05.719 0: HMLAN_Send:  HMLAN1 S:S6963CF6A stat:  00 t:00000000 d:01 r:6963CF6A m:6C A004 1DA462 278291 f4e3594f0f9ab3f18b18d2cc569a17f4
2017.01.04 13:11:05.720 0: HMLAN_Send:  HMLAN1 I:K
2017.01.04 13:11:05.724 0: HMLAN_Delay: HMLAN1 278291
2017.01.04 13:11:06.044 0: HMLAN_Parse: HMLAN1 R:E278291   stat:0100 t:00DDE96F d:FF r:FFCC     m:6B A641 278291 1DA462 012B00
2017.01.04 13:11:06.091 0: HMLAN_Parse: HMLAN1 V:03C5 sNo:LEQ0640815 d:2CD8CE O:1DA462 t:00DDE9F2 IDcnt:001D L:1 %
2017.01.04 13:11:06.092 0: HMLAN_Parse: HMLAN1 R:E278291   stat:00C0 t:00DDE96F d:01 r:FFCC     m:6B A641 278291 1DA462 012B00
2017.01.04 13:11:06.147 4: TSCUL_Parse: CUL0  249890 A FF01 15052580 00 11 6B A102 1DA462 278291 04DE48EEA0C1FC02 -51
2017.01.04 13:11:06.154 4: TSCUL_Parse: CUL0  249897 A FF01 15052712 00 19 6B A203 278291 1DA462 90AF610DE0DED958D0D28D8FCA9AA899 -47.5
2017.01.04 13:11:06.206 4: TSCUL_Parse: CUL0  249949 A FF01 15052832 00 0E 6B 8002 1DA462 278291 008A7B4108 -51.5
2017.01.04 13:11:06.469 4: TSCUL_Parse: CUL0  250212 A FF01 15053120 00 19 6C A004 1DA462 278291 EC1889852AD5BC06332A894AE6844A0C -51.5
2017.01.04 13:11:06.736 4: TSCUL_Parse: CUL0  250479 A FF01 15053316 00 19 6C A004 1DA462 278291 EC1889852AD5BC06332A894AE6844A0C -51.5
2017.01.04 13:11:06.742 4: TSCUL_Parse: CUL0  250485 A FF01 15053516 00 19 6C A004 1DA462 278291 EC1889852AD5BC06332A894AE6844A0C -51.5
2017.01.04 13:11:06.999 0: HMLAN_Parse: HMLAN1 R:R6963CF6A stat:0008 t:00000000 d:FF r:7FFF     m:6C A004 1DA462 278291 EC1889852AD5BC06332A894AE6844A0C
2017.01.04 13:11:06.999 0: HMLAN_Parse: HMLAN1 no ACK from 278291
2017.01.04 13:11:10.801 4: TSCUL_Parse: CUL0  254544 A FF01 15057640 00 0C 6C A641 278291 1DA462 012C00 -47.5
2017.01.04 13:11:10.906 0: HMLAN_Send:  HMLAN1 S:S6963E3AD stat:  00 t:00000000 d:01 r:6963E3AD m:6D A004 1DA462 278291 f4e3594f0f9ab3f18b18d2cc569a17f4
2017.01.04 13:11:10.919 0: HMLAN_Delay: HMLAN1 278291
2017.01.04 13:11:11.237 0: HMLAN_Parse: HMLAN1 R:E278291   stat:0100 t:00DDFDB5 d:FF r:FFCC     m:6C A641 278291 1DA462 012C00
2017.01.04 13:11:11.287 0: HMLAN_Parse: HMLAN1 R:E278291   stat:00C0 t:00DDFDB5 d:01 r:FFCC     m:6C A641 278291 1DA462 012C00
2017.01.04 13:11:11.344 4: TSCUL_Parse: CUL0  255087 A FF01 15057768 00 11 6C A102 1DA462 278291 04C254F2BCDDE002 -52
2017.01.04 13:11:11.351 4: TSCUL_Parse: CUL0  255094 A FF01 15057900 00 19 6C A203 278291 1DA462 1FB1F3D65299C5F072574DF5EAEA4DD5 -47.5
2017.01.04 13:11:11.403 4: TSCUL_Parse: CUL0  255146 A FF01 15058020 00 0E 6C 8002 1DA462 278291 00ADBFF0BA -52.5
2017.01.04 13:11:11.666 4: TSCUL_Parse: CUL0  255409 A FF01 15058308 00 19 6D A004 1DA462 278291 EC1889852AD5BC06332A894AE6844A0C -51.5
2017.01.04 13:11:11.926 4: TSCUL_Parse: CUL0  255669 A FF01 15058504 00 19 6D A004 1DA462 278291 EC1889852AD5BC06332A894AE6844A0C -52
2017.01.04 13:11:11.932 4: TSCUL_Parse: CUL0  255675 A FF01 15058704 00 19 6D A004 1DA462 278291 EC1889852AD5BC06332A894AE6844A0C -52
2017.01.04 13:11:12.191 0: HMLAN_Parse: HMLAN1 R:R6963E3AD stat:0008 t:00000000 d:FF r:7FFF     m:6D A004 1DA462 278291 EC1889852AD5BC06332A894AE6844A0C
2017.01.04 13:11:12.192 0: HMLAN_Parse: HMLAN1 no ACK from 278291



Greets

Byte
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 04 Januar 2017, 14:48:28
Hallo Byte,

ich habe die Logs jetzt mal etwas verglichen.

hier geht was seltsam schief:
1. Auf
2017.01.04 12:12:40.697 4: TSCUL_Parse: CUL0  414456 A FF01 11547292 00 0C 64 A641 278291 1DA462 0124C8 -46.5
2017.01.04 12:12:40.715 4: TSCUL_send:  CUL0                         As 0D 64 8002 1DA462 278291 0101C800
2017.01.04 12:12:41.381 4: TSCUL_send:  CUL0                         As 11 64 A002 1DA462 278291 0443B656770AD702

es wird von CUL_HM die Antwort geschickt, die ohne AES geschickt würde und dann kommt der Signing Request von CUL_HM.

Es klappt auch schon mal mit CUL, wenn nichts stört:
2. Auf (hier erst)
2017.01.04 12:14:23.593 4: TSCUL_Parse: CUL0  517352 A FF11 11650304 00 0C 66 A641 278291 1DA462 0126C8 -46
2017.01.04 12:14:23.607 4: TSCUL_send:  CUL0                         As 11 66 A002 1DA462 278291 04D2CB26916CD402
2017.01.04 12:14:23.607 3: TSCUL_XmitDlyHM:  CUL0  id:278291 dDly:112 toms:84
2017.01.04 12:14:23.909 4: TSCUL_Parse: CUL0  517668 A FF13 11650424 01 11 66 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:120 -138
2017.01.04 12:14:23.911 4: TSCUL_Parse: CUL0  517670 A FF11 11650584 00 19 66 A203 278291 1DA462 8150419F19627C366C8B73422608A0BB -45.5
2017.01.04 12:14:23.928 4: TSCUL_send:  CUL0                         As 11 66 8002 1DA462 278291 0101C8001f130f2f

sieht erst mal sauber durchgelaufen aus.

Aber dann:
2017.01.04 12:14:24.322 4: TSCUL_send:  CUL0                         As 11 66 A002 1DA462 278291 04AE9B9E6A71C002
2017.01.04 12:14:24.326 4: TSCUL_Parse: CUL0  518085 A FF13 11650704 01 11 66 8002 1DA462 278291 01 _CCAdly:4 _dhmSt:120 -138
2017.01.04 12:14:24.329 4: TSCUL_Parse: CUL0  518087 A FF11 11650828 00 0C 66 A241 278291 1DA462 0126C8 -47.5
2017.01.04 12:14:24.342 4: TSCUL_send:  CUL0                         As 11 66 A002 1DA462 278291 04AE9B9E6A71C002
2017.01.04 12:14:24.655 4: TSCUL_Parse: CUL0  518414 A FF13 11651036 02 11 66 A002 1DA462 278291 04 _CCAdly:8 _dhmSt:208 -138
2017.01.04 12:14:24.657 4: TSCUL_Parse: CUL0  518416 A FF13 11651132 01 11 66 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:304 -138
2017.01.04 12:14:24.659 4: TSCUL_Parse: CUL0  518418 A FF11 11651340 00 0C 66 A241 278291 1DA462 0126C8 -46
2017.01.04 12:14:24.672 4: TSCUL_send:  CUL0                         As 11 66 A002 1DA462 278291 04AE9B9E6A71C002
2017.01.04 12:14:25.031 4: TSCUL_Parse: CUL0  518790 A FF13 11651460 01 11 66 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:632 -138
2017.01.04 12:14:25.044 4: TSCUL_send:  CUL0                         As 11 66 A002 1DA462 278291 04AE9B9E6A71C002
2017.01.04 12:14:25.045 4: TSCUL_Parse: CUL0  518792 A FF11 11651620 00 19 66 A203 278291 1DA462 B1CEA71E7661219C7270A4B51F100A10 -46.5
2017.01.04 12:14:25.365 4: TSCUL_Parse: CUL0  519124 A FF13 11651756 01 11 66 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:136 -138
2017.01.04 12:14:25.367 4: TSCUL_Parse: CUL0  519126 A FF13 11652008 01 11 66 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:388 -138
2017.01.04 12:14:25.626 4: TSCUL_Parse: CUL0  519385 A FF13 11652260 01 11 66 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:640 -138
2017.01.04 12:14:25.885 1: TSCUL_ParseTsHM CUL0 HM repeat failed sending to 278291/EG_FensterBuero: AFF10002C7367001166A0021DA46227829104
2017.01.04 12:14:25.885 4: TSCUL_Parse: CUL0  519644 A FF10 11652508 00 11 66 A002 1DA462 278291 04 _sfail -138
2017.01.04 12:14:26.154 4: TSCUL_send:  CUL0                         As 11 66 8002 1DA462 278291 0101C80093ad6d0d
2017.01.04 12:14:26.154 4: TSCUL_Parse: CUL0  519901 A FF11 11652628 00 0C 66 A241 278291 1DA462 0126C8 -46
2017.01.04 12:14:26.526 4: TSCUL_send:  CUL0                         As 11 66 A002 1DA462 278291 04CC4E12729E3002
2017.01.04 12:14:26.531 4: TSCUL_Parse: CUL0  520290 A FF13 11652868 02 11 66 8002 1DA462 278291 01 _CCAdly:8 _dhmSt:240 -138
2017.01.04 12:14:26.839 4: TSCUL_Parse: CUL0  520598 A FF13 11653240 01 11 66 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:612 -138
2017.01.04 12:14:26.841 4: TSCUL_Parse: CUL0  520600 A FF13 11653492 01 11 66 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:864 -138
2017.01.04 12:14:27.107 4: TSCUL_Parse: CUL0  520866 A FF13 11653744 01 11 66 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:1116 -138
2017.01.04 12:14:27.366 1: TSCUL_ParseTsHM CUL0 HM repeat failed sending to 278291/EG_FensterBuero: AFF10002C74DA001166A0021DA46227829104
2017.01.04 12:14:27.367 4: TSCUL_Parse: CUL0  521125 A FF10 11653992 00 11 66 A002 1DA462 278291 04 _sfail -138
2017.01.04 12:14:27.963 4: TSCUL_send:  CUL0                         As 11 66 A002 1DA462 278291 04CC4E12729E3002
2017.01.04 12:14:27.963 4: TSCUL_Parse: CUL0  521711 A FF11 11654664 00 0C 66 A241 278291 1DA462 0126C8 -46
2017.01.04 12:14:28.280 4: TSCUL_Parse: CUL0  522039 A FF13 11654784 01 11 66 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:2156 -138
2017.01.04 12:14:28.293 4: TSCUL_send:  CUL0                         As 11 66 A002 1DA462 278291 04CC4E12729E3002
2017.01.04 12:14:28.293 3: TSCUL_XmitDlyHM:  CUL0  id:278291 dDly:67 toms:84
2017.01.04 12:14:28.294 4: TSCUL_Parse: CUL0  522041 A FF11 11654944 00 19 66 A203 278291 1DA462 800F8360770A495608DD248C394C138C -46
2017.01.04 12:14:28.661 4: TSCUL_Parse: CUL0  522420 A FF13 11655064 01 11 66 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:120 -138
2017.01.04 12:14:28.663 4: TSCUL_Parse: CUL0  522422 A FF13 11655316 01 11 66 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:372 -138
2017.01.04 12:14:28.926 4: TSCUL_Parse: CUL0  522685 A FF13 11655568 01 11 66 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:624 -138
2017.01.04 12:14:29.188 1: TSCUL_ParseTsHM CUL0 HM repeat failed sending to 278291/EG_FensterBuero: AFF10002C76A2001166A0021DA46227829104
2017.01.04 12:14:29.189 4: TSCUL_Parse: CUL0  522947 A FF10 11655816 00 11 66 A002 1DA462 278291 04 _sfail -138
2017.01.04 12:14:31.532 4: TSCUL_send:  CUL0                         As 11 66 8002 1DA462 278291 0101C800ed6f68a6
2017.01.04 12:14:31.562 4: TSCUL_Parse: CUL0  001033 A FF13 11658244 01 11 66 8002 1DA462 278291 01 _CCAdly:4 -138
2017.01.04 12:14:31.826 4: TSCUL_send:  CUL0                         As 11 66 A002 1DA462 278291 045D00C5DFE0BC02
2017.01.04 12:14:32.092 4: TSCUL_Parse: CUL0  001563 A FF13 11658540 01 11 66 A002 1DA462 278291 04 _CCAdly:4 -138
2017.01.04 12:14:32.352 4: TSCUL_Parse: CUL0  001823 A FF13 11658792 01 11 66 A002 1DA462 278291 04 _CCAdly:4 -138
2017.01.04 12:14:32.355 4: TSCUL_Parse: CUL0  001825 A FF11 11659008 00 0C 66 A241 278291 1DA462 0126C8 -46.5
2017.01.04 12:14:32.367 4: TSCUL_send:  CUL0                         As 11 66 A002 1DA462 278291 045D00C5DFE0BC02
2017.01.04 12:14:32.368 3: TSCUL_XmitDlyHM:  CUL0  id:278291 dDly:57 toms:84
2017.01.04 12:14:32.722 4: TSCUL_Parse: CUL0  002193 A FF13 11659128 01 11 66 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:120 -138
2017.01.04 12:14:32.735 4: TSCUL_send:  CUL0                         As 11 66 A002 1DA462 278291 045D00C5DFE0BC02
2017.01.04 12:14:32.736 4: TSCUL_Parse: CUL0  002195 A FF11 11659292 00 19 66 A203 278291 1DA462 F4F3A0D67A6CA79C7A406E65DA4EB4F7 -46.5
2017.01.04 12:14:33.060 4: TSCUL_Parse: CUL0  002531 A FF13 11659448 01 11 66 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:156 -138
2017.01.04 12:14:33.062 4: TSCUL_Parse: CUL0  002533 A FF13 11659700 01 11 66 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:408 -138
2017.01.04 12:14:33.321 4: TSCUL_Parse: CUL0  002792 A FF13 11659952 01 11 66 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:660 -138
2017.01.04 12:14:33.580 1: TSCUL_ParseTsHM CUL0 HM repeat failed sending to 278291/EG_FensterBuero: AFF10002C7AEA001166A0021DA46227829104
2017.01.04 12:14:33.580 4: TSCUL_Parse: CUL0  003051 A FF10 11660200 00 11 66 A002 1DA462 278291 04 _sfail -138
2017.01.04 12:14:34.493 4: TSCUL_Parse: CUL0  003963 A FF11 11661204 00 0F 7A 865E 3BD2E7 000000 ED43ED00EA60 -85.5
2017.01.04 12:14:35.749 4: TSCUL_send:  CUL0                         As 11 66 8002 1DA462 278291 0101C8009ea0faf4
2017.01.04 12:14:36.359 4: TSCUL_Parse: CUL0  005830 A FF13 11662464 02 11 66 8002 1DA462 278291 01 _CCAdly:8 -138

kommt noch ein signing request hinter her, den ich nicht verstehe. Macht der überhaupt Sinn?

Witzigerweise kommt so was auch bei HMLAN scheinbar grundlos hinterher
Ups, falsch geguckt, von HMLAN kommt was anderers mit message type 04 hinterher:
zu
2017.01.04 13:11:05.613 4: TSCUL_Parse: CUL0  249356 A FF01 15052452 00 0C 6B A641 278291 1DA462 012B00 -47.5
2017.01.04 13:11:05.719 0: HMLAN_Send:  HMLAN1 S:S6963CF6A stat:  00 t:00000000 d:01 r:6963CF6A m:6C A004 1DA462 278291 f4e3594f0f9ab3f18b18d2cc569a17f4
2017.01.04 13:11:05.720 0: HMLAN_Send:  HMLAN1 I:K
2017.01.04 13:11:05.724 0: HMLAN_Delay: HMLAN1 278291
2017.01.04 13:11:06.044 0: HMLAN_Parse: HMLAN1 R:E278291   stat:0100 t:00DDE96F d:FF r:FFCC     m:6B A641 278291 1DA462 012B00
2017.01.04 13:11:06.091 0: HMLAN_Parse: HMLAN1 V:03C5 sNo:LEQ0640815 d:2CD8CE O:1DA462 t:00DDE9F2 IDcnt:001D L:1 %
2017.01.04 13:11:06.092 0: HMLAN_Parse: HMLAN1 R:E278291   stat:00C0 t:00DDE96F d:01 r:FFCC     m:6B A641 278291 1DA462 012B00
2017.01.04 13:11:06.147 4: TSCUL_Parse: CUL0  249890 A FF01 15052580 00 11 6B A102 1DA462 278291 04DE48EEA0C1FC02 -51
2017.01.04 13:11:06.154 4: TSCUL_Parse: CUL0  249897 A FF01 15052712 00 19 6B A203 278291 1DA462 90AF610DE0DED958D0D28D8FCA9AA899 -47.5
2017.01.04 13:11:06.206 4: TSCUL_Parse: CUL0  249949 A FF01 15052832 00 0E 6B 8002 1DA462 278291 008A7B4108 -51.5
2017.01.04 13:11:06.469 4: TSCUL_Parse: CUL0  250212 A FF01 15053120 00 19 6C A004 1DA462 278291 EC1889852AD5BC06332A894AE6844A0C -51.5
2017.01.04 13:11:06.736 4: TSCUL_Parse: CUL0  250479 A FF01 15053316 00 19 6C A004 1DA462 278291 EC1889852AD5BC06332A894AE6844A0C -51.5
2017.01.04 13:11:06.742 4: TSCUL_Parse: CUL0  250485 A FF01 15053516 00 19 6C A004 1DA462 278291 EC1889852AD5BC06332A894AE6844A0C -51.5
2017.01.04 13:11:06.999 0: HMLAN_Parse: HMLAN1 R:R6963CF6A stat:0008 t:00000000 d:FF r:7FFF     m:6C A004 1DA462 278291 EC1889852AD5BC06332A894AE6844A0C
2017.01.04 13:11:06.999 0: HMLAN_Parse: HMLAN1 no ACK from 278291

allerdings mit message nummer 6C, also 1 mehr, als bei CUL_HM und scheitert dennoch.
Ich denke, da ist noch was in CUL_HM nicht sauber, aber dazu können andere Protokollspezis wohl mehr sagen.

Außerdem scheinen beide (CUL und HMLAN) mal 1 device zu bedienen. Das gibt auch Merkwürdigkeiten.
1. Auf
2017.01.04 12:12:40.697 4: TSCUL_Parse: CUL0  414456 A FF01 11547292 00 0C 64 A641 278291 1DA462 0124C8 -46.5
2017.01.04 12:12:40.715 4: TSCUL_send:  CUL0                         As 0D 64 8002 1DA462 278291 0101C800
2017.01.04 12:12:41.381 4: TSCUL_send:  CUL0                         As 11 64 A002 1DA462 278291 0443B656770AD702
2017.01.04 12:12:41.385 4: TSCUL_Parse: CUL0  415144 A FF13 11547428 02 0D 64 8002 1DA462 278291 01 _CCAdly:8 _dhmSt:136 -138

2017.01.04 12:12:41.386 4: TSCUL_Parse: CUL0  415146 A FF11 11547676 00 0E 64 8002 1DA462 278291 00691A4923 -51

2017.01.04 12:12:41.649 4: TSCUL_Parse: CUL0  415408 A FF13 11548092 02 11 64 A002 1DA462 278291 04 _CCAdly:8 _dhmSt:800 -138
2017.01.04 12:12:41.909 4: TSCUL_Parse: CUL0  415668 A FF13 11548344 01 11 64 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:1052 -138
2017.01.04 12:12:42.169 4: TSCUL_Parse: CUL0  415929 A FF13 11548596 01 11 64 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:1304 -138

2017.01.04 12:12:41.386 wurde nicht von CUL gesendet, sondern vermutlich von HMLAN.

Der Multi-IO Betrieb hat wohl so seine Tücken, die aber nicht auf Firmwareebene gelöst werden können, sondern es muss in CUL_HM gelöst und getrennt werden, welches device von welchem IO bedient wird. Sonst kann keines das Timing sauber halten.
HMLAN darf jedenfalls nicht (ungestraft  ;) ) einfach so in die CUL Kommunikation eingreifen.

Vielleicht hilft es noch was, bei den Fensterkontakten explizit ein IO zuzuweisen, statt die Automatik zu nutzen.

Damit musst Du wohl nochmal ins Homematic Forum posten.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bytechanger am 04 Januar 2017, 15:04:06
OK, mache ich.

Habe nun den HMLAN mal vom Strom getrennt.
Jetzt geht es einige male, aber auch da bleibt es manchmal in pending.... hängen!!

2017.01.04 15:00:58.657 4: TSCUL_Parse: CUL0  026656 A FF13 04865312 01 11 76 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:120 -138
2017.01.04 15:00:58.659 4: TSCUL_Parse: CUL0  026658 A FF11 04865472 00 19 76 A203 278291 1DA462 9A0DA7F2179C9F25BE6C2F7DACB9CDA6 -48.5
2017.01.04 15:00:58.675 4: TSCUL_send:  CUL0                         As 11 76 8002 1DA462 278291 0101C800a912232b
2017.01.04 15:00:58.729 4: TSCUL_Parse: CUL0  026728 A FF11 04865728 00 0C 77 A641 278291 1DA462 013700 -48.5
2017.01.04 15:00:58.781 4: TSCUL_Parse: CUL0  026779 A FF11 04865980 00 0C 77 A241 278291 1DA462 013700 -48.5
2017.01.04 15:00:58.831 4: TSCUL_Parse: CUL0  026830 A FF11 04866488 00 0C 77 A241 278291 1DA462 013700 -48
2017.01.04 15:00:59.145 4: TSCUL_send:  CUL0                         As 11 77 A002 1DA462 278291 041439EB1F9EFA02
2017.01.04 15:00:59.161 4: TSCUL_send:  CUL0                         As 11 77 A002 1DA462 278291 041439EB1F9EFA02
2017.01.04 15:00:59.161 4: TSCUL_Parse: CUL0  027148 A FF11 04867508 00 0C 77 A241 278291 1DA462 013700 -48.5
2017.01.04 15:00:59.212 4: TSCUL_Parse: CUL0  027211 A FF13 04868536 01 11 76 8002 1DA462 278291 01 _CCAdly:4 _dhmSt:2808 -138
2017.01.04 15:00:59.532 4: TSCUL_Parse: CUL0  027531 A FF13 04869008 02 11 77 A002 1DA462 278291 04 _CCAdly:8 -138
2017.01.04 15:00:59.534 4: TSCUL_Parse: CUL0  027533 A FF13 04869100 01 11 77 A002 1DA462 278291 04 _CCAdly:4 -138
2017.01.04 15:00:59.535 4: TSCUL_Parse: CUL0  027535 A FF13 04869352 01 11 77 A002 1DA462 278291 04 _CCAdly:4 -138
2017.01.04 15:00:59.801 4: TSCUL_send:  CUL0                         As 11 77 A002 1DA462 278291 041439EB1F9EFA02
2017.01.04 15:00:59.802 4: TSCUL_Parse: CUL0  027789 A FF11 04869540 00 0C 77 A241 278291 1DA462 013700 -48
2017.01.04 15:01:00.109 4: TSCUL_Parse: CUL0  028108 A FF13 04869664 02 11 77 A002 1DA462 278291 04 _CCAdly:8 -138
2017.01.04 15:01:00.122 4: TSCUL_send:  CUL0                         As 11 77 A002 1DA462 278291 041439EB1F9EFA02
2017.01.04 15:01:00.122 4: TSCUL_Parse: CUL0  028109 A FF11 04869824 00 19 77 A203 278291 1DA462 BF8D9A60060362A47F093B10EC34FC83 -48.5
2017.01.04 15:01:00.518 4: TSCUL_Parse: CUL0  028516 A FF13 04869984 01 11 77 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:160 -138
2017.01.04 15:01:00.519 4: TSCUL_Parse: CUL0  028518 A FF13 04870236 01 11 77 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:412 -138
2017.01.04 15:01:00.774 4: TSCUL_Parse: CUL0  028773 A FF13 04870488 01 11 77 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:664 -138
2017.01.04 15:01:01.031 1: TSCUL_ParseTsHM CUL0 HM repeat failed sending to 278291/EG_FensterBuero: AFF1000529494001177A0021DA46227829104
2017.01.04 15:01:01.032 4: TSCUL_Parse: CUL0  029031 A FF10 04870736 00 11 77 A002 1DA462 278291 04 _sfail -138
2017.01.04 15:01:03.265 4: TSCUL_send:  CUL0                         As 11 77 A002 1DA462 278291 041439EB1F9EFA02
2017.01.04 15:01:03.526 4: TSCUL_Parse: CUL0  031525 A FF13 04873128 02 11 77 A002 1DA462 278291 04 _CCAdly:8 -138
2017.01.04 15:01:03.795 4: TSCUL_Parse: CUL0  031794 A FF13 04873380 01 11 77 A002 1DA462 278291 04 _CCAdly:4 -138
2017.01.04 15:01:04.054 4: TSCUL_Parse: CUL0  032053 A FF13 04873632 01 11 77 A002 1DA462 278291 04 _CCAdly:4 -138
2017.01.04 15:01:04.055 1: TSCUL_ParseTsHM CUL0 HM repeat failed sending to 278291/EG_FensterBuero: AFF10005297A6001177A0021DA46227829104
2017.01.04 15:01:04.056 4: TSCUL_Parse: CUL0  032055 A FF10 04873880 00 11 77 A002 1DA462 278291 04 _sfail -138
2017.01.04 15:01:04.068 4: TSCUL_send:  CUL0                         As 11 77 8002 1DA462 278291 0101C8005f401390
2017.01.04 15:01:04.069 3: TSCUL_XmitDlyHM:  CUL0  id:278291 dDly:82 toms:84
2017.01.04 15:01:04.069 4: TSCUL_Parse: CUL0  032056 A FF11 04873884 00 0C 77 A241 278291 1DA462 013700 -48
2017.01.04 15:01:04.392 4: TSCUL_send:  CUL0                         As 11 77 A002 1DA462 278291 041DFEF8AF5D0802
2017.01.04 15:01:04.396 4: TSCUL_Parse: CUL0  032395 A FF13 04874004 01 11 77 8002 1DA462 278291 01 _CCAdly:4 _dhmSt:120 -138
2017.01.04 15:01:04.652 4: TSCUL_Parse: CUL0  032651 A FF13 04874252 01 11 77 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:368 -138
2017.01.04 15:01:04.913 4: TSCUL_Parse: CUL0  032912 A FF13 04874504 01 11 77 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:620 -138
2017.01.04 15:01:05.183 4: TSCUL_Parse: CUL0  033182 A FF13 04874756 01 11 77 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:872 -138
2017.01.04 15:01:05.185 1: TSCUL_ParseTsHM CUL0 HM repeat failed sending to 278291/EG_FensterBuero: AFF10005298BF001177A0021DA46227829104
2017.01.04 15:01:05.185 4: TSCUL_Parse: CUL0  033184 A FF10 04875004 00 11 77 A002 1DA462 278291 04 _sfail -138
2017.01.04 15:02:01.853 1: Perfmon: possible freeze starting at 15:01:59, delay is 2.853
2017.01.04 15:02:01.864 4: TSCUL_Parse: CUL0  089863 A FF11 04929100 00 0C 03 865A 2617F9 000000 88DA2A -87.5
2017.01.04 15:02:19.256 4: TSCUL_Parse: CUL0  107254 A FF01 04949104 00 0C 03 8470 2617F9 000000 00DA2A -87.5


Also sauber läuft es so auch nicht...

Und wie gesagt, es springt bei einem Zustandswechsel mehfrach zwischen ok und pending und ok herum, was es bei HMLAN nicht macht

Greets

Byte
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 04 Januar 2017, 16:25:25
Hallo theophilou85,

hier https://forum.fhem.de/index.php/topic,24436.msg529649.html#msg529649 (https://forum.fhem.de/index.php/topic,24436.msg529649.html#msg529649) gibt es eine neue TSCUL_fwcode_00_05_02_FHEM_Modules_00_05_03.zip.
Darin ist 00_TSCUL.pm ergänzt um set ITClock. Damit sollte das Standard IT Modul nutzbar sein.

10_TSIT.pm ist jedoch auch auf den Stand von 10_IT.pm gebracht, also fast identisch. Damit habe ich auch getestet, dass meine IT-Schalter noch schaltbar sind.  ;)

Damit sollte Dein Code nun verstanden und gesendet werden.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 04 Januar 2017, 16:52:23
Hallo Byte,

2017.01.04 15:00:58.657 4: TSCUL_Parse: CUL0  026656 A FF13 04865312 01 11 76 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:120 -138
2017.01.04 15:00:58.659 4: TSCUL_Parse: CUL0  026658 A FF11 04865472 00 19 76 A203 278291 1DA462 9A0DA7F2179C9F25BE6C2F7DACB9CDA6 -48.5
2017.01.04 15:00:58.675 4: TSCUL_send:  CUL0                         As 11 76 8002 1DA462 278291 0101C800a912232b

bis dahin sieht es gut aus (die Zeile davor fehlt leider).

2017.01.04 15:00:58.729 4: TSCUL_Parse: CUL0  026728 A FF11 04865728 00 0C 77 A641 278291 1DA462 013700 -48.5
2017.01.04 15:00:58.781 4: TSCUL_Parse: CUL0  026779 A FF11 04865980 00 0C 77 A241 278291 1DA462 013700 -48.5
2017.01.04 15:00:58.831 4: TSCUL_Parse: CUL0  026830 A FF11 04866488 00 0C 77 A241 278291 1DA462 013700 -48

Hier kommt aber was neues vom device, aber zeitlich viel zu kurz aufeinander bei FHEM im Vergleich zu CUL Timestamps.
Das löst wohl mit jedem mal neue Signings aus, was aber wegen Verzögerungen zu spät gesandt wird.
Dann schaukelt sich das auf.

2017.01.04 15:02:01.853 1: Perfmon: possible freeze starting at 15:01:59, delay is 2.853
ZitatHabe nun den HMLAN mal vom Strom getrennt.
Eventuell "vermisst" FHEM den fehlenden HMLAN mit Wiederverbindungsversuchen und das verursacht vielleicht Stockungen bei FHEM, so dass die Daten seitens FHEM nur verzögert bearbeitet werden.
Oder es stört ein anderes Modul mit langen Verarbeitungszeiten.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: tndx am 04 Januar 2017, 17:12:09
Hallo Ansgar,

ich habe ein ähnliches Problem wie der Bytechanger, nur dass ich NanoCUL und HMUARTLGW als IO-Devices nutze. Wie in dem Thread https://forum.fhem.de/index.php/topic,62680.msg548957.html#msg548957 (https://forum.fhem.de/index.php/topic,62680.msg548957.html#msg548957) beschrieben, funktioniert mein Neigungssensor anstandslos mit AES, solange nur der NanoCUL aktiv ist und nicht mehr, wenn der HMUARTLGW dazugeschaltet wird. Lt. Martin liegt das an den Timing-Problemen des NanoCUL. Besteht die Hoffnung, dass Du die TimeStamp-Option auch für NanoCUL irgendwannmal einbaust?
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 04 Januar 2017, 17:59:13
Hallo tndx,

ZitatBesteht die Hoffnung, dass Du die TimeStamp-Option auch für NanoCUL irgendwannmal einbaust?
Ist schon in der zip als hex file drin (sofern Du nicht einen exotischen nanoCUL gebaut hast). Kannst Du also nutzen.

Zitatund nicht mehr, wenn der HMUARTLGW dazugeschaltet wird.
wenn der auch dazwischen quasselt, wie HMLAN es bei Bytechanger zu machen scheint, dann wird die Firmware allein nicht helfen.
In Deinem Log ist aber davon nichts zu sehen, was aber auch im gleichzeitigen Sendeversuch des nanoCUL untergehen kann.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 04 Januar 2017, 18:12:11
Zitat von: tndx am 04 Januar 2017, 17:12:09
Besteht die Hoffnung, dass Du die TimeStamp-Option auch für NanoCUL irgendwannmal einbaust?

Zitat von: noansi am 04 Januar 2017, 17:59:13
Ist schon in der zip als hex file drin (sofern Du nicht einen exotischen nanoCUL gebaut hast). Kannst Du also nutzen.

Ansonsten kannst/musst du sie halt selber bauen, Sourcen sind ja da...
...habe ich auch schon gemacht...

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 05 Januar 2017, 12:10:28
Hallo Testwillige,

ich habe nochmal eine Aktualisierung auf VTS 0.06 hier https://forum.fhem.de/index.php/topic,24436.msg529649.html#msg529649 (https://forum.fhem.de/index.php/topic,24436.msg529649.html#msg529649) hinterlegt.

TSIT entfällt damit und IT muss verwendet werden. Misch-Masch macht hier keinen Sinn, denke ich.
Bei den .HEX Firmwaredateien ist TS nun dem Namen vorran gestellt.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bastel-Frank am 05 Januar 2017, 14:28:53
Zitat von: noansi am 05 Januar 2017, 12:10:28
TSIT entfällt damit und IT muss verwendet werden. Misch-Masch macht hier keinen Sinn, denke ich.

Kurze Frage:
Was ist TSIT und IT?

Viele Grüße
Frank
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 05 Januar 2017, 16:00:20
Hallo Frank,

ZitatWas ist TSIT und IT?
Das ist das Intertechno FHEM Modul, mit dem günstige meißt 433,9MHz Schaltdosen etc. gesteuert werden können, sofern man den Code dafür raus bekommt.

Da theophilou85 das nutzen möchte (bzw. bisher genutzt hat), um innerhalb (sehr geringer Reichweite, wegen CUL mit falscher Funkfrequenz, so nicht zu empfehlen) neben HM so was in der Art zu steuern, habe ich das Thema angepackt, da meine TSIT Variante bisher für meine Intertechno Dosen abgespeckt war.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bastel-Frank am 05 Januar 2017, 17:12:48
Hallo Ansgar,

vielen Dank für deine Erläuterungen und deinen tollen Support :-).

Viele Grüße
Frank
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: theophilou85 am 05 Januar 2017, 19:36:07
Hallo Ansgar

habe es erst mit der TSCUL_fwcode_00_05_02_FHEM_Modules_00_05_03.zip versucht, da bekam ich aber einen ungültigen Handle, mit der von dir vorgeschlagenen TSCUL_fwcode_00_05_02_FHEM_Modules_00_05_02.zip klappt es. Die IT-Befehle lassen sich absetzen und auch die konvertierten AC's funktionieren tadellos.
Toll das du das Thema aufgegriffen hast, vielen Dank. Der CULslowRF+IT-Abneigung vieler hier im Forum, kann ich mich zwar gar nicht anschließen (bei mir geht öfter bei HM was verloren als bei IT und vom Preis ganz zu schweigen), aber ich möchte ja niemanden bekehren und lasse mich lieber belehren ;)

Ich werde gerne die TSCUL_fwcode_00_06_FHEM_Modules_00_06.zip testen, muss aber erst was mit meinen HM-Fensterkontakten richten, damit ich mich auch zum Homematicbetrieb korrekt äußern kann.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 05 Januar 2017, 19:42:13
Zitat von: theophilou85 am 05 Januar 2017, 19:36:07
Toll das du das Thema aufgegriffen hast, vielen Dank. Der CULslowRF+IT-Abneigung vieler hier im Forum, kann ich mich zwar gar nicht anschließen (bei mir geht öfter bei HM was verloren als bei IT und vom Preis ganz zu schweigen), aber ich möchte ja niemanden bekehren und lasse mich lieber belehren ;)

Habe auch mit IT angefangen bzw. habe immer noch welche...

Will auch niemanden belehren/bekehren aber was ich bei Homematic gut finde ist, dass ich bei den batteriebetriebenen Geräten sehen kann, wenn die Batterie leer wird/ist.

Bei meinen batteriebetrieben IT-Sendern merke ich es immer erst, wenn er halt mal wieder nicht mehr geht... ;-)

Allerdings halte ich von "Doppelbetrieb" auf einem CUL immer noch nichts...
...dass da bei Homematic mal was verloren gehen kann ist logisch.

Hmmm, gut doch ein wenig "belehrt"... ;)

Aber schön, dass es jetzt schon besser klappt!

Viel Erfolg weiterhin! Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 05 Januar 2017, 20:19:26
Hallo theophilou85,

ZitatDie IT-Befehle lassen sich absetzen und auch die konvertierten AC's funktionieren tadellos.

Gut, konnte bisher nur IT V1 bei mir testen, dann klappt das also auch.  ;)

ZitatCULslowRF+IT-Abneigung vieler hier im Forum
Nur stören tut, dass Du für das IT Senden halt umschaltest auf Intertechno und während dessen nichts von HM empfangen werden kann. Das kann bei HM dann zu gelegentlichen Problemen führen.

Für kleines Geld könntest Du Dir auch einen nanoCUL für 433.92 MHz basteln und damit Intertechno mit angepasstem Sender machen. Nebenbei mit der Firmware Deiner Wahl, die am besten dazu passt.
Aber letztlich Deine Entscheidung.

Mein Fokus liegt auf HM Kommunikation. Für Intertechno habe ich nicht vor, wie bei der a-cuflfw intensiver zu ergänzen, sprich den SlowRF Empfang zu erweitern.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 06 Januar 2017, 16:38:10
Hallo Testwillige,

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 nötigen Änderungen eingebaut hat.

Danke Rudolf!

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: rudolfkoenig am 06 Januar 2017, 17:11:57
Und wie kommt jetzt Stefan ins Spiel? :)
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 06 Januar 2017, 17:59:27
Hallo Rudolf,

ZitatUnd wie kommt jetzt Stefan ins Spiel?

Hmm, ist so in meinem Zip Download von https://svn.fhem.de/ (https://svn.fhem.de/) drin gewesen. Da habe ich den Text der Versionsinfo raus kopiert.

Habe ich da gerade eine neue Baustelle aufgemacht?  :o  Da steht auch schon mal fhemupdate als Name drin...

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: rudolfkoenig am 06 Januar 2017, 18:23:52
ZitatHabe ich da gerade eine neue Baustelle aufgemacht?
Ja  :-\
Aber danke fuer den Hinweis.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 06 Januar 2017, 18:28:15
Hallo Rudolf,

bei STACKABLE_CC ist mir aufgefallen, dass TCM da rein gekommen ist, was ich derzeit nach erster Recherche mit EnOcean in Verbindung bringe?!?
Ist das für ein SCC auf dem EnOcean läuft?

Ich bin dabei, diese Änderung  auch in TSSTACKED einzubauen.
Ich verstehe aber die Prefix Geschichte dabei nicht.

Es gibt
STACKABLE_CC_DelPrefix($$)
{
  my ($hash, $msg) = @_;
  $msg =~ s/^[^A-Z0-9]//i;
  return $msg;
}

was das '*' von STACKABLE nicht entfernt???

Und
sub
STACKABLE_CC_Write($$)
{
  my ($hash,$fn,$msg) = @_;

  ($fn, $msg) = CUL_WriteTranslate($hash, $fn, $msg);
  return if(!defined($fn));
  IOWrite($hash, "", ($hash->{TCM} ? "%":"*")."$fn$msg"); # No more translations
}

was entweder das '*' voranstellt oder bei TCM ein '%'.
Mit dem '%' kann ich aber nun gar nichts anfangen und es ist mir in der Matchlist bei CUL nicht aufgefallen.

Warum wird es nur ergänzt, aber nicht entfernt?

Kannst Du mir da bitte beim Verständniss helfen was da wie ablaufen soll? Oder ist das noch irgendwo falsch umgesetzt???

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: rudolfkoenig am 06 Januar 2017, 18:36:19
% svn blame 16_STACKABLE_CC.pm | grep TCM
12515 rudolfkoen   $hash->{TCM} = pop @a if(int(@a) == 4 && $a[3] eq "TCM");
...
% svn log -r 12515 16_STACKABLE_CC.pm
...
16_STACKABLE_CC.pm: add TCM option (Forum #60028)

=> Hier steht mehr dazu: https://forum.fhem.de/index.php?topic=60028.0

Laut hermi funktioniert es. Ich habs zwar gebaut, aber nie getestet, und will es solange nicht anfassen, bis jemand das gegentesten kann.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 06 Januar 2017, 20:18:08
Hallo Rudolf,

danke für den Wink, wie ich einen Forumsbeitrag zu einer Änderung finden kann.

Ok, ich denke ich hab's verstanden.
- Vom EnOcean Modul kommt 55usw. (gut das der Sync keinen Buchstaben enthält, ein Kennbuchstabe hätte aber besser in's System gepasst)
  dabei wird bei jedem SCC ein * ergänzt, wie gehabt. Klappt also. Die 5 ist also Kennung und zugleich Datenanteil. Wenn sie auch nicht als Kennung genutzt wird.
- an das EnOcean Modul wird % als Kennbuchstabe gesendet.
  mit den SCCs werden weiter * vorrangestellt,wie gehabt

richtig?

(Von den 57600baud bin ich nicht so begeistert. Mit gleichzeitigem SlowRF Empfang wird die Luft da schon dünn bis zum Datenverlust auf der seriellen Schnitsstelle, bzw. auch die Zeit um die EnOcean Daten nach unten weiter zu reichen. Also Klotzen mit den Puffern, statt Kleckern, wenn größere EnOcean Pakete hin und her sollen.)

So lange ich das nicht bei mir in die Firmware einbaue, muss ich es also eigentlich nicht in TSSTACKED berücksichtigen, da ich nur '*' zu sehen bekomme. :D  Aber nu isses ja schon quasi drin.

Gruß und danke, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: rudolfkoenig am 06 Januar 2017, 20:52:20
ZitatDie 5 ist also Kennung und zugleich Datenanteil
Ich meine nicht. Wenn das SCC als TCM gekennzeichnet ist, dann ist der Prefix %, sonst *, in beide Richtungen. Im TCM Fall wird beim Schreiben Binaer in Hex gewandelt, und beim Lesen umgekehrt. Achtung: das Ganze ist im TCM Fall verschachtelter als man denkt, es laeuft ueber DevIo als IODev, mit definierten IOReadFn/IOWriteFn. Wie gesagt: ohne Testen will ich es nicht anfassen :)
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 06 Januar 2017, 21:08:08
Hallo Rudolf,

ZitatWenn das SCC als TCM gekennzeichnet ist, dann ist der Prefix %, sonst *, in beide Richtungen.
Dem Code nach zumindest nicht.
Im SCC vor dem TCM Hardware Modul wird nur bei einem empfangenen '%' UART1 auf 57600 umgestellt und gesendet, was dann kommt nach Umwandlung von HEX in Binär.
Über UART1 empfangene Daten werden von binaer nach HEX umkodiert und dann Richtung FHEM geschickt. Von einem % habe ich da nichts gesehen. Statt dessen wird die 5 nicht weggefiltert beim DelPrefix (der Match hat mich erst mal wieder genarrt).
Ausschläusen musst Du über das IODEV, % wird da nicht geparst und somit auch nicht über den Dispatcher an das passende FHEM Modul weiter geleitet. So mein Verständnis.

Ich verstehe, dass Du es nicht unnötig anpacken möchtest... tricky, genau wie STACKABLE...  ;)

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: chris1284 am 09 Januar 2017, 16:43:24
ist die version in « Antwort #266 am: 27 November 2016, 18:19:57 » immer noch die neuste? (komische angewohnheit sowas nicht im erföffnungspost einzubauen sondern mitten in einer von xxxxxxx seiten, gut hier ist wenigstens ein link im post 1 :-)  )

wenn ja, wäre es möglich den culCUBE /CUBe als unterstütztes device aufzunehmen oder gleich alle cul-derrivate wie es die aculfw macht?
https://github.com/heliflieger/a-culfw/tree/master/culfw/Devices

ich habe einen cube der ausschließlich hm macht und da wäre die fw wohl die bessere wahl
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 10 Januar 2017, 00:31:57
Hallo Chris,

hier https://forum.fhem.de/index.php/topic,24436.msg540872/topicseen.html#msg540872 (https://forum.fhem.de/index.php/topic,24436.msg540872/topicseen.html#msg540872) hatte ich darauf schon mal geantwortet.

  AT91C_BASE_TC1->TC_CMR = AT91C_TC_CLKS_TIMER_DIV4_CLOCK | AT91C_TC_CPCTRG;  // Timer1: 2,666us = 48MHz/128

ließt sich da leider recht kontraproduktiv.

D.h. intesiver check an allen code Teilen, die mit den 16-bit Timer 1 Timing machen bezüglich Überlauf und ggf. Umgehung.

Timer 1 muss auf 8µs laufen, wie beim CUL, um relativ schnell zum Ziel zu kommen. Geht das mit dem ARM im CUBE?

Ich habe nicht die Hardware, um damit denn auch zu testen. Geschweigedenn Ahnung vom ARM.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bastel-Frank am 15 Januar 2017, 12:04:25
Hallo Ansgar,

ich habe versucht, die Firmware eines Devices OverTheAir (OTA) upzudaten. Das OTA-Tool fragt leider die Firmware-Version ab, und bricht dann den Firmware-Prozess ab, da die Version zu klein zu.

Opening culfw-device at path /dev/ttyACM0 with speed 38400
Requesting firmware version
culfw-device firmware version: 0.05

This version does _not_ support firmware upgrade mode, you need at least 1.58!


Was kann man da machen?

Viele Grüße
Frank
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 15 Januar 2017, 15:45:01
Hallo Frank,

ZitatWas kann man da machen?

im Quellcode der firmware kannst Du

Zitat#define VERSION_1               00
#define VERSION_2               06
#define VERSION                 "0.06"

die Versionsnummer ändern, neu compilieren und auf den CUL flashen.

Bei HM-Devices in fhem gibt es:
set  fwUpdate [onlyEnterBootLoader] <filename> [<waitTime>]

Da ich bisher keine Testrückmeldung zum Firmwareupdate in den letzten Versionen bekommen habe, bist Du dabei alpha-Tester.
Die Firmware unterstützt die Umschaltung in den FUP Modus.
Ich habe allerdings selbst kein OTA-Update fähiges device, um es testen zu können.

In jedem Fall musst Du abwarten, bis die credits in CUL aufgeladen sind (1800 ist max.), damit sie während es Updates nicht ausgehen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bastel-Frank am 15 Januar 2017, 19:06:13
Hallo Ansgar,

wie kann man die Firmware compilieren?

Ein make im /.../DEVICES/CUL Verzeichnis bringt folgende Fehlermeldung:
Cleaning project:
Compiling C: ../../clib/Descriptors.c
/bin/sh: 1: avr-gcc: not found
makefile:230: recipe for target '../../clib/Descriptors.o' failed
make[1]: *** [../../clib/Descriptors.o] Error 127


Viele Grüße
Frank
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 15 Januar 2017, 19:32:50
Hallo Frank,

hast Du es erst mal mit dem FHEM Firmwareupdate über set fwUpdate für das device probiert?
Das wäre der erste Versuch. Da ist mir keine Versionsabfrage aufgefallen.

Zitatwie kann man die Firmware compilieren?
Zitat/bin/sh: 1: avr-gcc: not found
Du musst erst mal mit aptitude avr-gcc nebst libs installieren. Der Compiler wird nicht gefunden.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bastel-Frank am 15 Januar 2017, 20:29:08
ok, übersetzen geht jetzt. Unter Ubuntu muss man folgende Pakete installieren:

apt-get install gcc-avr avr-libc binutils-avr

Mit fwUpdate habe ich noch Probleme, da die betreffende eq3-Datei leider einen CRC-Fehler hat.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 15 Januar 2017, 20:45:35
Hallo Frank,

noch ein Hinweis. Wenn Du bei der Firmware die Version hoch setzt, dann musst Du bei der aktuellen 00_TSCUL.pm auch oben

Zitatmy $reqTSCulFWmax        = 0.06;                           # required max. tscul firmware version
anpassen, wenn Du nicht zurück flashen möchtest.

Sonst meckert 00_TSCUL.pm später die Firmware an und will damit nicht zusammen arbeiten.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bastel-Frank am 16 Januar 2017, 18:53:42
Hallo Ansgar,

nochmal eine Frage. Wie stelle ich mit den Parametern z.B. die Version 1.66 ein?
#define VERSION_1               00
#define VERSION_2               06
#define VERSION                 "0.06"


Viele Grüße
Frank

Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: theophilou85 am 16 Januar 2017, 19:09:53
Hallo Ansgar

Habe jetzt deine Firmware noch weiter getestet. Homematic läuft einwandfrei, aber die Deckenlampe zickt manchmal:

2017.01.16 19:01:07 2: wz0_cul00 IT_set: wz0_del00_sch00 off
2017.01.16 19:01:12 2: IT IODev device didn't answer is command correctly:   raw => AFF130666B57E0109C4B11200000126043E80
2017.01.16 19:01:12 2: wz0_cul00 IT_set: wz0_del00_sch01 off
2017.01.16 19:01:17 2: IT IODev device didn't answer is command correctly:   raw => is00100000100001100110010110001000
2017.01.16 19:01:18 3: wz0_cul00: Unknown code is00100000100001100110010110001001, help me!
2017.01.16 19:01:19 3: TSCUL_XmitDlyHM:  wz0_cul00  id:4E9763 dDly:107 toms:75
2017.01.16 19:01:20 1: TSCUL_ParseTsHM wz0_cul00 HM repeat failed sending to 26043E/wz0_the00: AFF200666C1BB000CC5A01100000126043E86
2017.01.16 19:01:56 3: TSCUL_XmitDlyHM:  wz0_cul00  id:26BDD2 dDly:43 toms:74


define wz0_del00_sch00 IT 00100000100001100110010110 0 1000
attr wz0_del00_sch00 IODev wz0_cul00
attr wz0_del00_sch00 alias Licht
attr wz0_del00_sch00 group [AC] Deckenleuchten
attr wz0_del00_sch00 room X_Geräte,Deckenleuchten

define wz0_del00_sch01 IT 00100000100001100110010110 0 1001
attr wz0_del00_sch01 IODev wz0_cul00
attr wz0_del00_sch01 alias Ambiente
attr wz0_del00_sch01 group [AC] Deckenleuchten
attr wz0_del00_sch01 room X_Geräte,Deckenleuchten


Folgende Firmware: CUL_V3 TSCUL_fwcode_00_05_02.hex
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 16 Januar 2017, 21:23:50
Hallo theophilou85,

Zitataber die Deckenlampe zickt manchmal
Schaltet sie richtig, so wie gewünscht?

ZitatIT IODev device didn't answer is command correctly:   raw => AFF130666B57E0109C4B11200000126043E80
Das ist Folge des Mischbetriebs. IT gesendet und zufällig gerade HM empfangen. (der HM Empfang ist in diesem Fall sogar verloren, da es nicht weiter geparst wird)
Du hast es so gewollt.  ;)
Lösung: eigener CUL für IT
Aber auch dann können noch andere IT oder SlowRF Daten empfangen werden, so dass das Senden an CUL und Auswerten der ersten Antwort nie richtig funktionieren kann.

Zitat2017.01.16 19:01:17 2: IT IODev device didn't answer is command correctly:   raw => is00100000100001100110010110001000
2017.01.16 19:01:18 3: wz0_cul00: Unknown code is00100000100001100110010110001001, help me!
Ich habe das Feedback zum Senden geändert, eben wegen obigen Grund.
Mit dem "is" könnte man das normal Parsen und über den Dispatcher wieder IT zuführen zwecks Auswertung.
Das IT Modul kommt mit diesem geänderten Feedback aber nicht zurecht.
Das werde ich auch nicht ändern, weil das meiner Ansicht nach die sinnvolle Lösung für Mischbetrieb ist. Das IT Modul müßte dahingehend sinnvoll angepasst werden.
Das Feedback ist aber eigentlich so weitgehend Quatsch, weil eh nur das zurück kommt, was zu CUL geschickt wurde. Ob es gesendet wurde geht daraus nicht hervor (und ob die Lampe schaltet sowieso nicht). Nur Probleme bei der seriellen Datenübertragung (z.B. zu kleiner Puffer auf CUL) fallen so auf.

Mit verbose 5 bei Deinen IT devices kannst Du auch loggen, was an CUL raus geht und mit dem vergleichen, was zurück kommt, falls die Lampen nicht richtig schalten.
Die 0, die gegenüber der Definition mehr drin ist, muss so vom IT Modul kommen. Ob das so richtig ist, habe nicht geprüft.

Wenn die Lampen richtig schalten, dann verbose 0 bei den IT devices und im log taucht es nicht mehr auf. (Oder das IT Modul umprogrammieren.)

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: theophilou85 am 17 Januar 2017, 00:48:26
Hallo Ansgar

Bis vor zwei Tagen hat sie noch richtig geschalten. Habe es jetzt mehrfach probiert und sie schaltet nicht mehr, sehr wohl aber alle anderen IT-Devices.
Ich werde auf ein eigenes Device umsteigen, sobald der Tuxradio v4 verfügbar ist, bis dahin, hätte ich mich gerne noch so über Wasser gehalten.

Gibt es ein Workaround für meine Situation?

Unterstützt deine Firmware eigentlich: TRX_LIGHT.pm? Dann könnte ich versuchen den Befehl mal direkt mit AC abzusetzen.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 17 Januar 2017, 21:13:56
Hallo Frank,

#define VERSION_1               01
#define VERSION_2               66
#define VERSION                 "1.66"

ergibt Version 1.66 .

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 17 Januar 2017, 21:49:27
Hallo theophilou85,

ZitatBis vor zwei Tagen hat sie noch richtig geschalten.
- Schaltet sie noch mit der zugehörigen Fernbedienung? Sprich, funktioniert die Lampe noch inklusive Leuchtmittel?
- Hast Du zu diesem Zeitpunkt was geändert? Z.B. ein FHEM Update gefahren? Oder den Empfang durch irgendwelche Umbauten in der Bude verschlechtert (Du sendest ja eh schwach)? CUL Position verändert usw.
- Hast Du mal die Sendefrequenz etwas variiert (Attribut  ITfrequency)? Temperaturveränderungen können dabei eventuell auch eine Rolle spielen.
- Hast Du mal geprüft, ob der Code, der gesendet wird (also das was mit verbose 5 im Log erscheint), auch richtig ist?

sehr wohl aber alle anderen IT-Devices
Daher sehe ich auch erst mal keinen Grund für Dein Problem bei der Firmware. Gesendet wird es als Intertechno_V3.
Was AC im speziellen ggf. anders sendet weiß ich nicht, da müsstest Du mal Infos zu suchen.

ZitatUnterstützt deine Firmware eigentlich: TRX_LIGHT.pm?
leider nein.
Aber wenn eine der letzten 2 Fragen Dein Problem löst, dann würde das auch nicht helfen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: theophilou85 am 18 Januar 2017, 00:00:25
Hallo Ansgar

Erstmal danke für deine Zeit, "Theo" ist übrigens mehr als ausreichend.
Lampe funktioniert mit FB, CUL bewegte sich keinen Millimeter und ich dachte auch nichts geändert zu haben: "falsch": Ich hatte die fhem.save im Zuge des Löschens der Logs mitgelöscht.

Ich habe keine Ahnung ob das einen Sinn macht, aber ich kann es immer(!) rekonstruieren:
Aktuelle fhem.save -->Lampe schaltet nicht:
2017.01.17 23:46:33 2: TSCUL_Parse: wz0_cul00 new condition Warning-HighLoad
2017.01.17 23:46:33 2: TSCUL_Parse: wz0_cul00 new condition ERROR-Overload
2017.01.17 23:46:38 2: wz0_cul00 IT_set: wz0_del00_sch00 off
2017.01.17 23:46:38 5: wz0_cul00 IT_set: Type=TSCUL Protocol=V3
2017.01.17 23:46:43 5: IT_Set: GetFn(raw): message = is00100000100001100110010110001000 Antwort =   raw => LOVF
2017.01.17 23:46:43 2: IT IODev device didn't answer is command correctly:   raw => LOVF
2017.01.17 23:46:44 3: wz0_cul00: Unknown code is00100000100001100110010110001000, help me!


fhem.save eines alten Backups (sonst alle Dateien gleich)
2017.01.17 23:48:16 2: TSCUL_Parse: wz0_cul00 new condition Warning-HighLoad
2017.01.17 23:48:16 3: CUL_HM set wz0_inm00_Schalter1 statusRequest
2017.01.17 23:48:17 3: TSCUL_XmitDlyHM:  wz0_cul00  id:2FF75C dDly:14 toms:51
2017.01.17 23:48:17 3: TSCUL_XmitDlyHM:  wz0_cul00  id:2FF75C dDly:74 toms:50
2017.01.17 23:48:17 2: TSCUL_Parse: wz0_cul00 new condition ERROR-Overload
2017.01.17 23:48:23 2: wz0_cul00 IT_set: wz0_del00_sch00 off
2017.01.17 23:48:23 5: wz0_cul00 IT_set: Type=TSCUL Protocol=V3
2017.01.17 23:48:28 5: IT_Set: GetFn(raw): message = is00100000100001100110010110000000 Antwort =   raw => is00100000100001100110010110000000


Ergibt das Sinn?
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 18 Januar 2017, 07:23:07
Hallo Theo,

Zitat2017.01.17 23:46:33 2: TSCUL_Parse: wz0_cul00 new condition ERROR-Overload
Sendezeit Limit erreicht (1% Regel)

Zitat2017.01.17 23:46:43 5: IT_Set: GetFn(raw): message = is00100000100001100110010110001000 Antwort =   raw => LOVF
Sendezeit Limit erreicht (1% Regel)

Warten bis wieder genügend credits angesammelt sind (get credits bei CUL).

ZitatIch hatte die fhem.save im Zuge des Löschens der Logs mitgelöscht.
ganz schlechte Idee, weil HM dann versucht alle Register von allen devices neu zu lesen.
autoreadreg readallmissing nutzen und HMInfo mit autosave.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: theophilou85 am 18 Januar 2017, 18:28:59
Hi Ansgar

Gehe ich richtig in der Annahme dass du das attr autoUpdate für hm (define hm HMinfo) meinst? Ich frage lieber einmal mehr, bevor ich mir wieder etwas zerschieße ;)
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bastel-Frank am 18 Januar 2017, 20:37:17
Hallo Ansgar,

mit:
Zitat von: noansi am 17 Januar 2017, 21:13:56
#define VERSION_1               01
#define VERSION_2               66
#define VERSION                 "1.66"

ergibt Version 1.66 .

meldet mir das OTA-Tool leider dann, dass nur die Version 0.66 geflasht wurde. Kannst Du das bitte bei Dir kurz testen?

Viele Grüße
Frank
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bastel-Frank am 18 Januar 2017, 20:58:28
... hmm, komisch. In den Internals wird die Version mit 1.66 angegeben. Das OTA-Tool meldet aber, dass nur Version 0.66 vorliegt  :-[
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 18 Januar 2017, 21:13:27
Hallo Theo,

für HMInfo nutze ich folgende Definition:
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 event-on-update-reading ERR_battery
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

sumERROR und sumStatus musst Du ggf. nach Deinen Wünschen anpassen. Siehe auch commandref und wiki etc.

Bei den einzelnen HM devices nutze ich in der Regel das:
attr <devicename> autoReadReg 5_readMissing
um nur nicht bereits gelesene Register nochmal vom device zu holen, was die credits gerade beim Start von FHEM schont, da dadurch viel an die devices gesendet werden muss. Und fhem.save lösche ich nie (bewußt), eben auch, um die credits beim FHEM Start zu schonen. Für den Normalbetrieb habe ich bisher keine Einschränkungen wegen mangelnder credits bemerken können.

Und
attr <devicename> expert 3_allReg+raw
um möglichst viel Registerwerte zu Gesicht zu bekommen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 18 Januar 2017, 21:29:58
Hallo Frank,

was spricht gegen einen Firmware Update Versuch aus FHEM herraus, wie ich es mal vorgeschlagen hatte, wozu Du aber nichts geschrieben hast?
Du mußt das device erst mal pairen und dann solltest Du den credits Stand checken und kannst einen Firmwareupdate mit dem device versuchen.

ZitatIn den Internals wird die Version mit 1.66 angegeben.
Deswegen muss ich das auch nicht testen.  ;)

ZitatDas OTA-Tool meldet aber, dass nur Version 0.66 vorliegt
Dann kommt das OTA-Tool wohl mit der VTS Versionskennung nicht klar.
Die ist einfach in fncollection.c von VTS in V zu ändern. Nur wird es dann völliger Murks, da ich das VTS gerade wegen eindeutiger Unterscheidung von TS Firmware gewählt habe.

Richtiger wäre, wenn der OTA-Tool Entwickler sich der Versionsproblematik mal annehmen würde. Der dann auch direkt einen check auf ausreichend credits einbauen sollte, sofern nicht schon geschehen. Und dann auch mit Timestamp Rückmeldungen klar kommen sollte, da ich die ohnehin künftig stets per default aktiv habe und auch die Abschaltung weglasse.

Du kannst natürlich auch einfach mal die Standard Firmware flashen, damit Dein Update mit dem OTA Tool fahren und dann wieder die TS Firmware flashen, um die Sache abzukürzen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bastel-Frank am 19 Januar 2017, 07:45:28
Hallo Ansgar,

vielen Dank für deine Hilfe und Geduld.

Ich möchte den Universalsensor (von Dirk hier aus dem Forum) updaten. Dieser unterstützt das normale fhem-fw-Update von der Komandozeile leider nicht. Daher kann man den von Dir vorgeschlagenen Standard-Weg nicht einschlagen.

Da es mit dem OTA-Tool wohl nicht gehen wird, kürzen wir die Sache dann tatsächlich ab und ich begebe mich ans Flashen ...

Viele Grüße
Frank
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: theophilou85 am 21 Januar 2017, 15:58:09
Hallo Ansgar

Danke für den Tipp, habe ich gleich umgesetzt. Wie steht es eigentlich um "autoReadReg" beim Actiondetector? Hast du den auch auf 5?
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 21 Januar 2017, 22:15:26
Hallo Theo,

ZitatWie steht es eigentlich um "autoReadReg" beim Actiondetector? Hast du den auch auf 5?

Das Attribut macht da keinen Sinn, weil das kein Funk device ist, von dem Register zu lesen wären.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 23 Januar 2017, 21:58:08
Hallo Frank,

Michael hat den Support für tsculfw jetzt in sein Firmware Update Tool 1.03 eingebaut.
Damit könntest Du einen neuen Versuch starten, ohne CUL umflashen zu müssen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: theophilou85 am 23 Januar 2017, 23:26:20
Hi Ansgar

Ich habe meine HMinfo und die autoreadreg der Hm-Devices jetzt so eingestellt wie du vorgeschlagen hast:

define ActionDetector CUL_HM 000001
attr ActionDetector actCycle 600
attr ActionDetector actStatus
#attr ActionDetector autoReadReg 4_reqStatus
attr ActionDetector event-on-change-reading .*
attr ActionDetector expert 2_full
attr ActionDetector group FHEM
attr ActionDetector model ActionDetector

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 sumERROR battery:ok,sabotageError:off,powerError:ok,overload:off,overheat:off,reduced:off,motorErr:ok,error:none,uncertain:[no|yes],smoke_detect:none,cover:closed
attr hm_info sumStatus battery,sabotageError,powerError,motor
attr hm_info webCmd update:protoEvents short:rssi:peerXref:configCheck:models

attr wz0_the00 autoReadReg 5_readMissing
...
attr wz0_kon01 autoReadReg 5_readMissing
...


Bekomme aber selbst wenn keiner zu Hause ist und kein IT-Devices oder sonst irgendwas schalten muss, nach einigen Stunden folgende Fehlermeldung:
2017.01.23 08:03:11 1: PERL WARNING: Use of uninitialized value $name in hash element at ./FHEM/10_CUL_HM.pm line 9108.
2017.01.23 23:11:54 1: reload: Error:Modul 99_myUtils deactivated:

2017.01.23 23:11:54 1: starting in console mode


Komme ich dann nach Hause lassen sich die IT-Devices nicht mehr schalten.

Das einzige, dass mir bei der Sache auffällt ist: Ich habe kein /opt/fhem, da ich FHEM ja als Dienst unter Windows laufen lasse (nicht mehr lange). Oder hängt sich das FHEM wegen dem MyUtils auf? Darin habe ich aktuell aber nur den Addlog. Ich deaktiviere diesen einmal zum Test.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 24 Januar 2017, 06:33:38
Hallo Theo,

ZitatIch habe kein /opt/fhem
Dann must Du das wohl beim attribut configDir anpassen. Wenn Du es gant weg läßt, dann wird als default ein . genommen, laut code.

Unter Linux auf dem RasPi ist /opt/fhem das default Installationsverzeichnis.  Wo es unter Windows ist, kann ich nicht sagen. Stell die Frage bitte nochmal im Homatic Forum.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bastel-Frank am 24 Januar 2017, 07:55:57
Zitat von: noansi am 23 Januar 2017, 21:58:08
Hallo Frank,

Michael hat den Support für tsculfw jetzt in sein Firmware Update Tool 1.03 eingebaut.
Damit könntest Du einen neuen Versuch starten, ohne CUL umflashen zu müssen.

Gruß, Ansgar.

Hallo Ansgar,

vielen Dank für die Info. Ich werde die neue Version testen.

Viele Grüße
Frank
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 24 Januar 2017, 23:40:45
Hallo Theo,

ZitatOder hängt sich das FHEM wegen dem MyUtils auf? Darin habe ich aktuell aber nur den Addlog. Ich deaktiviere diesen einmal zum Test.

Wenn da ein Bug drin steckt, kann das auch zu Deinem Problem führen oder zumindest den Log Eintrag dazu erklären.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: schka17 am 26 Januar 2017, 11:33:10
Hallo,

da ich sukzessive von SlowRF alles auf Homematic umstelle, benötige ich weitere IO Devices, ich habe da jetzt dieses geniale LGW mit CoProzessor, darauf habe ich bis jetzt a-culfw laufen, damit geht aber im HM Bereich so gut wie gar nichts, jetzt will ich mal TSCUL verwenden aber es gibt leider keine hex Datei für den mini, nur nano. Jetzt will ich mir das selber kompilieren (weiss zwar noch nicht wie), reicht es eigentlich wenn ich die board.h vom mini verwende oder muss ich da mehr ändern????

Gruß

Karl
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 26 Januar 2017, 23:25:37
Hallo Karl,

hier https://forum.fhem.de/index.php/topic,24436.msg529649.html#msg529649 (https://forum.fhem.de/index.php/topic,24436.msg529649.html#msg529649) habe ich in TSCUL_fwcode_00_06_FHEM_Modules_00_06m.zip mal auf Basis der nanoCUL Variante eine miniCUL Variante gebaut. Testen kann ich sie leider nicht.

Auch diese verwendet SPI_CC1101_READ_SPECIAL_PORT Port B Pin 6 als ungenutzten Pin. Falls dieser Pin doch genutzt ist, muss das geändert werden, sprich auf einen ungenutzten I/O Pin in board.h angepasst werden.

Es wird ein Version für Marker Pins gebaut. Damit bei unbeschalteten Pins eine 868MHz Version. Mit 433MHz Rf Modul macht es wohl weniger Sinn.

Bitte gib Feedback, ob es funktioniert.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: schka17 am 27 Januar 2017, 00:11:10
Zitat von: noansi am 26 Januar 2017, 23:25:37
Hallo Karl,

hier https://forum.fhem.de/index.php/topic,24436.msg529649.html#msg529649 (https://forum.fhem.de/index.php/topic,24436.msg529649.html#msg529649) habe ich in TSCUL_fwcode_00_06_FHEM_Modules_00_06m.zip mal auf Basis der nanoCUL Variante eine miniCUL Variante gebaut. Testen kann ich sie leider nicht.

Auch diese verwendet SPI_CC1101_READ_SPECIAL_PORT Port B Pin 6 als ungenutzten Pin. Falls dieser Pin doch genutzt ist, muss das geändert werden, sprich auf einen ungenutzten I/O Pin in board.h angepasst werden.

Es wird ein Version für Marker Pins gebaut. Damit bei unbeschalteten Pins eine 868MHz Version. Mit 433MHz Rf Modul macht es wohl weniger Sinn.

Bitte gib Feedback, ob es funktioniert.

Gruß, Ansgar.
Hallo Ansgar,

Ich hoffe ich komme spätestens am Wochenende dazu, bekomme gerade meine neue Heizung. Ich probiere das aus, aber ich habe das schon richtig verstanden dass ich "nur" die board.h anpassen müsste? Soviel ich im ersten schnellen durchsehen bei der a-culfw gesehen gibts nur dort Unterschiede in der Pinbelegeung.

Gru, Karl


Sent from my iPad using Tapatalk
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 27 Januar 2017, 06:29:24
Hallo Karl,

ZitatIch probiere das aus, aber ich habe das schon richtig verstanden dass ich "nur" die board.h anpassen müsste?

Unter Devices habe ich "miniCUL" erstellt.
Ich habe board.h, miniCUL.c und makefile nach miniCUL aus der a-culfw angepasst.

Wenn Irren nicht menschlich wäre, dann müßtest Du dort nur compilieren und flashen.  ;)

Danach ergibt sich dann die Frage, ob TSCUL damit läüft, bzw. auf miniCUL zugreifen kann.

Gruß, Angar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: schka17 am 27 Januar 2017, 10:11:13
Zitat von: noansi am 27 Januar 2017, 06:29:24
Hallo Karl,

Unter Devices habe ich "miniCUL" erstellt.
Ich habe board.h, miniCUL.c und makefile nach miniCUL aus der a-culfw angepasst.

Wenn Irren nicht menschlich wäre, dann müßtest Du dort nur compilieren und flashen.  ;)

Danach ergibt sich dann die Frage, ob TSCUL damit läüft, bzw. auf miniCUL zugreifen kann.

Gruß, Angar.

Hallo Angar,

schnelles erstes Feedback,

2017.01.27 10:01:51 1: LGW2_TSCUL is VERSION_TS, VTS 0.06 miniCUL, miniCUL_V1.x
2017.01.27 10:04:05 2: TSCUL_condUpdate: LGW2_TSCUL new condition init
2017.01.27 10:04:05 1: LGW2_TSCUL is VERSION_TS, VTS 0.06 miniCUL, miniCUL_V1.x
2017.01.27 10:04:05 1: DevIoTS_OpenDev: 192.168.255.17:85 reappeared (LGW2_TSCUL)
2017.01.27 10:04:08 4: TSCUL_Parse: LGW2_TSCUL K971450860073C705 -71.5
2017.01.27 10:04:33 2: TSCUL_Parse: LGW2_TSCUL: unknown message T1F5E00B6FFF9


Soweit glaube ich dass man die Frage beantworten kann, konnte kompilieren, flashen und darauf zugreifen. Jetzt noch meinen CUL flashen und dann weiter damit beschäftigen. Vielen Dank jedenfalls für diese rasche Unterstützung.

Sollte noch jemand versuchen einen miniCUL auf einem LGW betreiben zu wollen, kompilieren mit
make program
kommt dann natürlich eine Fehlermeldung weill der mini ja nicht angesteckt ist, flashen auf das LGW mit
curl --http1.0 -H "Content_Type:multipart/form-data" -F "file=@./TSminiCUL.hex; filename=addon.hex" http://192.168.255.17/ota/addon.hex

Gruß, Karl

Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 28 Januar 2017, 01:17:46
Hallo Karl,

neben einer KS Nachricht ist auch eine FHT-artige Nachricht in Deinem Protokoll angekommen.

FHT hatte ich in 00_TSCUL.pm auskommentiert, da meinerseits untestbar.
Außerdem ist es in miniCUL genau wie nanoCUL weitgehend abgeschaltet um RAM für die HM Puffer bereit zu stellen.

Wenn Du also doch  irgendwas mit den FHT Nachrichten anfangen möchtest, dann wären noch Änderungen nötig und da nur 2kB RAM zur Verfügung stehen geht wohl nicht alles mit dem miniCUL.

Aber natürlich kannst Du auch testen, ob der SlowRF Empfang besser oder schlechter ist, als mit den anderen Firmware Alternativen.
KS Sensoren habe ich auch im Einsatz und daher auch im SlowRF Bereich Änderungen einfließen lassen.

Wenn Du bei den KS Sensoren keine V1.1 Sensoren hast, dann solltest Du HAS_NO_WS2000_V1_1_SUPPORT  in der board.h definieren, was Fehlempfang für V1.2 verbessert, da bei V1.1 die Checksummenabsicherung schwächer ist, als beim V1.2 Protokoll und daher mehr "Schrott" durchkommt.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: schka17 am 28 Januar 2017, 11:59:37
Zitat von: noansi am 28 Januar 2017, 01:17:46
Hallo Karl,

neben einer KS Nachricht ist auch eine FHT-artige Nachricht in Deinem Protokoll angekommen.

FHT hatte ich in 00_TSCUL.pm auskommentiert, da meinerseits untestbar.
Außerdem ist es in miniCUL genau wie nanoCUL weitgehend abgeschaltet um RAM für die HM Puffer bereit zu stellen.

Wenn Du also doch  irgendwas mit den FHT Nachrichten anfangen möchtest, dann wären noch Änderungen nötig und da nur 2kB RAM zur Verfügung stehen geht wohl nicht alles mit dem miniCUL.

Aber natürlich kannst Du auch testen, ob der SlowRF Empfang besser oder schlechter ist, als mit den anderen Firmware Alternativen.
KS Sensoren habe ich auch im Einsatz und daher auch im SlowRF Bereich Änderungen einfließen lassen.

Wenn Du bei den KS Sensoren keine V1.1 Sensoren hast, dann solltest Du HAS_NO_WS2000_V1_1_SUPPORT  in der board.h definieren, was Fehlempfang für V1.2 verbessert, da bei V1.1 die Checksummenabsicherung schwächer ist, als beim V1.2 Protokoll und daher mehr "Schrott" durchkommt.

Gruß, Ansgar.
Hallo Ansgar,

Die FHT's werden sowieso abgebaut, der miniCUL ist ausschließlich für Homematic vorgesehen da ich eben immer mehr HM Komponenten habe, gehen die IO device immer in Overload wenn ich z.b. heizprofile umstelle. Da möchte ich den Funkverkehr auf mehrere HM IO aufteilen. Für slowrf habe ich einen CUNO. Ich muss mich da jetzt mal rantasten, ich dachte mir dass mal alles auskommentiere was nicht mit HM zu tun, aber so wie es jetzt schon läuft bin ich mega zufrieden. Möglicherweise nur ein Schönheitsfehler, aber es gibt natürlich den miniCUL nicht als model in 00_TSCUL.pm, weiss nicht ob das einen Impact hat, bemerket habe ich nichts, also so weit mal so gut. Jetzt ist mal die Integration der neuen Heizung mit ebus an der Reihe, vielen Dank für den Support.

Gruß, Karl


Sent from my iPad using Tapatalk
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 28 Januar 2017, 16:48:23
Hallo Karl,

Zitataber es gibt natürlich den miniCUL nicht als model in 00_TSCUL.pm, weiss nicht ob das einen Impact hat
nein  :)

Gruß, Ansgar

Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: sledge am 12 Februar 2017, 11:05:11
Habe die neue FW auf zwei LGW mit miniCUL erfolgreich am Start - läuft bisher (~20h) problemlos.

Hänge die addon.hex (VTS 0.06 miniCUL) für den miniCUL mal an, hat ja ggfs. nicht jeder die avr-Toolchain griffbereit.

Gruß, Tom
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: dieter am 22 Februar 2017, 16:31:47
 .
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: b4rRa am 02 März 2017, 10:37:08
Moin Moin :) Kann man die vorkompilierte TSnanoCUL.hex in der ZIP File ohne Probleme flashen? Sprich ist die schon auf 868 eingestellt und HM optimiert, oder sollte ich mir diese besser selbst kompilieren und in der board.h noch etwas anpassen?
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 02 März 2017, 10:46:55
Hallo b4rRa,

wenn Du nicht von der Bauanleitung abgewichen bist, dann sollte es passen, da hier im Thread schon getestet.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: hanoba am 10 März 2017, 22:20:36
Mir wurde im Thread https://forum.fhem.de/index.php/topic,64375.msg555971.html#msg555971 geraten, die TSCUL-Firmware zu probieren. Leider hat TSCUL keine Verbesserung, sondern eine Verschlechterung gebracht (Details im oben genannten Thread).

Zu den erzeugten TSCUL-Log-Files hätte ich ein paar Fragen:
- Was bedeutet TSCUL_send und TSCUL_parse genau (siehe Beispiel unten)?
  TSCUL_send:  nanoCul                                           As 0E 3E B011 133A3C 35F481 0205000000
  TSCUL_Parse: nanoCul  139750 A FF13 08120968 01 0E 3E B011 133A3C 35F481 02 _bst _CCAdly:4 -138
- Was ist "139750 A FF13" im Beispiel oben? Timestamp?
- Was bedeuten  "_bst"
- Was bedeutet "_CCAdly:4"
- Was bedeutet: "TSCUL_XmitDlyHM:  nanoCul  id:35F481 dDly:95 toms:33"
- Was bedeutet: "_dhmSt"

Vielleicht kann hier jemand weiterhelfen.

Danke und Gruß

Harald
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 11 März 2017, 09:14:06
Hallo Harald,

ich habe keine HM gesteuerten Rollos, daher kann ich dazu nichts selber testen.

Daher bitte ein Device List (CUL+Rollos) und ein Log (mit verbose 4 beim nanoCul) zu Deinem Problemfall.
Und zwar ein Log mit dem Steuern nur eines Rollos möglichst ohne dass was anderes noch dazwischen funkt.
Und dann ein Log mit dem Steuern mehrerer Rollos auf einmal.

ZitatAußerdem zeigt sich mit TSCUL das gleiche fehlerhafte Verhalten, dass nicht auf ein ACK gewartet wird bevor ein neuer Funkbefehl gesendet wird.
Das ist so nicht richtig. Wenn ein Befehl mit Ack-Anforderungs Flag gesendet wird, wartet die Firmware eine gewisse Zeit auf die Antwort, bevor ein weiterer Befehl gesendet wird. Aber ich kann nicht ausschließen, dass es für Deine Rollos nicht passt, also die z.B. nicht innerhalb dieser Zeit antworten.
Bezüglich Sendezeiten müssen die Sendequittungen ausgewertet werden. As schickt nur eine Sende-message an CUL.

Außerdem darfst Du für HM generell nicht FHEM mit busy waiting oder hoher Auslastung am rechtzeitigen Senden und Verarbeiten weiterer HM-Nachrichten hindern.

ZitatTSCUL_Parse: nanoCul  139750 A FF13 08120968 01 0E 3E B011 133A3C 35F481 02 _bst _CCAdly:4 -138
Zitat139750
Zeit (ms) des Starts der Verarbeitung einer HM Nachricht in 00_TSCUL.pm (also in FHEM)
ZitatA
ASKSIN message vom CUL
ZitatFF
Kennung für Timestamp ASKSIN message (eigentlich nur das erste der beiden F, das zweite kann noch Verwendung finden)
Zitat13
grober credits Stand und Typ der message (1=Empfangene Nachricht, 2=ping, 3=Sendequittung, 0 und 4 bis 7 Sendefehler)
Zitat08120968
Timestamp in ms auf CUL zu der die message erzeugt wurde
Zitat01
CCA Verzögerung in 4ms Einheiten, 1 ergibt sich schon durch das Umschalten auf Senden
Zitat0E 3E B011 133A3C 35F481 02
hier so viel von der gesendeten Nachricht, dass sie eindeutig wieder zu erkennen ist

ZitatWas bedeuten  "_bst"
Das Burst Flag ist gesetzt, d.h. es wird die lange 300ms Aufweckpräambel statt der nomalen 10ms gesendet
ZitatWas bedeutet "_CCAdly:4"
CCA bedingte Zusatzverzögerung (wenn der Kanal nicht frei ist, 4 ergibt sich bereits durch die Umschaltung auf Senden bei freiem Kanal)
Zitat- Was bedeutet: "TSCUL_XmitDlyHM:  nanoCul  id:35F481 dDly:95 toms:33"
00_TSCUL.pm interne Verzögerungszeiten für das Senden an CUL.
Zitat- Was bedeutet: "_dhmSt"
Antwortzeit bezogen auf die letzte vom device empfangene Nachricht in ms

00_TSCUL.pm kennt übrigens das Attribut hmLanQlen.

Hast Du die Firmware aus "TSCUL_fwcode_00_06_FHEM_Modules_00_06m.zip" von hier https://forum.fhem.de/index.php/topic,24436.msg529649.html#msg529649 (https://forum.fhem.de/index.php/topic,24436.msg529649.html#msg529649) geflasht? Das ist die aktuellste.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: b4rRa am 16 März 2017, 17:46:51
Hallo :)

ich habe auf meinem nanoCUL mittlerweile die TS_CUL Firmware laufen. Ich habe wie nachgefragt, direkt die fertige hex-File für den nanoCUL geflasht. Prinzipiell läuft es auch. Aber ich bekomme leider im Log ziemlich oft folgende Fehler

2017.03.16 17:42:25 1: TSCUL_ParseTsHM nanoCUL_868_HM HM repeat failed sending to 30C21A/Bastelecke: AFF600001029F000E50A011A1B2C330C21A02

es werden dann teilweise Befehle nicht ausgeführt oder der Status nicht aktualisiert. Ich bekomme dann einen NACK als state. Den Fehler bekomme ich auch immer wenn ich einen status request über das Device manuell ausführe.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 16 März 2017, 22:27:44
Hallo  :)

ohne List vom nanoCul, Linst vom device und Log mit Verbose 4 beim nanoCul wirst Du meine Glaskugel leider nicht sehr erhellen können.

Möglicherweise kann nanoCul nicht senden, weil er z.B. nah an einer Störquelle liegt. Oder das Device antwortet nicht oder ist zu weit weg oder dicht dran. Oder Du versuchst mehrere devices gleichzeitig zu schalten und das scheitert dann an der Kanalbelegung bezüglich des rechtzeitgen Empfangs. Usw...
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: b4rRa am 17 März 2017, 17:18:14
Hallo :)

Danke für Deine Antwort! Ja, das mit der Glaskugel ist immer so eine Sache.. Meist dann kaputt wenn man sie braucht ;D

Habe mir das Wochenende frei genommen und werde noch mal einige Sachen testen.. Sollte ich weiterhin Probleme haben, werde ich mich mit diversen Logs wieder melden :)

VG
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Manul am 06 Mai 2017, 11:25:52
Ich habe gerade versucht, die Firmware zu flashen, bin aber nicht sicher, ob's erfolgreich war, da die udev-Regeln nicht greifen und der vorher definierte CUL weiter zu funktionieren scheint. Mein CUL meldet sich mit Version "V 1.66 CUL868" - welchen Versionsstring würde denn die aktuelle TS-Firmware ausgeben?
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 06 Mai 2017, 12:07:18
Hallo Manul,

die Versionsinfo der TS Firmware fängt mit "VTS" statt "V" an.
Du warst offenbar nicht erfolgreich.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Manul am 07 Mai 2017, 16:19:36
Danke. Ich bin wie folgt vorgegangen:

[li]CULflash <CUL> CUL_V3 in fhem eingegeben
[/li][/list]

Allerdings scheine ich jetzt in /opt/fhem/FHEM/firmware/CUL_V3.hex eine neuere und größere Datei zu haben. Wo liegt mein Fehler?

Nebenbei: Wäre es nicht an der Zeit, der TSCUL-Firmware mal eine Seite im Wiki zu spendieren? Und die Firmware selbst vielleicht irgendwo außerhalb dieses Threads zu hosten? Es ist schon etwas mühsam, sich hier durch den Thread wühlen zu müssen. Bei einer Wiki-Seite helfe ich auch gerne mit.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 07 Mai 2017, 18:10:18
Hallo Manul,

Du hast anscheinend einen CUL V3!?!

CULflash geht nicht, da es aus dem Internet die aktuelle Standard Firmware runter lädt und diese dann flashed (wie es auch das Commandref beschreibt).

Die folgende Beschreibung gilt für einen Rapsberry Pi, also Linux.

Um den CUL V3 also mit der tsculfw zu flashen musst Du erst mal dfu-programmer installiert haben.

Dann muss der CUL V3 mittels dem Befehl "B01" in den Bootloader gestartet werden (mach ich in FHEM mit set raw beim CUL und FHEM kann normalerweise weiter laufen). Alternativ geht es auch mit Taste am CUL drücken und mit gedrückter Taste CUL in den USB Port stecken.

Dann in einem Terminal zum Verzeichnis der hex Datei wechseln und dann:
sudo dfu-programmer atmega32u4 erase
sudo dfu-programmer atmega32u4 flash TSCUL_V3.hex
sudo dfu-programmer atmega32u4 start


Dann sollte der CUL V3 mit TSCUL_V3.hex geflashed werden und neu booten.
Und diese Beschreibung gilt nur für CUL V3. Andere Typen benötigen einen anderen Programmer und ein anderes Vorgehen.

ZitatWäre es nicht an der Zeit, der TSCUL-Firmware mal eine Seite im Wiki zu spendieren?
Wenn Du Zeit dafür hast, gerne.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Manul am 07 Mai 2017, 18:26:14
Danke, ich hab in der Tat einen CUL_V3 an einem Raspi. Über die derzeit installierte culfw kann ich den doch auch in den Bootloader starten, oder?

Was soll hier:

sudo dfu-programmer atmega32u4 erase || true

das "|| true" bewirken?

Zitat von: noansi am 07 Mai 2017, 18:10:18
Wenn Du Zeit dafür hast, gerne.

So nach und nach werde ich die schon finden. Muß ja nicht alles sofort sein. Wo kann ich denn nachlesen, welche Probleme TSCUL behebt bzw. was die Motivation für deren Entwicklung war. Ich habe hier im Thread den Eindruck, daß das vorherige Problem als bekannt vorausgesetzt wird.

Und gibt es eigentlich einen Grund, warum die TS-features nicht in die "offizielle" culfw aufgenommen wurden?
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: rudolfkoenig am 07 Mai 2017, 18:30:35
ZitatUnd gibt es eigentlich einen Grund, warum die TS-features nicht in die "offizielle" culfw aufgenommen wurden?

Die Aenderungen waren/sind so umfangreich, dass ich das nicht alles verstanden habe bzw. testen konnte.
Weiterhin haben wir (Ansgar und ich) unterschiedliche Philosophien, wie man mit seltenen bzw. schwer reproduzierbaren Problemen umgeht.

Zusaetzlich habe ich die Motivation verloren culfw fuer HM zu optimieren, da ich das FHEM Modul nicht mehr betreue, und auch keine Geraete mehr im Betrieb habe.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 07 Mai 2017, 20:01:44
Hallo Manul,

ZitatÜber die derzeit installierte culfw kann ich den doch auch in den Bootloader starten, oder?
Ja, ebenfalls B01.

Zitatdas "|| true" bewirken?
Habe ich so stumpf aus dem makefile übernommen, da ich normalerweise über make auch flashe.
Vermutlich soll es bei einer Fehlermeldung diese bezüglich Rückgabe unterdrücken? Der Ersteller des ursprünglichen makefiles wird es wohl wissen.  ;)
Vermutlich kannst Du das || true wohl auch weglassen.

ZitatDie Aenderungen waren/sind so umfangreich, dass ich das nicht alles verstanden habe bzw. testen konnte.
War und ist eine tolle Ausgangsbasis für die Änderungen und Anpassungen.

Alle meine Bugs habe ich mangels Testhardware sicherlich auch noch nicht gefunden. So ist mir jüngst aufgefallen, dass SlowRF EM in der aktuellen Version noch nicht funktioniert. Wird in der nächsten Firmwareversion funktionieren.

ZitatWo kann ich denn nachlesen, welche Probleme TSCUL behebt bzw. was die Motivation für deren Entwicklung war.
In diversen Threads, hauptsächlich hier und bezüglich HM im Homematic Forum.

Ich habe mit HM, wie so viele, das Problem mit culfw gehabt, dass die Geräte bezüglich Empfangstiming von Antworten empfindlich sind. Das gesamte Protokoll wird nur mit einer einfachen CUL Warteschlange und FHEM Timer bezüglich Sendezeitpunkt abgearbeitet.
Daher habe ich zunächst versucht in 00_CUL.pm Verbesserungen zu erzielen. Das geht aber nur bis zu einem gewissen Grad, da FHEM strukturbedingt Timer nicht genau einhalten kann.

Daher bin ich auf den Gedanken gekommen, culfw mit Timing arbeiten zu lassen. Dazu habe ich die ASKSIN Befehle Aw und Aa ergänzt, mit denen auf CUL vor dem Senden gewartet werden kann (Aw) oder zu einem bestimmten Zeitpunkt gesendet werden kann (Aa).
Damit FHEM auch Sendezeitpunkte liefern kann habe ich das Schnitstellenprotokoll um zusätzliche Informationen ergänzt, insbesondere einen Zeitstempel (Timestamp) für Empfangsdaten und Sendequittungen. Damit läßt sich schon sehr viel bezüglich Timing erreichen, wenn FHEM nicht ab und zu mal so "richtig lang trödeln" würde.
Das stört dann doch insbesondere bei aktivem AES, da dabei Stellbefehle auch noch im passenden Timing signiert werden müssen.
Da Rudolf meine Änderungen nicht übernommen hat und damit auch der Grund für Flashspeicherschonende Programmierung entfallen ist (CUL_V2 muss es nicht mehr tun), habe ich im nächsten Schritt AES Signierungen ebenfalls auf CUL gebracht, was dann eine Nachrichtenwarteschlange auf dem CUL nötigt machte und somit auch noch mehr Sendetimingoptimierung durch CUL ermöglicht hat. Die befehle Aa und Aw sind damit eigentlich hinfällig und fliegen wohl auch mal wieder raus.
Damit gibt es nur noch den Schwachpunkt beim Antworttiming durch Antworten, die nur durch 10_CUL_HM.pm erfolgen können.

Zusätzlich hatte ich mit CUL_V3 das Problem des gelegentlichen "Verschwindens" von CUL_V3 als USB Device.
Dazu habe ich einige Änderungen an der USB Kommunikation in tsculfw eingebaut, die bei mir auch die Stabilität verbessert haben nebst Änderungen an DeviceIo.pm, um ein kurzzeitig abgemeldetet device wieder an die gleiche Schnittstelle zu bekommen.
Um CUL V3 immer an die gleiche Schnittstelle zu bekommen, was beim RasPi je nach Startart unterschiedlich sein kann, habe ich eine USB Seriennummer eingebaut.
Diese kann in der board.h vor dem compilieren angepasst werden. Für 868er CULs lautet sie
"868000" und für 433er CULs "433000".

Bei CUNO2 habe ich Stabilitätsverbesserungen an der Netzwerkschnittstelle einfließen lassen, was im Wesentlichen am Netzwerktreiber lag.

Bei SCC habe ich insbesondere die Stackingschnitstelle zu höheren devices im Stapel optimiert. Im "Original" wurden Nachrichten für das nächste device immer erst komplett empfangen und dann nach oben weiter gereicht. Das ist in tsculfw geändert in Weiterreichen ab dem ersten Zeichen, so dass die Sendezeit zum richtigen Stackmitglied drastisch verkürzt ist.
Da ich einen COC auf einem SCC betreibe und dieser COC HM macht dient das auch der HM Optimierung.

Zusätzlich gibt es Änderungen an SlowRF, da ich mit der Auswertung der Empfangsdaten nicht glücklich war. Das ist nur getestet, so weit ich auch Testhardware greifbar habe.
...

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Manul am 08 Mai 2017, 20:11:15
Noch eine Verständnisfrage zu AES: Wie interagieren die auf dem CUL gespeicherten Schlüssel mit denen in FHEM?
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 08 Mai 2017, 22:26:52
Hallo Manul,

ZitatWie interagieren die auf dem CUL gespeicherten Schlüssel mit denen in FHEM?
Das Verhalten ist analog zu HMLAN.
Du setzt den/die Schlüssel bei TSCUL (oder VCCU) via Attribut und dann werden sie von FHEM in TSCUL gesetzt.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Manul am 09 Mai 2017, 00:13:54
Danke! Das heißt also, der Umstieg von CUL auf TSCUL ist quasi vollständig transparent, sofern man eine VCCU nutzt? Ich muß mich nur um den Schlüssel der VCCU kümmern, den Rest erledigt FHEM?
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 09 Mai 2017, 06:40:27
Hallo Manul,

Zitatden Rest erledigt FHEM?

Die fhem.cfg musst Du schon noch anpacken, damit die TS Module genutzt werden.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Manul am 09 Mai 2017, 09:50:06
Hallo Ansgar,

Zitat von: noansi am 09 Mai 2017, 06:40:27
Die fhem.cfg musst Du schon noch anpacken, damit die TS Module genutzt werden.

Schon klar. Ich meinte lediglich in Bezug auf AES.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 09 Mai 2017, 20:22:51
Hallo Zusammen,

ein Hinweis im Bezug auf OTA Firmware Updates via FHEM.
Mit der aktuellen TSCUL und tsculfw klappt es leider nicht, da der Hochschaltbefehl auf 100kbits für CUL den Hochschaltfunkbefehl an das Device "überholt", so dass dieser fälschlicherweise mit 100kbits an das noch auf 10kbits lauschende device gesendet wird.

Das wird mit der nächsten TSCUL Version mit einer Wartezeit in TSCUL behoben.

Michael Gernoth aktuelles flash-ota Tool 0.03 aus hmcfgusb-0.103 kann alternativ ohne fhem genutzt werden, da es Anpassungen an tsculfw enthält und funktioniert.

Übergangsweise kann aber auch in 10_CUL_HM.pm die Wartezeit vor dem Hochschalten erhöht werden also:

sub CUL_HM_FWupdateSteps($){#steps for FW update
  my $mIn = shift;

...

    CUL_HM_SndCmd($hash,"${mNoA}00CB$id${dst}105B11F81547");
#    CUL_HM_SndCmd($hash,"${mNoA}20CB$id${dst}105B11F815470B081A1C191D1BC71C001DB221B623EA");
    select(undef, undef, undef, (0.04));
    CUL_HM_FWupdateSpeed($name,100);


ändern in

sub CUL_HM_FWupdateSteps($){#steps for FW update
  my $mIn = shift;

...

    CUL_HM_SndCmd($hash,"${mNoA}00CB$id${dst}105B11F81547");
#    CUL_HM_SndCmd($hash,"${mNoA}20CB$id${dst}105B11F815470B081A1C191D1BC71C001DB221B623EA");
    select(undef, undef, undef, (0.2)); # longer wait for tsculfw
    CUL_HM_FWupdateSpeed($name,100);


Dann sollte es klappen (wenn dann nicht zufälligerweise kurz zuvor noch Sendebefehle an andere devices in den tsculfw HM-Puffer geschoben wurden und noch abgearbeitet werden).

Außerdem wichtig, es müssen vor einem OTA Updateversuch die verfügbaren credits10ms abgefragt werden. Nur wenn die nahezu auf 1800 "aufgeladen" sind, steht genug Sendezeit für ein OTA Update zur Verfügung.
In 10_CUL_HM wird das derzeit nicht abgefragt, wohl aber von Michaels flash-ota Tool 0.03.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 14 Mai 2017, 11:42:09
Hallo Testwillige,

hier eine neue Version der Timestamp Firmware und der dazu benötigten FHEM Module.

Im Anhang ist in TSCUL_fwcode_00_08_FHEM_Modules_00_08.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 tsculfw Firmware kann nicht mit FHEM geflashed werden, sondern muss mit dem jeweiligen Flash Programmer geflashed werden.
So z.B. https://forum.fhem.de/index.php/topic,24436.msg631743.html#msg631743 (https://forum.fhem.de/index.php/topic,24436.msg631743.html#msg631743) kann es mit einem USB CUL Stick gehen.

Wichtig für SCC Nutzer. TSSTACKED ist entfallen und wird nicht mehr unterstützt.
Statt dessen gibt es das neue Modul STACKABLETS (als Abwandlung von Rudolfs STACKABLE).
Dieses wird sozusagen zwischen die Stackteilnehmer eingebaut.

Beispiel für fhem.cfg:
#erstes SCC Modul als Basis
define SCC_WS868 TSCUL /dev/ttyAMA0@38400 0000
attr SCC_WS868 event-on-change-reading Ints_per_sec,IntCalcStat,MatchStat
attr SCC_WS868 rfmode SlowRF
attr SCC_WS868 room Receiver
attr SCC_WS868 sendpool CUL_HM868,SCC_WS868
attr SCC_WS868 verbose 1

#neues STACKABLETS virtuelles IO device
define STACK_1 STACKABLETS SCC_WS868
attr STACK_1 verbose 1

#zweites SCC Modul
define SCC_HM868 TSCUL FHEM:DEVIO:STACK_1:38400 1034
attr SCC_HM868 event-on-change-reading cond
attr SCC_HM868 hmId F11034
attr SCC_HM868 hmLanQlen 3_normal
attr SCC_HM868 rfmode HomeMatic
attr SCC_HM868 room Receiver
attr SCC_HM868 sendpool CUL_HM868,SCC_WS868
attr SCC_HM868 verbose 1


Ergänzender Hinweis zu USB CULs: 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_08\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 1234
bzw.
define CUL_433 TSCUL /dev/CUL433_0@12000000 0000
definiert 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 Zip Datei sind ebenfalls die ergänzten Module zu finden, die zur Nutzung der Firmware erforderlich sind.

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_STACKABLETS.pm -> statt der 16_STACKABLE.pm, aus STACKABLE werden damit STACKABLETS devices in der fhem.cfg (händisch anzupassen)

10_UNIRoll_TS.pm  -> statt der 10_UNIRoll.pm, mit TSCUL 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 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 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 IO-devices zu verwenden, aus CUL_WS wird dann TSCUL_WS  in der fhem.cfg (händisch anzupassen)
15_TSCUL_EM.pm   -> statt der 15_CUL_EM.pm, mit TSCUL IO-devices zu verwenden, aus CUL_EM wird dann TSCUL_EM  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.


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_STACKABLETS.pm DevIoTS.pm CUL_Util.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.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` }

Der letzte Hinweis zum Problem beim OTA Firmware Update ist damit auch weitgehend entschärft, wie angekündigt.

Das Sendetiming zu devices ist in der Firmware etwas geändert, ich hoffe zum Besseren.

Noch ein Hinweis: TSCUL fragt auch die Firmwareversion der tsculfw auf 0.08 ab. Eine ältere Version wird also nicht unterstützt, so dass mit dem Austausch der FHEM Module auch ein Firmwareupdate des CUL devices erforderlich ist.

Gruß, Ansgar.

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

EDIT: update auf 0.08, Firmware Bug bei MsgCnt Reihenfolge behoben, Timing für FUP (OTA-Update) verbessert
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 17 Mai 2017, 01:21:23
Hallo Testwillige,

im letzten Eintrag habe ich ein Update auf Version 0.08 eingepflegt, weil mir ein älterer Bug bezüglich Messagecounter in der Firmware aufgefallen ist. Insbesondere beim OTA-Firmwareupdate bei HM Devices konnte das zu unnötigen Übertragungswiederholungen führen.
Außerdem eine Timinganpassung für das OTA-Update.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 26 Mai 2017, 21:49:19
Hallo Testwillige,

hier eine neue Version der Timestamp Firmware und der dazu benötigten FHEM Module.

Im Anhang ist in TSCUL_fwcode_00_09_FHEM_Modules_00_09.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 tsculfw Firmware kann für TSCUL_V3 mit FHEM mit dem modifizierten CULflash geflashed werden. Die anderen müssen mit dem jeweiligen Flash Programmer geflashed werden.
So z.B. https://forum.fhem.de/index.php/topic,24436.msg631743.html#msg631743 kann es mit einem USB CUL Stick gehen, wenn man nicht CULflash verwendet.

Es gibt nicht den Luxus des Downloads beim modifizierten CULflash, sondern die Firmware muss händisch in den FHEM/firmware Ordner kopiert werden. Der Typ ist dann TSCUL_V3.
Beispiel:
CULflash MeinCulDevice TSCUL_V3

Wichtig für SCC Nutzer. TSSTACKED ist entfallen und wird nicht mehr unterstützt.
Statt dessen gibt es das neue Modul STACKABLETS (als Abwandlung von Rudolfs STACKABLE).
Dieses wird sozusagen zwischen die Stackteilnehmer eingebaut.

Beispiel für fhem.cfg:
#erstes SCC Modul als Basis
define SCC_WS868 TSCUL /dev/ttyAMA0@38400 0000
attr SCC_WS868 event-on-change-reading Ints_per_sec,IntCalcStat,MatchStat
attr SCC_WS868 rfmode SlowRF
attr SCC_WS868 room Receiver
attr SCC_WS868 sendpool CUL_HM868,SCC_WS868
attr SCC_WS868 verbose 1

#neues STACKABLETS virtuelles IO device
define STACK_1 STACKABLETS SCC_WS868
attr STACK_1 verbose 1

#zweites SCC Modul
define SCC_HM868 TSCUL FHEM:DEVIO:STACK_1:38400 1034
attr SCC_HM868 event-on-change-reading cond
attr SCC_HM868 hmId F11034


Ergänzender Hinweis zu USB CULs: 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_08\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 1234
bzw.
define CUL_433 TSCUL /dev/CUL433_0@12000000 0000
definiert 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 Zip Datei sind ebenfalls die ergänzten Module zu finden, die zur Nutzung der Firmware erforderlich sind.

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_STACKABLETS.pm -> statt der 16_STACKABLE.pm, aus STACKABLE werden damit STACKABLETS devices in der fhem.cfg (händisch anzupassen)

10_UNIRoll_TS.pm  -> statt der 10_UNIRoll.pm, mit TSCUL 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 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 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 IO-devices zu verwenden, aus CUL_WS wird dann TSCUL_WS  in der fhem.cfg (händisch anzupassen)
15_TSCUL_EM.pm   -> statt der 15_CUL_EM.pm, mit TSCUL IO-devices zu verwenden, aus CUL_EM wird dann TSCUL_EM  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.

Außerdem:

10_CUL_HM.pm         -> verlängertes Wiederholtiming als Anpassung für TSCUL/tsculfw. Ich bitte auch um Feedback, wie es mit HMLAN läuft.
98_CULflash.pm         -> Ergänzt um Flash von TSCUL_V3 mit Datei in FHEM/firmware

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 98_CULflash.pm 10_CUL_HM.pm 00_TSCUL.pm 16_STACKABLETS.pm DevIoTS.pm CUL_Util.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.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` }

Das Sendetiming zu devices ist in der Firmware etwas geändert, ich hoffe zum Besseren.

Noch ein Hinweis: TSCUL fragt auch die Firmwareversion der tsculfw auf 0.09 ab. Eine ältere Version wird also nicht unterstützt, da sich diesmal auch das Timestamp Protokoll etwas (aber inkompatibel zum vorherigen Stand) geändert hat, so dass mit dem Austausch der FHEM Module auch ein Firmwareupdate des CUL devices erforderlich ist!

Gruß, Ansgar.

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

EDIT: auf TSCUL_fwcode_00_09_FHEM_Modules_00_09c.zip aktualisiert. Darin 00_TSCUL.pm und DevIoTS.pm aktualisiert. Besseres Hochlaufverhalten durch ping-verzögerte HM Sendefreigabe.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 28 Mai 2017, 01:44:02
Hallo Testwillige,

hier eine neue Version der Timestamp Firmware und der dazu benötigten FHEM Module.

Neu ist diesmal ein Throttle Mechanismus für von TSCUL für CUL_HM bei hoher Systemlast und damit einhergehender langer Sendeverzögerung an CUL. Diese lange Sendeverzögerung macht Probleme in der HM Kommunikation, so z.B. beim Systemstart, mit vielen vergeblichen Sendeversuchen, wenn CUL_HM nicht gebremst wird.
In Anlehnung an HMLAN ist das Attribut "respTime" hinzu gekommen. Allerdings ist es die Zeit, die maximal vergehen darf, bis ein "Echo" für ASKSIN Sendenachrichten ankommt, sonst setzt das Throtteling über XmitOpen ein und wird beendet, wenn die Antwortzeit von Test Pings wieder unter die Hälfte von "respTime" gefallen ist. 0,5 Sekunden sind im Code hinterlegt. Weniger als 0,1 Sekunden und mehr als 1 Sekunde macht sicherlich keinen Sinn einzustellen.

Im Anhang ist in TSCUL_fwcode_00_10_FHEM_Modules_00_11.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 tsculfw Firmware kann für TSCUL_V3 mit FHEM mit dem TSCULflash geflashed werden. Die anderen müssen mit dem jeweiligen Flash Programmer geflashed werden.
So z.B. https://forum.fhem.de/index.php/topic,24436.msg631743.html#msg631743 kann es mit einem USB CUL Stick gehen, wenn man nicht TSCULflash verwendet.

Es gibt nicht den Luxus des Downloads beim TSCULflash, sondern die Firmware muss händisch in den FHEM/firmware Ordner kopiert werden. Der Typ ist dann TSCUL_V3.
Beispiel:
TSCULflash MeinCulDevice TSCUL_V3

Wichtig für SCC Nutzer. TSSTACKED ist entfallen und wird nicht mehr unterstützt.
Statt dessen gibt es das neue Modul STACKABLETS (als Abwandlung von Rudolfs STACKABLE).
Dieses wird sozusagen zwischen die Stackteilnehmer eingebaut.

Beispiel für fhem.cfg:
#erstes SCC Modul als Basis
define SCC_WS868 TSCUL /dev/ttyAMA0@38400 0000
attr SCC_WS868 event-on-change-reading Ints_per_sec,IntCalcStat,MatchStat
attr SCC_WS868 rfmode SlowRF
attr SCC_WS868 room Receiver
attr SCC_WS868 sendpool CUL_HM868,SCC_WS868
attr SCC_WS868 verbose 1

#neues STACKABLETS virtuelles IO device
define STACK_1 STACKABLETS SCC_WS868
attr STACK_1 verbose 1

#zweites SCC Modul
define SCC_HM868 TSCUL FHEM:DEVIO:STACK_1:38400 1034
attr SCC_HM868 event-on-change-reading cond
attr SCC_HM868 hmId F11034


Ergänzender Hinweis zu USB CULs: 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_08\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 1234
bzw.
define CUL_433 TSCUL /dev/CUL433_0@12000000 0000
definiert 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 Zip Datei sind ebenfalls die ergänzten Module zu finden, die zur Nutzung der Firmware erforderlich sind.

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_STACKABLETS.pm -> statt der 16_STACKABLE.pm, aus STACKABLE werden damit STACKABLETS devices in der fhem.cfg (händisch anzupassen)

10_UNIRoll_TS.pm  -> statt der 10_UNIRoll.pm, mit TSCUL 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 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 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 IO-devices zu verwenden, aus CUL_WS wird dann TSCUL_WS  in der fhem.cfg (händisch anzupassen)
15_TSCUL_EM.pm   -> statt der 15_CUL_EM.pm, mit TSCUL IO-devices zu verwenden, aus CUL_EM wird dann TSCUL_EM  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.

Außerdem:

10_CUL_HM.pm         -> verlängertes Wiederholtiming als Anpassung für TSCUL/tsculfw. Ich bitte auch um Feedback, wie es mit HMLAN läuft.
98_TSCULflash.pm         -> Zum Flash von TSCUL_V3 mit Datei in FHEM/firmware

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_STACKABLETS.pm DevIoTS.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.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` }

Noch ein Hinweis: TSCUL fragt auch die Firmwareversion der tsculfw auf 0.10 ab. Eine ältere Version wird also nicht unterstützt, da sich diesmal auch das Timestamp Protokoll etwas (aber inkompatibel zum vorherigen Stand) geändert hat, so dass mit dem Austausch der FHEM Module auch ein Firmwareupdate des CUL devices erforderlich ist!

Gruß, Ansgar.

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

EDIT: 10_CUL_HM.pm muss nicht mehr ausgetauscht werden, da Martin meine wesentliche Änderung übernommen hat. Ich lasse es aber noch drin, falls er das nochmal Rückgängig macht, wenn es damit mit anderen HM-IOs zu Problemen kommen sollte.

EDIT: TSCULflash ersetzt CULflash zum Flashen der tsculfw auf USB CULs. CUL_Util.pm ist entfallen, da es nicht seinem eigentlichen Zweck dienen konnte. Module sind nun wieder unabhängig von anderen Modulen von FHEM.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 28 Mai 2017, 01:51:45
Hallo Ansgar,

du schläfst wohl auch nie ;)

Ich hab zwar schon länger keine Probleme mehr: Danke!!

Aber ich werd bei Gelegenheit mal die neue FW (bauen und) flashen und die neuen Module einspielen.

Leider werde ich wohl keine deiner erwarteten Feedbacks liefern können...
...höchstens, dass es immer noch ohne Probleme läuft...

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 28 Mai 2017, 02:07:58
Hallo Joachim,

danke für das Feedback, wenn auch zum alten Stand.

ZitatIch hab zwar schon länger keine Probleme mehr
Wenn Du noch auf einem historischen Stand bist, dann kennst Du sie eventuell nur noch nicht.   ::)
Z.B. OTA-Firmware Update von HM Devices klappt vor 0.08 nicht über FHEM.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 28 Mai 2017, 02:13:02
Zitat von: noansi am 28 Mai 2017, 02:07:58
Hallo Joachim,

danke für das Feedback, wenn auch zum alten Stand.
Wenn Du noch auf einem historischen Stand bist, dann kennst Du sie eventuell nur noch nicht.   ::)
Z.B. OTA-Firmware Update von HM Devices klappt vor 0.08 nicht über FHEM.

Gruß, Ansgar.

Hallo Ansgar,

bitte gerne!

Hmm, das kann sein.
Es ist ja auch immer noch "nur" mein Testsystem ;)

Aber ich kann ja "spasseshalber" mal das mit dem FW-Update probieren (mal sehen, ob ich noch ein HM-Gerät am Testsystem hab was noch ein Update vertragen kann oder wo ich 2 FW-Stände zum hin und her spielen hab)...

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 28 Mai 2017, 02:55:54
Hallo Joachim,

Zitatoder wo ich 2 FW-Stände zum hin und her spielen hab)...

Mußt Du nicht, Du kannst auch den gleichen Stand nochmal Senden. Bei Kommunikationsfehlern meckert FHEM...

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: MadMax-FHEM am 15 Juni 2017, 00:26:16
Hallo Ansgar,

so endlich! Sorry!!

Hatte viel zu tun und noch so einige andere "Baustellen" ;)

Aber jetzt habe ich die neue FW eingespielt (habe sie mal mit meiner bestehenden board.h selber compiliert, hat ja immer gut funktioniert / evtl. spiele ich die vorcompilierte FW auch mal ein...) und auch die Module kopiert.

FW-Update klappt prima!

Bin nur beim Hin-und-her-einspielen in die "1%-Falle" getappt... ;)

Wenn ich was testen kann oder du irgendwelche Infos brauchst einfach Bescheid sagen...

Ansonsten läuft auch diese Version prima!

EDIT: zu früh gefreut... Nein kein Problem mit der FW etc. aber ich hab "natürlich" TSCUL_fwcode_00_09_FHEM_Modules_00_10 ausprobiert. Du hast aber mittlerweile TSCUL_fwcode_00_10_FHEM_Modules_00_11 hier eingestellt... Da werde ich wohl dann demnächst noch mal dran gehen... ;)

EDIT2: so, doch schon mal compiliert und eingespielt ;) Läuft immer noch prima! ;) Also einen FW-Update habe ich jetzt noch nicht noch mal gemacht ;) Wenn ich was testen kann etc. einfach Bescheid geben...

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: kaihs am 25 Juli 2017, 20:52:32
Hallo Ansgar,

ich habe jetzt endlich auch mal deine TSculfw auf dem rpiAddOn-Board zum Einsatz gebracht.
Lässt sich ohne Änderungen compilieren und flashen und funktioniert auch.

Ein Problem gibt es aber noch mit dem TSCUL Modul:

2017.07.25 20:20:58 1: CUL_0 is VERSION_TS, VTS 0.10 RPIAddOn_CSM
2017.07.25 20:20:59 1: define IR_Dev CUL_IR CUL_0: Wrong IODev specified or IODev doesn't support CUL_IR


Das Board hat auch einen IR-Empfänger und -Sender, unterstützt durch das CUL_IR Modul.
Das original CUL Modul unterstützt das auch, bei deinem ist das wohl nicht (mehr) enthalten.
Kannst du das noch mit geringem Aufwand einbauen?
Wenn nicht, muss ich es mal selbst versuchen.

Unabhängig von deiner Firmware habe ich mit einem meiner Boards noch ein spezielles Problem (https://forum.fhem.de/index.php/topic,74574.msg663403.html#msg663403).
Das sendet nicht mehr, mit der original culfw stürzt es beim Senden einfach ab.
Bei deiner zwar nicht, aber es wird wohl nicht gesendet. Das andere Board empfängt nichts, Aktoren reagieren nicht. Der Empfang funktioniert dagegen problemlos.
Hast du eine Idee woran das liegen könnte oder was man da noch debuggen könnte?

Gruß,

Kai
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 25 Juli 2017, 22:25:27
Hallo Kai,

ZitatDas Board hat auch einen IR-Empfänger und -Sender, unterstützt durch das CUL_IR Modul.
Das original CUL Modul unterstützt das auch, bei deinem ist das wohl nicht (mehr) enthalten.
Kannst du das noch mit geringem Aufwand einbauen?

Das Problem liegt Modulseits eher in 10_CUL_IR.pm Zeile 64
    if((defined($cl) && $cl =~ m/:CUL_IR:/) &&


Mit TSCUL passt der match nur für SlowRF. Homematic ist CUL_IR bei den clients in $clientsHomeMatic (und ggf. $clientsMAX und $clientsWMBus) am Ende ohne abschließenden ':' in TSCUL, was mAn sonst unnötig Rechenzeit kostet.

Du kannst entweder in TSCUL noch einen ':' am Ende ergänzen oder obigen match in CUL_IR vom zweiten : befreien respektive besser auch auf CUL_IR ohne : aber Ende testen lassen.

IR (und rpiAddOn) habe ich aber bisher nicht testen können und von daher kann ich nicht versprechen, dass die Firmware dazu nicht noch Unschärfen enthält.

ZitatHast du eine Idee woran das liegen könnte oder was man da noch debuggen könnte?
Wie Rudi schon im anderen Thread von Dir meinte, kann es an CCA scheitern, wenn das Board zu viel Störsignale/-rauschen empfängt. Meine SCCs und COC nutze ich mit abgesetzter Antenne, um Störungen durch den Pi zu vermeiden. Andere Geräte in der Nähe können auch stören. Und ein Dauerstörsender auf dem Kanal kann auch zu CCA Problen führen (hatte ich mal mit einem S200 Sensor, dessen Batterien zu Ende gingen und der mit aktivem Sender bis zum Batterieende den Kanal belegte).
Was steht denn im log, wenn Du für das board verbose 4 aktivierst und einen Sendeversuch startest? In den Timestamps wird ein CCA Sendefehler gemeldet. Also AFFx4... statt AFFx3... bei "erfolgreichem" Versand.

Natürlich könnte auch der cc1101 gelitten haben, sprich der Sendetreiber defekt sein, das wäre schade.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: kaihs am 27 Juli 2017, 20:05:33
Zitat von: noansi am 25 Juli 2017, 22:25:27
Hallo Kai,

Das Problem liegt Modulseits eher in 10_CUL_IR.pm Zeile 64
    if((defined($cl) && $cl =~ m/:CUL_IR:/) &&


Mit TSCUL passt der match nur für SlowRF. Homematic ist CUL_IR bei den clients in $clientsHomeMatic (und ggf. $clientsMAX und $clientsWMBus) am Ende ohne abschließenden ':' in TSCUL, was mAn sonst unnötig Rechenzeit kostet.

Du kannst entweder in TSCUL noch einen ':' am Ende ergänzen oder obigen match in CUL_IR vom zweiten : befreien respektive besser auch auf CUL_IR ohne : aber Ende testen lassen.

Danke für die Analyse.
Ich habe 10_CUL_IR.pm etwas anders geändert:

     if (defined($cl)) {
        my @clients = split /:/, $cl;
       
    if(grep(/^CUL_IR$/, @clients) &&
       $defs{$p}{NAME} eq $a[2]) {   
          $hash->{IODev} = $defs{$p};
          last; 
        }
    }

Das ist m. E. noch etwas robuster, so kann CUL_IR an beliebiger Stelle in der Clientliste stehen.
Werde ich mal als Patch mit der Bitte um Übernahme ins passende Forums stellen.

Zitat
Was steht denn im log, wenn Du für das board verbose 4 aktivierst und einen Sendeversuch startest? In den Timestamps wird ein CCA Sendefehler gemeldet. Also AFFx4... statt AFFx3... bei "erfolgreichem" Versand.


2017.07.27 19:58:42 4: TSCUL_send:  CUL_0                         As 0C 7C A011 F11034 52B558 0201C8
2017.07.27 19:58:42 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:90 rtoms:1761
2017.07.27 19:58:43 1: TSCUL_ParseTsHM: CUL_0 CCA channel busy error to 52B558/az_Rollo:  221509 A F004 07189076 00 0C 7C A011 F11034 52B558 02 _sfail
2017.07.27 19:58:44 4: TSCUL_XmitAwaitTo CUL_0: timeout - 52B558
2017.07.27 19:58:44 1: TSCUL_ParseTsHM: CUL_0 CCA channel busy error to 52B558/az_Rollo:  222745 A F004 07190332 00 0C 7C A011 F11034 52B558 02 _sfail
2017.07.27 19:58:45 1: TSCUL_ParseTsHM: CUL_0 CCA channel busy error to 52B558/az_Rollo:  223981 A F004 07191588 00 0C 7C A011 F11034 52B558 02 _sfail
2017.07.27 19:58:45 1: TSCUL_ParseTsHM: CUL_0 HM repeat failed to 52B558/az_Rollo:  224212 A F009 07192844 00 0C 7C A011 F11034 52B558 02 _sfail


Tatsächlich CCA.
Fragt sich nur warum. Ich werde das Board jetzt mal auf einem anderen Hostrechner testen. Mglw. strahl der BananaPi jetzt mehr Störungen aus.

Vielen Dank nochmal für deine Unterstützung!
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: kaihs am 27 Juli 2017, 21:01:45
Ich habe die Boards jetzt getauscht.
Auf dem Bananapi läuft das bisher funktionierende Board, auf dem RPi läuft das 'kaputte' auch weiterhin nicht.
Sieht tatsächlich nach einem Hardwaredefekt aus :-(

Allerdings kommen von dem kaputten Board auf dem RPi andere Fehler:

2017.07.27 20:57:10 4: TSCUL_send:  CUL_rpi                         As 0A F4 8002 F11034 52B558 00
2017.07.27 20:57:10 4: TSCUL_XmitDlyHM:  CUL_rpi  id:52B558 toms:96
2017.07.27 20:57:10 4: TSCUL_Parse: CUL_rpi  058513 A F103 02343000 01 0A F4 8002 F11034 52B558 00 _CCAdly:4 -138
2017.07.27 20:57:12 4: TSCUL_send:  CUL_rpi                         As 10 F4 A001 F11034 52B558 010452B5580103
2017.07.27 20:57:12 4: TSCUL_XmitDlyHM:  CUL_rpi  id:52B558 toms:101 rtoms:1746
2017.07.27 20:57:12 4: TSCUL_Parse: CUL_rpi  061188 A F103 02345700 01 10 F4 A001 F11034 52B558 01 _CCAdly:4 -138
2017.07.27 20:57:13 4: TSCUL_Parse: CUL_rpi  061324 A F101 02345868 00 1A F4 A010 52B558 F11034 0301000000326400FF00FF014454630000 -42
2017.07.27 20:57:13 4: TSCUL_Parse: CUL_rpi  061620 A F101 02346168 00 1A F4 A010 52B558 F11034 0301000000326400FF00FF014454630000 -41.5
2017.07.27 20:57:13 4: TSCUL_Parse: CUL_rpi  062018 A F101 02346572 00 1A F4 A010 52B558 F11034 0301000000326400FF00FF014454630000 -41.5
2017.07.27 20:57:14 4: TSCUL_XmitAwaitTo CUL_rpi: timeout - 52B558
2017.07.27 20:57:14 4: TSCUL_send:  CUL_rpi                         As 0A F4 8002 F11034 52B558 00
2017.07.27 20:57:14 4: TSCUL_XmitDlyHM:  CUL_rpi  id:52B558 toms:96
2017.07.27 20:57:14 4: TSCUL_Parse: CUL_rpi  063137 A F103 02347692 01 0A F4 8002 F11034 52B558 00 _CCAdly:4 -138
2017.07.27 20:57:25 4: TSCUL_Parse: CUL_rpi  073875 A F102 02358612 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2017.07.27 20:57:47 4: TSCUL_Parse: CUL_rpi  095650 A F102 02380688 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2017.07.27 20:58:13 4: TSCUL_Parse: CUL_rpi  122099 A F102 02407528 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2017.07.27 20:58:47 4: TSCUL_Parse: CUL_rpi  155901 A F002 02441832 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138


Das Device CUL_rpi ist per ser2net an FHEM angebunden. Am Schluss geht der State des angesprochnen Homematic Devices dann auf IOErr.
Kannst du mir diese Meldungen noch erläutern?
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 27 Juli 2017, 23:51:06
Hallo Kai,

CCA ist eindeitig nicht das Problem, ebenso wenig, wie credits, denn die Sendequittungen kommen im Log (Fxx3), wie es sein soll.
2017.07.27 20:57:12 4: TSCUL_Parse: CUL_rpi  061188 A F103 02345700 01 10 F4 A001 F11034 52B558 01 _CCAdly:4 -138

D.h. das board sendet einfach nichts raus, vermutlich ist leider der cc1101 defekt. Oder mit ein bischen Glück nur die Spannungsversorgung für den cc1101 nicht ausreichend.

Auf
2017.07.27 20:57:12 4: TSCUL_send:  CUL_rpi                         As 10 F4 A001 F11034 52B558 010452B5580103
kommt nicht die erwartete Antwort mit passender Message Number 10 und daher gibt es
2017.07.27 20:57:14 4: TSCUL_XmitAwaitTo CUL_rpi: timeout - 52B558

Das device wird dagegen zwar bestens mit -42dB empfangen, es sendet aber nicht die gewünschte Antwort (weil es die Sendenachricht vom board wohl nicht empfängt).

Quatsch wegen Tomaten auf den Augen, siehe unten.

2017.07.27 20:57:25 4: TSCUL_Parse: CUL_rpi  073875 A F102 02358612 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
sind nur ping Antworten, mit denen ich die Datenübertragungsrate FHEM->CUL zu messen versuche.

Das board kannst Du so wohl nur noch als Empfänger für SlowRF nutzen, wenn Du entsprechende Sensoren hast.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: kaihs am 30 Juli 2017, 12:54:52
Das ist alles sehr merkwürdig. Jetzt hat sich nämlich das Verhalten der beiden Boards vertauscht.
CUL_0 sendet jetzt wieder, CUL_rpi dafür nicht mehr.

Aber ich will diesen Thread damit nicht weiter stören, hat ja nicht direkt etwas mit deiner Firmware zu tun.

Allerdings gibt es noch einen weiteren Punkt der wohl mit deinem 00_CULTS.pm zu tun hat.
Das Board hat auch eine Onewire Schnittstelle. An diese habe ich DS18B20 Temperatursensoren angeschlossen.
Diese betreibe ich im HMS-Emulationsmodus (culfw Kommando OHo (http://culfw.de/commandref.html#cmd_O)).

Die Code dafür ist aber in 00_CULTS.pm/TSCUL_Parse auskommentiert:

elsif ($fn eq "H" && $len >= 13) {              # Reformat for 12_HMS.pm
   my $type = hex(substr(${$prmsg},6,1));
   my $stat = $type > 1 ? hex(substr(${$prmsg},7,2)) : hex(substr(${$prmsg},5,2));
   my $prf  = $type > 1 ? "02" : "05";
   my $bat  = $type > 1 ? hex(substr(${$prmsg},5,1))+1 : 1;
   my $hc = substr(${$prmsg},1,4);
   my $values = $type > 1 ?  "000000" : substr(${$prmsg},7);
   ${$prmsg} = sprintf("81%02x04xx%s%x%xa001%s0000%02x%s",
                     $len/2+8,            # Packet-Length
                     $prf, $bat, $type,
                     $hc,                 # House-Code
                     $stat,
                     $values);            # Values
   ${$prmsg} = lc(${$prmsg});
}


Ich habe es bei mir wieder rein genommen, funktioniert.
Kannst du das evtl. in deine offizielle Version übernehmen?
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 30 Juli 2017, 16:35:37
Hallo Kai,

ZitatDas ist alles sehr merkwürdig. Jetzt hat sich nämlich das Verhalten der beiden Boards vertauscht.
CUL_0 sendet jetzt wieder, CUL_rpi dafür nicht mehr.

???

Allerdings fällt mit gerade auf, dass ich dusselig message Länge (10) und message Nummer (F4) in Deinem Protokoll verwechselt habe, sorry, Tomaten auf den Augen.
EDIT: Und ich hatte Deinen Post davor bzgl. CCA gar nicht gesehen.
Vom device kommt also was mit richtiger Nummer. Allerdings 3 mal, d.h. die Antwort (ACK As 0A F4 8002 F11034 52B558 00) kommt wohl zu spät beim device an. Das wäre ggf. ein Signallaufzeitproblem, möglicherweise aus Deiner mehrstufigen IO Anbindung.

Dann müsste
2017.07.27 20:57:14 4: TSCUL_XmitAwaitTo CUL_rpi: timeout - 52B558
in TSCUL an der Behandlung von Warten auf Antworten gelegen haben, sprich die Antworten zu spät bei FHEM eingegangen sein.

Die ACKs kommen von FHEM und müssen schnell genug beim Device ankommen.
Deswegen habe ich schon bei SCC die serielle Übertragung optimiert um in einem SCC Stapel noch schnell genug Antworten senden zu können.

Der zweite ACK auf die 3 Wiederholungen wird erst 1120ms  nach Empfang der letzten Wiederholung gesendet, das kannst Du an der 8-stelligen Timestamp sehen, die in ms im Log steht (02347692-02346572). Das ist fast Faktor 10 zu langsam!
Eventuell würde dann ein HMLAN helfen, wenn es auf die messages selbst ein ACK sendet.
Auto ACKs kann ich nicht einbauen, mangels Speicher für gepairte devices.

Hat das mit ser2net und HM denn jemals funktioniert?

ZitatIch habe es bei mir wieder rein genommen, funktioniert.
Kannst du das evtl. in deine offizielle Version übernehmen?
Wenn Du ausgiebig testest.  :)

Ich hatte mal alles, was ich mangels Hardware nicht testet kann oder kein anderer testet aus TSCUL raus genommen, um unerwünschte Nebeneffekte zu vermeiden.

Ob die gleichzeitige Nutzung von Onewire bei Deinem anderen Problem stört, kann ich nicht sagen. Eventuell bringt verbose 5 statt 4 noch mehr ans Licht.

Schalt in der fhem.cfg auch mal
Zitatattr global mseclog 1
aktiv, damit das Logging ms mit einschließt.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: kaihs am 30 Juli 2017, 17:42:37
Zitat von: noansi am 30 Juli 2017, 16:35:37
Hat das mit ser2net und HM denn jemals funktioniert?

Ja, das hat mit der original culfw funktioniert, mehr als ein Jahr lang. Dann kam es zu dem Sendeproblem mit dem einen CUL und im Zuge der Fehleranalyse habe ich dann deine Firmware installiert. Hatte ich aber sowieso schon länger vor.

Aktuell ist der Stand mal wieder so, dass nur noch der per ser2net angebundene CUL_rpi sendet.

Nochmal die Beschreibung des aktuellen Aufbaus:
Zwei rpiaddons:
CUL_0 direkt an dem Rechner angeschlossen auf dem die Haupt FHEM Instanz läuft, sendet aktuell nicht
CUL_rpi über eine WLAN Verbindung per ser2net angebunden
vccu mit IOList     CUL_rpi,CUL_0

Hier mal das Log wenn ich damit einen Rolladenaktor anspreche. Nach kurzer Verzögerung reagiert der Aktor, es gibt auch kein MISSING_ACK oder einen anderen Fehler in FHEM:

2017.07.30 17:22:09.766 4: TSCUL_send:  CUL_rpi                         As 0C 15 A011 F11034 52B558 02018E
2017.07.30 17:22:09.767 4: TSCUL_XmitDlyHM:  CUL_rpi  id:52B558 toms:98 rtoms:1746
2017.07.30 17:22:09.890 4: TSCUL_Parse: CUL_0  467027 A F001 11049748 00 0C 15 A011 F11034 52B558 02018E -85
2017.07.30 17:22:09.924 4: TSCUL_Parse: CUL_rpi  467074 A F103 03382552 01 0C 15 A011 F11034 52B558 02 _CCAdly:4 -138
2017.07.30 17:22:09.950 4: TSCUL_Parse: CUL_0  467088 A F001 11049876 00 0E 15 8002 52B558 F11034 0101811044 -55.5
2017.07.30 17:22:10.096 4: TSCUL_Parse: CUL_0  467235 A F001 11050024 00 0C 15 A011 F11034 52B558 02018E -85.5
2017.07.30 17:22:10.101 4: CUL_HM vccu dupe: dont process
2017.07.30 17:22:10.220 4: TSCUL_Parse: CUL_0  467358 A F001 11050152 00 0E 15 8002 52B558 F11034 0101821040 -56.5
2017.07.30 17:22:10.739 4: TSCUL_Parse: CUL_rpi  467889 A F103 03382820 01 0C 15 A011 F11034 52B558 02 _CCAdly:4 -138
2017.07.30 17:22:10.747 4: TSCUL_Parse: CUL_rpi  467898 A F101 03382968 00 0E 15 8002 52B558 F11034 0101821040 -66
2017.07.30 17:22:11.520 4: TSCUL_XmitAwaitTo CUL_rpi: timeout - 52B558
2017.07.30 17:22:18.748 4: TSCUL_Parse: CUL_rpi  475897 A F001 03391360 00 0D 16 A410 52B558 F11034 06018E00 -70
2017.07.30 17:22:18.764 4: TSCUL_send:  CUL_rpi                         As 0A 16 8002 F11034 52B558 00
2017.07.30 17:22:18.766 4: TSCUL_XmitDlyHM:  CUL_rpi  id:52B558 toms:96
2017.07.30 17:22:18.960 4: TSCUL_Parse: CUL_rpi  476111 A F103 03391480 01 0A 16 8002 F11034 52B558 00 _CCAdly:4 _dhmSt:120 -138
2017.07.30 17:22:18.967 4: TSCUL_Parse: CUL_0  476107 A F001 11058968 00 0A 16 8002 F11034 52B558 00 -85.5


Ein anderes Rollo, näher an CUL_0, daher wird der wohl als Sender gewählt, Aktor reagiert nicht:

2017.07.30 17:29:37.056 4: TSCUL_send:  CUL_0                         As 0C 66 A011 F11034 52A533 0201B4
2017.07.30 17:29:37.058 4: TSCUL_XmitDlyHM:  CUL_0  id:52A533 toms:90 rtoms:1761
2017.07.30 17:29:38.086 1: TSCUL_ParseTsHM: CUL_0 CCA channel busy error to 52A533/ku_Rollo:  390937 A F004 11504356 00 0C 66 A011 F11034 52A533 02 _sfail
2017.07.30 17:29:38.825 4: TSCUL_XmitAwaitTo CUL_0: timeout - 52A533
2017.07.30 17:29:39.321 1: TSCUL_ParseTsHM: CUL_0 CCA channel busy error to 52A533/ku_Rollo:  392173 A F004 11505612 00 0C 66 A011 F11034 52A533 02 _sfail
2017.07.30 17:29:40.557 1: TSCUL_ParseTsHM: CUL_0 CCA channel busy error to 52A533/ku_Rollo:  393409 A F004 11506868 00 0C 66 A011 F11034 52A533 02 _sfail
2017.07.30 17:29:40.788 1: TSCUL_ParseTsHM: CUL_0 HM repeat failed to 52A533/ku_Rollo:  393640 A F009 11508124 00 0C 66 A011 F11034 52A533 02 _sfail
2017.07.30 17:29:42.939 4: TSCUL_send:  CUL_0                         As 0C 66 A011 F11034 52A533 0201B4
2017.07.30 17:29:42.943 4: TSCUL_XmitDlyHM:  CUL_0  id:52A533 toms:90 rtoms:1761
2017.07.30 17:29:43.969 1: TSCUL_ParseTsHM: CUL_0 CCA channel busy error to 52A533/ku_Rollo:  396820 A F004 11510332 00 0C 66 A011 F11034 52A533 02 _sfail
2017.07.30 17:29:44.707 4: TSCUL_XmitAwaitTo CUL_0: timeout - 52A533
2017.07.30 17:29:45.204 1: TSCUL_ParseTsHM: CUL_0 CCA channel busy error to 52A533/ku_Rollo:  398056 A F004 11511588 00 0C 66 A011 F11034 52A533 02 _sfail
2017.07.30 17:29:46.440 1: TSCUL_ParseTsHM: CUL_0 CCA channel busy error to 52A533/ku_Rollo:  399292 A F004 11512844 00 0C 66 A011 F11034 52A533 02 _sfail
2017.07.30 17:29:46.671 1: TSCUL_ParseTsHM: CUL_0 HM repeat failed to 52A533/ku_Rollo:  399523 A F009 11514100 00 0C 66 A011 F11034 52A533 02 _sfail
2017.07.30 17:29:48.911 4: TSCUL_send:  CUL_0                         As 0C 66 A011 F11034 52A533 0201B4
2017.07.30 17:29:48.914 4: TSCUL_XmitDlyHM:  CUL_0  id:52A533 toms:90 rtoms:1761
2017.07.30 17:29:49.941 1: TSCUL_ParseTsHM: CUL_0 CCA channel busy error to 52A533/ku_Rollo:  402792 A F004 11516396 00 0C 66 A011 F11034 52A533 02 _sfail
2017.07.30 17:29:50.387 4: TSCUL_Parse: CUL_0  403238 A F103 11517844 2F 0C 66 A011 F11034 52A533 02 _CCAdly:188 -138
2017.07.30 17:29:50.392 4: TSCUL_Parse: CUL_rpi  403254 A F001 03835808 00 0C 66 A011 F11034 52A533 0201B4 -83
2017.07.30 17:29:50.563 4: TSCUL_Parse: CUL_0  403410 A F101 11518000 00 0E 66 8002 52A533 F11034 0101BC2045 -67
2017.07.30 17:29:54.181 4: TSCUL_Parse: CUL_0  407031 A F001 11521728 00 0D 67 A410 52A533 F11034 0601B400 -69.5
2017.07.30 17:29:54.197 4: TSCUL_send:  CUL_0                         As 0A 67 8002 F11034 52A533 00
2017.07.30 17:29:54.198 4: TSCUL_XmitDlyHM:  CUL_0  id:52A533 toms:90
2017.07.30 17:29:55.299 1: TSCUL_ParseTsHM: CUL_0 CCA channel busy error to 52A533/ku_Rollo:  408151 A F004 11521844 00 0A 67 8002 F11034 52A533 00 _sfail
2017.07.30 17:30:02.765 4: TSCUL_Parse: CUL_0  415613 A F001 11530444 00 0D 67 A410 52A533 F11034 0601B400 -69.5
2017.07.30 17:30:02.780 4: TSCUL_send:  CUL_0                         As 0A 67 8002 F11034 52A533 00
2017.07.30 17:30:02.781 4: TSCUL_XmitDlyHM:  CUL_0  id:52A533 toms:90
2017.07.30 17:30:02.791 4: TSCUL_Parse: CUL_rpi  415652 A F001 03847992 00 0D 67 A410 52A533 F11034 0601B400 -82
2017.07.30 17:30:03.880 1: TSCUL_ParseTsHM: CUL_0 CCA channel busy error to 52A533/ku_Rollo:  416732 A F004 11530560 00 0A 67 8002 F11034 52A533 00 _sfail


Nehme ich aus der IOList der vccu den CUL_0 raus reagiert der Aktor und das Log sieht so aus:

2017.07.30 17:32:03.612 4: TSCUL_send:  CUL_rpi                         As 0C 68 A011 F11034 52A533 020196
2017.07.30 17:32:03.613 4: TSCUL_XmitDlyHM:  CUL_rpi  id:52A533 toms:98 rtoms:1746
2017.07.30 17:32:03.681 4: TSCUL_Parse: CUL_rpi  012254 A F103 03966888 02 0C 68 A011 F11034 52A533 02 _CCAdly:8 -138
2017.07.30 17:32:03.770 4: TSCUL_Parse: CUL_0  012332 A F001 11653356 00 0C 68 A011 F11034 52A533 020196 -85
2017.07.30 17:32:03.938 4: TSCUL_Parse: CUL_rpi  012513 A F103 03967152 01 0C 68 A011 F11034 52A533 02 _CCAdly:4 -138
2017.07.30 17:32:03.941 4: TSCUL_Parse: CUL_0  012504 A F001 11653628 00 0C 68 A011 F11034 52A533 020196 -84
2017.07.30 17:32:03.945 4: CUL_HM vccu dupe: dont process
2017.07.30 17:32:04.225 4: TSCUL_Parse: CUL_rpi  012799 A F103 03967432 04 0C 68 A011 F11034 52A533 02 _CCAdly:16 -138
2017.07.30 17:32:04.229 4: TSCUL_Parse: CUL_0  012792 A F001 11653920 00 0C 68 A011 F11034 52A533 020196 -83
2017.07.30 17:32:04.235 4: CUL_HM vccu dupe: dont process
2017.07.30 17:32:04.471 1: TSCUL_ParseTsHM: CUL_rpi HM repeat failed to 52A533/ku_Rollo:  013043 A F109 03967696 00 0C 68 A011 F11034 52A533 02 _sfail
2017.07.30 17:32:05.365 4: TSCUL_XmitAwaitTo CUL_rpi: timeout - 52A533
2017.07.30 17:32:06.680 4: TSCUL_send:  CUL_rpi                         As 0C 68 A011 F11034 52A533 020196
2017.07.30 17:32:06.683 4: TSCUL_XmitDlyHM:  CUL_rpi  id:52A533 toms:98 rtoms:1746
2017.07.30 17:32:06.739 4: TSCUL_Parse: CUL_0  015301 A F001 11656476 00 0C 68 A011 F11034 52A533 020196 -85
2017.07.30 17:32:06.746 4: CUL_HM vccu dupe: dont process
2017.07.30 17:32:06.753 4: TSCUL_Parse: CUL_rpi  015327 A F103 03969904 01 0C 68 A011 F11034 52A533 02 _CCAdly:4 -138
2017.07.30 17:32:07.008 4: TSCUL_Parse: CUL_rpi  015582 A F103 03970172 01 0C 68 A011 F11034 52A533 02 _CCAdly:4 -138
2017.07.30 17:32:07.280 4: TSCUL_Parse: CUL_0  015843 A F001 11657028 00 0C 68 A011 F11034 52A533 020196 -86.5
2017.07.30 17:32:07.285 4: CUL_HM vccu dupe: dont process
2017.07.30 17:32:07.291 4: TSCUL_Parse: CUL_rpi  015866 A F103 03970440 01 0C 68 A011 F11034 52A533 02 _CCAdly:4 -138
2017.07.30 17:32:07.519 1: TSCUL_ParseTsHM: CUL_rpi HM repeat failed to 52A533/ku_Rollo:  016094 A F109 03970704 00 0C 68 A011 F11034 52A533 02 _sfail
2017.07.30 17:32:08.432 4: TSCUL_XmitAwaitTo CUL_rpi: timeout - 52A533
2017.07.30 17:32:10.803 4: TSCUL_send:  CUL_rpi                         As 0C 68 A011 F11034 52A533 020196
2017.07.30 17:32:10.806 4: TSCUL_XmitDlyHM:  CUL_rpi  id:52A533 toms:98 rtoms:1746
2017.07.30 17:32:10.864 4: TSCUL_Parse: CUL_0  019425 A F001 11660668 00 0C 68 A011 F11034 52A533 020196 -84.5
2017.07.30 17:32:10.875 4: CUL_HM vccu dupe: dont process
2017.07.30 17:32:10.883 4: TSCUL_Parse: CUL_rpi  019456 A F103 03973960 01 0C 68 A011 F11034 52A533 02 _CCAdly:4 -138
2017.07.30 17:32:10.993 4: TSCUL_Parse: CUL_rpi  019565 A F101 03974112 00 0E 68 8002 52A533 F11034 0101960051 -84


Zitat
Wenn Du ausgiebig testest.  :)

Statt einer 'unknown code' Meldung steht jetzt im Log

2017.07.30 17:34:36.585 4: TSCUL_Parse: CUL_0 H009801830200FF -74.5
2017.07.30 17:34:36.640 4: TSCUL_Parse: CUL_0 H368B01640200FF -74.5


Zitat
Ob die gleichzeitige Nutzung von Onewire bei Deinem anderen Problem stört, kann ich nicht sagen. Eventuell bringt verbose 5 statt 4 noch mehr ans Licht.

Glaube ich eher nicht, mit der original culfw hat das immer funktioniert. Onewire wird auch nur alle 2 Minuten aktiv, in den Sendevorgänge oben  wurde es nicht aktiv.

Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 30 Juli 2017, 21:34:54
Hallo Kai,

hast Du die Antenne direkt am CUL_0 hängen oder eine Antenne mit längerem Kabel?

CCA schlägt bei CUL_0 fast ständig zu. Die Antenne vom Rechner weg zu bringen könnte helfen.
Ist natürlich schwer zu sagen, was die Störquelle ist. Rechner, Netzteil(e), Monitor ....

Ein dusseliges Gerät, dass lustig (auch beim Nachbarn) auf 868.3MHz Dauer sendet, kann auch problematisch sein. Wenn das CCA-Problem wandert, dann vermutlich auch der Störsender.

Du müsstest den Frequenzbereich mal sichtbar machen, um da gezielter ran gehen zu können.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 30 Juli 2017, 23:25:15
Hallo Kai,

angehängt mal eine neue Firmware (VTS 0.12) nebst Modulen.
Der Firmware Sourcecode ist nicht dabei, weil der derzeitige Zwischenstand wohl eher verwirren statt nutzen würde, da ich künftig auch CUNX mit neuer Firmware versorgen möchte (ein leider aufwändiges Projekt).

Geändert habe ich aber u.A. die CCA Empfindlichkeit bei ASKSIN.
Sprich bei einem schwachen Dauerstörer sollte es weniger Probleme geben.

Konkret habe ich
CC1101_AGCCTRL1, 0x67,              // 0x1C  new CARRIER_SENSE_REL_THR 10dB, CARRIER_SENSE_ABS_THR MAGN_TARGET 7dB
gewählt.

Wenn Du testen magst, dann weiß ich zumindest auch, ob ich bei IR und OneWire keinen Quatsch gemacht habe. Und natürlich, ob TSrpiaddon in der Konfiguration funktioniert.

Gruß, Ansgar.

PS: TSCULflash ist nur mit TSCUL_V3 oder TSPIGATOR in einem CUNX nutzbar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: kaihs am 31 Juli 2017, 20:43:30
Zitat von: noansi am 30 Juli 2017, 21:34:54
hast Du die Antenne direkt am CUL_0 hängen oder eine Antenne mit längerem Kabel?

Hängt direkt am CUL_0. Ich habe aktuell kein passendes Kabel um sie weiter weg zu positionieren.

Zitat
CCA schlägt bei CUL_0 fast ständig zu. Die Antenne vom Rechner weg zu bringen könnte helfen.
Ist natürlich schwer zu sagen, was die Störquelle ist. Rechner, Netzteil(e), Monitor ....

Oder die Hardware ist doch defekt.
Es ist leider ziemlich aufwändig, die Boards auszubauen und zu tauschen.
Ich werde das aber später nochmal tun und versuchen einzugrenzen, in welcher Konstellation das Problem auftritt und wieder verschwindet.

Zitat
Du müsstest den Frequenzbereich mal sichtbar machen, um da gezielter ran gehen zu können.

Ich habe dafür leider nicht die Hardware, also keinen SDR-Stick oder bessere Equipment.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: kaihs am 31 Juli 2017, 20:52:46
Zitat von: noansi am 30 Juli 2017, 23:25:15
angehängt mal eine neue Firmware (VTS 0.12) nebst Modulen.
Der Firmware Sourcecode ist nicht dabei, weil der derzeitige Zwischenstand wohl eher verwirren statt nutzen würde, da ich künftig auch CUNX mit neuer Firmware versorgen möchte (ein leider aufwändiges Projekt).

Danke für deine Bemühungen!
Ich werde diese Firmware ausprobieren.
Für IR-Senden/-Empfangen musste ich allerdings Anpassungen an irsndconfig.h und irmpconfig.h vornehmen. Das Board verwendet andere Pins.

Es ist ungünstig, dass man das nur global und nicht pro Board machen kann.
Ich hatte schon mal eine neuere Version von irmp integriert mit der das möglich wurde, allerdings habe ich mich nie darum bemüht es in die Standard culfw aufzunehmen.
Wenn das Sendeproblem mit dieser Version besser wird wäre ich dankbar wenn du mir auch die Sourcen gibts damit ich die Änderungen vornehmen kann.

Zitat
Konkret habe ich
CC1101_AGCCTRL1, 0x67,              // 0x1C  new CARRIER_SENSE_REL_THR 10dB, CARRIER_SENSE_ABS_THR MAGN_TARGET 7dB
gewählt.

Ist das die einzige hierfür relevante Änderung? Dann könnte ich das ja auch erstmal manuell in der 0.10 Version ändern die aktuell läuft.

Zitat
PS: TSCULflash ist nur mit TSCUL_V3 oder TSPIGATOR in einem CUNX nutzbar.

Ich flashe sowieso manuell, das Board braucht ein spezielles Pin-Togglen um in den Bootloader zu gehen.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: kaihs am 31 Juli 2017, 21:31:14
Erste Ergebnisse (CUL_0 mit 0.12, CUL_rpi noch mit 0.10, deine fhem Module auf dem neuesten Stand):

Beim Start von fhem:

2017.07.31 21:18:44 1: VH CUL_0
2017.07.31 21:18:48 1: VH CUL_0
2017.07.31 21:18:53 1: VH CUL_0
2017.07.31 21:18:57 1: VH CUL_0
2017.07.31 21:19:01 1: VH CUL_0
2017.07.31 21:19:01 1: CUL_0 is VERSION_TS, VTS 0.12 CSM868,
2017.07.31 21:19:16 1: VH CUL_rpi VTS 0.10 RPIAddOn_CSM
2017.07.31 21:19:16 1: VH CUL_rpi VTS 0.10 RPIAddOn_CSM
2017.07.31 21:19:16 1: VH CUL_rpi VTS 0.10 RPIAddOn_CSM
2017.07.31 21:19:16 1: VH CUL_rpi VTS 0.10 RPIAddOn_CSM
2017.07.31 21:19:17 1: VH CUL_rpi VTS 0.10 RPIAddOn_CSM
2017.07.31 21:19:17 1: CUL_rpi is VERSION_TS, VTS 0.10 RPIAddOn_CSM


Die Initialisierung dauert sehr lange, die VH Meldungen waren vorher nicht da.

Aber das Senden über CUL_0 funktioniert wieder! Danke!
Ich teste weiter, bisher sieht es gut aus:

2017.07.31 21:43:28.865 4: TSCUL_send:  CUL_0                         As 0C BF A011 F11034 52B558 02018E
2017.07.31 21:43:28.867 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:90 rtoms:1761
2017.07.31 21:43:28.921 4: TSCUL_Parse: CUL_0  309901 A F103 01862108 01 0C BF A011 F11034 52B558 02 _CCAdly:4 -138
2017.07.31 21:43:28.927 4: TSCUL_Parse: CUL_rpi  309917 A F001 11884056 00 0C BF A011 F11034 52B558 02018E -70.5
2017.07.31 21:43:29.186 4: TSCUL_Parse: CUL_rpi  310177 A F001 11884320 00 0C BF A011 F11034 52B558 02018E -70
2017.07.31 21:43:29.191 4: CUL_HM vccu dupe: dont process
2017.07.31 21:43:29.198 4: TSCUL_Parse: CUL_0  310177 A F103 01862376 01 0C BF A011 F11034 52B558 02 _CCAdly:4 -138
2017.07.31 21:43:29.328 4: TSCUL_Parse: CUL_0  310300 A F101 01862528 00 0E BF 8002 52B558 F11034 0101982036 -55.5


Wenn du mir jetzt noch die Sourcen gibst so dass ich die IR Konfiguration anpassen kann dann sehe ich Licht am Ende des Tunnels.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: kaihs am 31 Juli 2017, 21:38:25
Ein letzter Test noch, ein
set az_Rollo getConfig
schlägt mit
RESPONSE TIMEOUT:RegisterRead
fehl.

Log dazu:

2017.07.31 21:39:53.501 4: TSCUL_send:  CUL_0                         As 10 AF A001 F11034 52B558 00040000000000
2017.07.31 21:39:53.502 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:91 rtoms:1765
2017.07.31 21:39:53.572 4: TSCUL_Parse: CUL_0  094552 A F203 01645112 01 10 AF A001 F11034 52B558 00 _CCAdly:4 -138
2017.07.31 21:39:53.609 4: TSCUL_Parse: CUL_rpi  094600 A F001 11672116 00 10 AF A001 F11034 52B558 00040000000000 -70.5
2017.07.31 21:39:53.833 4: TSCUL_Parse: CUL_0  094813 A F203 01645384 01 10 AF A001 F11034 52B558 00 _CCAdly:4 -138
2017.07.31 21:39:53.839 4: TSCUL_Parse: CUL_rpi  094830 A F001 11672380 00 10 AF A001 F11034 52B558 00040000000000 -70.5
2017.07.31 21:39:53.843 4: CUL_HM vccu dupe: dont process
2017.07.31 21:39:54.103 4: TSCUL_Parse: CUL_0  095082 A F203 01645656 01 10 AF A001 F11034 52B558 00 _CCAdly:4 -138
2017.07.31 21:39:54.111 4: TSCUL_Parse: CUL_rpi  095101 A F001 11672648 00 10 AF A001 F11034 52B558 00040000000000 -70
2017.07.31 21:39:54.115 4: CUL_HM vccu dupe: dont process
2017.07.31 21:39:54.337 1: TSCUL_ParseTsHM: CUL_0 HM repeat failed to 52B558/az_Rollo:  095317 A F209 01645924 00 10 AF A001 F11034 52B558 00 _sfail
2017.07.31 21:39:54.942 4: TSCUL_Parse: CUL_rpi  095927 A F001 11673460 00 16 AF A010 52B558 F11034 0202810AF10B100C3415FF1800 -68.5
2017.07.31 21:39:55.272 4: TSCUL_XmitAwaitTo CUL_0: timeout - 52B558
2017.07.31 21:39:55.481 4: TSCUL_send:  CUL_0                         As 0A AF 8002 F11034 52B558 00
2017.07.31 21:39:55.482 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:90
2017.07.31 21:39:55.535 4: TSCUL_Parse: CUL_rpi  096525 A F001 11674056 00 0A AF 8002 F11034 52B558 00 -70.5
2017.07.31 21:39:55.547 4: TSCUL_Parse: CUL_0  096527 A F203 01647100 01 0A AF 8002 F11034 52B558 00 _CCAdly:4 -138
2017.07.31 21:39:55.845 4: TSCUL_Parse: CUL_rpi  096836 A F002 11674368 00 01 CC _ping -138
2017.07.31 21:39:56.977 4: TSCUL_send:  CUL_0                         As 10 AF A001 F11034 52B558 00040000000000
2017.07.31 21:39:56.978 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:91 rtoms:1765
2017.07.31 21:39:57.040 4: TSCUL_Parse: CUL_0  098019 A F203 01648612 01 10 AF A001 F11034 52B558 00 _CCAdly:4 -138
2017.07.31 21:39:57.048 4: TSCUL_Parse: CUL_rpi  098038 A F001 11675536 00 10 AF A001 F11034 52B558 00040000000000 -70.5
2017.07.31 21:39:57.310 4: TSCUL_Parse: CUL_0  098289 A F203 01648884 01 10 AF A001 F11034 52B558 00 _CCAdly:4 -138
2017.07.31 21:39:57.317 4: TSCUL_Parse: CUL_rpi  098308 A F001 11675800 00 10 AF A001 F11034 52B558 00040000000000 -70.5
2017.07.31 21:39:57.323 4: CUL_HM vccu dupe: dont process
2017.07.31 21:39:57.587 4: TSCUL_Parse: CUL_rpi  098574 A F001 11676068 00 10 AF A001 F11034 52B558 00040000000000 -70.5
2017.07.31 21:39:57.603 4: CUL_HM vccu dupe: dont process
2017.07.31 21:39:57.615 4: TSCUL_Parse: CUL_0  098592 A F203 01649156 01 10 AF A001 F11034 52B558 00 _CCAdly:4 -138
2017.07.31 21:39:57.814 1: TSCUL_ParseTsHM: CUL_0 HM repeat failed to 52B558/az_Rollo:  098794 A F209 01649424 00 10 AF A001 F11034 52B558 00 _sfail
2017.07.31 21:39:58.013 4: TSCUL_Parse: CUL_rpi  099002 A F001 11676484 00 16 AF A010 52B558 F11034 0202810AF10B100C3415FF1800 -68.5
2017.07.31 21:39:58.750 4: TSCUL_XmitAwaitTo CUL_0: timeout - 52B558
2017.07.31 21:39:58.961 4: TSCUL_send:  CUL_0                         As 0A AF 8002 F11034 52B558 00
2017.07.31 21:39:58.962 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:90
2017.07.31 21:39:59.015 4: TSCUL_Parse: CUL_0  099995 A F203 01650608 02 0A AF 8002 F11034 52B558 00 _CCAdly:8 -138
2017.07.31 21:39:59.024 4: TSCUL_Parse: CUL_rpi  100014 A F001 11677480 00 0A AF 8002 F11034 52B558 00 -70.5
2017.07.31 21:40:02.057 4: TSCUL_send:  CUL_0                         As 10 AF A001 F11034 52B558 00040000000000
2017.07.31 21:40:02.059 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:91 rtoms:1765
2017.07.31 21:40:02.120 4: TSCUL_Parse: CUL_0  103098 A F203 01653728 01 10 AF A001 F11034 52B558 00 _CCAdly:4 -138
2017.07.31 21:40:02.125 4: TSCUL_Parse: CUL_rpi  103114 A F001 11680532 00 10 AF A001 F11034 52B558 00040000000000 -70.5
2017.07.31 21:40:02.254 4: TSCUL_Parse: CUL_rpi  103243 A F001 11680660 00 16 AF A010 52B558 F11034 0202810AF10B100C3415FF1800 -68.5
2017.07.31 21:40:02.387 4: TSCUL_Parse: CUL_0  103367 A F203 01654000 01 10 AF A001 F11034 52B558 00 _CCAdly:4 -138
2017.07.31 21:40:02.392 4: TSCUL_Parse: CUL_rpi  103382 A F001 11680800 00 10 AF A001 F11034 52B558 00040000000000 -70
2017.07.31 21:40:02.397 4: CUL_HM vccu dupe: dont process
2017.07.31 21:40:02.523 4: TSCUL_Parse: CUL_0  103496 A F201 01654160 00 16 AF A010 52B558 F11034 0202810AF10B100C3415FF1800 -56.5
2017.07.31 21:40:02.534 4: TSCUL_Parse: CUL_rpi  103524 A F001 11680928 00 16 AF A010 52B558 F11034 0202810AF10B100C3415FF1800 -69.5
2017.07.31 21:40:02.822 4: TSCUL_Parse: CUL_rpi  103812 A F001 11681216 00 16 AF A010 52B558 F11034 0202810AF10B100C3415FF1800 -69
2017.07.31 21:40:03.844 4: TSCUL_XmitAwaitTo CUL_0: timeout - 52B558
2017.07.31 21:40:04.089 4: TSCUL_send:  CUL_0                         As 0A AF 8002 F11034 52B558 00
2017.07.31 21:40:04.089 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:90
2017.07.31 21:40:04.143 4: TSCUL_Parse: CUL_0  105123 A F203 01655772 02 0A AF 8002 F11034 52B558 00 _CCAdly:8 -138
2017.07.31 21:40:04.146 4: TSCUL_Parse: CUL_rpi  105136 A F001 11682528 00 0A AF 8002 F11034 52B558 00 -70.5
2017.07.31 21:40:07.275 4: TSCUL_send:  CUL_0                         As 10 AF A001 F11034 52B558 00040000000000
2017.07.31 21:40:07.277 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:91 rtoms:1765
2017.07.31 21:40:07.337 4: TSCUL_Parse: CUL_0  108315 A F203 01658984 02 10 AF A001 F11034 52B558 00 _CCAdly:8 -138
2017.07.31 21:40:07.342 4: TSCUL_Parse: CUL_rpi  108331 A F001 11685668 00 10 AF A001 F11034 52B558 00040000000000 -70
2017.07.31 21:40:07.603 4: TSCUL_Parse: CUL_0  108582 A F203 01659252 01 10 AF A001 F11034 52B558 00 _CCAdly:4 -138
2017.07.31 21:40:07.607 4: TSCUL_Parse: CUL_rpi  108597 A F001 11685932 00 10 AF A001 F11034 52B558 00040000000000 -70.5
2017.07.31 21:40:07.612 4: CUL_HM vccu dupe: dont process
2017.07.31 21:40:07.741 4: TSCUL_Parse: CUL_0  108713 A F201 01659412 00 16 AF A010 52B558 F11034 0202810AF10B100C3415FF1800 -56
2017.07.31 21:40:08.442 4: TSCUL_Parse: CUL_rpi  109423 A F001 11686740 00 16 AF A010 52B558 F11034 0202810AF10B100C3415FF1800 -69
2017.07.31 21:40:08.458 4: TSCUL_send:  CUL_0                         As 0A AF 8002 F11034 52B558 00
2017.07.31 21:40:08.461 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:90
2017.07.31 21:40:08.511 4: TSCUL_Parse: CUL_rpi  109501 A F001 11686824 00 0A AF 8002 F11034 52B558 00 -70
2017.07.31 21:40:08.523 4: TSCUL_Parse: CUL_0  109503 A F203 01660172 01 0A AF 8002 F11034 52B558 00 _CCAdly:4 -138
2017.07.31 21:40:09.327 4: TSCUL_Parse: CUL_rpi  110317 A F001 11687628 00 0C B0 A010 52B558 F11034 030000 -69.5
2017.07.31 21:40:09.351 4: TSCUL_send:  CUL_0                         As 0A B0 8002 F11034 52B558 00
2017.07.31 21:40:09.352 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:90
2017.07.31 21:40:09.405 4: TSCUL_Parse: CUL_0  110385 A F203 01661072 02 0A B0 8002 F11034 52B558 00 _CCAdly:8 -138
2017.07.31 21:40:09.413 4: TSCUL_Parse: CUL_rpi  110403 A F001 11687704 00 0A B0 8002 F11034 52B558 00 -70.5
2017.07.31 21:40:09.448 4: TSCUL_send:  CUL_0                         As 10 B1 A001 F11034 52B558 01040000000001
2017.07.31 21:40:09.449 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:91 rtoms:1765
2017.07.31 21:40:09.515 4: TSCUL_Parse: CUL_0  110494 A F203 01661176 01 10 B1 A001 F11034 52B558 01 _CCAdly:4 -138
2017.07.31 21:40:09.523 4: TSCUL_Parse: CUL_rpi  110513 A F001 11687812 00 10 B1 A001 F11034 52B558 01040000000001 -70.5
2017.07.31 21:40:09.782 4: TSCUL_Parse: CUL_0  110762 A F203 01661448 01 10 B1 A001 F11034 52B558 01 _CCAdly:4 -138
2017.07.31 21:40:09.789 4: TSCUL_Parse: CUL_rpi  110779 A F001 11688076 00 10 B1 A001 F11034 52B558 01040000000001 -70.5
2017.07.31 21:40:09.793 4: CUL_HM vccu dupe: dont process
2017.07.31 21:40:09.918 4: TSCUL_Parse: CUL_rpi  110907 A F001 11688204 00 14 B1 A010 52B558 F11034 0308000000011801220500 -69
2017.07.31 21:40:09.936 4: TSCUL_Parse: CUL_0  110910 A F201 01661604 00 14 B1 A010 52B558 F11034 0308000000011801220500 -56.5
2017.07.31 21:40:10.607 4: TSCUL_Parse: CUL_0  111582 A F201 01662304 00 14 B1 A010 52B558 F11034 0308000000011801220500 -56.5
2017.07.31 21:40:11.219 4: TSCUL_XmitAwaitTo CUL_0: timeout - 52B558
2017.07.31 21:40:11.430 4: TSCUL_send:  CUL_0                         As 0A B1 8002 F11034 52B558 00
2017.07.31 21:40:11.431 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:90
2017.07.31 21:40:11.483 4: TSCUL_Parse: CUL_0  112462 A F203 01663164 01 0A B1 8002 F11034 52B558 00 _CCAdly:4 -138
2017.07.31 21:40:11.488 4: TSCUL_Parse: CUL_rpi  112477 A F001 11689748 00 0A B1 8002 F11034 52B558 00 -70
2017.07.31 21:40:11.937 4: TSCUL_send:  CUL_0                         As 10 B1 A001 F11034 52B558 01040000000001
2017.07.31 21:40:11.939 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:91 rtoms:1765
2017.07.31 21:40:11.999 4: TSCUL_Parse: CUL_0  112978 A F203 01663680 01 10 B1 A001 F11034 52B558 01 _CCAdly:4 -138
2017.07.31 21:40:12.003 4: TSCUL_Parse: CUL_rpi  112993 A F001 11690256 00 10 B1 A001 F11034 52B558 01040000000001 -70.5
2017.07.31 21:40:12.134 4: TSCUL_Parse: CUL_0  113107 A F201 01663840 00 14 B1 A010 52B558 F11034 0308000000011801220500 -56.5
2017.07.31 21:40:12.146 4: TSCUL_Parse: CUL_rpi  113136 A F001 11690384 00 14 B1 A010 52B558 F11034 0308000000011801220500 -68.5
2017.07.31 21:40:12.163 4: TSCUL_send:  CUL_0                         As 0A B1 8002 F11034 52B558 00
2017.07.31 21:40:12.164 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:90
2017.07.31 21:40:12.271 4: TSCUL_Parse: CUL_0  113250 A F203 01663960 01 0A B1 8002 F11034 52B558 00 _CCAdly:4 -138
2017.07.31 21:40:12.275 4: TSCUL_Parse: CUL_rpi  113265 A F001 11690524 00 0A B1 8002 F11034 52B558 00 -70
2017.07.31 21:40:12.406 4: TSCUL_Parse: CUL_rpi  113396 A F001 11690652 00 10 B2 A010 52B558 F11034 02300657065600 -68.5
2017.07.31 21:40:12.418 4: TSCUL_send:  CUL_0                         As 0A B2 8002 F11034 52B558 00
2017.07.31 21:40:12.419 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:90
2017.07.31 21:40:12.471 4: TSCUL_Parse: CUL_0  113451 A F203 01664160 01 0A B2 8002 F11034 52B558 00 _CCAdly:4 -138
2017.07.31 21:40:12.476 4: TSCUL_Parse: CUL_rpi  113466 A F001 11690720 00 0A B2 8002 F11034 52B558 00 -70.5
2017.07.31 21:40:12.598 4: TSCUL_Parse: CUL_0  113577 A F201 01664312 00 0C B3 A010 52B558 F11034 030000 -56.5
2017.07.31 21:40:12.624 4: TSCUL_send:  CUL_0                         As 0A B3 8002 F11034 52B558 00
2017.07.31 21:40:12.625 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:90
2017.07.31 21:40:12.636 4: TSCUL_Parse: CUL_rpi  113626 A F001 11690848 00 0C B3 A010 52B558 F11034 030000 -68
2017.07.31 21:40:12.721 4: TSCUL_send:  CUL_0                         As 0B B4 A001 F11034 52B558 0103
2017.07.31 21:40:12.722 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:90 rtoms:1760
2017.07.31 21:40:12.740 4: TSCUL_Parse: CUL_0  113719 A F203 01664432 01 0A B3 8002 F11034 52B558 00 _CCAdly:4 _dhmSt:120 -138
2017.07.31 21:40:12.746 4: TSCUL_Parse: CUL_rpi  113736 A F001 11690984 00 0A B3 8002 F11034 52B558 00 -70.5
2017.07.31 21:40:12.844 4: TSCUL_Parse: CUL_0  113824 A F203 01664536 01 0B B4 A001 F11034 52B558 01 _CCAdly:4 _dhmSt:224 -138
2017.07.31 21:40:12.848 4: TSCUL_Parse: CUL_rpi  113839 A F001 11691088 00 0B B4 A001 F11034 52B558 0103 -70.5
2017.07.31 21:40:12.986 4: TSCUL_Parse: CUL_0  113958 A F201 01664696 00 16 B4 A010 52B558 F11034 0152B5580152B5580200000000 -56
2017.07.31 21:40:13.020 4: TSCUL_send:  CUL_0                         As 0A B4 8002 F11034 52B558 00
2017.07.31 21:40:13.021 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:90
2017.07.31 21:40:13.115 4: TSCUL_send:  CUL_0                         As 10 B5 A001 F11034 52B558 010452B5580103
2017.07.31 21:40:13.117 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:91 rtoms:1765
2017.07.31 21:40:13.124 4: TSCUL_Parse: CUL_0  114103 A F203 01664816 01 0A B4 8002 F11034 52B558 00 _CCAdly:4 _dhmSt:120 -138
2017.07.31 21:40:13.128 4: TSCUL_Parse: CUL_rpi  114118 A F001 11691360 00 0A B4 8002 F11034 52B558 00 -70.5
2017.07.31 21:40:13.230 4: TSCUL_Parse: CUL_0  114209 A F203 01664920 01 10 B5 A001 F11034 52B558 01 _CCAdly:4 _dhmSt:224 -138
2017.07.31 21:40:13.234 4: TSCUL_Parse: CUL_rpi  114224 A F001 11691468 00 10 B5 A001 F11034 52B558 010452B5580103 -70
2017.07.31 21:40:13.373 4: TSCUL_Parse: CUL_rpi  114362 A F001 11691596 00 1A B5 A010 52B558 F11034 0301000000326400FF00FF014454630000 -68.5
2017.07.31 21:40:13.502 4: TSCUL_Parse: CUL_0  114482 A F203 01665192 01 10 B5 A001 F11034 52B558 01 _CCAdly:4 _dhmSt:496 -138
2017.07.31 21:40:13.507 4: TSCUL_Parse: CUL_rpi  114497 A F001 11691732 00 10 B5 A001 F11034 52B558 010452B5580103 -71
2017.07.31 21:40:13.511 4: CUL_HM vccu dupe: dont process
2017.07.31 21:40:13.769 4: TSCUL_Parse: CUL_0  114748 A F203 01665464 01 10 B5 A001 F11034 52B558 01 _CCAdly:4 _dhmSt:768 -138
2017.07.31 21:40:13.773 4: TSCUL_Parse: CUL_rpi  114763 A F001 11691996 00 10 B5 A001 F11034 52B558 010452B5580103 -70.5
2017.07.31 21:40:13.778 4: CUL_HM vccu dupe: dont process
2017.07.31 21:40:13.909 4: TSCUL_Parse: CUL_0  114880 A F201 01665628 00 1A B5 A010 52B558 F11034 0301000000326400FF00FF014454630000 -56.5
2017.07.31 21:40:14.311 4: TSCUL_Parse: CUL_rpi  115301 A F002 11692140 00 15 AA001122AA001122AA001122AA001122AA001122AA _ping -138
2017.07.31 21:40:14.888 4: TSCUL_XmitAwaitTo CUL_0: timeout - 52B558
2017.07.31 21:40:15.099 4: TSCUL_send:  CUL_0                         As 0A B5 8002 F11034 52B558 00
2017.07.31 21:40:15.100 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:90
2017.07.31 21:40:15.152 4: TSCUL_Parse: CUL_rpi  116142 A F001 11693356 00 0A B5 8002 F11034 52B558 00 -71
2017.07.31 21:40:15.166 4: TSCUL_Parse: CUL_0  116146 A F203 01666860 01 0A B5 8002 F11034 52B558 00 _CCAdly:4 _dhmSt:2164 -138
2017.07.31 21:40:15.391 4: TSCUL_send:  CUL_0                         As 10 B5 A001 F11034 52B558 010452B5580103
2017.07.31 21:40:15.392 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:91 rtoms:1765
2017.07.31 21:40:15.453 4: TSCUL_Parse: CUL_0  116433 A F203 01667160 02 10 B5 A001 F11034 52B558 01 _CCAdly:8 _dhmSt:2464 -138
2017.07.31 21:40:15.461 4: TSCUL_Parse: CUL_rpi  116451 A F001 11693652 00 10 B5 A001 F11034 52B558 010452B5580103 -70.5
2017.07.31 21:40:15.596 4: TSCUL_Parse: CUL_rpi  116585 A F001 11693784 00 1A B5 A010 52B558 F11034 0301000000326400FF00FF014454630000 -68
2017.07.31 21:40:15.722 4: TSCUL_Parse: CUL_0  116701 A F203 01667432 01 10 B5 A001 F11034 52B558 01 _CCAdly:4 _dhmSt:2736 -138
2017.07.31 21:40:15.730 4: TSCUL_Parse: CUL_rpi  116720 A F001 11693920 00 10 B5 A001 F11034 52B558 010452B5580103 -70.5
2017.07.31 21:40:15.735 4: CUL_HM vccu dupe: dont process
2017.07.31 21:40:15.863 4: TSCUL_Parse: CUL_0  116835 A F201 01667596 00 1A B5 A010 52B558 F11034 0301000000326400FF00FF014454630000 -56.5
2017.07.31 21:40:16.841 4: TSCUL_Parse: CUL_rpi  117831 A F001 11694344 00 1A B5 A010 52B558 F11034 0301000000326400FF00FF014454630000 -69.5
2017.07.31 21:40:17.163 4: TSCUL_XmitAwaitTo CUL_0: timeout - 52B558
2017.07.31 21:40:17.372 4: TSCUL_send:  CUL_0                         As 0A B5 8002 F11034 52B558 00
2017.07.31 21:40:17.373 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:90
2017.07.31 21:40:17.426 4: TSCUL_Parse: CUL_0  118406 A F203 01669152 01 0A B5 8002 F11034 52B558 00 _CCAdly:4 -138
2017.07.31 21:40:17.435 4: TSCUL_Parse: CUL_rpi  118425 A F001 11695592 00 0A B5 8002 F11034 52B558 00 -70.5
2017.07.31 21:40:19.485 4: TSCUL_send:  CUL_0                         As 10 B5 A001 F11034 52B558 010452B5580103
2017.07.31 21:40:19.486 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:91 rtoms:1765
2017.07.31 21:40:19.547 4: TSCUL_Parse: CUL_0  120526 A F203 01671280 01 10 B5 A001 F11034 52B558 01 _CCAdly:4 -138
2017.07.31 21:40:19.555 4: TSCUL_Parse: CUL_rpi  120545 A F001 11697680 00 10 B5 A001 F11034 52B558 010452B5580103 -70.5
2017.07.31 21:40:19.815 4: TSCUL_Parse: CUL_0  120795 A F203 01671552 01 10 B5 A001 F11034 52B558 01 _CCAdly:4 -138
2017.07.31 21:40:19.823 4: TSCUL_Parse: CUL_rpi  120814 A F001 11697940 00 10 B5 A001 F11034 52B558 010452B5580103 -70.5
2017.07.31 21:40:19.828 4: CUL_HM vccu dupe: dont process
2017.07.31 21:40:19.958 4: TSCUL_Parse: CUL_rpi  120947 A F001 11698072 00 1A B5 A010 52B558 F11034 0301000000326400FF00FF014454630000 -68.5
2017.07.31 21:40:20.088 4: TSCUL_Parse: CUL_rpi  121078 A F001 11698208 00 10 B5 A001 F11034 52B558 010452B5580103 -70
2017.07.31 21:40:20.093 4: CUL_HM vccu dupe: dont process
2017.07.31 21:40:20.099 4: TSCUL_Parse: CUL_0  121078 A F203 01671824 01 10 B5 A001 F11034 52B558 01 _CCAdly:4 -138
2017.07.31 21:40:20.102 4: TSCUL_Parse: CUL_0  121076 A F202 01671856 00 15 AA001122AA001122AA001122AA001122AA001122AA _ping -138
2017.07.31 21:40:20.227 4: TSCUL_Parse: CUL_rpi  121217 A F001 11698340 00 1A B5 A010 52B558 F11034 0301000000326400FF00FF014454630000 -69
2017.07.31 21:40:20.239 4: TSCUL_Parse: CUL_0  121210 A F201 01671988 00 1A B5 A010 52B558 F11034 0301000000326400FF00FF014454630000 -56.5
2017.07.31 21:40:20.528 4: TSCUL_Parse: CUL_rpi  121518 A F001 11698636 00 1A B5 A010 52B558 F11034 0301000000326400FF00FF014454630000 -69.5
2017.07.31 21:40:20.923 4: TSCUL_Parse: CUL_0  121894 A F201 01672692 00 1A B5 A010 52B558 F11034 0301000000326400FF00FF014454630000 -55
2017.07.31 21:40:20.937 4: TSCUL_Parse: CUL_rpi  121927 A F001 11699028 00 1A B5 A010 52B558 F11034 0301000000326400FF00FF014454630000 -69
2017.07.31 21:40:21.264 4: TSCUL_XmitAwaitTo CUL_0: timeout - 52B558
2017.07.31 21:40:21.474 4: TSCUL_send:  CUL_0                         As 0A B5 8002 F11034 52B558 00
2017.07.31 21:40:21.475 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:90
2017.07.31 21:40:21.526 4: TSCUL_Parse: CUL_0  122506 A F203 01673284 02 0A B5 8002 F11034 52B558 00 _CCAdly:8 -138
2017.07.31 21:40:21.530 4: TSCUL_Parse: CUL_rpi  122520 A F001 11699628 00 0A B5 8002 F11034 52B558 00 -70
2017.07.31 21:40:24.763 4: TSCUL_send:  CUL_0                         As 10 B5 A001 F11034 52B558 010452B5580103
2017.07.31 21:40:24.765 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:91 rtoms:1765
2017.07.31 21:40:24.825 4: TSCUL_Parse: CUL_0  125804 A F203 01676596 01 10 B5 A001 F11034 52B558 01 _CCAdly:4 -138
2017.07.31 21:40:24.966 4: TSCUL_Parse: CUL_0  125935 A F201 01676760 00 1A B5 A010 52B558 F11034 0301000000326400FF00FF014454630000 -56
2017.07.31 21:40:24.982 4: TSCUL_Parse: CUL_rpi  125971 A F001 11703004 00 1A B5 A010 52B558 F11034 0301000000326400FF00FF014454630000 -69
2017.07.31 21:40:24.999 4: TSCUL_send:  CUL_0                         As 0A B5 8002 F11034 52B558 00
2017.07.31 21:40:25.000 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:90
2017.07.31 21:40:25.099 4: TSCUL_Parse: CUL_0  126079 A F203 01676880 01 0A B5 8002 F11034 52B558 00 _CCAdly:4 -138
2017.07.31 21:40:25.104 4: TSCUL_Parse: CUL_rpi  126094 A F001 11703144 00 0A B5 8002 F11034 52B558 00 -70.5
2017.07.31 21:40:25.109 4: CUL_HM vccu dupe: dont process
2017.07.31 21:40:25.539 4: TSCUL_Parse: CUL_0  126509 A F201 01677336 00 1A B6 A010 52B558 F11034 0311C80000000000000000000000FF9300 -56.5
2017.07.31 21:40:25.553 4: TSCUL_send:  CUL_0                         As 0A B6 8002 F11034 52B558 00
2017.07.31 21:40:25.553 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:90
2017.07.31 21:40:25.671 4: TSCUL_Parse: CUL_0  126650 A F203 01677456 01 0A B6 8002 F11034 52B558 00 _CCAdly:4 _dhmSt:120 -138
2017.07.31 21:40:25.675 4: TSCUL_Parse: CUL_rpi  126665 A F001 11703708 00 0A B6 8002 F11034 52B558 00 -70
2017.07.31 21:40:25.817 4: TSCUL_Parse: CUL_0  126788 A F201 01677620 00 1A B7 A010 52B558 F11034 0381000000326400FF00FF214454930000 -56
2017.07.31 21:40:25.828 4: TSCUL_send:  CUL_0                         As 0A B7 8002 F11034 52B558 00
2017.07.31 21:40:25.829 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:90
2017.07.31 21:40:25.960 4: TSCUL_Parse: CUL_0  126939 A F203 01677744 02 0A B7 8002 F11034 52B558 00 _CCAdly:8 _dhmSt:124 -138
2017.07.31 21:40:25.964 4: TSCUL_Parse: CUL_rpi  126954 A F001 11703992 00 0A B7 8002 F11034 52B558 00 -70.5
2017.07.31 21:40:26.107 4: TSCUL_Parse: CUL_0  127079 A F201 01677912 00 1A B7 A010 52B558 F11034 0381000000326400FF00FF214454930000 -56
2017.07.31 21:40:26.114 4: TSCUL_send:  CUL_0                         As 0A B7 8002 F11034 52B558 00
2017.07.31 21:40:26.115 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:90
2017.07.31 21:40:26.244 4: TSCUL_Parse: CUL_0  127223 A F203 01678032 01 0A B7 8002 F11034 52B558 00 _CCAdly:4 _dhmSt:412 -138
2017.07.31 21:40:26.248 4: TSCUL_Parse: CUL_rpi  127238 A F001 11704272 00 0A B7 8002 F11034 52B558 00 -70.5
2017.07.31 21:40:26.253 4: CUL_HM vccu dupe: dont process
2017.07.31 21:40:26.391 4: TSCUL_Parse: CUL_rpi  127381 A F001 11704408 00 1A B8 A010 52B558 F11034 0391C80000000000000000000000049300 -68.5
2017.07.31 21:40:26.402 4: TSCUL_send:  CUL_0                         As 0A B8 8002 F11034 52B558 00
2017.07.31 21:40:26.403 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:90
2017.07.31 21:40:26.455 4: TSCUL_Parse: CUL_0  127435 A F203 01678244 01 0A B8 8002 F11034 52B558 00 _CCAdly:4 _dhmSt:624 -138
2017.07.31 21:40:26.460 4: TSCUL_Parse: CUL_rpi  127450 A F001 11704480 00 0A B8 8002 F11034 52B558 00 -70.5
2017.07.31 21:40:26.582 4: TSCUL_Parse: CUL_rpi  127572 A F001 11704604 00 0C B9 A010 52B558 F11034 030000 -69.5
2017.07.31 21:40:26.635 4: TSCUL_send:  CUL_0                         As 0A B9 8002 F11034 52B558 00
2017.07.31 21:40:26.636 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:90
2017.07.31 21:40:26.689 4: TSCUL_Parse: CUL_0  127668 A F203 01678480 01 0A B9 8002 F11034 52B558 00 _CCAdly:4 _dhmSt:860 -138
2017.07.31 21:40:26.693 4: TSCUL_Parse: CUL_rpi  127683 A F001 11704708 00 0A B9 8002 F11034 52B558 00 -70.5
2017.07.31 21:40:26.732 4: TSCUL_send:  CUL_0                         As 10 BA A001 F11034 52B558 010452B5580203
2017.07.31 21:40:26.733 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:91 rtoms:1765
2017.07.31 21:40:26.797 4: TSCUL_Parse: CUL_0  127777 A F203 01678584 01 10 BA A001 F11034 52B558 01 _CCAdly:4 _dhmSt:964 -138
2017.07.31 21:40:26.802 4: TSCUL_Parse: CUL_rpi  127792 A F001 11704816 00 10 BA A001 F11034 52B558 010452B5580203 -70.5
2017.07.31 21:40:27.067 4: TSCUL_Parse: CUL_0  128047 A F203 01678856 01 10 BA A001 F11034 52B558 01 _CCAdly:4 _dhmSt:1236 -138
2017.07.31 21:40:27.072 4: TSCUL_Parse: CUL_rpi  128062 A F001 11705080 00 10 BA A001 F11034 52B558 010452B5580203 -70.5
2017.07.31 21:40:27.077 4: CUL_HM vccu dupe: dont process
2017.07.31 21:40:27.337 4: TSCUL_Parse: CUL_0  128316 A F203 01679128 01 10 BA A001 F11034 52B558 01 _CCAdly:4 _dhmSt:1508 -138
2017.07.31 21:40:27.341 4: TSCUL_Parse: CUL_rpi  128332 A F001 11705348 00 10 BA A001 F11034 52B558 010452B5580203 -70.5
2017.07.31 21:40:27.346 4: CUL_HM vccu dupe: dont process
2017.07.31 21:40:27.479 4: TSCUL_Parse: CUL_0  128449 A F201 01679292 00 1A BA A010 52B558 F11034 0301000000326400FF00FF011112630000 -56.5
2017.07.31 21:40:27.499 4: TSCUL_send:  CUL_0                         As 0A BA 8002 F11034 52B558 00
2017.07.31 21:40:27.500 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:90
2017.07.31 21:40:27.614 4: TSCUL_Parse: CUL_0  128594 A F203 01679412 01 0A BA 8002 F11034 52B558 00 _CCAdly:4 _dhmSt:120 -138
2017.07.31 21:40:27.619 4: TSCUL_Parse: CUL_rpi  128609 A F001 11705620 00 0A BA 8002 F11034 52B558 00 -70.5
2017.07.31 21:40:28.053 4: TSCUL_Parse: CUL_rpi  129044 A F001 11706044 00 1A BB A010 52B558 F11034 0311C80000000000000000000000FF6800 -68.5
2017.07.31 21:40:28.065 4: TSCUL_send:  CUL_0                         As 0A BB 8002 F11034 52B558 00
2017.07.31 21:40:28.066 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:90
2017.07.31 21:40:28.118 4: TSCUL_Parse: CUL_0  129097 A F203 01679920 02 0A BB 8002 F11034 52B558 00 _CCAdly:8 _dhmSt:628 -138
2017.07.31 21:40:28.122 4: TSCUL_Parse: CUL_rpi  129112 A F001 11706116 00 0A BB 8002 F11034 52B558 00 -70.5
2017.07.31 21:40:28.263 4: TSCUL_Parse: CUL_0  129234 A F201 01680084 00 1A BC A010 52B558 F11034 0381000000326400FF00FF211112680000 -56.5
2017.07.31 21:40:28.274 4: TSCUL_send:  CUL_0                         As 0A BC 8002 F11034 52B558 00
2017.07.31 21:40:28.275 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:90
2017.07.31 21:40:28.401 4: TSCUL_Parse: CUL_0  129380 A F203 01680204 01 0A BC 8002 F11034 52B558 00 _CCAdly:4 _dhmSt:120 -138
2017.07.31 21:40:28.405 4: TSCUL_Parse: CUL_rpi  129395 A F001 11706392 00 0A BC 8002 F11034 52B558 00 -70.5
2017.07.31 21:40:29.235 4: TSCUL_Parse: CUL_0  130207 A F201 01681060 00 1A BD A010 52B558 F11034 0391C80000000000000000000000046800 -56
2017.07.31 21:40:29.246 4: TSCUL_send:  CUL_0                         As 0A BD 8002 F11034 52B558 00
2017.07.31 21:40:29.247 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:90
2017.07.31 21:40:29.370 4: TSCUL_Parse: CUL_0  130349 A F203 01681180 01 0A BD 8002 F11034 52B558 00 _CCAdly:4 _dhmSt:120 -138
2017.07.31 21:40:29.374 4: TSCUL_Parse: CUL_rpi  130365 A F001 11707348 00 0A BD 8002 F11034 52B558 00 -70.5
2017.07.31 21:40:30.185 4: TSCUL_Parse: CUL_0  131164 A F201 01682024 00 0C BE A010 52B558 F11034 030000 -56.5
2017.07.31 21:40:30.231 4: TSCUL_send:  CUL_0                         As 0A BE 8002 F11034 52B558 00
2017.07.31 21:40:30.232 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:90
2017.07.31 21:40:30.330 4: TSCUL_Parse: CUL_0  131310 A F203 01682144 01 0A BE 8002 F11034 52B558 00 _CCAdly:4 _dhmSt:120 -138
2017.07.31 21:40:30.973 4: TSCUL_Parse: CUL_rpi  131964 A F001 11708148 00 0C BE A010 52B558 F11034 030000 -69
2017.07.31 21:40:30.983 4: TSCUL_Parse: CUL_rpi  131973 A F001 11708288 00 0A BE 8002 F11034 52B558 00 -70.5
2017.07.31 21:40:42.873 4: TSCUL_Parse: CUL_rpi  143862 A F002 11720628 00 15 AA001122AA001122AA001122AA001122AA001122AA _ping -138
2017.07.31 21:40:52.261 4: TSCUL_Parse: CUL_0  153234 A F202 01704256 00 15 AA001122AA001122AA001122AA001122AA001122AA _ping -138
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 31 Juli 2017, 23:58:44
Hallo Kai,

ZitatIst das die einzige hierfür relevante Änderung? Dann könnte ich das ja auch erstmal manuell in der 0.10 Version ändern die aktuell läuft.
Ja und musst Du nur in rf_asksin.c nach CC1101_AGCCTRL2 in ASKSIN_CFG[] und ASKSIN_UPDATE_CFG[] ergänzen.

So sieht es bei mir jetzt aus:

# define ASKSIN_IOCFG2   0x07  // GDO2, CRC OK packet received, deasserts with read of first RX-FIFO byte
# define ASKSIN_IOCFG0   0x01  // GDO0, Associated to the RX FIFO: Asserts when RX FIFO is filled at or above the RX FIFO threshold or the end of packet is reached. De-asserts when the RX FIFO is empty
# define ASKSIN_FIFOTHR  0x41  // 0x03  0d -> 4d, 1 ADC retention (BW <= 325kHz), 0 close in RX, TX FIFO = 57 / RX FIFO = 8 byte
# define ASKSIN_PKTCTRL1 ASKSIN_PKTCTRL1_CRC_AUTOFLUSH_ON  // PQT = 0, CRC auto flush = 1, append status = 1, no address check


const uint8_t ASKSIN_CFG[] PROGMEM = {
     // we start with SRES -> so defaults in registers
//   REGISTER         VAL                   IDX   Remark
     CC1101_IOCFG2,   ASKSIN_IOCFG2,     // 0x00
     CC1101_IOCFG0,   ASKSIN_IOCFG0,     // 0x02  GDO0 not used, Associated to the RX FIFO: Asserts when RX FIFO is filled at or above the RX FIFO threshold or the end of packet is reached. De-asserts when the RX FIFO is empty
     CC1101_FIFOTHR,  ASKSIN_FIFOTHR,    // 0x03
     CC1101_SYNC1,    0xE9,              // 0x04  Sync word, High Byte
     CC1101_SYNC0,    0xCA,              // 0x05  Sync word, Low Byte
     CC1101_PKTLEN,   61,                // 0x06  maximum paket lenght, set to avoid RXFIFO_OVERFLOW issue, see errata and automatically discards much too long packages
     CC1101_PKTCTRL1, ASKSIN_PKTCTRL1,   // 0x07
     CC1101_FSCTRL1,  0x06,              // 0x0B  frequency synthesizer control, IF_FREQ
     CC1101_FREQ2,    0x21,              // 0x0D  868.299866 MHz
     CC1101_FREQ1,    0x65,              // 0x0E
     CC1101_FREQ0,    0x6A,              // 0x0F
     CC1101_MDMCFG4,  0xC8,              // 0x10  channel bandwidth, data rate
     CC1101_MDMCFG3,  0x93,              // 0x11  data rate
     CC1101_MDMCFG2,  0x03,              // 0x12  modulation 2-FSK, 30/32 sync word bits detected
     CC1101_DEVIATN,  0x34,              // 0x15  deviation
     CC1101_MCSM1,    ASKSIN_MCSM1_MODE, // 0x17
     CC1101_MCSM0,    0x18,              // 0x18  PO_TIMEOUT=64 (149 – 155us), FS_AUTOCAL=Calibration: IDLE to RX or TX (or FSTXON)
     CC1101_FOCCFG,   0x16,              // 0x19  0x16 FOC_BS_CS_GATE=allways running, FOC_PRE_K=3K, FOC_POST_K=K/2, FOC_LIMIT=±BWCHAN/4, FREQEST (0x32) gives the result of the Frequency Offset Compensation
     CC1101_AGCCTRL2, 0x43,              // 0x1B  MAX_DVGA_GAIN 1
     CC1101_AGCCTRL1, 0x67,              // 0x1C  new CARRIER_SENSE_REL_THR 10dB, CARRIER_SENSE_ABS_THR MAGN_TARGET 7dB
//     CC1101_FREND1,   0x56,              // 0x21  BW <= 101kHz, default is 0x56
     CC1101_FSCAL1,   0x00,              // 0x25
     CC1101_FSCAL0,   0x11,              // 0x26
//     CC1101_FSTEST,   0x59,              // 0x29  FSTEST, 0x59 is default
     CC1101_TEST2,    0x81,              // 0x2C  BW <= 325kHz
     CC1101_TEST1,    0x35,              // 0x2D  BW <= 325kHz
     CC1101_PATABLE,  0xC3,              // 0x3E  0x81, // 0x8D->0.6dB, 0x81->5dB, 0xC6->8.5dB, 0xC3->9.6dB

     CC1101_CONFIG_A_D_TABLE_END
};

const uint8_t ASKSIN_UPDATE_CFG[] PROGMEM = {
     CC1101_FSCTRL1,  0x08,              // 0x0B
     CC1101_MDMCFG4,  0x5B,              // 0x10  channel bandwidth, data rate
     CC1101_MDMCFG3,  0xF8,              // 0x11  data rate
     CC1101_DEVIATN,  0x47,              // 0x15  deviation
     CC1101_FOCCFG,   0x1D,              // 0x19  0x1D FOC_BS_CS_GATE=allways running, FOC_PRE_K=4K, FOC_POST_K=K/2, FOC_LIMIT=±BWCHAN/8, FREQEST (0x32) gives the result of the Frequency Offset Compensation
     CC1101_BSCFG,    0x1C,              // 0x1A
     CC1101_AGCCTRL2, 0xC7,              // 0x1B
     CC1101_AGCCTRL1, 0x00,              // 0x1C
     CC1101_AGCCTRL0, 0xB2,              // 0x1D
     CC1101_FREND1,   0xB6,              // 0x21  BW > 101kHz
     CC1101_FSCAL3,   0xEA,              // 0x23

     CC1101_CONFIG_A_D_TABLE_END
};


ZitatWenn du mir jetzt noch die Sourcen gibst so dass ich die IR Konfiguration anpassen kann dann sehe ich Licht am Ende des Tunnels.
Ich glaube, das Licht kann mit den aktuellen Sourcen auch zum Zug werden.  :o
Da ist zu viel unvollständiges und ungetestetes im Bezug auf CUNX drin. Zudem nur mit gcc4.9.2 compilierbar.
Sei mir nicht böse, aber das möchte ich weder Dir noch mir jetzt antun.

Ändere also lieber die 0.10er Version im source so minimal ab. Das wird Dir genauso beim CCA Problem helfen. Und nur eine Änderung zum bestehenden Problem was die Ergebnisanalyse vereinfacht.  ;)

ZitatEin letzter Test noch, ein
set az_Rollo getConfig
schlägt mit
RESPONSE TIMEOUT:RegisterRead
fehl.
Du kannst mit der Änderung trotz etwas Störungen Senden, was nicht bedeutet, dass das was gestört hat damit nicht mehr stört. Die Änderung sorgt nur dafür, dass gesendet wird, obwohl noch etwas anderes "relativ leise" empfangen wird.

Teilweise sehe ich im Log, dass der CUL_rpi eher eine Antwort empfängt, als der CUL_0.
Weiterhin die Störquelle oder dessen Empfang zu bekämpfen dürfte eher helfen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: kaihs am 10 August 2017, 22:04:45
Hallo Ansgar,

ich will mal nur kurz Rückmeldung über den aktuellen Stand geben.

Ich habe jetzt eine externe Antenne an den CUL_0 angeschlossen. Ganz selten bekomme ich immer noch CCA Fehler.
Ich warte noch auch einen SDR-Stick um das Spektrum analysieren zu können.
Ich verwende jetzt die 0.10 FW ohne Anpassungen an der CCA Empfindlichkeit.

Allerdings erhalte ich reproduzierbar auch solche Fehler:

2017.08.10 21:54:59.825 4: TSCUL_send:  CUL_0                         As 0C 16 A011 F11034 52B558 02013E
2017.08.10 21:54:59.826 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:90 rtoms:1761
2017.08.10 21:54:59.883 4: TSCUL_Parse: CUL_0  449951 A F103 05649984 02 0C 16 A011 F11034 52B558 02 _CCAdly:8 -138
2017.08.10 21:55:00.146 4: TSCUL_Parse: CUL_0  450214 A F103 05650252 01 0C 16 A011 F11034 52B558 02 _CCAdly:4 -138
2017.08.10 21:55:00.413 4: TSCUL_Parse: CUL_0  450481 A F103 05650520 01 0C 16 A011 F11034 52B558 02 _CCAdly:4 -138
2017.08.10 21:55:00.643 1: TSCUL_ParseTsHM: CUL_0 HM repeat failed to 52B558/az_Rollo:  450710 A F109 05650784 00 0C 16 A011 F11034 52B558 02 _sfail
2017.08.10 21:55:01.595 4: TSCUL_XmitAwaitTo CUL_0: timeout - 52B558
2017.08.10 21:55:09.824 4: TSCUL_Parse: CUL_0  459888 A F001 05660100 00 0D 17 A410 52B558 F11034 06013E00 -37.5
2017.08.10 21:55:09.825 4: TSCUL_Parse: CUL_0 dispatching A0D17A41052B558F1103406013E00::-37.5:CUL_0
2017.08.10 21:55:09.840 4: TSCUL_send:  CUL_0                         As 0A 17 8002 F11034 52B558 00
2017.08.10 21:55:09.841 4: TSCUL_XmitDlyHM:  CUL_0  id:52B558 toms:90
2017.08.10 21:55:10.208 4: TSCUL_Parse: CUL_0  460275 A F103 05660220 01 0A 17 8002 F11034 52B558 00 _CCAdly:4 _dhmSt:120 -138


CUL_0 ist wie gesagt direkt (serielle Schnittstelle) angeschlossen.
Abstand Antenne und az_Rollo ca. 1m, der Fehler tritt aber auch bei weiter entfernten Aktoren auf.
Gibt es eine Erklärung für das "TSCUL_ParseTsHM: CUL_0 HM repeat failed"?


Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 11 August 2017, 21:50:32
Hallo Kai,

ZitatIch habe jetzt eine externe Antenne an den CUL_0 angeschlossen. Ganz selten bekomme ich immer noch CCA Fehler.
Selten ist relativ und kann bedeuten, das zu dem Zeitpunkt ein anderes Gerät sendet oder dass Dein Antennenkabel noch zu kurz ist (Besserung ist ja eingetreten) oder dass der Rechner noch Störungen direkt auf die Empfängerplatine einstrahlt.

ZitatAllerdings erhalte ich reproduzierbar auch solche Fehler:
Was bedeutet reproduzierbar?
Welche gleiche Aktion führt dazu...

ZitatGibt es eine Erklärung für das "TSCUL_ParseTsHM: CUL_0 HM repeat failed"?
Ist es immer der gleiche Befehl, abgesehen vom Message Counter, bei dem das auftritt?
tsculfw sendet bei Nachrichten mit gesetztem Antwortflag 3 Versuche, wenn es die erwartete Antwort mit gleichem Message Counter nicht bekommt.
D.h. entweder antwortet das Device einfach nicht mit der angeforderte Antwort (mindestens ein ACK müsste kommen).
Oder die angeforderte Antwort wird 3 mal jeweils nicht innerhalb der erwarteten Zeit von tsculfw empfangen (zu nah dran kann auch negativ sein!).
Oder das device hat eine so unglücklich unpassende Antwort Zeit, die mit dem Senden der Wiederholung zusammen fällt und daher wegen der RX/TX oder TX/RX Umschaltzeit gerade nicht empfangen werde kann.

Letzteres liesse sich durch Anpassung des Antwort Timout Timings in der tsculfw beeinflussen.
Ich habe das Wiederholtiming so versucht einzustellen, dass es auch mit einem HM Repeater noch klappen sollte und aus emprischen Erfahrungen mit meiner beschränkten Auswahl an devices sowie aus Logs von Usern die mal HMLAN "zugehört" haben.
Rollos habe ich leider nicht zum Testen.

Empfängt denn das andere rpiaddon in diesem Zeitraum eine Antwort vom device?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bytechanger am 14 August 2017, 21:59:20
Hallo,

leider bekomme ich ein Firmwareupdate über meinen CUL nicht hin.
Im Log steht immer wieder "TSCUL_ParseTsHM: CUL0 HM repeat failed to 43F1C8/Markise:  417761 A F689 00328792 00 1D AE 20CA 1DA462 43F1C8 00 _fup _sfail"

Was mache ich falsch, oder hat jemand einen Tipp??

Grüße

Byte
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bytechanger am 14 August 2017, 22:30:16
Hallo,

leider bekomme ich ein Firmwareupdate über meinen CUL nicht hin.
Im Log steht immer wieder "TSCUL_ParseTsHM: CUL0 HM repeat failed to 43F1C8/Markise:  417761 A F689 00328792 00 1D AE 20CA 1DA462 43F1C8 00 _fup _sfail"

Auch mit der Änderung bleibt es unverändert:
sub CUL_HM_FWupdateSteps($){#steps for FW update
  my $mIn = shift;

...

    CUL_HM_SndCmd($hash,"${mNoA}00CB$id${dst}105B11F81547");
#    CUL_HM_SndCmd($hash,"${mNoA}20CB$id${dst}105B11F815470B081A1C191D1BC71C001DB221B623EA");
    select(undef, undef, undef, (0.2)); # longer wait for tsculfw
    CUL_HM_FWupdateSpeed($name,100)



Was mache ich falsch, oder hat jemand einen Tipp??

Grüße

Byte
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 14 August 2017, 23:02:45
Hallo Byte,

welche TS Firmware und welche TS Module hast Du installiert? Die letzte Version https://forum.fhem.de/index.php/topic,24436.msg640892.html#msg640892 (https://forum.fhem.de/index.php/topic,24436.msg640892.html#msg640892)?
Benutzt Du das aktuelle 10_CUL_HM.pm Modul von Martin?

Was ist es für ein CUL? List vom CUL?!

Welches Device Modell willst Du updaten?

Ist der Aktor weit weg oder in guter Funkreichweite?

Log vom Updatevorgang mit verbose 4?!

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bytechanger am 15 August 2017, 06:39:37
Hallo,

ich habe einen CUL V3 mit installierter V0.10.
Es handelt sich um ein HM-LC-Bl1PBU-FM das von V 2.8 auf V2.11 geupdated werden soll.

Er ist in einer vccu mit einem hmlan eingebettet. Das HMLAN deaktiviere ich aber, bzw. habe den
Stecker gezogen, damit es nicht dazwischen funkt.

Funkempfang Markisen-Aktor:
rssi_CUL0 max:-78 cnt:1 lst:-78 min:-78 avg:-78
rssi_at_CUL0  cnt:19 lst:-77.5 max:-77 min:-79.5 avg:-77.73

List CUL0:
Internals:
   CMDS       ABCEFGJKMRTUVWXYZeilmtx
   CUL0_MSGCNT 1111
   CUL0_TIME  2017-08-15 06:34:52
   Clients    STACKABLETS:STACKABLE:CUL_HM:HMS:CUL_IR
   DEF        /dev/serial/by-id/usb-busware.de_CUL868_868000-if00 0000
   DeviceName /dev/serial/by-id/usb-busware.de_CUL868_868000-if00
   FD         10
   FHTID      0000
   NAME       CUL0
   NR         124
   PARTIAL
   RAWMSG     A0E2C800217E2BB1C58010054CDF9E0::-95.5:CUL0
   RSSI       -95.5
   STATE      Initialized
   TYPE       TSCUL
   VERSION    VTS 0.10 CUL868
   VERSION_HW CUL_V3.4
   VERSION_TS yes
   XmitOpen   1
   initString X21
Ar
   owner_CCU  vccu
   MatchList:
     1:STACKABLETS ^\*
     2:STACKABLE ^\*
     A:CUL_HM   ^A[F(?A)]
     B:HMS      ^810e04....(1|5|9).a001
     C:CUL_IR   ^I............
   READINGS:
     2016-09-19 15:06:13   IntCalcStat     Last: 21.9  Min: 21.9  Mean: 21.9  Max: 50.9
     2016-09-19 15:06:13   Ints_per_sec    SI: 3.22848  TI: 1.40316  S: 0.08504  L: 0.00000  U: 0.00911  M: 0.00000
     2017-08-14 23:02:41   Xmit-Events     ok:1 disconnected:1 init:2
     2017-08-14 23:02:10   cmds             A B C E F G J K M R T U V W X Y Z e i l m t x
     2017-08-14 23:02:41   cond            ok
     2016-10-24 18:06:31   hmSioDly        2
     2016-09-19 20:46:49   prot_ERROR-Overload last
     2016-11-15 22:01:05   prot_Warning-HighLoad last
     2017-08-14 23:02:09   prot_disconnected last
     2017-08-14 23:02:10   prot_init       last
     2017-08-14 23:02:41   prot_ok         last
     2016-08-29 08:01:41   raw             V 1.66 CUL868
     2017-08-15 06:29:10   scF             0.999965952117542
     2017-08-14 23:02:10   state           Initialized
     2016-09-19 14:59:47   uptime          0 00:24:46
     2016-09-19 20:24:54   version         V 99.79 CUL868
   helper:
     CUrun      1
     ChkPart    0
     hmTSAt1Add
     DEVIO:
       RXfailTO
     HM:
       FUP        0
       hmCrdts    0
       hmSbusy    0
       unknwn:
     cnd:
       0          1
       253        1
       255        2
     hmQ:
       2781D4:
       2781F7:
       43F1C8:
       444922:
       487DB9:
       487EBB:
       487F9B:
       4882DA:
       48FDC8:
     q:
       ATrNo      0
       HMcndN     0
       InQueues   0
       XRpCnt     0
       XRpTm      1502744661.59309
       answerPend 0
       hmLanQlen  1
       apIDs:
         43F1C8     0
         444922     0
       cap:
         sum        33750
     ref:
       Sdly       249
       ioByteRate 1000000
       ioByteRateMeas 46184.3757955349
       lHMt       31362040
       lSys       606593885
       pTTu       1024
       pndAs      0
       pndCUAp    0
       pngLm      9
       pngMax     476
       pngMaxTot  476
       pngMin     1
       pngRef     3
       pngtm      606538479
       scErr      7.30351470224559
       scF        0.999965952117542
       scFN       26
       scHT       21065280
       scST       596297482
Attributes:
   event-on-change-reading .*
   group      Sender
   hmId       1DA462
   hmLanQlen  1_min
   icon       cul_cul
   rfmode     HomeMatic
   room       Basis
   verbose    2


Dann habe ich in der Datei 10_CUL_HM noch

select(undef, undef, undef, (0.2)); # longer wait for tsculfw

angepasst.
Welche 10_CUL_HM.pm von Martin meinst Du?? Sind dort noch weitere Anpassungen drin?

Greets

Byte
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 15 August 2017, 09:03:11
Hallo Byte,

Zitatich habe einen CUL V3 mit installierter V0.10.
Hast Du auch die Module, insbesondere 00_TSCUL.pm und DevIoTS.pm auf dem Stand zur Firmware aus dem Link, den ich angeben habe?

Darin ist die zusätzliche Wartezeit in TSCUL_Write($$$) schon eingebaut, die Du nun nochmal in CUL_HM zu verlängern versuchst.

ZitatWelche 10_CUL_HM.pm von Martin meinst Du?? Sind dort noch weitere Anpassungen drin?
Die aktuellst, die unter den FHEM Sourcen oder über FHEM update zu bekommen ist.

Zitatrssi_CUL0 max:-78 cnt:1 lst:-78 min:-78 avg:-78
rssi_at_CUL0  cnt:19 lst:-77.5 max:-77 min:-79.5 avg:-77.73
Das ist schon schwach. Keine Ahnung, ob das bei hoher Updatedatenrate noch klappt. Näher ran wäre wohl besser.

ZitatEs handelt sich um ein HM-LC-Bl1PBU-FM das von V 2.8 auf V2.11 geupdated werden soll.
Hast Du den erst nach der beigefügten Changelog in den Update Modus geschaltet oder es direkt über FHEM versucht.
Wenn der gepaired ist, dann sollte es wohl direkt gehen. Allerdings habe ich den Aktor nicht und kann daher nicht sagen, ob er vorbereitet werden muss oder irgendwas anders ist.

Und wo ist das Log mit CUL auf verbose 4 mit einem Updateversuch zur Glaskugelerhellung?

Credits musst Du vorher bei CUL immer schön voll "aufladen" lassen, damit es während des Updates nicht daran mangelt. War jedoch CULseits (noch) nicht das Problem in Deinem Einzeiler Log Auszug.
Der Aktor hat nur auf irgendwas nicht geantwortet.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bytechanger am 15 August 2017, 11:57:41
Hallo,

also ich habe natürlich auch die FHEM Dateien aus dem Firmware.zip kopiert.
Die Änderung an der 10_CUL_HM habe ich nur nachträglich vorgenommen, als es nicht ging. Brachte aber keinen Erfolg. Habe das FHEM-System über Update auf dem neuesten Stand.

Die Firmwareupdates mache ich über FHEM ausgeführt. Der Aktor ist schon länger im System eingebunden und läuft ohne Probleme (auch AES).

Credits waren kein Problem.

Hier das Log des Update-Versuchs bis zum ersten Fehlversuchs mit CUL Verbose 4:

2017.08.15 12:04:36.068 2: CUL_HM fwUpdate started for Markise
2017.08.15 12:04:36.070 4: TSCUL_send:  CUL0                         As 0A 0A 3011 1DA462 43F1C8 CA
2017.08.15 12:04:36.071 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:436 rtoms:2766
2017.08.15 12:04:36.155 3: CUL_HM set Markise fwUpdate eq.eq3
2017.08.15 12:04:36.672 4: TSCUL_Parse: CUL0  140736 A F103 01375804 02 0A 0A 3011 1DA462 43F1C8 CA _bst _CCAdly:8 -138
2017.08.15 12:04:36.674 4: TSCUL_Parse: CUL0  140737 A F101 01376296 00 11 0A A002 43F1C8 1DA462 0453BE8AC2C66202 -75
2017.08.15 12:04:36.930 4: TSCUL_Parse: CUL0  140994 A F103 01376416 01 19 0A A003 1DA462 43F1C8 79 _CCAdly:4 _dhmSt:120 -138
2017.08.15 12:04:36.932 4: TSCUL_Parse: CUL0  140995 A F101 01376572 00 12 0A 8002 43F1C8 1DA462 010164304CE1029A6F -74.5
2017.08.15 12:04:36.934 4: TSCUL_Parse: CUL0  140997 A F101 01376652 00 14 00 0010 43F1C8 000000 004D455131373331353032 -75.5
2017.08.15 12:04:36.935 2: CUL_HM fwUpdate Markise entered mode. IO-speed: fast
2017.08.15 12:04:36.936 4: TSCUL_send:  CUL0                         As 0F 0B 00CB 1DA462 43F1C8 105B11F81547
2017.08.15 12:04:36.937 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:100
2017.08.15 12:04:37.418 4: TSCUL_send:  CUL0                         As 27 0D 00CA 1DA462 43F1C8 0102267D269AD1E5142CB43C72463102BAB8BF3232F560713D57A5B8915E
2017.08.15 12:04:37.418 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:119
2017.08.15 12:04:37.438 4: TSCUL_Parse: CUL0  141502 A F103 01376772 01 0F 0B 00CB 1DA462 43F1C8 10 _CCAdly:4 _dhmSt:120 -138
2017.08.15 12:04:37.440 4: TSCUL_Parse: CUL0  141504 A F183 01377152 01 27 0D 00CA 1DA462 43F1C8 01 _fup _CCAdly:4 _dhmSt:500 -138
2017.08.15 12:04:37.694 4: TSCUL_send:  CUL0                         As 27 0E 00CA 1DA462 43F1C8 99993E78F907BCF70CFF1C688D593A937FDAD80A52D9D57B13A5BE834BB7
2017.08.15 12:04:37.695 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:37.952 4: TSCUL_send:  CUL0                         As 27 0F 00CA 1DA462 43F1C8 03AE9F484BF8A2120F1CE94D1837AF6F3D9377DA06609FCD7B98F7C51827
2017.08.15 12:04:37.953 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:37.956 4: TSCUL_Parse: CUL0  142019 A F183 01377428 01 27 0E 00CA 1DA462 43F1C8 99 _fup _CCAdly:4 _dhmSt:776 -138
2017.08.15 12:04:38.211 4: TSCUL_send:  CUL0                         As 27 10 00CA 1DA462 43F1C8 C46BC98C97B579ACC03032DF624F207D6582831A677B99A728B8E8CBE189
2017.08.15 12:04:38.212 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:38.271 4: TSCUL_Parse: CUL0  142335 A F183 01377688 02 27 0F 00CA 1DA462 43F1C8 03 _fup _CCAdly:8 _dhmSt:1036 -138
2017.08.15 12:04:38.273 4: TSCUL_Parse: CUL0  142337 A F183 01377944 01 27 10 00CA 1DA462 43F1C8 C4 _fup _CCAdly:4 _dhmSt:1292 -138
2017.08.15 12:04:38.525 4: TSCUL_send:  CUL0                         As 27 11 00CA 1DA462 43F1C8 CBD08358BA870B2549E5A54AC6FB29A82A58C22164A5DF47D82A3B55BD0C
2017.08.15 12:04:38.526 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:38.780 4: TSCUL_send:  CUL0                         As 27 12 00CA 1DA462 43F1C8 E925B1FE7DEB4EC35DC27C9FF7CCFCB70D855FF04CE25F3D84A074AF588D
2017.08.15 12:04:38.781 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:38.785 4: TSCUL_Parse: CUL0  142849 A F183 01378260 02 27 11 00CA 1DA462 43F1C8 CB _fup _CCAdly:8 _dhmSt:1608 -138
2017.08.15 12:04:39.039 4: TSCUL_send:  CUL0                         As 27 13 00CA 1DA462 43F1C8 8C859E16845427D7EF5F63C3AE91C4EE51543667145DBF8376BF142247DC
2017.08.15 12:04:39.039 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:39.051 4: TSCUL_Parse: CUL0  143114 A F183 01378516 02 27 12 00CA 1DA462 43F1C8 E9 _fup _CCAdly:8 _dhmSt:1864 -138
2017.08.15 12:04:39.306 4: TSCUL_send:  CUL0                         As 27 14 00CA 1DA462 43F1C8 788A4299F4C371560657DA066BFB52EEA0C74977CDBD06ABC7207FD4EBDF
2017.08.15 12:04:39.307 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:39.310 4: TSCUL_Parse: CUL0  143373 A F183 01378772 01 27 13 00CA 1DA462 43F1C8 8C _fup _CCAdly:4 _dhmSt:2120 -138
2017.08.15 12:04:39.564 4: TSCUL_send:  CUL0                         As 1D 15 20CA 1DA462 43F1C8 5753431E182034301FDC39933BFF3B07F0F6037D
2017.08.15 12:04:39.565 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:15 rtoms:1746
2017.08.15 12:04:39.611 4: TSCUL_Parse: CUL0  143674 A F183 01379040 01 27 14 00CA 1DA462 43F1C8 78 _fup _CCAdly:4 _dhmSt:2388 -138
2017.08.15 12:04:39.613 4: TSCUL_Parse: CUL0  143676 A F183 01379296 01 1D 15 20CA 1DA462 43F1C8 57 _fup _CCAdly:4 _dhmSt:2644 -138
2017.08.15 12:04:39.878 4: TSCUL_Parse: CUL0  143940 A F181 01379364 00 0A 15 0002 43F1C8 1DA462 00 _fup -72.5
2017.08.15 12:04:40.142 4: TSCUL_send:  CUL0                         As 27 16 00CA 1DA462 43F1C8 0112F795BB5822B33CA4A36BE0DDDD99DB4DB61B5BC680AF9ACFF9E2AF69
2017.08.15 12:04:40.142 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:40.165 4: TSCUL_Parse: CUL0  144229 A F183 01379876 01 27 16 00CA 1DA462 43F1C8 01 _fup _CCAdly:4 _dhmSt:512 -138
2017.08.15 12:04:40.420 4: TSCUL_send:  CUL0                         As 27 17 00CA 1DA462 43F1C8 6093DFE4D1F4AEC226BD3550ACBB2D33DF56E1356CEAFC169CB66E3687D5
2017.08.15 12:04:40.420 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:40.682 4: TSCUL_send:  CUL0                         As 27 18 00CA 1DA462 43F1C8 CC750F42F74BFC7BAFBBD6D167FC32A39EA3196C96B779D9632E023966C7
2017.08.15 12:04:40.683 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:40.692 4: TSCUL_Parse: CUL0  144755 A F183 01380152 01 27 17 00CA 1DA462 43F1C8 60 _fup _CCAdly:4 _dhmSt:788 -138
2017.08.15 12:04:40.952 4: TSCUL_send:  CUL0                         As 27 19 00CA 1DA462 43F1C8 B41FEF52D3538B617140D1D8268E5F33E378E0A235AEB230E5B3255155DB
2017.08.15 12:04:40.952 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:40.959 4: TSCUL_Parse: CUL0  145022 A F183 01380416 01 27 18 00CA 1DA462 43F1C8 CC _fup _CCAdly:4 _dhmSt:1052 -138
2017.08.15 12:04:41.220 4: TSCUL_send:  CUL0                         As 27 1A 00CA 1DA462 43F1C8 B885F760799CEBB50886F4D24EE61BA59604850A7EAAAAFF721B1588A61A
2017.08.15 12:04:41.221 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:41.230 4: TSCUL_Parse: CUL0  145293 A F183 01380684 01 27 19 00CA 1DA462 43F1C8 B4 _fup _CCAdly:4 _dhmSt:1320 -138
2017.08.15 12:04:41.491 4: TSCUL_send:  CUL0                         As 27 1B 00CA 1DA462 43F1C8 46A69714EE0EADED1AE6976651D49256D14285C57543CBDCED29BD87B93D
2017.08.15 12:04:41.491 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:41.500 4: TSCUL_Parse: CUL0  145563 A F183 01380956 02 27 1A 00CA 1DA462 43F1C8 B8 _fup _CCAdly:8 _dhmSt:1592 -138
2017.08.15 12:04:41.761 4: TSCUL_send:  CUL0                         As 27 1C 00CA 1DA462 43F1C8 0CACCA4DE0BBB14F006A1FF2E9C61B33E6D5AE27EDD4FE5CD4D388ADC21A
2017.08.15 12:04:41.761 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:41.767 4: TSCUL_Parse: CUL0  145830 A F183 01381224 01 27 1B 00CA 1DA462 43F1C8 46 _fup _CCAdly:4 _dhmSt:1860 -138
2017.08.15 12:04:42.023 4: TSCUL_send:  CUL0                         As 27 1D 00CA 1DA462 43F1C8 5582B5CDA242B4F27262F3A46CF639DC490162C39E6B2E8EA686F53C9114
2017.08.15 12:04:42.023 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:42.027 4: TSCUL_Parse: CUL0  146090 A F183 01381496 02 27 1C 00CA 1DA462 43F1C8 0C _fup _CCAdly:8 _dhmSt:2132 -138
2017.08.15 12:04:42.285 4: TSCUL_send:  CUL0                         As 27 1E 00CA 1DA462 43F1C8 26C9B6EA9B19575E9EDE79499BB515B0F32A3DEC3D4277968E1EEF5F6B46
2017.08.15 12:04:42.285 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:42.294 4: TSCUL_Parse: CUL0  146357 A F183 01381756 01 27 1D 00CA 1DA462 43F1C8 55 _fup _CCAdly:4 _dhmSt:2392 -138
2017.08.15 12:04:42.553 4: TSCUL_send:  CUL0                         As 0F 1F 20CA 1DA462 43F1C8 397BDCA81DD0
2017.08.15 12:04:42.553 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:14 rtoms:1746
2017.08.15 12:04:42.645 4: TSCUL_Parse: CUL0  146709 A F183 01382020 02 27 1E 00CA 1DA462 43F1C8 26 _fup _CCAdly:8 _dhmSt:2656 -138
2017.08.15 12:04:42.648 4: TSCUL_Parse: CUL0  146711 A F183 01382284 01 0F 1F 20CA 1DA462 43F1C8 39 _fup _CCAdly:4 _dhmSt:2920 -138
2017.08.15 12:04:42.650 4: TSCUL_Parse: CUL0  146713 A F181 01382340 00 0A 1F 0002 43F1C8 1DA462 00 _fup -72.5
2017.08.15 12:04:42.920 4: TSCUL_send:  CUL0                         As 1D 20 20CA 1DA462 43F1C8 0012805242DEC8D7F22C3BD9A9EAA0C4DCD3C7F3
2017.08.15 12:04:42.920 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:15 rtoms:1746
2017.08.15 12:04:43.184 4: TSCUL_Parse: CUL0  147247 A F183 01382652 01 1D 20 20CA 1DA462 43F1C8 00 _fup _CCAdly:4 _dhmSt:312 -138
2017.08.15 12:04:43.187 4: TSCUL_Parse: CUL0  147249 A F181 01382672 00 0A 20 0002 43F1C8 1DA462 00 _fup -72.5
2017.08.15 12:04:43.451 4: TSCUL_send:  CUL0                         As 27 21 00CA 1DA462 43F1C8 0112E6A579D0EE483F6193BE3A3B4F17DDC5DAE26F9537AAC911C281A310
2017.08.15 12:04:43.452 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:43.713 4: TSCUL_send:  CUL0                         As 27 22 00CA 1DA462 43F1C8 12E4E2B1A4537653FFD094A92695F6D49868235E5049E2CFFB8EB9307B7D
2017.08.15 12:04:43.714 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:43.720 4: TSCUL_Parse: CUL0  147783 A F183 01383184 01 27 21 00CA 1DA462 43F1C8 01 _fup _CCAdly:4 _dhmSt:512 -138
2017.08.15 12:04:43.975 4: TSCUL_send:  CUL0                         As 27 23 00CA 1DA462 43F1C8 BD52F0BA70BB38FF46246FAF0EE274CA60015399C3864C28DB254C431D89
2017.08.15 12:04:43.976 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:43.979 4: TSCUL_Parse: CUL0  148043 A F183 01383448 01 27 22 00CA 1DA462 43F1C8 12 _fup _CCAdly:4 _dhmSt:776 -138
2017.08.15 12:04:44.233 4: TSCUL_send:  CUL0                         As 27 24 00CA 1DA462 43F1C8 EED1076B2706B1C49E227CCFF1DCB2EF0C45D2F1E1E92A8D5ABA019E81D1
2017.08.15 12:04:44.233 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:44.237 4: TSCUL_Parse: CUL0  148301 A F183 01383708 01 27 23 00CA 1DA462 43F1C8 BD _fup _CCAdly:4 _dhmSt:1036 -138
2017.08.15 12:04:44.490 4: TSCUL_send:  CUL0                         As 27 25 00CA 1DA462 43F1C8 65468C0A51635A549576655400D515A304F50AFBD5D44FC79BF6B542F05D
2017.08.15 12:04:44.491 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:44.492 4: TSCUL_Parse: CUL0  148556 A F183 01383968 02 27 24 00CA 1DA462 43F1C8 EE _fup _CCAdly:8 _dhmSt:1296 -138
2017.08.15 12:04:44.746 4: TSCUL_send:  CUL0                         As 27 26 00CA 1DA462 43F1C8 4E31BECEA566BB0D5E5621ADC56FE5093A22008BAE23E901E8A71FB48F98
2017.08.15 12:04:44.747 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:44.756 4: TSCUL_Parse: CUL0  148819 A F183 01384224 01 27 25 00CA 1DA462 43F1C8 65 _fup _CCAdly:4 _dhmSt:1552 -138
2017.08.15 12:04:45.010 4: TSCUL_send:  CUL0                         As 27 27 00CA 1DA462 43F1C8 61B603167C9C3396FD28D409F9A0D9174FB9D4C618A4CB841EE39A4CA570
2017.08.15 12:04:45.011 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:45.018 4: TSCUL_Parse: CUL0  149081 A F183 01384480 01 27 26 00CA 1DA462 43F1C8 4E _fup _CCAdly:4 _dhmSt:1808 -138
2017.08.15 12:04:45.273 4: TSCUL_send:  CUL0                         As 27 28 00CA 1DA462 43F1C8 00141059688538F8C7806473908A20C08B384DCFE619514FC39C697F6DB9
2017.08.15 12:04:45.273 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:45.277 4: TSCUL_Parse: CUL0  149340 A F183 01384744 01 27 27 00CA 1DA462 43F1C8 61 _fup _CCAdly:4 _dhmSt:2072 -138
2017.08.15 12:04:45.532 4: TSCUL_send:  CUL0                         As 27 29 00CA 1DA462 43F1C8 4AEB9A2197D4AE8F7A6BCC4B579324B8C19E3BF4B838BD93FF0214825275
2017.08.15 12:04:45.536 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:45.543 4: TSCUL_Parse: CUL0  149607 A F183 01385008 02 27 28 00CA 1DA462 43F1C8 00 _fup _CCAdly:8 _dhmSt:2336 -138
2017.08.15 12:04:45.799 4: TSCUL_send:  CUL0                         As 0F 2A 20CA 1DA462 43F1C8 10E3640EC629
2017.08.15 12:04:45.800 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:14 rtoms:1746
2017.08.15 12:04:45.803 4: TSCUL_Parse: CUL0  149866 A F183 01385264 01 27 29 00CA 1DA462 43F1C8 4A _fup _CCAdly:4 _dhmSt:2592 -138
2017.08.15 12:04:46.125 4: TSCUL_Parse: CUL0  150188 A F183 01385532 01 0F 2A 20CA 1DA462 43F1C8 10 _fup _CCAdly:4 _dhmSt:2860 -138
2017.08.15 12:04:46.128 4: TSCUL_Parse: CUL0  150190 A F181 01385584 00 0A 2A 0002 43F1C8 1DA462 00 _fup -72
2017.08.15 12:04:46.385 4: TSCUL_send:  CUL0                         As 1D 2B 20CA 1DA462 43F1C8 00126A02ADA178A7A16CAE126AD617E692AB578F
2017.08.15 12:04:46.385 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:15 rtoms:1746
2017.08.15 12:04:46.642 4: TSCUL_Parse: CUL0  150705 A F183 01386116 01 1D 2B 20CA 1DA462 43F1C8 00 _fup _CCAdly:4 _dhmSt:532 -138
2017.08.15 12:04:46.645 4: TSCUL_Parse: CUL0  150707 A F181 01386136 00 0A 2B 0002 43F1C8 1DA462 00 _fup -72
2017.08.15 12:04:46.909 4: TSCUL_send:  CUL0                         As 27 2C 00CA 1DA462 43F1C8 0112E9552E4CFF026FB971A7DB61A1FD14C581E4338B326310115F5418F0
2017.08.15 12:04:46.909 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:47.167 4: TSCUL_send:  CUL0                         As 27 2D 00CA 1DA462 43F1C8 F3ED50E075AC17463F442E0683F664BAE2C161778ACE5272C48A89086758
2017.08.15 12:04:47.167 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:47.174 4: TSCUL_Parse: CUL0  151237 A F183 01386644 01 27 2C 00CA 1DA462 43F1C8 01 _fup _CCAdly:4 _dhmSt:508 -138
2017.08.15 12:04:47.429 4: TSCUL_send:  CUL0                         As 27 2E 00CA 1DA462 43F1C8 F9E1E299110BF9788DCE640CFA4839E536E1E63051DC6FF056E9EECEDB9F
2017.08.15 12:04:47.430 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:47.437 4: TSCUL_Parse: CUL0  151500 A F183 01386900 01 27 2D 00CA 1DA462 43F1C8 F3 _fup _CCAdly:4 _dhmSt:764 -138
2017.08.15 12:04:47.692 4: TSCUL_send:  CUL0                         As 27 2F 00CA 1DA462 43F1C8 2CED86911FA728A3CE13B289894F2DD8ED4CCBE7CDDEA5DD8C3DD8CB7FDF
2017.08.15 12:04:47.693 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:47.701 4: TSCUL_Parse: CUL0  151764 A F183 01387164 01 27 2E 00CA 1DA462 43F1C8 F9 _fup _CCAdly:4 _dhmSt:1028 -138
2017.08.15 12:04:47.956 4: TSCUL_send:  CUL0                         As 27 30 00CA 1DA462 43F1C8 63C1D9E687D04D80F98DF4FC38ABC1431A424F1118EAC9E7AEA57A4DDF1C
2017.08.15 12:04:47.956 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:47.960 4: TSCUL_Parse: CUL0  152023 A F183 01387428 02 27 2F 00CA 1DA462 43F1C8 2C _fup _CCAdly:8 _dhmSt:1292 -138
2017.08.15 12:04:48.214 4: TSCUL_send:  CUL0                         As 27 31 00CA 1DA462 43F1C8 ED0C5998E49A2FA91ABAFE4FA01DDE0B953143A4DC1A290E1628A115ADC6
2017.08.15 12:04:48.214 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:48.223 4: TSCUL_Parse: CUL0  152286 A F183 01387688 01 27 30 00CA 1DA462 43F1C8 63 _fup _CCAdly:4 _dhmSt:1552 -138
2017.08.15 12:04:48.478 4: TSCUL_send:  CUL0                         As 27 32 00CA 1DA462 43F1C8 A0EE9058FFE712C0995A76321F402F66EECB1A9A37498B97B8A3F8C3F62D
2017.08.15 12:04:48.478 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:48.482 4: TSCUL_Parse: CUL0  152545 A F183 01387948 01 27 31 00CA 1DA462 43F1C8 ED _fup _CCAdly:4 _dhmSt:1812 -138
2017.08.15 12:04:48.737 4: TSCUL_send:  CUL0                         As 27 33 00CA 1DA462 43F1C8 371A9BA3ED172F73703C6E34E6859B3863FB7BA4417D59E5665866D7BC64
2017.08.15 12:04:48.737 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:48.740 4: TSCUL_Parse: CUL0  152804 A F183 01388212 01 27 32 00CA 1DA462 43F1C8 A0 _fup _CCAdly:4 _dhmSt:2076 -138
2017.08.15 12:04:48.995 4: TSCUL_send:  CUL0                         As 27 34 00CA 1DA462 43F1C8 FFF07AAE27603001F015714B3A3F62BD66DD8D296F64DFB960701E72AB57
2017.08.15 12:04:48.995 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:49.004 4: TSCUL_Parse: CUL0  153067 A F183 01388472 02 27 33 00CA 1DA462 43F1C8 37 _fup _CCAdly:8 _dhmSt:2336 -138
2017.08.15 12:04:49.286 4: TSCUL_send:  CUL0                         As 0F 35 20CA 1DA462 43F1C8 E3FF41493BFE
2017.08.15 12:04:49.286 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:14 rtoms:1746
2017.08.15 12:04:49.295 4: TSCUL_Parse: CUL0  153358 A F183 01388728 01 27 34 00CA 1DA462 43F1C8 FF _fup _CCAdly:4 _dhmSt:2592 -138
2017.08.15 12:04:49.559 4: TSCUL_Parse: CUL0  153622 A F183 01389020 02 0F 35 20CA 1DA462 43F1C8 E3 _fup _CCAdly:8 _dhmSt:2884 -138
2017.08.15 12:04:49.562 4: TSCUL_Parse: CUL0  153624 A F181 01389072 00 0A 35 0002 43F1C8 1DA462 00 _fup -72.5
2017.08.15 12:04:49.825 4: TSCUL_send:  CUL0                         As 1D 36 20CA 1DA462 43F1C8 00125DC203CBECD8E31224E25C624F31E2D3A82E
2017.08.15 12:04:49.825 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:15 rtoms:1746
2017.08.15 12:04:50.102 4: TSCUL_Parse: CUL0  154165 A F183 01389556 01 1D 36 20CA 1DA462 43F1C8 00 _fup _CCAdly:4 _dhmSt:484 -138
2017.08.15 12:04:50.104 4: TSCUL_Parse: CUL0  154167 A F181 01389576 00 0A 36 0002 43F1C8 1DA462 00 _fup -72
2017.08.15 12:04:50.374 4: TSCUL_send:  CUL0                         As 27 37 00CA 1DA462 43F1C8 01129243CB5C2CE84E3BA32298AAD1C495EA7CDD91BBEE3FD75B4BB79664
2017.08.15 12:04:50.374 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:50.633 4: TSCUL_send:  CUL0                         As 27 38 00CA 1DA462 43F1C8 8206F12E9AE6EFA2F6AF19EBF062F8EFC1FD618C7CA4D270D57B7C11981B
2017.08.15 12:04:50.637 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:50.644 4: TSCUL_Parse: CUL0  154708 A F183 01390108 01 27 37 00CA 1DA462 43F1C8 01 _fup _CCAdly:4 _dhmSt:532 -138
2017.08.15 12:04:50.901 4: TSCUL_send:  CUL0                         As 27 39 00CA 1DA462 43F1C8 1ACEC1141BC95EA8323D05ECF41107A7BADD37817C3C3E00C2FEA65BA5C3
2017.08.15 12:04:50.901 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:50.912 4: TSCUL_Parse: CUL0  154975 A F183 01390368 02 27 38 00CA 1DA462 43F1C8 82 _fup _CCAdly:8 _dhmSt:792 -138
2017.08.15 12:04:51.165 4: TSCUL_send:  CUL0                         As 27 3A 00CA 1DA462 43F1C8 5A04FA2C14DFC7DD534E342D9A2B0E3BE42CA60722F0BABA4911D9468605
2017.08.15 12:04:51.165 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:51.167 4: TSCUL_Parse: CUL0  155231 A F183 01390636 02 27 39 00CA 1DA462 43F1C8 1A _fup _CCAdly:8 _dhmSt:1060 -138
2017.08.15 12:04:51.420 4: TSCUL_send:  CUL0                         As 27 3B 00CA 1DA462 43F1C8 3D441C72996AE203636A82204B82F51B76AB404232479C94C78597039CB2
2017.08.15 12:04:51.420 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:51.444 4: TSCUL_Parse: CUL0  155508 A F183 01390900 01 27 3A 00CA 1DA462 43F1C8 5A _fup _CCAdly:4 _dhmSt:1324 -138
2017.08.15 12:04:51.445 4: TSCUL_Parse: CUL0  155509 A F183 01391152 01 27 3B 00CA 1DA462 43F1C8 3D _fup _CCAdly:4 _dhmSt:1576 -138
2017.08.15 12:04:51.699 4: TSCUL_send:  CUL0                         As 27 3C 00CA 1DA462 43F1C8 75F49102C987A3E01B83D2F8B07F2D78D67EE4E7482229A05E43DA740B35
2017.08.15 12:04:51.699 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:51.956 4: TSCUL_send:  CUL0                         As 27 3D 00CA 1DA462 43F1C8 F664188A4F2F85D78F53F75B88AE03828062EA65992C8372927B54B027EC
2017.08.15 12:04:51.957 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:51.961 4: TSCUL_Parse: CUL0  156024 A F183 01391432 01 27 3C 00CA 1DA462 43F1C8 75 _fup _CCAdly:4 _dhmSt:1856 -138
2017.08.15 12:04:52.221 4: TSCUL_send:  CUL0                         As 27 3E 00CA 1DA462 43F1C8 9DF261F5AAFAA92A1A422E6FAF7DBCA67B797FC0EF7CEA18D5D6A7EB3C05
2017.08.15 12:04:52.221 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:52.225 4: TSCUL_Parse: CUL0  156288 A F183 01391692 02 27 3D 00CA 1DA462 43F1C8 F6 _fup _CCAdly:8 _dhmSt:2116 -138
2017.08.15 12:04:52.484 4: TSCUL_send:  CUL0                         As 27 3F 00CA 1DA462 43F1C8 2D65B3C6F4E6FC02DCD2163FEF274B5FD6F10E00D7EB06ABD8C076FD4058
2017.08.15 12:04:52.484 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:52.489 4: TSCUL_Parse: CUL0  156552 A F183 01391956 02 27 3E 00CA 1DA462 43F1C8 9D _fup _CCAdly:8 _dhmSt:2380 -138
2017.08.15 12:04:52.810 4: TSCUL_send:  CUL0                         As 0F 40 20CA 1DA462 43F1C8 6E70EA4F00AF
2017.08.15 12:04:52.811 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:14 rtoms:1746
2017.08.15 12:04:52.812 4: TSCUL_Parse: CUL0  156876 A F183 01392220 02 27 3F 00CA 1DA462 43F1C8 2D _fup _CCAdly:8 _dhmSt:2644 -138
2017.08.15 12:04:53.067 4: TSCUL_Parse: CUL0  157131 A F183 01392544 01 0F 40 20CA 1DA462 43F1C8 6E _fup _CCAdly:4 _dhmSt:2968 -138
2017.08.15 12:04:53.068 4: TSCUL_Parse: CUL0  157132 A F181 01392596 00 0A 40 0002 43F1C8 1DA462 00 _fup -72
2017.08.15 12:04:53.345 4: TSCUL_send:  CUL0                         As 1D 41 20CA 1DA462 43F1C8 0012B3F555341F2C78DA3CBD470992DEEA1F1F04
2017.08.15 12:04:53.346 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:15 rtoms:1746
2017.08.15 12:04:53.372 4: TSCUL_Parse: CUL0  157436 A F183 01393080 02 1D 41 20CA 1DA462 43F1C8 00 _fup _CCAdly:8 _dhmSt:484 -138
2017.08.15 12:04:53.643 4: TSCUL_Parse: CUL0  157705 A F181 01393100 00 0A 41 0002 43F1C8 1DA462 00 _fup -72
2017.08.15 12:04:53.907 4: TSCUL_send:  CUL0                         As 27 42 00CA 1DA462 43F1C8 011208E662DE7AEE7E5A24FF9E8219FD8F12ACA1E191DB4CB3DF7AB66BD9
2017.08.15 12:04:53.907 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:53.924 4: TSCUL_Parse: CUL0  157987 A F183 01393640 01 27 42 00CA 1DA462 43F1C8 01 _fup _CCAdly:4 _dhmSt:540 -138
2017.08.15 12:04:54.183 4: TSCUL_send:  CUL0                         As 27 43 00CA 1DA462 43F1C8 23FD1F0C9FE220FC221ABE3A318C872CD2EB288ED93A23AA8C419F5FAC80
2017.08.15 12:04:54.184 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:54.221 4: TSCUL_Parse: CUL0  158284 A F183 01393916 01 27 43 00CA 1DA462 43F1C8 23 _fup _CCAdly:4 _dhmSt:816 -138
2017.08.15 12:04:54.481 4: TSCUL_send:  CUL0                         As 27 44 00CA 1DA462 43F1C8 0D6F3BD5421F8C5A171A231B1298828712868113A9EE19430ADEA4638C12
2017.08.15 12:04:54.481 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:54.747 4: TSCUL_send:  CUL0                         As 27 45 00CA 1DA462 43F1C8 4589FF3BFBC75EA8EA449BB4451EB03AA0EE497C05C9388FB01208F73FEF
2017.08.15 12:04:54.748 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:54.752 4: TSCUL_Parse: CUL0  158815 A F183 01394216 02 27 44 00CA 1DA462 43F1C8 0D _fup _CCAdly:8 _dhmSt:1116 -138
2017.08.15 12:04:55.010 4: TSCUL_send:  CUL0                         As 27 46 00CA 1DA462 43F1C8 1C243AE7DA64EA193FA0D336E1943E3777F3BB0A55DAFE7E511E2809DAE0
2017.08.15 12:04:55.010 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:55.016 4: TSCUL_Parse: CUL0  159079 A F183 01394480 01 27 45 00CA 1DA462 43F1C8 45 _fup _CCAdly:4 _dhmSt:1380 -138
2017.08.15 12:04:55.275 4: TSCUL_send:  CUL0                         As 27 47 00CA 1DA462 43F1C8 6F7D88BE4516B3632D22947CEBDC12EE8BFBABE3F53D895FA36595122D93
2017.08.15 12:04:55.275 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:55.291 4: TSCUL_Parse: CUL0  159354 A F183 01394744 01 27 46 00CA 1DA462 43F1C8 1C _fup _CCAdly:4 _dhmSt:1644 -138
2017.08.15 12:04:55.294 4: TSCUL_Parse: CUL0  159357 A F183 01395008 01 27 47 00CA 1DA462 43F1C8 6F _fup _CCAdly:4 _dhmSt:1908 -138
2017.08.15 12:04:55.548 4: TSCUL_send:  CUL0                         As 27 48 00CA 1DA462 43F1C8 972353362BCB2500FEC1246952353C137DC6B25F119674F3C7037406C148
2017.08.15 12:04:55.548 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:55.806 4: TSCUL_send:  CUL0                         As 27 49 00CA 1DA462 43F1C8 A4175EFCD28FE0298C971928271D848952E727EA8F9638925435DFE0B293
2017.08.15 12:04:55.806 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:55.811 4: TSCUL_Parse: CUL0  159874 A F183 01395284 02 27 48 00CA 1DA462 43F1C8 97 _fup _CCAdly:8 _dhmSt:2184 -138
2017.08.15 12:04:56.066 4: TSCUL_send:  CUL0                         As 27 4A 00CA 1DA462 43F1C8 990EC4D2EAA6CBA9C33988CEE01C7DCEA195E0C9A11A63090C32859EED97
2017.08.15 12:04:56.067 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:56.077 4: TSCUL_Parse: CUL0  160140 A F183 01395540 01 27 49 00CA 1DA462 43F1C8 A4 _fup _CCAdly:4 _dhmSt:2440 -138
2017.08.15 12:04:56.332 4: TSCUL_send:  CUL0                         As 0F 4B 20CA 1DA462 43F1C8 4128E46DCF8A
2017.08.15 12:04:56.333 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:14 rtoms:1746
2017.08.15 12:04:56.340 4: TSCUL_Parse: CUL0  160403 A F183 01395800 01 27 4A 00CA 1DA462 43F1C8 99 _fup _CCAdly:4 _dhmSt:2700 -138
2017.08.15 12:04:56.635 4: TSCUL_Parse: CUL0  160699 A F183 01396064 01 0F 4B 20CA 1DA462 43F1C8 41 _fup _CCAdly:4 _dhmSt:2964 -138
2017.08.15 12:04:56.636 4: TSCUL_Parse: CUL0  160700 A F181 01396120 00 0A 4B 0002 43F1C8 1DA462 00 _fup -72
2017.08.15 12:04:56.890 4: TSCUL_send:  CUL0                         As 1D 4C 20CA 1DA462 43F1C8 0012B27D97B7BF21B71F0A5D811890A40DCB356D
2017.08.15 12:04:56.891 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:15 rtoms:1746
2017.08.15 12:04:57.147 4: TSCUL_Parse: CUL0  161211 A F183 01396624 01 1D 4C 20CA 1DA462 43F1C8 00 _fup _CCAdly:4 _dhmSt:504 -138
2017.08.15 12:04:57.148 4: TSCUL_Parse: CUL0  161212 A F181 01396644 00 0A 4C 0002 43F1C8 1DA462 00 _fup -72
2017.08.15 12:04:57.407 4: TSCUL_send:  CUL0                         As 27 4D 00CA 1DA462 43F1C8 01129BB9E29891FD2952E37F6A7F80E266E323A108F58B98A16DE05C76CC
2017.08.15 12:04:57.408 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:57.435 4: TSCUL_Parse: CUL0  161497 A F183 01397140 01 27 4D 00CA 1DA462 43F1C8 01 _fup _CCAdly:4 _dhmSt:496 -138
2017.08.15 12:04:57.690 4: TSCUL_send:  CUL0                         As 27 4E 00CA 1DA462 43F1C8 8EE358F2DDC0ED7C9EBEC9762F2E13C0C46637D1BBA09D2D1291067A3CEA
2017.08.15 12:04:57.690 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:57.775 4: TSCUL_Parse: CUL0  161839 A F183 01397424 01 27 4E 00CA 1DA462 43F1C8 8E _fup _CCAdly:4 _dhmSt:780 -138
2017.08.15 12:04:58.028 4: TSCUL_send:  CUL0                         As 27 4F 00CA 1DA462 43F1C8 6CDA8F15C79B3AE6E3C9D96184D744246DCDDAD0877C3400899F87C604D4
2017.08.15 12:04:58.028 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:58.298 4: TSCUL_send:  CUL0                         As 27 50 00CA 1DA462 43F1C8 18576D8D950919E822B589DE169FE6C87BEE3FF4BC588C48F600D3D0B95B
2017.08.15 12:04:58.298 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:58.306 4: TSCUL_Parse: CUL0  162369 A F183 01397764 02 27 4F 00CA 1DA462 43F1C8 6C _fup _CCAdly:8 _dhmSt:1120 -138
2017.08.15 12:04:58.566 4: TSCUL_send:  CUL0                         As 27 51 00CA 1DA462 43F1C8 EAAC0857EB0F8C2B6D3378A9243B68DCA2CDEF64ABE28BA64669FCE2EF63
2017.08.15 12:04:58.566 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:58.572 4: TSCUL_Parse: CUL0  162636 A F183 01398032 01 27 50 00CA 1DA462 43F1C8 18 _fup _CCAdly:4 _dhmSt:1388 -138
2017.08.15 12:04:58.828 4: TSCUL_send:  CUL0                         As 27 52 00CA 1DA462 43F1C8 5D9268A42A69063834A73A0858163AAB54004D1740FC7A2AA85EC662F4E7
2017.08.15 12:04:58.828 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:58.833 4: TSCUL_Parse: CUL0  162897 A F183 01398300 01 27 51 00CA 1DA462 43F1C8 EA _fup _CCAdly:4 _dhmSt:1656 -138
2017.08.15 12:04:59.093 4: TSCUL_send:  CUL0                         As 27 53 00CA 1DA462 43F1C8 3A8FFC87043B7E2CFABE8CC0C90B109133EADD3C4659B932FFF1E2ABC06B
2017.08.15 12:04:59.094 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:59.099 4: TSCUL_Parse: CUL0  163162 A F183 01398564 02 27 52 00CA 1DA462 43F1C8 5D _fup _CCAdly:8 _dhmSt:1920 -138
2017.08.15 12:04:59.356 4: TSCUL_send:  CUL0                         As 27 54 00CA 1DA462 43F1C8 437E26E7BDDE7D99A8DC2067BC6F8C8AD227F3ADE768E0962667E769A554
2017.08.15 12:04:59.357 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:59.360 4: TSCUL_Parse: CUL0  163423 A F183 01398828 01 27 53 00CA 1DA462 43F1C8 3A _fup _CCAdly:4 _dhmSt:2184 -138
2017.08.15 12:04:59.618 4: TSCUL_send:  CUL0                         As 27 55 00CA 1DA462 43F1C8 35B5C83BCFD035E89EB35320A9EB0F05558BBB6FF8F45B7840BB9173B526
2017.08.15 12:04:59.619 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:04:59.625 4: TSCUL_Parse: CUL0  163688 A F183 01399092 02 27 54 00CA 1DA462 43F1C8 43 _fup _CCAdly:8 _dhmSt:2448 -138
2017.08.15 12:04:59.883 4: TSCUL_send:  CUL0                         As 0F 56 20CA 1DA462 43F1C8 974077C7274D
2017.08.15 12:04:59.884 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:14 rtoms:1746
2017.08.15 12:04:59.887 4: TSCUL_Parse: CUL0  163950 A F183 01399352 01 27 55 00CA 1DA462 43F1C8 35 _fup _CCAdly:4 _dhmSt:2708 -138
2017.08.15 12:05:00.244 4: TSCUL_Parse: CUL0  164308 A F183 01399616 01 0F 56 20CA 1DA462 43F1C8 97 _fup _CCAdly:4 _dhmSt:2972 -138
2017.08.15 12:05:00.245 4: TSCUL_Parse: CUL0  164309 A F181 01399672 00 0A 56 0002 43F1C8 1DA462 00 _fup -72
2017.08.15 12:05:00.500 4: TSCUL_send:  CUL0                         As 1D 57 20CA 1DA462 43F1C8 00124EC58CB0A0412998BF86610AD59053B4B424
2017.08.15 12:05:00.500 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:15 rtoms:1746
2017.08.15 12:05:00.755 4: TSCUL_Parse: CUL0  164819 A F183 01400232 01 1D 57 20CA 1DA462 43F1C8 00 _fup _CCAdly:4 _dhmSt:560 -138
2017.08.15 12:05:01.517 1: TSCUL_ParseTsHM: CUL0 HM repeat failed to 43F1C8/Markise:  165580 A F189 01401236 00 1D 57 20CA 1DA462 43F1C8 00 _fup _sfail
2017.08.15 12:05:02.316 4: TSCUL_XmitAwaitTo CUL0: timeout - 43F1C8
2017.08.15 12:05:05.372 4: TSCUL_send:  CUL0                         As 1D 57 20CA 1DA462 43F1C8 00124EC58CB0A0412998BF86610AD59053B4B424
2017.08.15 12:05:05.373 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:15 rtoms:1746
2017.08.15 12:05:05.631 4: TSCUL_Parse: CUL0  169694 A F183 01405108 02 1D 57 20CA 1DA462 43F1C8 00 _fup _CCAdly:8 -138
2017.08.15 12:05:05.633 4: TSCUL_Parse: CUL0  169696 A F181 01405124 00 0A 57 0002 43F1C8 1DA462 00 _fup -72.5
2017.08.15 12:05:05.898 4: TSCUL_send:  CUL0                         As 27 58 00CA 1DA462 43F1C8 01123A914544A1C15A1617F539D0AE237BA9CA8E8FB1994B9926899CD006
2017.08.15 12:05:05.899 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:06.155 4: TSCUL_send:  CUL0                         As 27 59 00CA 1DA462 43F1C8 6FACA60DFF8EF83A45A110E1167F4A967F15D65CDD5376DEC84652D943EC
2017.08.15 12:05:06.155 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:06.160 4: TSCUL_Parse: CUL0  170223 A F183 01405632 01 27 58 00CA 1DA462 43F1C8 01 _fup _CCAdly:4 _dhmSt:508 -138
2017.08.15 12:05:06.415 4: TSCUL_send:  CUL0                         As 27 5A 00CA 1DA462 43F1C8 54521CFCA99C87E64FE43079C6BDB4312F55DC616A339FA89BAE2D646FE8
2017.08.15 12:05:06.415 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:06.419 4: TSCUL_Parse: CUL0  170483 A F183 01405888 01 27 59 00CA 1DA462 43F1C8 6F _fup _CCAdly:4 _dhmSt:764 -138
2017.08.15 12:05:06.675 4: TSCUL_send:  CUL0                         As 27 5B 00CA 1DA462 43F1C8 E28A38F8DD826D805D83E5F7195234B782D4FA527DDE69F1D6A0B9DB0B24
2017.08.15 12:05:06.675 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:06.683 4: TSCUL_Parse: CUL0  170746 A F183 01406148 01 27 5A 00CA 1DA462 43F1C8 54 _fup _CCAdly:4 _dhmSt:1024 -138
2017.08.15 12:05:06.939 4: TSCUL_send:  CUL0                         As 27 5C 00CA 1DA462 43F1C8 44075B0764DBAF5D01955C306A5C443B50814EE0A0159D56CCEA77B444FF
2017.08.15 12:05:06.940 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:06.943 4: TSCUL_Parse: CUL0  171006 A F183 01406408 01 27 5B 00CA 1DA462 43F1C8 E2 _fup _CCAdly:4 _dhmSt:1284 -138
2017.08.15 12:05:07.198 4: TSCUL_send:  CUL0                         As 27 5D 00CA 1DA462 43F1C8 5898B066515C7EC3262EDAF9551AB3AB896666E1B105D43BEEAD86717D6D
2017.08.15 12:05:07.198 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:07.202 4: TSCUL_Parse: CUL0  171266 A F183 01406672 01 27 5C 00CA 1DA462 43F1C8 44 _fup _CCAdly:4 _dhmSt:1548 -138
2017.08.15 12:05:07.458 4: TSCUL_send:  CUL0                         As 27 5E 00CA 1DA462 43F1C8 D4FFE6BEE9FEB28C41F8ED57A734951139F9667935BD047743DB27A5AB97
2017.08.15 12:05:07.458 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:07.462 4: TSCUL_Parse: CUL0  171525 A F183 01406932 01 27 5D 00CA 1DA462 43F1C8 58 _fup _CCAdly:4 _dhmSt:1808 -138
2017.08.15 12:05:07.765 4: TSCUL_send:  CUL0                         As 27 5F 00CA 1DA462 43F1C8 DCB94C181D50587AD9000EF975B762EE0584C428B8CBE217B0A306C670DE
2017.08.15 12:05:07.765 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:07.768 4: TSCUL_Parse: CUL0  171831 A F183 01407192 01 27 5E 00CA 1DA462 43F1C8 D4 _fup _CCAdly:4 _dhmSt:2068 -138
2017.08.15 12:05:08.024 4: TSCUL_send:  CUL0                         As 27 60 00CA 1DA462 43F1C8 CB1B447CCA70949F0B7B61D3CFDF436FA337069CCB28181130EB6935EECE
2017.08.15 12:05:08.025 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:08.027 4: TSCUL_Parse: CUL0  172091 A F183 01407500 01 27 5F 00CA 1DA462 43F1C8 DC _fup _CCAdly:4 _dhmSt:2376 -138
2017.08.15 12:05:08.294 4: TSCUL_send:  CUL0                         As 0F 61 20CA 1DA462 43F1C8 E1B1B46E5A1A
2017.08.15 12:05:08.295 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:14 rtoms:1746
2017.08.15 12:05:08.305 4: TSCUL_Parse: CUL0  172368 A F183 01407760 01 27 60 00CA 1DA462 43F1C8 CB _fup _CCAdly:4 _dhmSt:2636 -138
2017.08.15 12:05:08.567 4: TSCUL_Parse: CUL0  172630 A F183 01408028 01 0F 61 20CA 1DA462 43F1C8 E1 _fup _CCAdly:4 _dhmSt:2904 -138
2017.08.15 12:05:08.569 4: TSCUL_Parse: CUL0  172631 A F181 01408080 00 0A 61 0002 43F1C8 1DA462 00 _fup -73.5
2017.08.15 12:05:08.835 4: TSCUL_send:  CUL0                         As 1D 62 20CA 1DA462 43F1C8 0012E2DE85B3FCBB26006AB4BB49902A62F8B93C
2017.08.15 12:05:08.836 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:15 rtoms:1746
2017.08.15 12:05:09.109 4: TSCUL_Parse: CUL0  173172 A F183 01408568 01 1D 62 20CA 1DA462 43F1C8 00 _fup _CCAdly:4 _dhmSt:488 -138
2017.08.15 12:05:09.112 4: TSCUL_Parse: CUL0  173174 A F181 01408588 00 0A 62 0002 43F1C8 1DA462 00 _fup -72.5
2017.08.15 12:05:09.385 4: TSCUL_send:  CUL0                         As 27 63 00CA 1DA462 43F1C8 0112C04BEFA08D041317C1CC7E0B9C43C6C9A0846CE3B2D4E006196EF325
2017.08.15 12:05:09.386 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:09.644 4: TSCUL_send:  CUL0                         As 27 64 00CA 1DA462 43F1C8 4DB12453C6B0E5E693DB9DF864D401A5E6F280C96F02AE2FAA7E74E1BC4D
2017.08.15 12:05:09.645 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:09.652 4: TSCUL_Parse: CUL0  173715 A F183 01409120 01 27 63 00CA 1DA462 43F1C8 01 _fup _CCAdly:4 _dhmSt:532 -138
2017.08.15 12:05:09.910 4: TSCUL_send:  CUL0                         As 27 65 00CA 1DA462 43F1C8 533A4D784C90D48E26834E216D9D0E4D150B85867208383446D088DA5A3E
2017.08.15 12:05:09.910 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:09.914 4: TSCUL_Parse: CUL0  173977 A F183 01409380 02 27 64 00CA 1DA462 43F1C8 4D _fup _CCAdly:8 _dhmSt:792 -138
2017.08.15 12:05:10.182 4: TSCUL_send:  CUL0                         As 27 66 00CA 1DA462 43F1C8 159DFC05886E9E4E2645A71E8B6FACE5E8D3083EBCB3C804FF6565DAC55F
2017.08.15 12:05:10.182 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:10.244 4: TSCUL_Parse: CUL0  174308 A F183 01409644 01 27 65 00CA 1DA462 43F1C8 53 _fup _CCAdly:4 _dhmSt:1056 -138
2017.08.15 12:05:10.246 4: TSCUL_Parse: CUL0  174309 A F183 01409916 01 27 66 00CA 1DA462 43F1C8 15 _fup _CCAdly:4 _dhmSt:1328 -138
2017.08.15 12:05:10.498 4: TSCUL_send:  CUL0                         As 27 67 00CA 1DA462 43F1C8 368C4202567A56A8183E1441FBB5F0260D03A64EA18A889F7B02BAEF754E
2017.08.15 12:05:10.498 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:10.755 4: TSCUL_send:  CUL0                         As 27 68 00CA 1DA462 43F1C8 D142BA0942857FF09F73E606A102BAADC99F079DB2603E404C41D0E7FCC8
2017.08.15 12:05:10.755 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:10.757 4: TSCUL_Parse: CUL0  174820 A F183 01410232 01 27 67 00CA 1DA462 43F1C8 36 _fup _CCAdly:4 _dhmSt:1644 -138
2017.08.15 12:05:11.011 4: TSCUL_send:  CUL0                         As 27 69 00CA 1DA462 43F1C8 55AACC38341277F71327A5E29D3E77E47CE4E466983A4B406DF2B0F7B236
2017.08.15 12:05:11.011 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:11.016 4: TSCUL_Parse: CUL0  175079 A F183 01410488 01 27 68 00CA 1DA462 43F1C8 D1 _fup _CCAdly:4 _dhmSt:1900 -138
2017.08.15 12:05:11.270 4: TSCUL_send:  CUL0                         As 27 6A 00CA 1DA462 43F1C8 8F22F14D267E8F5F4495B6A129AFACB913773130D9F11EEE6B9180BF1F73
2017.08.15 12:05:11.270 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:11.275 4: TSCUL_Parse: CUL0  175338 A F183 01410744 01 27 69 00CA 1DA462 43F1C8 55 _fup _CCAdly:4 _dhmSt:2156 -138
2017.08.15 12:05:11.530 4: TSCUL_send:  CUL0                         As 27 6B 00CA 1DA462 43F1C8 FDB68C7AC0746B36EF91FB4B6CA9430103381F7BEABB9CE0E15D0836CAFC
2017.08.15 12:05:11.530 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:11.534 4: TSCUL_Parse: CUL0  175597 A F183 01411004 01 27 6A 00CA 1DA462 43F1C8 8F _fup _CCAdly:4 _dhmSt:2416 -138
2017.08.15 12:05:11.788 4: TSCUL_send:  CUL0                         As 0F 6C 20CA 1DA462 43F1C8 6EF8E6D55868
2017.08.15 12:05:11.791 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:14 rtoms:1746
2017.08.15 12:05:11.795 4: TSCUL_Parse: CUL0  175858 A F183 01411264 01 27 6B 00CA 1DA462 43F1C8 FD _fup _CCAdly:4 _dhmSt:2676 -138
2017.08.15 12:05:12.053 4: TSCUL_Parse: CUL0  176116 A F183 01411520 01 0F 6C 20CA 1DA462 43F1C8 6E _fup _CCAdly:4 _dhmSt:2932 -138
2017.08.15 12:05:12.056 4: TSCUL_Parse: CUL0  176118 A F181 01411576 00 0A 6C 0002 43F1C8 1DA462 00 _fup -72.5
2017.08.15 12:05:12.312 4: TSCUL_send:  CUL0                         As 1D 6D 20CA 1DA462 43F1C8 001215B77B4190637FC609D284FB678B5931FCC1
2017.08.15 12:05:12.312 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:15 rtoms:1746
2017.08.15 12:05:12.566 4: TSCUL_Parse: CUL0  176630 A F183 01412044 01 1D 6D 20CA 1DA462 43F1C8 00 _fup _CCAdly:4 _dhmSt:468 -138
2017.08.15 12:05:12.568 4: TSCUL_Parse: CUL0  176631 A F181 01412064 00 0A 6D 0002 43F1C8 1DA462 00 _fup -73
2017.08.15 12:05:12.827 4: TSCUL_send:  CUL0                         As 27 6E 00CA 1DA462 43F1C8 011204F77FF49B83C943EC89061B82054D964F0BADE5F922A4831460DFD0
2017.08.15 12:05:12.827 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:12.920 4: TSCUL_Parse: CUL0  176984 A F183 01412560 01 27 6E 00CA 1DA462 43F1C8 01 _fup _CCAdly:4 _dhmSt:496 -138
2017.08.15 12:05:13.175 4: TSCUL_send:  CUL0                         As 27 6F 00CA 1DA462 43F1C8 6BBF3621678A6A3B35B5C17656802C0454925B648A5010B2942474DA7779
2017.08.15 12:05:13.175 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:13.437 4: TSCUL_send:  CUL0                         As 27 70 00CA 1DA462 43F1C8 A9424794706AC4394C8E9C2C01F539369F904E2C6ECF1E585CB299D4CC9E
2017.08.15 12:05:13.437 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:13.440 4: TSCUL_Parse: CUL0  177503 A F183 01412908 01 27 6F 00CA 1DA462 43F1C8 6B _fup _CCAdly:4 _dhmSt:844 -138
2017.08.15 12:05:13.695 4: TSCUL_send:  CUL0                         As 27 71 00CA 1DA462 43F1C8 0B63EE65E10D0D4266F8A476AB5178B4AA18D6CD5887662DA3AB91A9976D
2017.08.15 12:05:13.695 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:13.699 4: TSCUL_Parse: CUL0  177762 A F183 01413172 01 27 70 00CA 1DA462 43F1C8 A9 _fup _CCAdly:4 _dhmSt:1108 -138
2017.08.15 12:05:13.954 4: TSCUL_send:  CUL0                         As 27 72 00CA 1DA462 43F1C8 8D7E22A81DF54A91615B5737D3E328CC2B782B31F03DE1B18AEB1B4AB626
2017.08.15 12:05:13.955 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:13.958 4: TSCUL_Parse: CUL0  178021 A F183 01413428 01 27 71 00CA 1DA462 43F1C8 0B _fup _CCAdly:4 _dhmSt:1364 -138
2017.08.15 12:05:14.212 4: TSCUL_send:  CUL0                         As 27 73 00CA 1DA462 43F1C8 D6F4D01FDEF34B371ABE73881E717604BD6F20554D8C053614C6FAA8725A
2017.08.15 12:05:14.212 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:14.219 4: TSCUL_Parse: CUL0  178283 A F183 01413688 01 27 72 00CA 1DA462 43F1C8 8D _fup _CCAdly:4 _dhmSt:1624 -138
2017.08.15 12:05:14.474 4: TSCUL_send:  CUL0                         As 27 74 00CA 1DA462 43F1C8 0170436175FA6EBA8ECCA38F0ED4EDC4309C52E2489C6A04E719DABAE560
2017.08.15 12:05:14.475 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:14.479 4: TSCUL_Parse: CUL0  178541 A F183 01413948 02 27 73 00CA 1DA462 43F1C8 D6 _fup _CCAdly:8 _dhmSt:1884 -138
2017.08.15 12:05:14.733 4: TSCUL_send:  CUL0                         As 27 75 00CA 1DA462 43F1C8 ECBB57BC21BDF92A77642426B983EF9B06D461D521A9D94C9FC26B90A5A6
2017.08.15 12:05:14.733 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:14.738 4: TSCUL_Parse: CUL0  178801 A F183 01414208 01 27 74 00CA 1DA462 43F1C8 01 _fup _CCAdly:4 _dhmSt:2144 -138
2017.08.15 12:05:14.993 4: TSCUL_send:  CUL0                         As 27 76 00CA 1DA462 43F1C8 BE5EE1F70AA22722C336B2AD52601E7A5F9784AC49C9FACB2C06F126EDC0
2017.08.15 12:05:14.993 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:14.997 4: TSCUL_Parse: CUL0  179060 A F183 01414468 01 27 75 00CA 1DA462 43F1C8 EC _fup _CCAdly:4 _dhmSt:2404 -138
2017.08.15 12:05:15.261 4: TSCUL_send:  CUL0                         As 0F 77 20CA 1DA462 43F1C8 1B0EA15A07EE
2017.08.15 12:05:15.262 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:14 rtoms:1746
2017.08.15 12:05:15.266 4: TSCUL_Parse: CUL0  179329 A F183 01414728 01 27 76 00CA 1DA462 43F1C8 BE _fup _CCAdly:4 _dhmSt:2664 -138
2017.08.15 12:05:15.523 4: TSCUL_Parse: CUL0  179587 A F183 01414996 02 0F 77 20CA 1DA462 43F1C8 1B _fup _CCAdly:8 _dhmSt:2932 -138
2017.08.15 12:05:15.526 4: TSCUL_Parse: CUL0  179588 A F181 01415048 00 0A 77 0002 43F1C8 1DA462 00 _fup -72.5
2017.08.15 12:05:15.818 4: TSCUL_send:  CUL0                         As 1D 78 20CA 1DA462 43F1C8 00129447BA3B700F7E5897E477F117EFD33ABFE1
2017.08.15 12:05:15.818 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:15 rtoms:1746
2017.08.15 12:05:16.081 4: TSCUL_Parse: CUL0  180144 A F183 01415552 01 1D 78 20CA 1DA462 43F1C8 00 _fup _CCAdly:4 _dhmSt:504 -138
2017.08.15 12:05:16.083 4: TSCUL_Parse: CUL0  180146 A F181 01415572 00 0A 78 0002 43F1C8 1DA462 00 _fup -72.5
2017.08.15 12:05:16.354 4: TSCUL_send:  CUL0                         As 27 79 00CA 1DA462 43F1C8 0112558EEF5EE468E98E7C70A0C2380523D3A38B56E138E7201233A93E35
2017.08.15 12:05:16.355 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:16.621 4: TSCUL_send:  CUL0                         As 27 7A 00CA 1DA462 43F1C8 77168781DB1E237B0C58BF455306F394F3DB5C6FC89BAC284D197ECC0555
2017.08.15 12:05:16.621 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:16.628 4: TSCUL_Parse: CUL0  180692 A F183 01416088 01 27 79 00CA 1DA462 43F1C8 01 _fup _CCAdly:4 _dhmSt:516 -138
2017.08.15 12:05:16.891 4: TSCUL_send:  CUL0                         As 27 7B 00CA 1DA462 43F1C8 2FFDB0EE63D6ACA06019954CBD5C5ED3E68596B2943CC74C1545BAC75EA6
2017.08.15 12:05:16.892 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:16.900 4: TSCUL_Parse: CUL0  180963 A F183 01416356 01 27 7A 00CA 1DA462 43F1C8 77 _fup _CCAdly:4 _dhmSt:784 -138
2017.08.15 12:05:17.163 4: TSCUL_send:  CUL0                         As 27 7C 00CA 1DA462 43F1C8 B210922348647DDDB08844667E1DAD6BF35B829BD2701510CD284E9AD333
2017.08.15 12:05:17.164 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:17.167 4: TSCUL_Parse: CUL0  181230 A F183 01416628 02 27 7B 00CA 1DA462 43F1C8 2F _fup _CCAdly:8 _dhmSt:1056 -138
2017.08.15 12:05:17.424 4: TSCUL_send:  CUL0                         As 27 7D 00CA 1DA462 43F1C8 D2F0BD6F937A9C118B27886D14A9FBD4B5CE59B5F465D59326C66D010586
2017.08.15 12:05:17.425 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:17.432 4: TSCUL_Parse: CUL0  181495 A F183 01416900 02 27 7C 00CA 1DA462 43F1C8 B2 _fup _CCAdly:8 _dhmSt:1328 -138
2017.08.15 12:05:17.690 4: TSCUL_send:  CUL0                         As 27 7E 00CA 1DA462 43F1C8 0B36AE5E648C87F860EF818EA18F877DA92FCCFF84F14CD8730DA2B884D7
2017.08.15 12:05:17.690 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:17.693 4: TSCUL_Parse: CUL0  181756 A F183 01417160 01 27 7D 00CA 1DA462 43F1C8 D2 _fup _CCAdly:4 _dhmSt:1588 -138
2017.08.15 12:05:17.960 4: TSCUL_send:  CUL0                         As 27 7F 00CA 1DA462 43F1C8 D40FE1FA246F0D44C86931E78F4D47D9CDFF3E94DDD2FF15CF1781F3CC75
2017.08.15 12:05:17.960 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:17.965 4: TSCUL_Parse: CUL0  182028 A F183 01417424 01 27 7E 00CA 1DA462 43F1C8 0B _fup _CCAdly:4 _dhmSt:1852 -138
2017.08.15 12:05:18.219 4: TSCUL_send:  CUL0                         As 27 80 00CA 1DA462 43F1C8 ADCAD59809938BE945FA2FDE3F0818DCEF823317AC93309023B8AA96270A
2017.08.15 12:05:18.219 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:18.288 4: TSCUL_Parse: CUL0  182351 A F183 01417696 02 27 7F 00CA 1DA462 43F1C8 D4 _fup _CCAdly:8 _dhmSt:2124 -138
2017.08.15 12:05:18.289 4: TSCUL_Parse: CUL0  182353 A F183 01417956 02 27 80 00CA 1DA462 43F1C8 AD _fup _CCAdly:8 _dhmSt:2384 -138
2017.08.15 12:05:18.541 4: TSCUL_send:  CUL0                         As 27 81 00CA 1DA462 43F1C8 85969028F1863CDAC9F3DC7CC107C0B8DF1A40FDF72F5E9A148586FF2F00
2017.08.15 12:05:18.542 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:18.798 4: TSCUL_send:  CUL0                         As 0F 82 20CA 1DA462 43F1C8 DA7C49CF6443
2017.08.15 12:05:18.798 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:14 rtoms:1746
2017.08.15 12:05:18.800 4: TSCUL_Parse: CUL0  182863 A F183 01418276 01 27 81 00CA 1DA462 43F1C8 85 _fup _CCAdly:4 _dhmSt:2704 -138
2017.08.15 12:05:19.057 4: TSCUL_Parse: CUL0  183120 A F183 01418532 01 0F 82 20CA 1DA462 43F1C8 DA _fup _CCAdly:4 _dhmSt:2960 -138
2017.08.15 12:05:19.059 4: TSCUL_Parse: CUL0  183122 A F181 01418584 00 0A 82 0002 43F1C8 1DA462 00 _fup -72
2017.08.15 12:05:19.317 4: TSCUL_send:  CUL0                         As 1D 83 20CA 1DA462 43F1C8 0012FD11C81A95D614E4E0FA2D69EC3A7995AB6A
2017.08.15 12:05:19.317 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:15 rtoms:1746
2017.08.15 12:05:19.573 4: TSCUL_Parse: CUL0  183637 A F183 01419052 02 1D 83 20CA 1DA462 43F1C8 00 _fup _CCAdly:8 _dhmSt:468 -138
2017.08.15 12:05:19.574 4: TSCUL_Parse: CUL0  183638 A F181 01419072 00 0A 83 0002 43F1C8 1DA462 00 _fup -72
2017.08.15 12:05:19.832 4: TSCUL_send:  CUL0                         As 27 84 00CA 1DA462 43F1C8 0112FDBCB6AB8BE877B249B95CB9BA7E6977F67DA0BFA36DCDD8DDC63A02
2017.08.15 12:05:19.833 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:20.087 4: TSCUL_send:  CUL0                         As 27 85 00CA 1DA462 43F1C8 090C5C37D5848F52AA2B133CA4995ACF89C0EC2591EF03FD3F1593C368CA
2017.08.15 12:05:20.088 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:20.089 4: TSCUL_Parse: CUL0  184153 A F183 01419568 01 27 84 00CA 1DA462 43F1C8 01 _fup _CCAdly:4 _dhmSt:496 -138
2017.08.15 12:05:20.343 4: TSCUL_send:  CUL0                         As 27 86 00CA 1DA462 43F1C8 B71635582389E73D4CE8C96CD4797FC752F32DC26A04D1D4F7C1E6120D68
2017.08.15 12:05:20.344 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:20.348 4: TSCUL_Parse: CUL0  184412 A F183 01419824 02 27 85 00CA 1DA462 43F1C8 09 _fup _CCAdly:8 _dhmSt:752 -138
2017.08.15 12:05:20.603 4: TSCUL_send:  CUL0                         As 27 87 00CA 1DA462 43F1C8 0DA55C50839719CB78E5C0B441A18DFD89EDCE9A2513BFA6F832BFB8252D
2017.08.15 12:05:20.603 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:20.608 4: TSCUL_Parse: CUL0  184671 A F183 01420080 02 27 86 00CA 1DA462 43F1C8 B7 _fup _CCAdly:8 _dhmSt:1008 -138
2017.08.15 12:05:20.863 4: TSCUL_send:  CUL0                         As 27 88 00CA 1DA462 43F1C8 2B1950279B93A5FEBD28FED17B0A7DFA2FE61E30D4562D1DE37FF7F0CAB7
2017.08.15 12:05:20.863 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:20.866 4: TSCUL_Parse: CUL0  184929 A F183 01420336 01 27 87 00CA 1DA462 43F1C8 0D _fup _CCAdly:4 _dhmSt:1264 -138
2017.08.15 12:05:21.121 4: TSCUL_send:  CUL0                         As 27 89 00CA 1DA462 43F1C8 04D0009F5D9F16DC05CD97078C87FFD7207196FC9991B9D4EA45DC747798
2017.08.15 12:05:21.121 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:21.126 4: TSCUL_Parse: CUL0  185189 A F183 01420596 01 27 88 00CA 1DA462 43F1C8 2B _fup _CCAdly:4 _dhmSt:1524 -138
2017.08.15 12:05:21.380 4: TSCUL_send:  CUL0                         As 27 8A 00CA 1DA462 43F1C8 74BC940E2E6C89BC5440E1B912F3B3BD115BA38B6FFFB3290BC63A496531
2017.08.15 12:05:21.380 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:21.385 4: TSCUL_Parse: CUL0  185448 A F183 01420856 01 27 89 00CA 1DA462 43F1C8 04 _fup _CCAdly:4 _dhmSt:1784 -138
2017.08.15 12:05:21.640 4: TSCUL_send:  CUL0                         As 27 8B 00CA 1DA462 43F1C8 CC00A7676AD66C97BE1CF09528E537C36894569E647E7C9FFA2BD5A223F0
2017.08.15 12:05:21.640 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:21.643 4: TSCUL_Parse: CUL0  185706 A F183 01421116 02 27 8A 00CA 1DA462 43F1C8 74 _fup _CCAdly:8 _dhmSt:2044 -138
2017.08.15 12:05:21.898 4: TSCUL_send:  CUL0                         As 27 8C 00CA 1DA462 43F1C8 D1B3157C428FE9D854DB27408B53F540C719F1A4ADD17A81AE60F2544C9A
2017.08.15 12:05:21.902 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:21.907 4: TSCUL_Parse: CUL0  185970 A F183 01421376 02 27 8B 00CA 1DA462 43F1C8 CC _fup _CCAdly:8 _dhmSt:2304 -138
2017.08.15 12:05:22.162 4: TSCUL_send:  CUL0                         As 0F 8D 20CA 1DA462 43F1C8 F7F93A7ABE40
2017.08.15 12:05:22.162 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:14 rtoms:1746
2017.08.15 12:05:22.193 4: TSCUL_Parse: CUL0  186257 A F183 01421632 01 27 8C 00CA 1DA462 43F1C8 D1 _fup _CCAdly:4 _dhmSt:2560 -138
2017.08.15 12:05:22.196 4: TSCUL_Parse: CUL0  186259 A F183 01421896 01 0F 8D 20CA 1DA462 43F1C8 F7 _fup _CCAdly:4 _dhmSt:2824 -138
2017.08.15 12:05:23.257 1: TSCUL_ParseTsHM: CUL0 HM repeat failed to 43F1C8/Markise:  187320 A F189 01422896 00 0F 8D 20CA 1DA462 43F1C8 F7 _fup _sfail
2017.08.15 12:05:24.162 4: TSCUL_XmitAwaitTo CUL0: timeout - 43F1C8
2017.08.15 12:05:24.836 4: TSCUL_send:  CUL0                         As 27 84 00CA 1DA462 43F1C8 0112FDBCB6AB8BE877B249B95CB9BA7E6977F67DA0BFA36DCDD8DDC63A02
2017.08.15 12:05:24.837 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:25.102 4: TSCUL_send:  CUL0                         As 27 85 00CA 1DA462 43F1C8 090C5C37D5848F52AA2B133CA4995ACF89C0EC2591EF03FD3F1593C368CA
2017.08.15 12:05:25.102 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:25.105 4: TSCUL_Parse: CUL0  189169 A F183 01424572 01 27 84 00CA 1DA462 43F1C8 01 _fup _CCAdly:4 -138
2017.08.15 12:05:25.370 4: TSCUL_send:  CUL0                         As 27 86 00CA 1DA462 43F1C8 B71635582389E73D4CE8C96CD4797FC752F32DC26A04D1D4F7C1E6120D68
2017.08.15 12:05:25.371 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 12:05:25.374 4: TSCUL_Parse: CUL0  189437 A F183 01424836 01 27 85 00CA 1DA462 43F1C8 09 _fup _CCAdly:4 -138
2017.08.15 12:05:25.630 4: TSCUL_send:  CUL0


Greets

Byte
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 15 August 2017, 16:48:47
Hallo Byte,

ZitatHier das Log des Update-Versuchs bis zum ersten Fehlversuchs mit CUL Verbose 4
Und wie ging es weiter?

Also der Verbindungsaufbau klappt inklusive Hochschalten auf 100kbits.

Blocks werden auch übertragen und vom Aktor bestätigt. Allerdings nicht immer direkt, so dass es zu Wiederholungen seitens CUL kommt. Bei MsgCnt 57 kommt es zu ersten Wiederholung, aber es geht dann weiter.

Bei 8D kommt es zu einem Problem, anscheinend bestätigt der Aktor nicht und FHEM versucht den Block ab MsgCnt 84 zu wiederholen.

Das Ende wäre jetzt interessant.

Versuch auch mal, noch näher mit CUL an den Aktor ran zu kommen (ggf. mit USB-Verlängerungskabel). Vielleicht sind die -72dB noch nicht ausreichend bei der Datenrate.
Bei meinen Update-Tests war ich um die -60dB unterwegs.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bytechanger am 15 August 2017, 19:36:46
2017.08.15 19:07:28.022 2: CUL_HM fwUpdate started for Markise
2017.08.15 19:07:28.024 4: TSCUL_send:  CUL0                         As 0A 0A 3011 1DA462 43F1C8 CA
2017.08.15 19:07:28.024 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:436 rtoms:2766
2017.08.15 19:07:28.081 3: CUL_HM set Markise fwUpdate eq.eq3
2017.08.15 19:07:28.600 4: TSCUL_Parse: CUL0  346840 A F103 07755788 02 0A 0A 3011 1DA462 43F1C8 CA _bst _CCAdly:8 -138
2017.08.15 19:07:28.602 4: TSCUL_Parse: CUL0  346841 A F101 07756280 00 11 0A A002 43F1C8 1DA462 0453BE8AC2C66202 -69
2017.08.15 19:07:28.859 4: TSCUL_Parse: CUL0  347098 A F103 07756400 01 19 0A A003 1DA462 43F1C8 85 _CCAdly:4 _dhmSt:120 -138
2017.08.15 19:07:29.382 4: TSCUL_Parse: CUL0  347621 A F103 07756636 01 0A 0A 3011 1DA462 43F1C8 CA _bst _CCAdly:4 _dhmSt:356 -138
2017.08.15 19:07:29.384 4: TSCUL_Parse: CUL0  347623 A F101 07757132 00 11 0A A002 43F1C8 1DA462 04C36720E6C71E02 -68
2017.08.15 19:07:29.639 4: TSCUL_Parse: CUL0  347878 A F103 07757252 01 19 0A A003 1DA462 43F1C8 F5 _CCAdly:4 _dhmSt:972 -138
2017.08.15 19:07:29.894 4: TSCUL_Parse: CUL0  348133 A F101 07757408 00 12 0A 8002 43F1C8 1DA462 01016430466B01C539 -69
2017.08.15 19:07:29.897 4: TSCUL_Parse: CUL0  348136 A F101 07757488 00 14 00 0010 43F1C8 000000 004D455131373331353032 -68
2017.08.15 19:07:29.898 2: CUL_HM fwUpdate Markise entered mode. IO-speed: fast
2017.08.15 19:07:29.899 4: TSCUL_send:  CUL0                         As 0F 0B 00CB 1DA462 43F1C8 105B11F81547
2017.08.15 19:07:29.899 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:100
2017.08.15 19:07:30.383 4: TSCUL_send:  CUL0                         As 27 0D 00CA 1DA462 43F1C8 0102267D269AD1E5142CB43C72463102BAB8BF3232F560713D57A5B8915E
2017.08.15 19:07:30.383 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:119
2017.08.15 19:07:30.390 4: TSCUL_Parse: CUL0  348629 A F103 07757664 02 0F 0B 00CB 1DA462 43F1C8 10 _CCAdly:8 _dhmSt:176 -138
2017.08.15 19:07:30.646 4: TSCUL_send:  CUL0                         As 27 0E 00CA 1DA462 43F1C8 99993E78F907BCF70CFF1C688D593A937FDAD80A52D9D57B13A5BE834BB7
2017.08.15 19:07:30.647 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:119
2017.08.15 19:07:30.652 4: TSCUL_Parse: CUL0  348890 A F183 07758148 01 27 0D 00CA 1DA462 43F1C8 01 _fup _CCAdly:4 _dhmSt:660 -138
2017.08.15 19:07:30.907 4: TSCUL_send:  CUL0                         As 27 0F 00CA 1DA462 43F1C8 03AE9F484BF8A2120F1CE94D1837AF6F3D9377DA06609FCD7B98F7C51827
2017.08.15 19:07:30.907 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 19:07:30.909 4: TSCUL_Parse: CUL0  349149 A F183 07758412 02 27 0E 00CA 1DA462 43F1C8 99 _fup _CCAdly:8 _dhmSt:924 -138
2017.08.15 19:07:31.162 4: TSCUL_send:  CUL0                         As 27 10 00CA 1DA462 43F1C8 C46BC98C97B579ACC03032DF624F207D6582831A677B99A728B8E8CBE189
2017.08.15 19:07:31.162 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 19:07:31.165 4: TSCUL_Parse: CUL0  349404 A F183 07758672 01 27 0F 00CA 1DA462 43F1C8 03 _fup _CCAdly:4 _dhmSt:1184 -138
2017.08.15 19:07:31.419 4: TSCUL_send:  CUL0                         As 27 11 00CA 1DA462 43F1C8 CBD08358BA870B2549E5A54AC6FB29A82A58C22164A5DF47D82A3B55BD0C
2017.08.15 19:07:31.419 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 19:07:31.425 4: TSCUL_Parse: CUL0  349664 A F183 07758928 02 27 10 00CA 1DA462 43F1C8 C4 _fup _CCAdly:8 _dhmSt:1440 -138
2017.08.15 19:07:31.680 4: TSCUL_send:  CUL0                         As 27 12 00CA 1DA462 43F1C8 E925B1FE7DEB4EC35DC27C9FF7CCFCB70D855FF04CE25F3D84A074AF588D
2017.08.15 19:07:31.680 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 19:07:31.685 4: TSCUL_Parse: CUL0  349923 A F183 07759184 01 27 11 00CA 1DA462 43F1C8 CB _fup _CCAdly:4 _dhmSt:1696 -138
2017.08.15 19:07:31.940 4: TSCUL_send:  CUL0                         As 27 13 00CA 1DA462 43F1C8 8C859E16845427D7EF5F63C3AE91C4EE51543667145DBF8376BF142247DC
2017.08.15 19:07:31.941 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 19:07:31.945 4: TSCUL_Parse: CUL0  350184 A F183 07759444 01 27 12 00CA 1DA462 43F1C8 E9 _fup _CCAdly:4 _dhmSt:1956 -138
2017.08.15 19:07:32.199 4: TSCUL_send:  CUL0                         As 27 14 00CA 1DA462 43F1C8 788A4299F4C371560657DA066BFB52EEA0C74977CDBD06ABC7207FD4EBDF
2017.08.15 19:07:32.200 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 19:07:32.205 4: TSCUL_Parse: CUL0  350444 A F183 07759704 01 27 13 00CA 1DA462 43F1C8 8C _fup _CCAdly:4 _dhmSt:2216 -138
2017.08.15 19:07:32.461 4: TSCUL_send:  CUL0                         As 1D 15 20CA 1DA462 43F1C8 5753431E182034301FDC39933BFF3B07F0F6037D
2017.08.15 19:07:32.461 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:15 rtoms:1746
2017.08.15 19:07:32.465 4: TSCUL_Parse: CUL0  350704 A F183 07759964 01 27 14 00CA 1DA462 43F1C8 78 _fup _CCAdly:4 _dhmSt:2476 -138
2017.08.15 19:07:32.721 4: TSCUL_Parse: CUL0  350960 A F183 07760224 01 1D 15 20CA 1DA462 43F1C8 57 _fup _CCAdly:4 _dhmSt:2736 -138


[...] und es dauert [...]

2017.08.15 19:24:30.903 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 19:24:30.908 4: TSCUL_Parse: CUL0  320571 A F283 08778444 01 27 35 00CA 1DA462 43F1C8 51 _fup _CCAdly:4 -138
2017.08.15 19:24:31.163 4: TSCUL_send:  CUL0                         As 27 37 00CA 1DA462 43F1C8 1E3D941101CB418CFDFAC7DDDE0594D43BC88057B285A2EC16821310635D
2017.08.15 19:24:31.167 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 19:24:31.172 4: TSCUL_Parse: CUL0  320835 A F283 08778704 02 27 36 00CA 1DA462 43F1C8 88 _fup _CCAdly:8 -138
2017.08.15 19:24:31.428 4: TSCUL_send:  CUL0                         As 0F 38 20CA 1DA462 43F1C8 601EC7F05248
2017.08.15 19:24:31.428 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:14 rtoms:1746
2017.08.15 19:24:31.432 4: TSCUL_Parse: CUL0  321095 A F283 08778964 02 27 37 00CA 1DA462 43F1C8 1E _fup _CCAdly:8 -138
2017.08.15 19:24:31.689 4: TSCUL_Parse: CUL0  321352 A F283 08779228 02 0F 38 20CA 1DA462 43F1C8 60 _fup _CCAdly:8 -138
2017.08.15 19:24:31.692 4: TSCUL_Parse: CUL0  321354 A F281 08779280 00 0A 38 0002 43F1C8 1DA462 00 _fup -77
2017.08.15 19:24:31.957 4: TSCUL_send:  CUL0                         As 27 39 00CA 1DA462 43F1C8 00D261309E1623FADE9DDA4041A84F187BC437DC63128D3E4D505B443D79
2017.08.15 19:24:31.958 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 19:24:32.216 4: TSCUL_send:  CUL0                         As 27 3A 00CA 1DA462 43F1C8 B0BD5BF7368BDBE7F8C757889856A434C43409C66D56CCA0CDF6B093CF20
2017.08.15 19:24:32.216 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 19:24:32.221 4: TSCUL_Parse: CUL0  321884 A F283 08779756 01 27 39 00CA 1DA462 43F1C8 00 _fup _CCAdly:4 _dhmSt:476 -138
2017.08.15 19:24:32.477 4: TSCUL_send:  CUL0                         As 27 3B 00CA 1DA462 43F1C8 108E91D9EB2E01173F59C503C521DEEF16D18605CC9A38ACF39680E976FC
2017.08.15 19:24:32.478 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 19:24:32.482 4: TSCUL_Parse: CUL0  322145 A F283 08780016 01 27 3A 00CA 1DA462 43F1C8 B0 _fup _CCAdly:4 _dhmSt:736 -138
2017.08.15 19:24:32.738 4: TSCUL_send:  CUL0                         As 27 3C 00CA 1DA462 43F1C8 C8A3814E2A456A4560A325E749F55490269236D7D16DEE4958505AA6A754
2017.08.15 19:24:32.738 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 19:24:32.742 4: TSCUL_Parse: CUL0  322405 A F283 08780276 01 27 3B 00CA 1DA462 43F1C8 10 _fup _CCAdly:4 _dhmSt:996 -138
2017.08.15 19:24:32.999 4: TSCUL_send:  CUL0                         As 27 3D 00CA 1DA462 43F1C8 1D45B44DFBF72DF8DE8B71EEAEF9271AA6B22D002AFF685127EA17E5C8E8
2017.08.15 19:24:32.999 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 19:24:33.001 4: TSCUL_Parse: CUL0  322665 A F283 08780536 01 27 3C 00CA 1DA462 43F1C8 C8 _fup _CCAdly:4 _dhmSt:1256 -138
2017.08.15 19:24:33.254 4: TSCUL_send:  CUL0                         As 27 3E 00CA 1DA462 43F1C8 D48E08AB2E55DD8F579F6B8E36FAC236DC86952981FAD931FE89B011B8CA
2017.08.15 19:24:33.254 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 19:24:33.257 4: TSCUL_Parse: CUL0  322920 A F283 08780800 02 27 3D 00CA 1DA462 43F1C8 1D _fup _CCAdly:8 _dhmSt:1520 -138
2017.08.15 19:24:33.512 4: TSCUL_send:  CUL0                         As 27 3F 00CA 1DA462 43F1C8 364C8B7DCA753A5CAEEB976A4BCB8C602E0621C56CE0559970BE96F71491
2017.08.15 19:24:33.512 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:16
2017.08.15 19:24:33.517 4: TSCUL_Parse: CUL0  323181 A F283 08781052 01 27 3E 00CA 1DA462 43F1C8 D4 _fup _CCAdly:4 _dhmSt:1772 -138
2017.08.15 19:24:33.772 4: TSCUL_send:  CUL0                         As 0B 40 20CA 1DA462 43F1C8 BEB1
2017.08.15 19:24:33.773 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:13 rtoms:1746
2017.08.15 19:24:33.777 4: TSCUL_Parse: CUL0  323440 A F283 08781312 01 27 3F 00CA 1DA462 43F1C8 36 _fup _CCAdly:4 _dhmSt:2032 -138
2017.08.15 19:24:34.036 4: TSCUL_Parse: CUL0  323698 A F283 08781572 02 0B 40 20CA 1DA462 43F1C8 BE _fup _CCAdly:8 _dhmSt:2292 -138
2017.08.15 19:24:34.038 4: TSCUL_Parse: CUL0  323700 A F281 08781656 00 0A 40 0002 43F1C8 1DA462 00 _fup -80.5
2017.08.15 19:24:34.184 2: CUL_HM fwUpdate Markise end. IO-speed: normal
2017.08.15 19:24:34.184 2: CUL_HM fwUpdate completed
2017.08.15 19:24:34.216 3: CUL0: Unknown code A0A40000243F1C81DA46200::-80.5:CUL0, help me!
2017.08.15 19:24:35.102 4: TSCUL_Parse: CUL0  324765 A F201 08782876 00 0D 00 A410 43F1C8 1DA462 06016430 -81.5
2017.08.15 19:24:35.114 4: TSCUL_send:  CUL0                         As 0A 00 8002 1DA462 43F1C8 00
2017.08.15 19:24:35.115 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:96
2017.08.15 19:24:35.469 4: TSCUL_Parse: CUL0  325133 A F203 08782996 01 0A 00 8002 1DA462 43F1C8 00 _CCAdly:4 _dhmSt:120 -138
2017.08.15 19:24:36.240 3: CUL_HM set Markise getConfig
2017.08.15 19:24:36.246 4: TSCUL_send:  CUL0                         As 10 01 A001 1DA462 43F1C8 00040000000000
2017.08.15 19:24:36.247 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:101 rtoms:1746
2017.08.15 19:24:36.599 4: TSCUL_Parse: CUL0  326262 A F203 08784044 01 10 01 A001 1DA462 43F1C8 00 _CCAdly:4 _dhmSt:1168 -138
2017.08.15 19:24:36.602 4: TSCUL_Parse: CUL0  326264 A F201 08784204 00 16 01 A010 43F1C8 1DA462 0202010A1D0BA40C6215FF1800 -78
2017.08.15 19:24:36.877 4: TSCUL_send:  CUL0                         As 0A 01 8002 1DA462 43F1C8 00
2017.08.15 19:24:36.877 4: TSCUL_XmitDlyHM:  CUL0  id:43F1C8 toms:96
2017.08.15 19:24:36.881 4: TSCUL_Parse: CUL0  326544 A F201 08784496 00 16 01 A010 43F1C8 1DA462 0202010A1D0BA40C6215FF1800 -79.5


Dann ein "set clear all"
"set getConfig"
"set getVersion"

Aber nirgens taucht mehr die aktuelle Version auf.
Vor einigen Updates stand da immer noch V2.8

Laut Log sollte doch das Firmwareupgrade geklappt haben, obwohl es ja ewig gedauert hat!

Wie erfahre ich nun die aktuelle Version??

Greets

Byte
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 15 August 2017, 19:56:49
Hallo Byte,

ZitatCUL_HM fwUpdate completed
Das liesst sich gut.

ZitatWie erfahre ich nun die aktuelle Version??
Wird getVersion denn in der Auswahlliste angeboten?
Damit wird die Version bei unterstützten devices auch aktualisiert. Aber nicht alle haben die Auswahl.

Versuch es mal alternativ mit der Anlerntaste am Aktor.
Neues Pairing aktualisierte bei mir die Versionsinfo.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bytechanger am 15 August 2017, 20:55:54
Hi,

OK, also getVersion wurde angeboten, gab aber keine Änderung.
Schalter geöffnet, auf Config gedrückt, nun steht die neue Version 2.11 in FHEM!
Danke, hat funktioniert.
Ist es normal, dass das Update so lange dauert und ständig Sendungen wiederholt werden?

Greets

Byte
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 15 August 2017, 21:28:22
Hallo Byte,

schön, dass es geklappt hat.

ZitatIst es normal, dass das Update so lange dauert und ständig Sendungen wiederholt werden?
Wenn die Funkverbindung nicht gut ist, dann sicherlich.

Aus dem, was Du an Logs gezeigt hast, ist ein konkretes Problem nicht erkennbar, außer halt des nicht so dollen RSSI. Daran wolltest Du wohl nichts ändern???

Natürlich kann auch was anderes dazwischen gequasselt haben. Hast Du vielleicht noch mehr 868.3MHz Komponenten, die fröhlich unaufgefordert senden?

Es dauert schon was, bis alle Blöcke gesandt und geflashed sind, aber ich habe es nicht so lange in Erinnerung, wie bei Dir. Allerdings hatte ich auch nur ganz selten Wiederholungen bei Blöcken.

Bei einem Batteriebetriebenen Aktor hätte ich für so einen langen Versuch wohl zu einem Netzteil als Stromquelle für den Aktor tendiert.  ;)

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bytechanger am 15 August 2017, 22:31:21
Hallo,

ich habe mich mit einer 5m Verlängerung mich näher an die Markise gearbeitet.
Ich betreibe noch 6 Temperatursensoren die über LaCrosse in FHEM eingelesen werden. Die arbeiten auch auf 863 MHz und senden, soweit ich weiss, im 10 Sekundentakt ?
Was ich nochmal testen wollte ist das Verhalten von CUL und AES-Sensoren. Da hatte ich in der Vergangenheit -bei abgeschaltetem/deaktiviertem HMLAN- arge Probleme.
Die Antwort des CUL war da offensichtlich für die Sensoren unbefriedigend (rote LED leuchtete nach orange).

Greets

Byte
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 16 August 2017, 00:03:23
Hallo Byte,

ZitatIch betreibe noch 6 Temperatursensoren die über LaCrosse in FHEM eingelesen werden. Die arbeiten auch auf 863 MHz und senden, soweit ich weiss, im 10 Sekundentakt ?
Meinst Du 868.3MHz? Nun, beim nächsten Update nimm halt mal aus all den LaCrosse Sensoren die Batterien raus und schau, ob es besser geht.

ZitatWas ich nochmal testen wollte ist das Verhalten von CUL und AES-Sensoren. Da hatte ich in der Vergangenheit -bei abgeschaltetem/deaktiviertem HMLAN- arge Probleme.
Also beim Senden an devices unterstützt die tscul Firmware das Signieren (Register Wert Sign auf on).

Wenn Sendedaten von devices kommend von FHEM signiert gewünscht werden (attribut aesCommReq), dann sendet FHEM die Signierungsanforderung und muss dabei schnell genug sein, damit das device auch noch wach ist, wenn die Signierungsanforderung gesendet wird.
Ob es dabei zu Problemen kommen kann, habe ich nicht testen können, mangels entsprechender devices.
Logs dazu sind willkommen.
Oder wenn es gut funktioniert auch positives Feedback. ;)

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bytechanger am 16 August 2017, 12:22:32
Habe die Kühlschränke vergessen. Es sind 10 Thermometer. Puhh, weiss nicht, ob ich überall die Batterie raushole.

Ich werde mal testen. Ich glaube das Problem war genau bei der Anforderung der Signierung. Wenn ich aesCommReq ausschaltete, ging es.
Ich werde Nachberichten, da ich ein starkes Interesse habe, dass dies funktioniert! Dann kommen auch Logs....


Greets

Byte
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bytechanger am 16 August 2017, 16:37:28
Hallo,

ich habe mal getestet.
Solange der HMLAN irgendwie an ist, geht alles. Also selbst, wenn ich ihn über FHEM auf closed setze meckert kein Sensor.
Stecke ich ihn jedoch komplett vom Strom ab und lasse nur den CUL reden passiert folgendes:

Die Sensoren melden "offen" und quittieren auch optisch mit grünem Schlusslicht. Schließe ich jedoch das Fenster wieder, wechselt der Sensor nach langer orange Zeit in rot.
Da scheint also etwas nicht zu funktionieren:

Hier das Log eines Öffnen und Schließens:
2017.08.16 16:30:44.259 4: TSCUL_Parse: CUL0  272162 A F001 06721300 00 0C 77 A641 278291 1DA462 015EC8 -50.5
2017.08.16 16:30:44.262 4: TSCUL_send:  CUL0                         As 11 77 A002 1DA462 278291 04ECEB2A25356702
2017.08.16 16:30:44.262 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.16 16:30:44.550 4: TSCUL_Parse: CUL0  272453 A F103 06721420 01 11 77 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:120 -138
2017.08.16 16:30:44.552 4: TSCUL_Parse: CUL0  272454 A F101 06721580 00 19 77 A203 278291 1DA462 2F755F719BC66AFC1AE4548B34CCC164 -50
2017.08.16 16:30:44.861 4: TSCUL_send:  CUL0                         As 11 77 8002 1DA462 278291 0101C800281cecfc
2017.08.16 16:30:44.861 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102
2017.08.16 16:30:44.863 4: TSCUL_Parse: CUL0  272767 A F101 06721824 00 0C 77 A241 278291 1DA462 015EC8 -49.5
2017.08.16 16:30:45.134 4: TSCUL_send:  CUL0                         As 11 77 A002 1DA462 278291 041E16D632238602
2017.08.16 16:30:45.134 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.16 16:30:45.136 4: TSCUL_Parse: CUL0  273040 A F103 06721964 02 11 77 8002 1DA462 278291 01 _CCAdly:8 _dhmSt:140 -138
2017.08.16 16:30:45.393 4: TSCUL_Parse: CUL0  273296 A F103 06722236 01 11 77 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:412 -138
2017.08.16 16:30:45.677 4: TSCUL_Parse: CUL0  273580 A F103 06722508 01 11 77 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:684 -138
2017.08.16 16:30:45.931 4: TSCUL_Parse: CUL0  273834 A F103 06722780 01 11 77 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:956 -138
2017.08.16 16:30:46.187 1: TSCUL_ParseTsHM: CUL0 HM repeat failed to 278291/EG_FensterBuero:  274091 A F109 06723048 00 11 77 A002 1DA462 278291 04 _sfail
2017.08.16 16:30:46.957 4: TSCUL_XmitAwaitTo CUL0: timeout - 278291
2017.08.16 16:30:48.704 4: TSCUL_Parse: CUL0  276607 A F101 06725796 00 0C 78 A641 278291 1DA462 015F00 -48
2017.08.16 16:30:48.707 4: TSCUL_send:  CUL0                         As 11 78 A002 1DA462 278291 041E16D632238602
2017.08.16 16:30:48.707 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.16 16:30:48.985 4: TSCUL_Parse: CUL0  276888 A F103 06725916 01 11 78 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:120 -138
2017.08.16 16:30:49.245 4: TSCUL_Parse: CUL0  277146 A F101 06726076 00 19 78 A203 278291 1DA462 6919ADC6C7835382ABB7553205FC2140 -47.5
2017.08.16 16:30:49.305 4: TSCUL_Parse: CUL0  277208 A F101 06726320 00 0C 78 A241 278291 1DA462 015F00 -47.5
2017.08.16 16:30:49.594 4: TSCUL_send:  CUL0                         As 11 78 8002 1DA462 278291 0101C8005f1b762e
2017.08.16 16:30:49.594 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102
2017.08.16 16:30:49.850 4: TSCUL_send:  CUL0                         As 11 78 A002 1DA462 278291 041BD491BC627102
2017.08.16 16:30:49.850 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.16 16:30:49.854 4: TSCUL_Parse: CUL0  277758 A F103 06726696 01 11 78 8002 1DA462 278291 01 _CCAdly:4 _dhmSt:376 -138
2017.08.16 16:30:49.856 4: TSCUL_Parse: CUL0  277759 A F101 06726824 00 0C 78 A241 278291 1DA462 015F00 -47.5
2017.08.16 16:30:50.136 4: TSCUL_Parse: CUL0  278039 A F103 06726952 01 11 78 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:632 -138
2017.08.16 16:30:50.138 4: TSCUL_Parse: CUL0  278041 A F101 06727112 00 19 78 A203 278291 1DA462 14AABB4DF1F5639A4A92C5772DCE1307 -47.5
2017.08.16 16:30:50.143 4: TSCUL_send:  CUL0                         As 11 78 8002 1DA462 278291 0101C800c0d4dfa5
2017.08.16 16:30:50.143 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102
2017.08.16 16:30:50.436 4: TSCUL_Parse: CUL0  278340 A F103 06727244 01 11 78 8002 1DA462 278291 01 _CCAdly:4 _dhmSt:132 -138
2017.08.16 16:30:51.198 4: TSCUL_Parse: CUL0  279101 A F101 06728116 00 0C 78 A241 278291 1DA462 015F00 -47.5
2017.08.16 16:30:51.201 4: TSCUL_send:  CUL0                         As 11 78 A002 1DA462 278291 042E1DA8F664DE02
2017.08.16 16:30:51.201 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.16 16:30:51.492 4: TSCUL_Parse: CUL0  279395 A F103 06728304 02 11 78 A002 1DA462 278291 04 _CCAdly:8 _dhmSt:188 -138
2017.08.16 16:30:51.749 4: TSCUL_Parse: CUL0  279652 A F103 06728572 01 11 78 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:456 -138
2017.08.16 16:30:52.007 4: TSCUL_Parse: CUL0  279910 A F103 06728844 01 11 78 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:728 -138
2017.08.16 16:30:52.261 1: TSCUL_ParseTsHM: CUL0 HM repeat failed to 278291/EG_FensterBuero:  280164 A F109 06729112 00 11 78 A002 1DA462 278291 04 _sfail
2017.08.16 16:30:53.031 4: TSCUL_XmitAwaitTo CUL0: timeout - 278291
2017.08.16 16:30:53.289 4: TSCUL_Parse: CUL0  281192 A F101 06730136 00 0C 78 A241 278291 1DA462 015F00 -47.5
2017.08.16 16:30:53.290 4: TSCUL_send:  CUL0                         As 11 78 A002 1DA462 278291 042E1DA8F664DE02
2017.08.16 16:30:53.290 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.16 16:30:53.561 4: TSCUL_Parse: CUL0  281465 A F103 06730392 01 11 78 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:2276 -138
2017.08.16 16:30:53.841 4: TSCUL_Parse: CUL0  281744 A F103 06730664 01 11 78 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:2548 -138
2017.08.16 16:30:54.098 4: TSCUL_Parse: CUL0  282001 A F103 06730936 01 11 78 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:2820 -138
2017.08.16 16:30:54.358 1: TSCUL_ParseTsHM: CUL0 HM repeat failed to 278291/EG_FensterBuero:  282262 A F109 06731204 00 11 78 A002 1DA462 278291 04 _sfail
2017.08.16 16:30:55.123 4: TSCUL_XmitAwaitTo CUL0: timeout - 278291
2017.08.16 16:30:57.287 4: TSCUL_Parse: CUL0  285190 A F101 06734184 00 0C 78 A241 278291 1DA462 015F00 -47.5
2017.08.16 16:30:57.290 4: TSCUL_send:  CUL0                         As 11 78 A002 1DA462 278291 042E1DA8F664DE02
2017.08.16 16:30:57.291 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.16 16:30:57.581 4: TSCUL_Parse: CUL0  285484 A F103 06734392 01 11 78 A002 1DA462 278291 04 _CCAdly:4 -138
2017.08.16 16:30:57.839 4: TSCUL_Parse: CUL0  285742 A F103 06734664 01 11 78 A002 1DA462 278291 04 _CCAdly:4 -138
2017.08.16 16:30:58.096 4: TSCUL_Parse: CUL0  285999 A F103 06734936 01 11 78 A002 1DA462 278291 04 _CCAdly:4 -138
2017.08.16 16:30:58.350 1: TSCUL_ParseTsHM: CUL0 HM repeat failed to 278291/EG_FensterBuero:  286254 A F109 06735204 00 11 78 A002 1DA462 278291 04 _sfail
2017.08.16 16:30:59.165 4: TSCUL_XmitAwaitTo CUL0: timeout - 278291


aesCommToDev bleibt auch bei "pending" stehen.

Internals:
   CUL0_MSGCNT 55
   CUL0_RAWMSG A0C7AA2412782911DA462016100::-52:CUL0
   CUL0_RSSI  -52
   CUL0_TIME  2017-08-16 16:31:33
   DEF        278291
   HMLAN1_MSGCNT 13
   HMLAN1_RAWMSG E278291,0040,071C752C,01,FFC6,74A6412782911DA462015B00
   HMLAN1_RSSI -58
   HMLAN1_TIME 2017-08-16 16:27:24
   IODev      CUL0
   LASTInputDev CUL0
   MSGCNT     68
   NAME       EG_FensterBuero
   NOTIFYDEV  global
   NR         390
   NTFY_ORDER 50-EG_FensterBuero
   STATE      open
   TYPE       CUL_HM
   lastMsg    No:79 - t:41 s:278291 d:1DA462 0160C8
   protEvt_AESCom-ok 7 last_at:2017-08-16 16:31:23
   protLastRcv 2017-08-16 16:31:23
   protSnd    8 last_at:2017-08-16 16:31:23
   protState  CMDs_done
   rssi_at_CUL0 lst:-47.5 max:-47.5 cnt:5 min:-50.5 avg:-48.7
   rssi_at_HMLAN1 max:-58 lst:-58 cnt:3 min:-72 avg:-62.66
   READINGS:
     2017-08-15 20:00:39   Activity        alive
     2016-06-08 13:53:01   D-firmware      2.4
     2016-06-08 13:53:01   D-serialNr      LEQ0214244
     2016-10-21 06:43:32   PairedTo        0x1DA462
     2016-06-08 16:53:11   R-cyclicInfoMsg on
     2016-06-09 07:06:38   R-eventDlyTime  0 s
     2016-06-08 16:53:11   R-pairCentral   0x1DA462
     2016-06-08 16:53:11   R-sabotageMsg   on
     2016-06-09 07:06:38   R-sign          on
     2016-10-21 06:43:32   RegL_00.        02:01 09:01 0A:1D 0B:A4 0C:62 10:01 14:06 00:00
     2016-10-22 06:34:32   RegL_01.        08:01 20:60 21:00 22:64 30:06 00:00
     2017-08-16 16:31:33   aesCommToDev    pending
     2017-08-16 16:28:06   aesReqTo        vccu
     2017-08-16 16:07:41   alive           yes
     2017-08-16 16:31:23   battery         ok
     2017-08-16 16:31:23   contact         open (to vccu)
     2016-10-19 07:01:52   powerOn         2016-10-19 07:01:52
     2017-08-16 16:07:41   recentStateType info
     2017-08-16 16:07:41   sabotageError   off
     2017-08-16 16:31:23   state           open
     2017-01-19 05:55:51   trigDst_1D5B09  noConfig
     2016-07-23 09:48:22   trigDst_vccu    noConfig
     2017-08-16 16:31:23   trig_aes_vccu   ok:96
     2017-08-16 16:31:23   trigger_cnt     96
   helper:
     HM_CMDNR   121
     mId        00B1
     rxType     28
     supp_Pair_Rep 0
     ack:
     aesCommRq:
       challenge  EB513D3A931F
       kNo        1
       msg        A0C7AA2412782911DA462016100
       msgIn      A0C7AA2412782911DA462016100::-52:CUL0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       lstRecType 41
       newChn     +278291,01,01,02
       nextSend   1502893885.30628
       nxtSndMcnt 7A
       rxt        2
       tgtDly     100
       vccu       vccu
       lRcTm:
         CUL0       73871164
         tnms       729073430
       p:
         278291
         01
         01
         02
       prefIO:
         CUL0
     mRssi:
       mNo        79
       io:
         CUL0       -45.5
     prt:
       bErr       0
       sProc      0
       sleeping   1
       rspWait:
     q:
       qReqConf
       qReqStat
     role:
       chn        1
       dev        1
     rpt:
       IO         CUL0
       flg        A
       ts         1502893883.01108
       ack:
         HASH(0x2b967c0)
         7980021DA4622782910101C800
     rssi:
       at_CUL0:
         avg        -48.7
         cnt        5
         lst        -47.5
         max        -47.5
         min        -50.5
       at_HMLAN1:
         avg        -62.6666666666667
         cnt        3
         lst        -58
         max        -58
         min        -72
     shadowReg:
     tmpl:
   role:
Attributes:
   IODev      CUL0
   IOgrp      vccu:CUL0
   actCycle   028:00
   actStatus  alive
   aesCommReq 1
   alarmDevice Sensor
   alarmSettings alarm6,|EG_FensterBuero:[Oo]pen.*|Fenster Büro|on
   autoReadReg 4_reqStatus
   devStateIcon open:fts_window_1w_open@red closed:fts_window_1w@green
   expert     2_raw
   firmware   2.4
   group      Fenster
   icon       fts_window_2w_open
   model      HM-SEC-SC-2
   peerIDs    00000000,
   room       CUL_HM,Zustand,Öffnungssensoren
   serialNr   LEQ0214244
   subType    threeStateSensor


Greets

Byte
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 16 August 2017, 20:51:48
Hallo Byte,

kannst Du das bitte nochmal mit aktivem HMLAN wiederholen und CUL_0 mit verbose 4 dabei zuhören lassen?

Ich denke derzeit anhand des Logs, dass die AES Antwort seitens FHEM zu langsam raus geschickt wird. 309ms dauert es, bis die Signierungsantwort an CUL raus ist und dann wiederholt das device schon, akzeptiert aber die Antwort anscheinend noch?!?
Sprich auch das Öffnen ist nicht richtig abgelaufen.
(Ein bischen mehr Zeit zwischen Öffnen und Schließen wäre auch nicht verkehrt gewesen)

Beim Schließen waren es wohl 349ms
Warum weiß ich noch nicht.

Oder war davor oder dahinter oder mittendrin noch was, was Du weg gelassen hast?

ZitataesCommToDev bleibt auch bei "pending" stehen.
Da anscheinend dann das device nicht mehr mitspielt.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bytechanger am 16 August 2017, 21:18:14
Hi,

bin nicht sicher, ob ich es richtig verstanden habe.
Ich habe HMLAN nun eingeschaltet und mit FHEM verbunden, aber als preferred Device im Sensor den CUL:

Öffnen:
2017.08.16 21:07:13.258 4: TSCUL_Parse: CUL0  083945 A F001 15652848 00 0C 7D A641 278291 1DA462 0164C8 -52.5
2017.08.16 21:07:13.261 4: TSCUL_send:  CUL0                         As 11 7D A002 1DA462 278291 04E436D6CB52F602
2017.08.16 21:07:13.262 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.16 21:07:13.589 4: TSCUL_Parse: CUL0  084277 A F103 15652980 04 11 7D A002 1DA462 278291 04 _CCAdly:16 _dhmSt:132 -138
2017.08.16 21:07:13.846 4: TSCUL_Parse: CUL0  084534 A F101 15653228 00 0E 7D 8002 1DA462 278291 0029A9C509 -54.5
2017.08.16 21:07:13.850 4: TSCUL_Parse: CUL0  084537 A F103 15653308 01 11 7D A002 1DA462 278291 04 _CCAdly:4 _dhmSt:460 -138
2017.08.16 21:07:14.139 4: TSCUL_Parse: CUL0  084826 A F103 15653580 01 11 7D A002 1DA462 278291 04 _CCAdly:4 _dhmSt:732 -138
2017.08.16 21:07:14.398 1: TSCUL_ParseTsHM: CUL0 HM repeat failed to 278291/EG_FensterBuero:  085085 A F109 15653848 00 11 7D A002 1DA462 278291 04 _sfail
2017.08.16 21:07:15.255 4: TSCUL_XmitAwaitTo CUL0: timeout - 278291
2017.08.16 21:07:15.711 4: TSCUL_send:  CUL0                         As 0D 7D 8002 1DA462 278291 0101C800
2017.08.16 21:07:15.711 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:99
2017.08.16 21:07:15.972 4: TSCUL_Parse: CUL0  086659 A F103 15655344 01 0D 7D 8002 1DA462 278291 01 _CCAdly:4 _dhmSt:2496 -138


(IODev CUL0
LASTInputDev  HMLAN1)

Schließen
2017.08.16 21:09:14.783 4: TSCUL_Parse: CUL0  205469 A F001 15774364 00 0C 7E A641 278291 1DA462 016500 -52.5
2017.08.16 21:09:14.786 4: TSCUL_send:  CUL0                         As 11 7E A002 1DA462 278291 04E436D6CB52F602
2017.08.16 21:09:14.786 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.16 21:09:15.117 4: TSCUL_Parse: CUL0  205804 A F103 15774496 04 11 7E A002 1DA462 278291 04 _CCAdly:16 _dhmSt:132 -138
2017.08.16 21:09:15.374 4: TSCUL_Parse: CUL0  206062 A F103 15774768 01 11 7E A002 1DA462 278291 04 _CCAdly:4 _dhmSt:404 -138
2017.08.16 21:09:15.658 4: TSCUL_Parse: CUL0  206345 A F103 15775040 01 11 7E A002 1DA462 278291 04 _CCAdly:4 _dhmSt:676 -138
2017.08.16 21:09:15.920 1: TSCUL_ParseTsHM: CUL0 HM repeat failed to 278291/EG_FensterBuero:  206607 A F109 15775308 00 11 7E A002 1DA462 278291 04 _sfail
2017.08.16 21:09:16.786 4: TSCUL_XmitAwaitTo CUL0: timeout - 278291
2017.08.16 21:09:17.243 4: TSCUL_send:  CUL0                         As 0D 7E 8002 1DA462 278291 0101C800
2017.08.16 21:09:17.243 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:99
2017.08.16 21:09:17.504 4: TSCUL_Parse: CUL0  208191 A F103 15776880 01 0D 7E 8002 1DA462 278291 01 _CCAdly:4 _dhmSt:2516 -138


HMLAN von FHEM getrennt (disconnected) ABER noch mit Strom (ich vermute es Antwortet trotzdem):
Öffnen:
2017.08.16 21:10:04.255 4: TSCUL_Parse: CUL0  254942 A F001 15823868 00 0C 7F A641 278291 1DA462 0166C8 -55.5
2017.08.16 21:10:04.256 4: TSCUL_send:  CUL0                         As 11 7F A002 1DA462 278291 04E436D6CB52F602
2017.08.16 21:10:04.257 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.16 21:10:04.546 4: TSCUL_Parse: CUL0  255233 A F103 15824004 05 11 7F A002 1DA462 278291 04 _CCAdly:20 _dhmSt:136 -138
2017.08.16 21:10:04.547 4: TSCUL_Parse: CUL0  255234 A F101 15824128 00 19 7F A203 278291 1DA462 79DC22541A74C11D232CB0E61E0D59B9 -53
2017.08.16 21:10:04.825 4: TSCUL_Parse: CUL0  255512 A F101 15824252 00 0E 7F 8002 1DA462 278291 00661A4C3A -53.5


Schließen (hier schon Fehler!):

2017.08.16 21:14:34.758 4: TSCUL_Parse: CUL0  001157 A F001 16094396 00 0C 8A A641 278291 1DA462 017100 -57.5
2017.08.16 21:14:34.761 4: TSCUL_send:  CUL0                         As 11 8A A002 1DA462 278291 045E1400CAAAD102
2017.08.16 21:14:34.762 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.16 21:14:35.086 4: TSCUL_Parse: CUL0  001486 A F103 16094532 05 11 8A A002 1DA462 278291 04 _CCAdly:20 _dhmSt:136 -138
2017.08.16 21:14:35.087 4: TSCUL_Parse: CUL0  001487 A F101 16094660 00 19 8A A203 278291 1DA462 B02A79685C1E5C6885415D6E15F8EE4E -57
2017.08.16 21:14:35.360 4: TSCUL_Parse: CUL0  001760 A F101 16094780 00 0E 8A 8002 1DA462 278291 007A939F9F -53.5


Jetzt mit komplett getrenntem HMLAN:

Öffnen (schon mit Fehler "pending"):
2017.08.16 21:15:48.263 4: TSCUL_Parse: CUL0  074661 A F001 16167660 00 0C 8B A641 278291 1DA462 0172C8 -53
2017.08.16 21:15:48.266 4: TSCUL_send:  CUL0                         As 11 8B A002 1DA462 278291 04FEB60494D17502
2017.08.16 21:15:48.267 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.16 21:15:48.581 4: TSCUL_Parse: CUL0  074980 A F001 16167912 00 0C 8B A241 278291 1DA462 0172C8 -54.5
2017.08.16 21:15:48.601 4: TSCUL_Parse: CUL0  075001 A F103 16168032 01 11 8B A002 1DA462 278291 04 _CCAdly:4 _dhmSt:372 -138
2017.08.16 21:15:48.602 4: TSCUL_Parse: CUL0  075002 A F101 16168192 00 19 8B A203 278291 1DA462 79FBC76FAB2228716EB3D5A3EFE08F87 -54.5
2017.08.16 21:15:48.884 4: TSCUL_send:  CUL0                         As 11 8B 8002 1DA462 278291 0101C800e0deea86
2017.08.16 21:15:48.884 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102
2017.08.16 21:15:49.151 4: TSCUL_Parse: CUL0  075550 A F103 16168536 01 11 8B 8002 1DA462 278291 01 _CCAdly:4 _dhmSt:344 -138
2017.08.16 21:15:49.153 4: TSCUL_Parse: CUL0  075552 A F101 16168688 00 0C 8B A241 278291 1DA462 0172C8 -54
2017.08.16 21:15:49.156 4: TSCUL_send:  CUL0                         As 11 8B A002 1DA462 278291 045915C7ACBA7F02
2017.08.16 21:15:49.156 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.16 21:15:49.445 4: TSCUL_Parse: CUL0  075845 A F103 16168808 01 11 8B A002 1DA462 278291 04 _CCAdly:4 _dhmSt:120 -138
2017.08.16 21:15:49.448 4: TSCUL_Parse: CUL0  075846 A F101 16168968 00 19 8B A203 278291 1DA462 F084C3B7764399C51AD098D915B23F1D -53.5
2017.08.16 21:15:49.742 4: TSCUL_send:  CUL0                         As 11 8B 8002 1DA462 278291 0101C800897335c9
2017.08.16 21:15:49.742 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102
2017.08.16 21:15:50.029 4: TSCUL_Parse: CUL0  076428 A F103 16169396 02 11 8B 8002 1DA462 278291 01 _CCAdly:8 _dhmSt:428 -138
2017.08.16 21:15:50.539 4: TSCUL_Parse: CUL0  076938 A F101 16169972 00 0C 8B A241 278291 1DA462 0172C8 -53.5
2017.08.16 21:15:50.542 4: TSCUL_send:  CUL0                         As 11 8B A002 1DA462 278291 045B50ADEB948002
2017.08.16 21:15:50.543 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.16 21:15:50.829 4: TSCUL_Parse: CUL0  077229 A F103 16170196 02 11 8B A002 1DA462 278291 04 _CCAdly:8 _dhmSt:224 -138
2017.08.16 21:15:51.091 4: TSCUL_Parse: CUL0  077490 A F103 16170464 01 11 8B A002 1DA462 278291 04 _CCAdly:4 _dhmSt:492 -138
2017.08.16 21:15:51.345 4: TSCUL_Parse: CUL0  077744 A F103 16170736 01 11 8B A002 1DA462 278291 04 _CCAdly:4 _dhmSt:764 -138
2017.08.16 21:15:51.603 1: TSCUL_ParseTsHM: CUL0 HM repeat failed to 278291/EG_FensterBuero:  078003 A F109 16171004 00 11 8B A002 1DA462 278291 04 _sfail
2017.08.16 21:15:52.475 4: TSCUL_XmitAwaitTo CUL0: timeout - 278291
2017.08.16 21:15:52.483 4: TSCUL_Parse: CUL0  078882 A F101 16171992 00 0C 8B A241 278291 1DA462 0172C8 -53.5
2017.08.16 21:15:56.597 4: TSCUL_Parse: CUL0  082995 A F101 16176040 00 0C 8B A241 278291 1DA462 0172C8 -53.5
2017.08.16 21:15:56.600 4: TSCUL_send:  CUL0                         As 11 8B A002 1DA462 278291 045B50ADEB948002
2017.08.16 21:15:56.601 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.16 21:15:56.934 4: TSCUL_Parse: CUL0  083334 A F103 16176252 01 11 8B A002 1DA462 278291 04 _CCAdly:4 -138
2017.08.16 21:15:56.936 4: TSCUL_Parse: CUL0  083335 A F103 16176524 01 11 8B A002 1DA462 278291 04 _CCAdly:4 -138
2017.08.16 21:15:57.194 4: TSCUL_Parse: CUL0  083593 A F103 16176796 01 11 8B A002 1DA462 278291 04 _CCAdly:4 -138
2017.08.16 21:15:57.448 1: TSCUL_ParseTsHM: CUL0 HM repeat failed to 278291/EG_FensterBuero:  083847 A F109 16177064 00 11 8B A002 1DA462 278291 04 _sfail
2017.08.16 21:15:58.600 4: TSCUL_XmitAwaitTo CUL0: timeout - 278291


Schließen diesmal ohne Fehler (grüne LED):
2017.08.16 21:16:41.268 4: TSCUL_Parse: CUL0  127667 A F001 16220912 00 0C 8C A641 278291 1DA462 017300 -57.5
2017.08.16 21:16:41.271 4: TSCUL_send:  CUL0                         As 11 8C A002 1DA462 278291 045B50ADEB948002
2017.08.16 21:16:41.272 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.16 21:16:41.596 4: TSCUL_Parse: CUL0  127996 A F103 16221032 01 11 8C A002 1DA462 278291 04 _CCAdly:4 _dhmSt:120 -138
2017.08.16 21:16:41.597 4: TSCUL_Parse: CUL0  127997 A F101 16221192 00 19 8C A203 278291 1DA462 6A94406FB64C7532E748C975D83C1E42 -58
2017.08.16 21:16:41.879 4: TSCUL_send:  CUL0                         As 11 8C 8002 1DA462 278291 0101C8005134a60a
2017.08.16 21:16:41.879 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102
2017.08.16 21:16:41.881 4: TSCUL_Parse: CUL0  128281 A F101 16221436 00 0C 8C A241 278291 1DA462 017300 -58.5
2017.08.16 21:16:42.153 4: TSCUL_send:  CUL0                         As 11 8C A002 1DA462 278291 04FA1DF3C4EAE402
2017.08.16 21:16:42.153 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.16 21:16:42.158 4: TSCUL_Parse: CUL0  128557 A F103 16221556 01 11 8C 8002 1DA462 278291 01 _CCAdly:4 _dhmSt:120 -138
2017.08.16 21:16:42.415 4: TSCUL_Parse: CUL0  128815 A F103 16221808 02 11 8C A002 1DA462 278291 04 _CCAdly:8 _dhmSt:372 -138
2017.08.16 21:16:42.670 4: TSCUL_Parse: CUL0  129069 A F103 16222080 01 11 8C A002 1DA462 278291 04 _CCAdly:4 _dhmSt:644 -138
2017.08.16 21:16:42.963 4: TSCUL_Parse: CUL0  129362 A F103 16222352 01 11 8C A002 1DA462 278291 04 _CCAdly:4 _dhmSt:916 -138
2017.08.16 21:16:43.220 1: TSCUL_ParseTsHM: CUL0 HM repeat failed to 278291/EG_FensterBuero:  129619 A F109 16222620 00 11 8C A002 1DA462 278291 04 _sfail
2017.08.16 21:16:44.153 4: TSCUL_XmitAwaitTo CUL0: timeout - 278291


Beim nächsten Versuch ergaben Öffnen und Schließen einen Fehler (rotes Licht).
Hört sich für mich an, dass es vermutlich das von Dir benannte Timing Problem ist?!


Greets

Byte
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 16 August 2017, 22:01:53
Hallo Byte,

Zitatbin nicht sicher, ob ich es richtig verstanden habe.
HMLAN sollte das IODev sein und CUL nur zuhören. Ich wollte es mal "richtig" sehen.

Aber mir ist noch was anderes aufgefallen.
Dein System hat eine sehr lange Durchlaufzeit für Messages Wenn an CUL was zum Senden raus geht, dann dauert es bis zum Eintreffen der TSCUL Sendequittung bei FHEM 250ms und mehr.
Damit kann ein ~120ms Antworttiming nicht wirklich realisiert werden.

Was hast Du für ein System?

Hast Du mit den Attributen "event-on-change-reading" und "event-on-update-reading" bei allen Geräten die Notify Flut in Deinem System auf das notwendigste zu begrenzen versucht? (Bei dem Fensterkontakt jedenfalls nicht).
Im Normalfall interessieren bei einem HM Device beispielsweise nur ein oder vielleicht zwei Readings. Es werden aber mehr aktualisiert und erzeugen unkontrolliert eben auch entsprechend viele Notifies, die vom System abgearbeitet werden müssen.

Es macht keinen Sinn hier weiter zu suchen, wenn Du das nicht optimiert hast.Deutlich unter 100ms sollte das Ziel sein.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 16 August 2017, 22:25:11
Hallo Byte,

ZitatHMLAN von FHEM getrennt (disconnected) ABER noch mit Strom (ich vermute es Antwortet trotzdem)

Sieht so aus und ist natürlich zusätzlich kontraproduktiv!

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bytechanger am 16 August 2017, 22:31:02
Hallo,

das war zu Testzwecken der einzige Fensterkontakt, der das "event-on-change-reading" nicht hatte.
Sonst habe ich es großzügig verteilt. Habe ich nachgebessert.
Der EventMonitor ist aber sehr ruhig, so dass es nicht zu vielen Events kommt!

Woran erkenne ich diese Durchlaufzeit ?
Ist es dieser Zeitlauf?

2017.08.16 21:09:15.117 4: TSCUL_Parse: CUL0  205804 A F103 15774496 04 11 7E A002 1DA462 278291 04 _CCAdly:16 _dhmSt:132 -138
2017.08.16 21:09:15.374 4: TSCUL_Parse: CUL0  206062 A F103 15774768 01 11 7E A002 1DA462 278291 04 _CCAdly:4 _dhmSt:404 -138
2017.08.16 21:09:15.658 4: TSCUL_Parse: CUL0  206345 A F103 15775040 01 11 7E A002 1DA462 278291 04 _CCAdly:4 _dhmSt:676 -138
2017.08.16 21:09:15.920 1: TSCUL_ParseTsHM: CUL0 HM repeat failed to 278291/EG_FensterBuero:  206607 A F109 15775308 00 11 7E A002 1DA462 278291 04 _sfail
2017.08.16 21:09:16.786 4: TSCUL_XmitAwaitTo CUL0: timeout - 278291
2017.08.16 21:09:17.243 4: TSCUL_send:  CUL0                         As 0D 7E 8002 1DA462 278291 0101C800
Also in dem Fall 2 Sekunden und 126 Millisekunden??
Wie gesagt, der Eventmonitor langweilt sich.

Woran kann die Verzögerung noch liegen? FHEM läuft auf einem Raspi3, die Prozessorauslastung sieht auch nicht hoch aus.

Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 16 August 2017, 23:03:20
Hallo Byte,

ZitatWoran erkenne ich diese Durchlaufzeit ?

Hier ein Beispiel von Dir:
2017.08.16 21:16:41.268 4: TSCUL_Parse: CUL0  127667 A F001 16220912 00 0C 8C A641 278291 1DA462 017300 -57.5
2017.08.16 21:16:41.271 4: TSCUL_send:  CUL0                         As 11 8C A002 1DA462 278291 045B50ADEB948002
2017.08.16 21:16:41.272 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.16 21:16:41.596 4: TSCUL_Parse: CUL0  127996 A F103 16221032 01 11 8C A002 1DA462 278291 04 _CCAdly:4 _dhmSt:120 -138


CUL empfängt Nachricht (1 am Ende von F001):
2017.08.16 21:16:41.268 4: TSCUL_Parse: CUL0  127667 A F001 16220912 00 0C 8C A641 278291 1DA462 017300 -57.5

3ms später sendet CUL_HM die Antwort:
2017.08.16 21:16:41.271 4: TSCUL_send:  CUL0                         As 11 8C A002 1DA462 278291 045B50ADEB948002

1ms später nach dem Senden an CUL Hat TSCUL Timeout zum nächsten Senden berechnet und einen Antworttimeout bestimmt:
Zitat2017.08.16 21:16:41.272 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746

Und hier die Sendequittung (3 am Ende von F103) von CUL 596-271=325ms:
2017.08.16 21:16:41.596 4: TSCUL_Parse: CUL0  127996 A F103 16221032 01 11 8C A002 1DA462 278291 04 _CCAdly:4 _dhmSt:120 -138
Aber die Sendenachricht kam noch früh genug bei CUL an um nach 120ms auf die Empfangsnachricht zu Antworten 16221032-16220912=120ms.

Also ist entweder Dein USB so lahm oder wird ausgebremst oder FHEM läßt eine Kaskade von Notifies los.
Oder etwas anderes passiert zwischnzeitlich um beschäftigt FHEM oder Deinen Pi.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 17 August 2017, 18:57:00
Hallo Byte,

kannst Du bitte mal in 00_TSCUL.pm Zeile 1034 (fast am Ende von TSCUL_ParseTsHM($$$$$$) ):
        InternalTimer(${$ptn}, "TSCUL_XmitDlyHMTo", $mh{sid}.':'.${$pname}, 1); # send next message, use timer to allow CUL_HM to create it from received!


gegen:
        TSCUL_XmitDlyHMTo($mh{sid}.':'.${$pname}); # send next message in queue for this device, if one is waiting


austauschen und damit testen, ob es hilft (ich hab's mal angehangen). Das reduziert um die Durchlaufzeit durch HM bis eine anhängige Nachricht in der Warteschlange gesendet wird.

Gruß, Ansgar.

PS: Und ich bin immer noch an der Logging Variante mit HMLAN als IODev und CUL_0 auf verbose 4 lauschend interessiert.  :)
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bytechanger am 19 August 2017, 07:50:50
HAllo noansi,

danke für Deine Hilfe.
Also jetzt registriert FHEM den Zusandswechsel, aber aesCommToDev bleibt auf "pending" und der Sensor schaltet von lange orange auf rot.
Log öffnen:
2017.08.19 07:47:10.050 4: TSCUL_Parse: CUL0  516962 A F202 01747360 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2017.08.19 07:47:15.495 4: TSCUL_Parse: CUL0  522406 A F201 01752748 00 0C 9F A641 278291 1DA462 0184C8 -52.5
2017.08.19 07:47:15.500 4: TSCUL_send:  CUL0                         As 11 9F A002 1DA462 278291 0449BE7DC68BBC02
2017.08.19 07:47:15.501 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.19 07:47:15.789 4: TSCUL_Parse: CUL0  522700 A F203 01752868 01 11 9F A002 1DA462 278291 04 _CCAdly:4 _dhmSt:120 -138
2017.08.19 07:47:15.791 4: TSCUL_Parse: CUL0  522701 A F201 01753028 00 19 9F A203 278291 1DA462 ECBA3F547A42C5F86A5C4D01F310D387 -52.5
2017.08.19 07:47:15.797 4: TSCUL_send:  CUL0                         As 11 9F 8002 1DA462 278291 0101C800da03ab9f
2017.08.19 07:47:15.798 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102
2017.08.19 07:47:16.099 4: TSCUL_Parse: CUL0  523010 A F203 01753148 01 11 9F 8002 1DA462 278291 01 _CCAdly:4 _dhmSt:120 -138
2017.08.19 07:47:16.100 4: TSCUL_Parse: CUL0  523012 A F201 01753272 00 0C 9F A241 278291 1DA462 0184C8 -52.5
2017.08.19 07:47:16.103 4: TSCUL_send:  CUL0                         As 11 9F A002 1DA462 278291 046CC844151B3D02
2017.08.19 07:47:16.103 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.19 07:47:16.393 4: TSCUL_Parse: CUL0  523304 A F203 01753420 01 11 9F A002 1DA462 278291 04 _CCAdly:4 _dhmSt:148 -138
2017.08.19 07:47:16.396 4: TSCUL_Parse: CUL0  523306 A F201 01753584 00 19 9F A203 278291 1DA462 4C7C0EEAEB88E7996075CDC6A1B2BCA7 -52.5
2017.08.19 07:47:16.401 4: TSCUL_send:  CUL0                         As 11 9F 8002 1DA462 278291 0101C800353f9cb7
2017.08.19 07:47:16.401 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102
2017.08.19 07:47:16.690 4: TSCUL_Parse: CUL0  523602 A F203 01753720 02 11 9F 8002 1DA462 278291 01 _CCAdly:8 _dhmSt:136 -138
2017.08.19 07:47:16.946 4: TSCUL_Parse: CUL0  523858 A F201 01754080 00 0C 9F A241 278291 1DA462 0184C8 -52.5
2017.08.19 07:47:16.948 4: TSCUL_send:  CUL0                         As 11 9F A002 1DA462 278291 04102C236AA81402
2017.08.19 07:47:16.948 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.19 07:47:17.221 4: TSCUL_Parse: CUL0  524133 A F203 01754264 01 11 9F A002 1DA462 278291 04 _CCAdly:4 _dhmSt:184 -138
2017.08.19 07:47:20.480 1: Perfmon: possible freeze starting at 07:47:18, delay is 2.48
2017.08.19 07:47:20.483 4: TSCUL_XmitAwaitTo CUL0: timeout - 278291
2017.08.19 07:47:20.487 4: TSCUL_Parse: CUL0  003110 A F203 01754536 01 11 9F A002 1DA462 278291 04 _CCAdly:4 _dhmSt:456 -138
2017.08.19 07:47:20.488 4: TSCUL_Parse: CUL0  003112 A F203 01754808 01 11 9F A002 1DA462 278291 04 _CCAdly:4 _dhmSt:728 -138
2017.08.19 07:47:20.489 1: TSCUL_ParseTsHM: CUL0 HM repeat failed to 278291/EG_FensterBuero:  003113 A F209 01755076 00 11 9F A002 1DA462 278291 04 _sfail
2017.08.19 07:47:20.491 4: TSCUL_Parse: CUL0  003114 A F201 01755092 00 0C 9F A241 278291 1DA462 0184C8 -53
2017.08.19 07:47:20.495 4: TSCUL_Parse: CUL0  003118 A F201 01757120 00 0C 9F A241 278291 1DA462 0184C8 -52.5
2017.08.19 07:47:24.093 4: TSCUL_Parse: CUL0  006716 A F201 01761176 00 0C 9F A241 278291 1DA462 0184C8 -52.5
2017.08.19 07:47:24.096 4: TSCUL_send:  CUL0                         As 11 9F A002 1DA462 278291 04102C236AA81402
2017.08.19 07:47:24.096 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.19 07:47:24.353 4: TSCUL_Parse: CUL0  006976 A F203 01761412 01 11 9F A002 1DA462 278291 04 _CCAdly:4 -138
2017.08.19 07:47:24.610 4: TSCUL_Parse: CUL0  007233 A F203 01761684 01 11 9F A002 1DA462 278291 04 _CCAdly:4 -138
2017.08.19 07:47:24.869 4: TSCUL_Parse: CUL0  007492 A F203 01761956 01 11 9F A002 1DA462 278291 04 _CCAdly:4 -138
2017.08.19 07:47:25.130 1: TSCUL_ParseTsHM: CUL0 HM repeat failed to 278291/EG_FensterBuero:  007753 A F209 01762224 00 11 9F A002 1DA462 278291 04 _sfail
2017.08.19 07:47:25.997 4: TSCUL_XmitAwaitTo CUL0: timeout - 278291


Log schließen:
2017.08.19 07:49:09.642 4: TSCUL_Parse: CUL0  112265 A F102 01866956 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2017.08.19 07:49:13.755 4: TSCUL_Parse: CUL0  116378 A F101 01871012 00 0C A0 A641 278291 1DA462 018500 -53.5
2017.08.19 07:49:13.758 4: TSCUL_send:  CUL0                         As 11 A0 A002 1DA462 278291 04102C236AA81402
2017.08.19 07:49:13.759 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.19 07:49:14.016 4: TSCUL_Parse: CUL0  116639 A F103 01871132 01 11 A0 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:120 -138
2017.08.19 07:49:14.017 4: TSCUL_Parse: CUL0  116640 A F101 01871292 00 19 A0 A203 278291 1DA462 8D9F98912080709D722C9BE75F228BE1 -53
2017.08.19 07:49:14.021 4: TSCUL_send:  CUL0                         As 11 A0 8002 1DA462 278291 0101C800c8a1df03
2017.08.19 07:49:14.021 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102
2017.08.19 07:49:14.304 4: TSCUL_Parse: CUL0  116928 A F103 01871412 01 11 A0 8002 1DA462 278291 01 _CCAdly:4 _dhmSt:120 -138
2017.08.19 07:49:14.305 4: TSCUL_Parse: CUL0  116929 A F101 01871536 00 0C A0 A241 278291 1DA462 018500 -53
2017.08.19 07:49:14.306 4: TSCUL_send:  CUL0                         As 11 A0 A002 1DA462 278291 0405CA24DE96AD02
2017.08.19 07:49:14.307 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.19 07:49:14.583 4: TSCUL_Parse: CUL0  117206 A F103 01871656 01 11 A0 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:120 -138
2017.08.19 07:49:14.586 4: TSCUL_Parse: CUL0  117208 A F101 01871816 00 19 A0 A203 278291 1DA462 192D687575331585174B3F42E1641F19 -53
2017.08.19 07:49:14.592 4: TSCUL_send:  CUL0                         As 11 A0 8002 1DA462 278291 0101C800fa0047a6
2017.08.19 07:49:14.592 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102
2017.08.19 07:49:14.885 4: TSCUL_Parse: CUL0  117509 A F103 01871936 01 11 A0 8002 1DA462 278291 01 _CCAdly:4 _dhmSt:120 -138
2017.08.19 07:49:15.139 4: TSCUL_Parse: CUL0  117763 A F101 01872316 00 0C A0 A241 278291 1DA462 018500 -53.5
2017.08.19 07:49:15.140 4: TSCUL_send:  CUL0                         As 11 A0 A002 1DA462 278291 04D7781CD62E2202
2017.08.19 07:49:15.141 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.19 07:49:15.418 4: TSCUL_Parse: CUL0  118041 A F103 01872464 02 11 A0 A002 1DA462 278291 04 _CCAdly:8 _dhmSt:148 -138
2017.08.19 07:49:15.421 4: TSCUL_Parse: CUL0  118043 A F101 01872624 00 19 A0 A203 278291 1DA462 B9600ADDDC1CE9BBF1D5FE660E614DD3 -53
2017.08.19 07:49:15.427 4: TSCUL_send:  CUL0                         As 11 A0 8002 1DA462 278291 0101C800010fd9e1
2017.08.19 07:49:15.427 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102
2017.08.19 07:49:15.720 4: TSCUL_Parse: CUL0  118344 A F103 01872748 01 11 A0 8002 1DA462 278291 01 _CCAdly:4 _dhmSt:124 -138
2017.08.19 07:49:16.316 4: TSCUL_Parse: CUL0  118939 A F101 01873628 00 0C A0 A241 278291 1DA462 018500 -53.5
2017.08.19 07:49:16.319 4: TSCUL_send:  CUL0                         As 11 A0 A002 1DA462 278291 048B66F5B532C102
2017.08.19 07:49:16.320 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.19 07:49:16.612 4: TSCUL_Parse: CUL0  119235 A F103 01873748 01 11 A0 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:120 -138
2017.08.19 07:49:16.615 4: TSCUL_Parse: CUL0  119237 A F101 01873908 00 19 A0 A203 278291 1DA462 BEA6EFE92B8534FABCA314DFE6DC5AA5 -52.5
2017.08.19 07:49:16.620 4: TSCUL_send:  CUL0                         As 11 A0 8002 1DA462 278291 0101C80009a9127b
2017.08.19 07:49:16.621 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102
2017.08.19 07:49:16.912 4: TSCUL_Parse: CUL0  119536 A F103 01874028 01 11 A0 8002 1DA462 278291 01 _CCAdly:4 _dhmSt:120 -138
2017.08.19 07:49:18.849 4: TSCUL_Parse: CUL0  121472 A F101 01875928 00 0C A0 A241 278291 1DA462 018500 -52.5
2017.08.19 07:49:18.852 4: TSCUL_send:  CUL0                         As 11 A0 A002 1DA462 278291 045DFAC99859CE02
2017.08.19 07:49:18.853 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.19 07:49:19.149 4: TSCUL_Parse: CUL0  121773 A F103 01876176 02 11 A0 A002 1DA462 278291 04 _CCAdly:8 _dhmSt:248 -138
2017.08.19 07:49:19.406 4: TSCUL_Parse: CUL0  122029 A F103 01876444 01 11 A0 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:516 -138
2017.08.19 07:49:19.660 4: TSCUL_Parse: CUL0  122283 A F103 01876716 01 11 A0 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:788 -138
2017.08.19 07:49:19.915 1: TSCUL_ParseTsHM: CUL0 HM repeat failed to 278291/EG_FensterBuero:  122538 A F109 01876984 00 11 A0 A002 1DA462 278291 04 _sfail
2017.08.19 07:49:20.853 4: TSCUL_XmitAwaitTo CUL0: timeout - 278291
2017.08.19 07:49:22.673 4: TSCUL_Parse: CUL0  125296 A F101 01879984 00 0C A0 A241 278291 1DA462 018500 -52.5
2017.08.19 07:49:22.676 4: TSCUL_send:  CUL0                         As 11 A0 A002 1DA462 278291 045DFAC99859CE02
2017.08.19 07:49:22.677 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.19 07:49:22.935 4: TSCUL_Parse: CUL0  125558 A F103 01880104 01 11 A0 A002 1DA462 278291 04 _CCAdly:4 -138
2017.08.19 07:49:23.194 4: TSCUL_Parse: CUL0  125816 A F101 01880264 00 19 A0 A203 278291 1DA462 684DBA950B9895AAC4FF08B68BCF6E08 -52.5
2017.08.19 07:49:23.200 4: TSCUL_send:  CUL0                         As 11 A0 8002 1DA462 278291 0101C80069fa7bec
2017.08.19 07:49:23.201 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102
2017.08.19 07:49:26.498 4: TSCUL_SendPingHM CUL0 ApC0 send
2017.08.19 07:49:26.499 1: Perfmon: possible freeze starting at 07:49:24, delay is 2.499
2017.08.19 07:49:26.520 4: TSCUL_Parse: CUL0  129143 A F103 01880524 02 11 A0 8002 1DA462 278291 01 _CCAdly:8 _dhmSt:260 -138
2017.08.19 07:49:26.522 4: TSCUL_ParseTsHM: CUL0 Xmit release ping received, XmitOpen 2->1 :  129145 A F102 01883816 00 01 C0 _ping


Ich weiß wirklich nicht, warum das Antwortverhalten so langsam sein soll.
Ich habe nun den CUL0 direkt an den Raspi angeschlossen (keine USB Verlängerung zur Empfangsverbesserung).
EventMonitor weiterhin ruhig, CPU nicht ausgelaustet....

Die Aktoren funktionieren übrigens einwandfrei. Auch sie fordern eine Signierung von FHEM an (sign on).

Greets

Byte
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 19 August 2017, 08:58:08
Hallo Byte,

das Zeitverhalten ist besser geworden.
Aber Dein Kontakt ist nicht zufrieden mit der ACK-Antwort und wiederholt.

Jetzt brauche ich das lange gewünschte Log mit HMLAN als IODev und CUL_0 mit verbose 4.
Da muss was anders sein, denke ich.

Danke!

ZitatDie Aktoren funktionieren übrigens einwandfrei. Auch sie fordern eine Signierung von FHEM an (sign on).
Das ist auch die andere Richtung und die macht die tsculfw.

Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bytechanger am 19 August 2017, 09:51:37
Hallo,

also nun mit Kommunikation über HMLAN und CUL0 hört mit verbose 4 zu.
HMLAN habe ich auch mal auf sys,all gestellt.

Öffnen:
2017.08.19 09:46:56.492 4: TSCUL_Parse: CUL0  363371 A F001 08934044 00 0C A8 A641 278291 1DA462 018CC8 -60
2017.08.19 09:46:56.747 0: HMLAN_Parse: HMLAN1 R:E278291   stat:0000 t:000BAD8F d:FF r:FFC6     m:A8 A641 278291 1DA462 018CC8
2017.08.19 09:46:56.752 0: HMLAN_Send:  HMLAN1 I:+278291,00,00,
2017.08.19 09:46:56.753 0: HMLAN_Send:  HMLAN1 S:+278291,01,01,02
2017.08.19 09:46:56.754 0: HMLAN_Send:  HMLAN1 S:SF9758DCE stat:  00 t:00000000 d:01 r:F9758DCE m:A8 8002 1DA462 278291 0101C800
2017.08.19 09:46:56.826 4: TSCUL_Parse: CUL0  363706 A F001 08934296 00 0C A8 A241 278291 1DA462 018CC8 -59.5
2017.08.19 09:46:57.081 0: HMLAN_Parse: HMLAN1 R:E278291   stat:0000 t:000BAE8B d:FF r:FFC7     m:A8 A241 278291 1DA462 018CC8
2017.08.19 09:46:57.083 0: HMLAN_Send:  HMLAN1 S:SF9758F17 stat:  00 t:00000000 d:01 r:F9758F17 m:A8 8002 1DA462 278291 0101C800
2017.08.19 09:46:57.085 0: HMLAN_Parse: HMLAN1 R:RF9758DCE stat:0002 t:00000000 d:FF r:7FFF     m:A8 8002 1DA462 278291 0101C800
2017.08.19 09:46:57.086 4: TSCUL_Parse: CUL0  363965 A F001 08934552 00 0D A8 8002 1DA462 278291 0101C800 -50
2017.08.19 09:46:57.340 0: HMLAN_Parse: HMLAN1 R:RF9758F17 stat:0002 t:00000000 d:FF r:7FFF     m:A8 8002 1DA462 278291 0101C800
2017.08.19 09:46:57.342 4: TSCUL_Parse: CUL0  364221 A F001 08934800 00 0C A8 A241 278291 1DA462 018CC8 -59.5
2017.08.19 09:46:57.343 4: TSCUL_Parse: CUL0  364223 A F001 08934824 00 0D A8 8002 1DA462 278291 0101C800 -49.5


Schließen:
2017.08.19 09:48:01.289 0: HMLAN_Parse: HMLAN1 R:E278291   stat:0100 t:000CAA8B d:FF r:FFC9     m:A9 A641 278291 1DA462 018D00
2017.08.19 09:48:01.300 4: TSCUL_Parse: CUL0  428179 A F001 08998800 00 0C A9 A641 278291 1DA462 018D00 -58.5
2017.08.19 09:48:01.562 4: TSCUL_Parse: CUL0  428441 A F001 08998928 00 11 A9 A002 1DA462 278291 0441D7713F5E6302 -51
2017.08.19 09:48:01.569 4: TSCUL_Parse: CUL0  428448 A F001 08999060 00 19 A9 A203 278291 1DA462 EA814974FA242E097340AE2D770F3987 -57.5
2017.08.19 09:48:01.824 0: HMLAN_Parse: HMLAN1 R:E278291   stat:0040 t:000CAA8B d:01 r:FFC9     m:A9 A641 278291 1DA462 018D00
2017.08.19 09:48:01.830 0: HMLAN_Send:  HMLAN1 S:SF9768C02 stat:  00 t:00000000 d:01 r:F9768C02 m:A9 8002 1DA462 278291 0101C800
2017.08.19 09:48:01.871 4: TSCUL_Parse: CUL0  428750 A F001 08999180 00 0E A9 8002 1DA462 278291 009652D2DA -51
2017.08.19 09:48:02.130 0: HMLAN_Parse: HMLAN1 R:RF9768C02 stat:0002 t:00000000 d:FF r:7FFF     m:A9 8002 1DA462 278291 0101C800
2017.08.19 09:48:02.131 4: TSCUL_Parse: CUL0  429011 A F001 08999452 00 0D A9 8002 1DA462 278291 0101C800 -51.5


Ich programmiere zwar auch in verschiedenen Sprachen, aber dass hier zu lesen ist schon schwierig. Gibt es da eigentlich eine Doko zu
(z.B. dass F001 das Empfangen einer Nachricht ist, F103 ist eine Sendequittung.... usw.)



Greets

Byte
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 19 August 2017, 10:09:13
Hallo Byte,

das ist definitv anders.

Beim Öffnen kommt nur ein ACK ohne Signierungsanforderung.

HMLAN macht AES-Signierungsanforderung nur beim Schliessen.
Und die Signierung enthält nicht die Kontaktquittierung, sondern wohl nur ein signiertes ACK.

Das muss Martin korrigieren (ggf. mit Michael), denke ich, da das in CUL_HM abläuft.

Gruß, Ansgar.

PS:
ZitatIch programmiere zwar auch in verschiedenen Sprachen, aber dass hier zu lesen ist schon schwierig. Gibt es da eigentlich eine Doko zu
(z.B. dass F001 das Empfangen einer Nachricht ist, F103 ist eine Sendequittung.... usw.)
Den Quellcode zur Firmware und diverse Erklärungen hier im Thread.

Das letzte Nibble bedeutet z.B.:
#define TS_ID_RECTIME           0x01  // Receive TimeStamp
#define TS_ID_PING              0x02  // Ping Receive TimeStamp
#define TS_ID_SENDSUCC          0x03  // Send Success TimeStamp
#define TS_ID_SENDFAIL_CCA      0x04  // Send Fail TimeStamp, failed due to switch to TX, channel not free
#define TS_ID_SENDFAIL_CREDIT   0x05  // Send Fail TimeStamp, failed due to not enough credits
#define TS_ID_SENDFAIL_BUF      0x06  // Send Fail TimeStamp, failed due to no buf free
#define TS_ID_SENDFAIL_FIFO     0x07  // Send Fail TimeStamp, failed due to TX-FIFO underflow error
#define TS_ID_SENDFAIL_LEN      0x08  // Send Fail TimeStamp, failed due to send message length error
#define TS_ID_SENDFAIL_REP      0x09  // Send Fail TimeStamp, failed due to repeat failed
#define TS_ID_SENDFAIL_AUTH     0x0a  // Send Fail TimeStamp, failed due to AES authentication error
#define TS_ID_SENDFAIL_AUTH_BUF 0x0b  // Send Fail TimeStamp, failed due to no buf free for AES authentication
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 19 August 2017, 10:24:53
Hallo Byte,

hier https://forum.fhem.de/index.php/topic,75579.0.html (https://forum.fhem.de/index.php/topic,75579.0.html) habe ich mal einen Thread zum Fensterkontaktproblem geöffnet.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bytechanger am 19 August 2017, 10:35:18
Super,

um einen Fehler meinerseits auszuschließen hier nochmal das Protokoll eines anderen Fenstersensors:

öffnen:
2017.08.19 10:32:06.531 0: HMLAN_Send:  HMLAN1 I:K
2017.08.19 10:32:06.805 0: HMLAN_Parse: HMLAN1 V:03C5 sNo:LEQ0640815 d:2CD8CE O:1DA462 t:00350955 IDcnt:001B L:2 %
2017.08.19 10:32:16.389 0: HMLAN_Parse: HMLAN1 R:E278205   stat:0100 t:00352F70 d:FF r:FFC7     m:CF A641 278205 1DA462 0167C8
2017.08.19 10:32:16.395 4: TSCUL_Parse: CUL0  461834 A F001 11653936 00 0C CF A641 278205 1DA462 0167C8 -64.5
2017.08.19 10:32:16.650 4: TSCUL_Parse: CUL0  462089 A F001 11654064 00 11 CF A002 1DA462 278205 04D94FE9A7C6FB02 -49.5
2017.08.19 10:32:16.653 4: TSCUL_Parse: CUL0  462093 A F001 11654192 00 19 CF A203 278205 1DA462 83E33ADB29E7F81F0338F7801A98CE72 -66.5
2017.08.19 10:32:16.909 0: HMLAN_Parse: HMLAN1 R:E278205   stat:0040 t:00352F70 d:01 r:FFC7     m:CF A641 278205 1DA462 0167C8
2017.08.19 10:32:16.915 0: HMLAN_Send:  HMLAN1 S:SF99F0F70 stat:  00 t:00000000 d:01 r:F99F0F70 m:CF 8002 1DA462 278205 0101C800
2017.08.19 10:32:16.940 4: TSCUL_Parse: CUL0  462380 A F001 11654316 00 0E CF 8002 1DA462 278205 00A7921E49 -48.5
2017.08.19 10:32:17.197 0: HMLAN_Parse: HMLAN1 R:RF99F0F70 stat:0002 t:00000000 d:FF r:7FFF     m:CF 8002 1DA462 278205 0101C800
2017.08.19 10:32:17.198 4: TSCUL_Parse: CUL0  462638 A F001 11654588 00 0D CF 8002 1DA462 278205 0101C800 -48.5


schließen:

2017.08.19 10:33:10.293 4: TSCUL_Parse: CUL0  515732 A F001 11707940 00 0C D0 A641 278205 1DA462 016800 -66
2017.08.19 10:33:10.548 0: HMLAN_Parse: HMLAN1 R:E278205   stat:0100 t:0036026B d:FF r:FFC8     m:D0 A641 278205 1DA462 016800
2017.08.19 10:33:10.588 4: TSCUL_Parse: CUL0  516027 A F001 11708068 00 11 D0 A002 1DA462 278205 040D9B3D73122F02 -47
2017.08.19 10:33:10.595 4: TSCUL_Parse: CUL0  516034 A F001 11708200 00 19 D0 A203 278205 1DA462 99A5C9EACAB63F8AEE70C8562BD4C58A -65
2017.08.19 10:33:10.887 0: HMLAN_Parse: HMLAN1 R:E278205   stat:0040 t:0036026B d:01 r:FFC8     m:D0 A641 278205 1DA462 016800
2017.08.19 10:33:10.890 0: HMLAN_Send:  HMLAN1 S:SF99FE247 stat:  00 t:00000000 d:01 r:F99FE247 m:D0 8002 1DA462 278205 0101C800
2017.08.19 10:33:10.914 4: TSCUL_Parse: CUL0  516354 A F001 11708320 00 0E D0 8002 1DA462 278205 00250CC7B1 -47
2017.08.19 10:33:11.170 0: HMLAN_Parse: HMLAN1 R:RF99FE247 stat:0002 t:00000000 d:FF r:7FFF     m:D0 8002 1DA462 278205 0101C800
2017.08.19 10:33:11.172 4: TSCUL_Parse: CUL0  516611 A F001 11708588 00 0D D0 8002 1DA462 278205 0101C800 -47.5
2017.08.19 10:33:22.255 0: HMLAN_Send:  HMLAN1 I:K
2017.08.19 10:33:22.259 0: HMLAN_Parse: HMLAN1 V:03C5 sNo:LEQ0640815 d:2CD8CE O:1DA462 t:0036312D IDcnt:001B L:3 %


Also ist es derzeit so, dass ein Öffnen keine Signierung anfordert (Fehler von FHEM) ?
Das fände ich schlecht, da ich eine Alarmanlage realisiert habe und ein Fehlalarm durch manipulation möglich wäre...

Bin gespannt, ob das Problem gelöst wird...

Greets

Byte
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 19 August 2017, 10:55:13
Hallo Byte,

diesmal AES für beide Vorgänge?!?!
List vom Device? Andere Firmwareversion?

Und bitte poste das mal in dem neuen Thread.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 19 August 2017, 11:48:38
Hallo Byte,

versuch mal die CUL_HM im Anhang.
Ich habe mal ein ACK ergänzt.

Es muss mit beiden Sendern, also CUL_0 und HMLAN erfolgreich getestet werden!

ZitatAlso ist es derzeit so, dass ein Öffnen keine Signierung anfordert (Fehler von FHEM) ?
Da der Kontakt beim Öffnen wiederholt hat, denke ich, er war noch nicht glücklich in dem Auszug vom Log.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bytechanger am 19 August 2017, 17:23:25
Hi,
sorry, musste am Haus etwas vorbereiten, morgen kommt der Maler....

Also habe wieder die original TSCUL genommen und deine 10_CUL_HM eingespielt.
Zuerst dachte ich, er frisst es, leider zu früh gefreut. Einige Öffnungen und Schließungen gingen, danach nur noch rot:

Öffnen nur mit CUL (HMLAN ausgesteckt) mit Grün als Antwort:
2017.08.19 17:15:36.441 4: TSCUL_Parse: CUL0  020343 A F002 02300200 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2017.08.19 17:15:43.300 4: TSCUL_Parse: CUL0  027204 A F001 02307336 00 0C AC A641 278291 1DA462 0190C8 -54
2017.08.19 17:15:43.301 0: HMLAN_Send:  HMLAN1 I:-278291
2017.08.19 17:15:43.555 4: TSCUL_Parse: CUL0  027458 A F001 02307592 00 0C AC A241 278291 1DA462 0190C8 -55.5
2017.08.19 17:15:43.557 4: TSCUL_send:  CUL0                         As 11 AC A002 1DA462 278291 04DA7050C9E09002
2017.08.19 17:15:43.557 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.19 17:15:43.851 4: TSCUL_Parse: CUL0  027754 A F103 02307712 01 11 AC A002 1DA462 278291 04 _CCAdly:4 _dhmSt:376 -138
2017.08.19 17:15:43.854 4: TSCUL_Parse: CUL0  027755 A F101 02307872 00 19 AC A203 278291 1DA462 130564D792E0BA970A97A8C98B3FC078 -54
2017.08.19 17:15:44.166 4: TSCUL_send:  CUL0                         As 0E AC 8002 1DA462 278291 00eb37769d
2017.08.19 17:15:44.166 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:99
2017.08.19 17:15:44.421 4: TSCUL_send:  CUL0                         As 11 AC 8002 1DA462 278291 0101C800eb37769d
2017.08.19 17:15:44.421 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102
2017.08.19 17:15:44.423 4: TSCUL_Parse: CUL0  028327 A F103 02308212 01 0E AC 8002 1DA462 278291 00 _CCAdly:4 _dhmSt:340 -138
2017.08.19 17:15:44.424 4: TSCUL_Parse: CUL0  028328 A F101 02308368 00 0C AC A241 278291 1DA462 0190C8 -54.5
2017.08.19 17:15:47.703 4: TSCUL_send:  CUL0                         As 11 AC A002 1DA462 278291 040CC47EA17C2402
2017.08.19 17:15:47.704 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.19 17:15:47.704 4: TSCUL_SendPingHM CUL0 ApC0 send
2017.08.19 17:15:47.705 1: Perfmon: possible freeze starting at 17:15:45, delay is 2.705


schließen (ACHTUNG HIER WOLLTE ER NICHT!):
2017.08.19 17:19:15.986 4: TSCUL_Parse: CUL0  239889 A F001 02519860 00 0C AD A641 278291 1DA462 019100 -54
2017.08.19 17:19:15.989 4: TSCUL_send:  CUL0                         As 11 AD A002 1DA462 278291 040CC47EA17C2402
2017.08.19 17:19:15.989 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.19 17:19:16.249 4: TSCUL_Parse: CUL0  240152 A F103 02520044 02 11 AD A002 1DA462 278291 04 _CCAdly:8 _dhmSt:184 -138
2017.08.19 17:19:16.252 4: TSCUL_Parse: CUL0  240154 A F101 02520116 00 0C AD A241 278291 1DA462 019100 -54
2017.08.19 17:19:16.578 4: TSCUL_Parse: CUL0  240481 A F101 02520620 00 0C AD A241 278291 1DA462 019100 -54
2017.08.19 17:19:16.580 4: TSCUL_send:  CUL0                         As 11 AD A002 1DA462 278291 040CC47EA17C2402
2017.08.19 17:19:16.581 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.19 17:19:16.837 4: TSCUL_Parse: CUL0  240741 A F103 02520740 01 11 AD A002 1DA462 278291 04 _CCAdly:4 _dhmSt:880 -138
2017.08.19 17:19:17.096 4: TSCUL_Parse: CUL0  240998 A F101 02520900 00 19 AD A203 278291 1DA462 03B4E3B98A1169C94FED5E310D9EE113 -54
2017.08.19 17:19:17.399 4: TSCUL_send:  CUL0                         As 0E AD 8002 1DA462 278291 005787fe72
2017.08.19 17:19:17.399 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:99
2017.08.19 17:19:17.660 4: TSCUL_send:  CUL0                         As 11 AD 8002 1DA462 278291 0101C8005787fe72
2017.08.19 17:19:17.660 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102
2017.08.19 17:19:17.664 4: TSCUL_Parse: CUL0  241567 A F103 02521452 01 0E AD 8002 1DA462 278291 00 _CCAdly:4 _dhmSt:552 -138
2017.08.19 17:19:17.922 4: TSCUL_Parse: CUL0  241825 A F103 02521712 01 11 AD 8002 1DA462 278291 01 _CCAdly:4 _dhmSt:812 -138
2017.08.19 17:19:17.924 4: TSCUL_Parse: CUL0  241827 A F101 02521904 00 0C AD A241 278291 1DA462 019100 -54
2017.08.19 17:19:17.926 4: TSCUL_send:  CUL0                         As 11 AD A002 1DA462 278291 040573DCB711A002
2017.08.19 17:19:17.927 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.19 17:19:18.218 4: TSCUL_Parse: CUL0  242121 A F103 02522024 01 11 AD A002 1DA462 278291 04 _CCAdly:4 _dhmSt:120 -138
2017.08.19 17:19:18.221 4: TSCUL_Parse: CUL0  242123 A F101 02522184 00 19 AD A203 278291 1DA462 AFED30521148AAD97A93D96D2C116D67 -54
2017.08.19 17:19:18.515 4: TSCUL_send:  CUL0                         As 0E AD 8002 1DA462 278291 008ac425d0
2017.08.19 17:19:18.515 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:99
2017.08.19 17:19:18.773 4: TSCUL_send:  CUL0                         As 11 AD 8002 1DA462 278291 0101C8008ac425d0
2017.08.19 17:19:18.773 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102
2017.08.19 17:19:18.777 4: TSCUL_Parse: CUL0  242680 A F103 02522568 01 0E AD 8002 1DA462 278291 00 _CCAdly:4 _dhmSt:384 -138
2017.08.19 17:19:19.035 4: TSCUL_Parse: CUL0  242938 A F103 02522828 02 11 AD 8002 1DA462 278291 01 _CCAdly:8 _dhmSt:644 -138
2017.08.19 17:19:20.258 4: TSCUL_Parse: CUL0  244161 A F101 02524204 00 0C AD A241 278291 1DA462 019100 -53.5
2017.08.19 17:19:20.265 4: TSCUL_send:  CUL0                         As 11 AD A002 1DA462 278291 04D7897A7EC6B202
2017.08.19 17:19:20.265 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.19 17:19:20.553 4: TSCUL_Parse: CUL0  244456 A F103 02524324 01 11 AD A002 1DA462 278291 04 _CCAdly:4 _dhmSt:120 -138
2017.08.19 17:19:20.556 4: TSCUL_Parse: CUL0  244458 A F101 02524484 00 19 AD A203 278291 1DA462 F690FAD636EFE55098DA1FDD3DBFAEC1 -54
2017.08.19 17:19:20.849 4: TSCUL_send:  CUL0                         As 0E AD 8002 1DA462 278291 0049a0091d
2017.08.19 17:19:20.850 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:99
2017.08.19 17:19:21.107 4: TSCUL_send:  CUL0                         As 11 AD 8002 1DA462 278291 0101C80049a0091d
2017.08.19 17:19:21.108 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102
2017.08.19 17:19:21.111 4: TSCUL_Parse: CUL0  245015 A F103 02524904 02 0E AD 8002 1DA462 278291 00 _CCAdly:8 _dhmSt:420 -138
2017.08.19 17:19:21.370 4: TSCUL_Parse: CUL0  245273 A F103 02525160 01 11 AD 8002 1DA462 278291 01 _CCAdly:4 _dhmSt:676 -138
2017.08.19 17:19:24.524 4: TSCUL_Parse: CUL0  248427 A F101 02528536 00 0C AD A241 278291 1DA462 019100 -54
2017.08.19 17:19:24.527 4: TSCUL_send:  CUL0                         As 11 AD A002 1DA462 278291 04FC1AC02C237D02
2017.08.19 17:19:24.528 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.19 17:19:24.818 4: TSCUL_Parse: CUL0  248721 A F103 02528656 01 11 AD A002 1DA462 278291 04 _CCAdly:4 _dhmSt:120 -138
2017.08.19 17:19:24.821 4: TSCUL_Parse: CUL0  248723 A F101 02528816 00 19 AD A203 278291 1DA462 661C97D53C2288C5D97A3733F133A802 -54
2017.08.19 17:19:25.115 4: TSCUL_send:  CUL0                         As 0E AD 8002 1DA462 278291 0093a8117d
2017.08.19 17:19:25.116 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:99
2017.08.19 17:19:25.374 4: TSCUL_send:  CUL0                         As 11 AD 8002 1DA462 278291 0101C80093a8117d
2017.08.19 17:19:25.374 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102
2017.08.19 17:19:25.380 4: TSCUL_Parse: CUL0  249283 A F103 02529168 01 0E AD 8002 1DA462 278291 00 _CCAdly:4 _dhmSt:352 -138
2017.08.19 17:19:25.638 4: TSCUL_Parse: CUL0  249542 A F103 02529428 01 11 AD 8002 1DA462 278291 01 _CCAdly:4 _dhmSt:612 -138


Weitere Logs mit ROT:
2017.08.19 17:21:03.260 1: Perfmon: possible freeze starting at 17:21:00, delay is 3.26
2017.08.19 17:21:07.256 4: TSCUL_Parse: CUL0  351160 A F101 02631156 00 0C DD A641 278205 1DA462 0175C8 -61.5
2017.08.19 17:21:07.257 0: HMLAN_Send:  HMLAN1 I:-278205
2017.08.19 17:21:07.510 4: TSCUL_Parse: CUL0  351414 A F101 02631404 00 0C DD A241 278205 1DA462 0175C8 -61.5
2017.08.19 17:21:07.512 4: TSCUL_send:  CUL0                         As 11 DD A002 1DA462 278205 04499AD3D383E702
2017.08.19 17:21:07.512 4: TSCUL_XmitDlyHM:  CUL0  id:278205 toms:102 rtoms:1746
2017.08.19 17:21:07.784 4: TSCUL_Parse: CUL0  351688 A F103 02631568 01 11 DD A002 1DA462 278205 04 _CCAdly:4 _dhmSt:412 -138
2017.08.19 17:21:08.042 4: TSCUL_Parse: CUL0  351945 A F103 02631840 01 11 DD A002 1DA462 278205 04 _CCAdly:4 _dhmSt:684 -138
2017.08.19 17:21:08.045 4: TSCUL_Parse: CUL0  351947 A F101 02631896 00 0C DD A241 278205 1DA462 0175C8 -62
2017.08.19 17:21:08.838 4: TSCUL_Parse: CUL0  352741 A F101 02632884 00 0C DD A241 278205 1DA462 0175C8 -62
2017.08.19 17:21:08.841 4: TSCUL_send:  CUL0                         As 11 DD A002 1DA462 278205 04499AD3D383E702
2017.08.19 17:21:08.841 4: TSCUL_XmitDlyHM:  CUL0  id:278205 toms:102 rtoms:1746
2017.08.19 17:21:09.107 4: TSCUL_Parse: CUL0  353010 A F103 02633004 01 11 DD A002 1DA462 278205 04 _CCAdly:4 _dhmSt:1848 -138
2017.08.19 17:21:09.366 4: TSCUL_Parse: CUL0  353268 A F101 02633164 00 19 DD A203 278205 1DA462 197B9296470D09386803C218E5C5D596 -61.5
2017.08.19 17:21:09.666 4: TSCUL_send:  CUL0                         As 0E DD 8002 1DA462 278205 000dc6aaba
2017.08.19 17:21:09.666 4: TSCUL_XmitDlyHM:  CUL0  id:278205 toms:99
2017.08.19 17:21:09.921 4: TSCUL_send:  CUL0                         As 11 DD 8002 1DA462 278205 0101C8000dc6aaba
2017.08.19 17:21:09.921 4: TSCUL_XmitDlyHM:  CUL0  id:278205 toms:102
2017.08.19 17:21:09.923 4: TSCUL_Parse: CUL0  353827 A F103 02633724 02 0E DD 8002 1DA462 278205 00 _CCAdly:8 _dhmSt:560 -138
2017.08.19 17:21:10.182 4: TSCUL_Parse: CUL0  354085 A F103 02633980 02 11 DD 8002 1DA462 278205 01 _CCAdly:8 _dhmSt:816 -138
2017.08.19 17:21:11.231 4: TSCUL_Parse: CUL0  355133 A F101 02635128 00 0C DD A241 278205 1DA462 0175C8 -61.5
2017.08.19 17:21:11.234 4: TSCUL_send:  CUL0                         As 11 DD A002 1DA462 278205 045856068628E302
2017.08.19 17:21:11.235 4: TSCUL_XmitDlyHM:  CUL0  id:278205 toms:102 rtoms:1746
2017.08.19 17:21:11.515 4: TSCUL_Parse: CUL0  355419 A F103 02635292 01 11 DD A002 1DA462 278205 04 _CCAdly:4 _dhmSt:164 -138
2017.08.19 17:21:11.769 4: TSCUL_Parse: CUL0  355673 A F103 02635564 01 11 DD A002 1DA462 278205 04 _CCAdly:4 _dhmSt:436 -138
2017.08.19 17:21:12.026 4: TSCUL_Parse: CUL0  355929 A F103 02635836 01 11 DD A002 1DA462 278205 04 _CCAdly:4 _dhmSt:708 -138
2017.08.19 17:21:12.281 1: TSCUL_ParseTsHM: CUL0 HM repeat failed to 278205/EG_Kueche:  356184 A F109 02636104 00 11 DD A002 1DA462 278205 04 _sfail
2017.08.19 17:21:13.232 4: TSCUL_XmitAwaitTo CUL0: timeout - 278205
2017.08.19 17:21:15.260 4: TSCUL_Parse: CUL0  359163 A F101 02639084 00 0C DD A241 278205 1DA462 0175C8 -62.5
2017.08.19 17:21:15.263 4: TSCUL_send:  CUL0                         As 11 DD A002 1DA462 278205 045856068628E302
2017.08.19 17:21:15.264 4: TSCUL_XmitDlyHM:  CUL0  id:278205 toms:102 rtoms:1746
2017.08.19 17:21:15.521 4: TSCUL_Parse: CUL0  359424 A F103 02639320 01 11 DD A002 1DA462 278205 04 _CCAdly:4 -138
2017.08.19 17:21:15.779 4: TSCUL_Parse: CUL0  359682 A F103 02639592 01 11 DD A002 1DA462 278205 04 _CCAdly:4 -138
2017.08.19 17:21:16.041 4: TSCUL_Parse: CUL0  359944 A F103 02639864 01 11 DD A002 1DA462 278205 04 _CCAdly:4 -138
2017.08.19 17:21:16.296 1: TSCUL_ParseTsHM: CUL0 HM repeat failed to 278205/EG_Kueche:  360199 A F109 02640132 00 11 DD A002 1DA462 278205 04 _sfail
2017.08.19 17:21:17.175 4: TSCUL_XmitAwaitTo CUL0: timeout - 278205
2017.08.19 17:21:17.179 4: TSCUL_Parse: CUL0  361082 A F102 02641228 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2017.08.19 17:21:18.793 4: TSCUL_Parse: CUL0  362696 A F101 02642656 00 0C DE A641 278205 1DA462 017600 -61
2017.08.19 17:21:18.796 4: TSCUL_send:  CUL0                         As 11 DE A002 1DA462 278205 045856068628E302
2017.08.19 17:21:18.797 4: TSCUL_XmitDlyHM:  CUL0  id:278205 toms:102 rtoms:1746
2017.08.19 17:21:19.057 4: TSCUL_Parse: CUL0  362961 A F103 02642852 01 11 DE A002 1DA462 278205 04 _CCAdly:4 _dhmSt:196 -138
2017.08.19 17:21:19.060 4: TSCUL_Parse: CUL0  362962 A F101 02642904 00 0C DE A241 278205 1DA462 017600 -61
2017.08.19 17:21:19.352 4: TSCUL_Parse: CUL0  363255 A F101 02643400 00 0C DE A241 278205 1DA462 017600 -61
2017.08.19 17:21:19.355 4: TSCUL_send:  CUL0                         As 11 DE A002 1DA462 278205 045856068628E302
2017.08.19 17:21:19.355 4: TSCUL_XmitDlyHM:  CUL0  id:278205 toms:102 rtoms:1746
2017.08.19 17:21:19.613 4: TSCUL_Parse: CUL0  363516 A F103 02643520 01 11 DE A002 1DA462 278205 04 _CCAdly:4 _dhmSt:864 -138
2017.08.19 17:21:19.868 4: TSCUL_Parse: CUL0  363771 A F101 02643680 00 19 DE A203 278205 1DA462 994D533D3F75BFA6413A34905FC0286A -61
2017.08.19 17:21:20.144 4: TSCUL_send:  CUL0                         As 0E DE 8002 1DA462 278205 0038bf5f03
2017.08.19 17:21:20.144 4: TSCUL_XmitDlyHM:  CUL0  id:278205 toms:99
2017.08.19 17:21:20.399 4: TSCUL_send:  CUL0                         As 11 DE 8002 1DA462 278205 0101C80038bf5f03
2017.08.19 17:21:20.399 4: TSCUL_XmitDlyHM:  CUL0  id:278205 toms:102
2017.08.19 17:21:20.401 4: TSCUL_Parse: CUL0  364305 A F103 02644200 01 0E DE 8002 1DA462 278205 00 _CCAdly:4 _dhmSt:520 -138
2017.08.19 17:21:20.659 4: TSCUL_Parse: CUL0  364563 A F103 02644456 01 11 DE 8002 1DA462 278205 01 _CCAdly:4 _dhmSt:776 -138
2017.08.19 17:21:20.661 4: TSCUL_Parse: CUL0  364564 A F101 02644656 00 0C DE A241 278205 1DA462 017600 -60.5
2017.08.19 17:21:20.664 4: TSCUL_send:  CUL0                         As 11 DE A002 1DA462 278205 04EEFA181A6B8802
2017.08.19 17:21:20.665 4: TSCUL_XmitDlyHM:  CUL0  id:278205 toms:102 rtoms:1746
2017.08.19 17:21:20.953 4: TSCUL_Parse: CUL0  364856 A F103 02644776 01 11 DE A002 1DA462 278205 04 _CCAdly:4 _dhmSt:120 -138
2017.08.19 17:21:20.955 4: TSCUL_Parse: CUL0  364858 A F101 02644936 00 19 DE A203 278205 1DA462 315195CDC93F52F44ED9201D55F08BA0 -61
2017.08.19 17:21:21.247 4: TSCUL_send:  CUL0                         As 0E DE 8002 1DA462 278205 0016dce497
2017.08.19 17:21:21.247 4: TSCUL_XmitDlyHM:  CUL0  id:278205 toms:99
2017.08.19 17:21:21.505 4: TSCUL_send:  CUL0                         As 11 DE 8002 1DA462 278205 0101C80016dce497
2017.08.19 17:21:21.506 4: TSCUL_XmitDlyHM:  CUL0  id:278205 toms:102
2017.08.19 17:21:21.510 4: TSCUL_Parse: CUL0  365413 A F103 02645304 01 0E DE 8002 1DA462 278205 00 _CCAdly:4 _dhmSt:368 -138
2017.08.19 17:21:21.768 4: TSCUL_Parse: CUL0  365671 A F103 02645564 02 11 DE 8002 1DA462 278205 01 _CCAdly:8 _dhmSt:628 -138
2017.08.19 17:21:22.854 4: TSCUL_Parse: CUL0  366757 A F101 02646900 00 0C DE A241 278205 1DA462 017600 -61
2017.08.19 17:21:22.857 4: TSCUL_send:  CUL0                         As 11 DE A002 1DA462 278205 046713440BF73002
2017.08.19 17:21:22.858 4: TSCUL_XmitDlyHM:  CUL0  id:278205 toms:102 rtoms:1746
2017.08.19 17:21:23.131 4: TSCUL_Parse: CUL0  367034 A F103 02647020 01 11 DE A002 1DA462 278205 04 _CCAdly:4 _dhmSt:120 -138
2017.08.19 17:21:23.392 4: TSCUL_Parse: CUL0  367294 A F101 02647180 00 19 DE A203 278205 1DA462 96581943581ED4CDE6D1EAD837E0BD61 -60.5
2017.08.19 17:21:23.684 4: TSCUL_send:  CUL0                         As 0E DE 8002 1DA462 278205 0091d95e4c
2017.08.19 17:21:23.685 4: TSCUL_XmitDlyHM:  CUL0  id:278205 toms:99
2017.08.19 17:21:23.942 4: TSCUL_send:  CUL0                         As 11 DE 8002 1DA462 278205 0101C80091d95e4c
2017.08.19 17:21:23.942 4: TSCUL_XmitDlyHM:  CUL0  id:278205 toms:102
2017.08.19 17:21:23.948 4: TSCUL_Parse: CUL0  367852 A F103 02647744 02 0E DE 8002 1DA462 278205 00 _CCAdly:8 _dhmSt:564 -138
2017.08.19 17:21:24.207 4: TSCUL_Parse: CUL0  368110 A F103 02648000 02 11 DE 8002 1DA462 278205 01 _CCAdly:8 _dhmSt:820 -138
2017.08.19 17:21:27.251 4: TSCUL_Parse: CUL0  371154 A F101 02651120 00 0C DE A241 278205 1DA462 017600 -60.5
2017.08.19 17:21:27.255 4: TSCUL_send:  CUL0                         As 11 DE A002 1DA462 278205 04F69AD7D70D1A02
2017.08.19 17:21:27.255 4: TSCUL_XmitDlyHM:  CUL0  id:278205 toms:102 rtoms:1746
2017.08.19 17:21:27.542 4: TSCUL_Parse: CUL0  371445 A F103 02651312 01 11 DE A002 1DA462 278205 04 _CCAdly:4 _dhmSt:192 -138
2017.08.19 17:21:27.797 4: TSCUL_Parse: CUL0  371701 A F103 02651584 01 11 DE A002 1DA462 278205 04 _CCAdly:4 _dhmSt:464 -138
2017.08.19 17:21:28.051 4: TSCUL_Parse: CUL0  371955 A F103 02651856 01 11 DE A002 1DA462 278205 04 _CCAdly:4 _dhmSt:736 -138
2017.08.19 17:21:28.306 1: TSCUL_ParseTsHM: CUL0 HM repeat failed to 278205/EG_Kueche:  372209 A F109 02652124 00 11 DE A002 1DA462 278205 04 _sfail
2017.08.19 17:21:29.066 4: TSCUL_XmitAwaitTo CUL0: timeout - 278205
2017.08.19 17:21:30.088 4: TSCUL_Parse: CUL0  373991 A F101 02653908 00 0C DF A641 278205 1DA462 0177C8 -61.5
2017.08.19 17:21:30.091 4: TSCUL_send:  CUL0                         As 11 DF A002 1DA462 278205 04F69AD7D70D1A02
2017.08.19 17:21:30.092 4: TSCUL_XmitDlyHM:  CUL0  id:278205 toms:102 rtoms:1746
2017.08.19 17:21:30.350 4: TSCUL_Parse: CUL0  374253 A F103 02654160 04 11 DF A002 1DA462 278205 04 _CCAdly:16 _dhmSt:252 -138
2017.08.19 17:21:30.608 4: TSCUL_Parse: CUL0  374511 A F103 02654432 01 11 DF A002 1DA462 278205 04 _CCAdly:4 _dhmSt:524 -138
2017.08.19 17:21:30.863 4: TSCUL_Parse: CUL0  374765 A F103 02654704 01 11 DF A002 1DA462 278205 04 _CCAdly:4 _dhmSt:796 -138
2017.08.19 17:21:30.866 4: TSCUL_Parse: CUL0  374768 A F101 02654800 00 0C DF A241 278205 1DA462 0177C8 -62
2017.08.19 17:21:31.890 4: TSCUL_Parse: CUL0  375793 A F101 02655792 00 0C DF A241 278205 1DA462 0177C8 -62
2017.08.19 17:21:31.893 4: TSCUL_send:  CUL0                         As 11 DF A002 1DA462 278205 04F69AD7D70D1A02
2017.08.19 17:21:31.894 4: TSCUL_XmitDlyHM:  CUL0  id:278205 toms:102 rtoms:1746
2017.08.19 17:21:32.155 4: TSCUL_Parse: CUL0  376058 A F103 02655952 01 11 DF A002 1DA462 278205 04 _CCAdly:4 _dhmSt:2044 -138
2017.08.19 17:21:32.467 4: TSCUL_Parse: CUL0  376370 A F103 02656224 01 11 DF A002 1DA462 278205 04 _CCAdly:4 _dhmSt:2316 -138
2017.08.19 17:21:32.723 4: TSCUL_Parse: CUL0  376626 A F103 02656496 01 11 DF A002 1DA462 278205 04 _CCAdly:4 _dhmSt:2588 -138
2017.08.19 17:21:32.725 1: TSCUL_ParseTsHM: CUL0 HM repeat failed to 278205/EG_Kueche:  376628 A F109 02656764 00 11 DF A002 1DA462 278205 04 _sfail
2017.08.19 17:21:33.682 4: TSCUL_XmitAwaitTo CUL0: timeout - 278205
2017.08.19 17:21:34.046 4: TSCUL_Parse: CUL0  377949 A F101 02657768 00 0C DF A241 278205 1DA462 0177C8 -62.5
2017.08.19 17:21:34.049 4: TSCUL_send:  CUL0                         As 11 DF A002 1DA462 278205 04F69AD7D70D1A02
2017.08.19 17:21:34.049 4: TSCUL_XmitDlyHM:  CUL0  id:278205 toms:102 rtoms:1746
2017.08.19 17:21:34.314 4: TSCUL_Parse: CUL0  378217 A F103 02658108 02 11 DF A002 1DA462 278205 04 _CCAdly:8 -138
2017.08.19 17:21:34.592 4: TSCUL_Parse: CUL0  378495 A F103 02658380 01 11 DF A002 1DA462 278205 04 _CCAdly:4 -138
2017.08.19 17:21:34.847 4: TSCUL_Parse: CUL0  378750 A F103 02658652 01 11 DF A002 1DA462 278205 04 _CCAdly:4 -138
2017.08.19 17:21:35.105 1: TSCUL_ParseTsHM: CUL0 HM repeat failed to 278205/EG_Kueche:  379008 A F109 02658920 00 11 DF A002 1DA462 278205 04 _sfail
2017.08.19 17:21:36.049 4: TSCUL_XmitAwaitTo CUL0: timeout - 278205
2017.08.19 17:21:37.679 4: TSCUL_Parse: CUL0  381581 A F101 02661728 00 0C DF A241 278205 1DA462 0177C8 -62.5
2017.08.19 17:21:37.681 4: TSCUL_send:  CUL0                         As 11 DF A002 1DA462 278205 04F69AD7D70D1A02
2017.08.19 17:21:37.682 4: TSCUL_XmitDlyHM:  CUL0  id:278205 toms:102 rtoms:1746
2017.08.19 17:21:37.939 4: TSCUL_Parse: CUL0  381842 A F103 02661848 01 11 DF A002 1DA462 278205 04 _CCAdly:4 -138
2017.08.19 17:21:38.198 4: TSCUL_Parse: CUL0  382100 A F101 02662008 00 19 DF A203 278205 1DA462 0D06B3B6BEFF7C4B684172ABC6518FDF -62.5
2017.08.19 17:21:38.499 4: TSCUL_send:  CUL0                         As 0E DF 8002 1DA462 278205 00dd8fc4b1
2017.08.19 17:21:38.499 4: TSCUL_XmitDlyHM:  CUL0  id:278205 toms:99
2017.08.19 17:21:38.754 4: TSCUL_send:  CUL0                         As 11 DF 8002 1DA462 278205 0101C800dd8fc4b1
2017.08.19 17:21:38.754 4: TSCUL_XmitDlyHM:  CUL0  id:278205 toms:102
2017.08.19 17:21:38.756 4: TSCUL_Parse: CUL0  382660 A F103 02662556 01 0E DF 8002 1DA462 278205 00 _CCAdly:4 _dhmSt:548 -138
2017.08.19 17:21:39.015 4: TSCUL_Parse: CUL0  382918 A F103 02662812 01 11 DF 8002 1DA462 278205 01 _CCAdly:4 _dhmSt:804 -138
2017.08.19 17:21:39.016 4: TSCUL_Parse: CUL0  382920 A F101 02662964 00 11 1A A002 17E2BB 1C5801 04A581E775D9DF02 -95.5
2017.08.19 17:21:39.277 4: TSCUL_Parse: CUL0  383180 A F101 02663220 00 0E 1A 8002 17E2BB 1C5801 001A5A0D2A -95
2017.08.19 17:21:42.258 4: TSCUL_Parse: CUL0  386161 A F101 02666160 00 0C E0 A641 278205 1DA462 017800 -61.5
2017.08.19 17:21:42.261 4: TSCUL_send:  CUL0                         As 11 E0 A002 1DA462 278205 04B8E9AC5FECDD02
2017.08.19 17:21:42.262 4: TSCUL_XmitDlyHM:  CUL0  id:278205 toms:102 rtoms:1746
2017.08.19 17:21:42.547 4: TSCUL_Parse: CUL0  386450 A F103 02666320 01 11 E0 A002 1DA462 278205 04 _CCAdly:4 _dhmSt:160 -138
2017.08.19 17:21:42.549 4: TSCUL_Parse: CUL0  386452 A F101 02666408 00 0C E0 A241 278205 1DA462 017800 -61.5
2017.08.19 17:21:42.853 4: TSCUL_Parse: CUL0  386756 A F101 02666900 00 0C E0 A241 278205 1DA462 017800 -61
2017.08.19 17:21:42.855 4: TSCUL_send:  CUL0                         As 11 E0 A002 1DA462 278205 04B8E9AC5FECDD02
2017.08.19 17:21:42.856 4: TSCUL_XmitDlyHM:  CUL0  id:278205 toms:102 rtoms:1746
2017.08.19 17:21:43.116 4: TSCUL_Parse: CUL0  387020 A F103 02667020 01 11 E0 A002 1DA462 278205 04 _CCAdly:4 _dhmSt:860 -138
2017.08.19 17:21:43.375 4: TSCUL_Parse: CUL0  387277 A F101 02667176 00 19 E0 A203 278205 1DA462 B5301998BE85B2D0D20500DE618271D6 -61
2017.08.19 17:21:43.674 4: TSCUL_send:  CUL0                         As 0E E0 8002 1DA462 278205 00e5159a6f
2017.08.19 17:21:43.674 4: TSCUL_XmitDlyHM:  CUL0  id:278205 toms:99
2017.08.19 17:21:43.929 4: TSCUL_send:  CUL0                         As 11 E0 8002 1DA462 278205 0101C800e5159a6f
2017.08.19 17:21:43.929 4: TSCUL_XmitDlyHM:  CUL0  id:278205 toms:102
2017.08.19 17:21:43.931 4: TSCUL_Parse: CUL0  387835 A F103 02667732 01 0E E0 8002 1DA462 278205 00 _CCAdly:4 _dhmSt:556 -138
2017.08.19 17:21:44.192 4: TSCUL_Parse: CUL0  388096 A F103 02667988 01 11 E0 8002 1DA462 278205 01 _CCAdly:4 _dhmSt:812 -138
2017.08.19 17:21:44.194 4: TSCUL_Parse: CUL0  388097 A F101 02668156 00 0C E0 A241 278205 1DA462 017800 -61
2017.08.19 17:21:44.197 4: TSCUL_send:  CUL0                         As 11 E0 A002 1DA462 278205 044932ED76338F02
2017.08.19 17:21:44.197 4: TSCUL_XmitDlyHM:  CUL0  id:278205 toms:102 rtoms:1746
2017.08.19 17:21:44.485 4: TSCUL_Parse: CUL0  388388 A F103 02668276 01 11 E0 A002 1DA462 278205 04 _CCAdly:4 _dhmSt:120 -138
2017.08.19 17:21:44.488 4: TSCUL_Parse: CUL0  388390 A F101 02668432 00 19 E0 A203 278205 1DA462 6286196745A2F28BAAFE7CB2937DCE51 -60
2017.08.19 17:21:44.778 4: TSCUL_send:  CUL0                         As 0E E0 8002 1DA462 278205 000bab4b37
2017.08.19 17:21:44.778 4: TSCUL_XmitDlyHM:  CUL0  id:278205 toms:99
2017.08.19 17:21:45.033 4: TSCUL_send:  CUL0                         As 11 E0 8002 1DA462 278205 0101C8000bab4b37
2017.08.19 17:21:45.034 4: TSCUL_XmitDlyHM:  CUL0  id:278205 toms:102
2017.08.19 17:21:45.036 4: TSCUL_Parse: CUL0  388939 A F103 02668836 01 0E E0 8002 1DA462 278205 00 _CCAdly:4 _dhmSt:404 -138
2017.08.19 17:21:45.294 4: TSCUL_Parse: CUL0  389197 A F103 02669092 01 11 E0 8002 1DA462 278205 01 _CCAdly:4 _dhmSt:660 -138
2017.08.19 17:21:46.351 4: TSCUL_Parse: CUL0  390254 A F101 02670400 00 0C E0 A241 278205 1DA462 017800 -62
2017.08.19 17:21:46.354 4: TSCUL_send:  CUL0                         As 11 E0 A002 1DA462 278205 04D213C1038B0E02
2017.08.19 17:21:46.355 4: TSCUL_XmitDlyHM:  CUL0  id:278205 toms:102 rtoms:1746
2017.08.19 17:21:46.640 4: TSCUL_Parse: CUL0  390543 A F103 02670520 01 11 E0 A002 1DA462 278205 04 _CCAdly:4 _dhmSt:120 -138
2017.08.19 17:21:46.643 4: TSCUL_Parse: CUL0  390545 A F101 02670680 00 19 E0 A203 278205 1DA462 ADB1734369DF1501FCB1F18D5E90B47C -62.5
2017.08.19 17:21:46.937 4: TSCUL_send:  CUL0                         As 0E E0 8002 1DA462 278205 0058bdf45c
2017.08.19 17:21:46.937 4: TSCUL_XmitDlyHM:  CUL0  id:278205 toms:99
2017.08.19 17:21:47.196 4: TSCUL_send:  CUL0                         As 11 E0 8002 1DA462 278205 0101C80058bdf45c
2017.08.19 17:21:47.196 4: TSCUL_XmitDlyHM:  CUL0  id:278205 toms:102
2017.08.19 17:21:47.200 4: TSCUL_Parse: CUL0  391103 A F103 02670996 02 0E E0 8002 1DA462 278205 00 _CCAdly:8 _dhmSt:316 -138
2017.08.19 17:21:47.494 4: TSCUL_Parse: CUL0  391396 A F103 02671256 02 11 E0 8002 1DA462 278205 01 _CCAdly:8 _dhmSt:576 -138
2017.08.19 17:21:50.576 4: TSCUL_Parse: CUL0  394479 A F101 02674624 00 0C E0 A241 278205 1DA462 017800 -59
2017.08.19 17:21:50.579 4: TSCUL_send:  CUL0                         As 11 E0 A002 1DA462 278205 04CB4E620F819A02
2017.08.19 17:21:50.580 4: TSCUL_XmitDlyHM:  CUL0  id:278205 toms:102 rtoms:1746
2017.08.19 17:21:50.865 4: TSCUL_Parse: CUL0  394768 A F103 02674744 01 11 E0 A002 1DA462 278205 04 _CCAdly:4 _dhmSt:120 -138
2017.08.19 17:21:50.868 4: TSCUL_Parse: CUL0  394770 A F101 02674904 00 19 E0 A203 278205 1DA462 6FFB6035091A21957F07E15739E8599C -58.5
2017.08.19 17:21:51.160 4: TSCUL_send:  CUL0                         As 0E E0 8002 1DA462 278205 00565f86da
2017.08.19 17:21:51.160 4: TSCUL_XmitDlyHM:  CUL0  id:278205 toms:99
2017.08.19 17:21:51.418 4: TSCUL_send:  CUL0                         As 11 E0 8002 1DA462 278205 0101C800565f86da
2017.08.19 17:21:51.419 4: TSCUL_XmitDlyHM:  CUL0  id:278205 toms:102
2017.08.19 17:21:51.422 4: TSCUL_Parse: CUL0  395325 A F103 02675220 02 0E E0 8002 1DA462 278205 00 _CCAdly:8 _dhmSt:316 -138
2017.08.19 17:21:51.681 4: TSCUL_Parse: CUL0  395584 A F103 02675476 01 11 E0 8002 1DA462 278205 01 _CCAdly:4 _dhmSt:572 -138
2017.08.19 17:21:55.274 4: TSCUL_Parse: CUL0  399177 A F102 02678976 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2017.08.19 17:22:06.523 1: Perfmon: possible freeze starting at 17:22:04, delay is 2.523
2017.08.19 17:22:29.531 4: TSCUL_Parse: CUL0  433434 A F102 02713328 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138
2017.08.19 17:22:55.129 4: TSCUL_Parse: CUL0  459032 A F102 02739180 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138


Oder sollte die TSCUL auch mit verwendet werden?

Greets

Byte
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 19 August 2017, 18:34:39
Hallo Byte,

ZitatAlso habe wieder die original TSCUL genommen und deine 10_CUL_HM eingespielt.
Warum?

ZitatOder sollte die TSCUL auch mit verwendet werden?
Sicher das!

ZitatZuerst dachte ich, er frisst es, leider zu früh gefreut.
Also der Trick mit dem zusätzlich ACK scheint bei der Firmware des Fensterkontaktes zu funktionieren.  :)

Ich fürchte aber es wird bei einem "Blinker" bleiben.

Ich habe einen Bewegungsmelder zum Testen und Experimentieren entdeckt. Und das Experiment zeigt immer wieder mal, das FHEM zeitweise zu beschäftigt ist, um sich schnell genug um die Antworten an CUL zu kümmern.
Wenn der erste Versuch seitens des devices nicht klappt, dann haben die nachfolgenden nur noch eine äusserst geringe Chance, nicht an FHEM Timingproblematiken oder auch an der Unwilligkeit des devices zu scheitern.

Bei Dir scheitert es zusätzlich noch an einer tsculfw Kleinigkeit, da tsculfw in der Version 0.10 die Signierungsanforderung wiederholt, wenn sie keine Antwort bekommt, wie bei anderen Anfragen auch. Aber auch, wenn ich das für die Signierungsanforderung ändere, bleibt es problematisch. Teilweise bekomme ich 2 Versuche vom Bewegungsmelder quasi "gleichzeitig" rein, weil FHEM den Empfangspuffer zu lange hat "liegen" lassen.

Aber teste nochmal mit der letzten 00_TSCUL.pm. Der Erste Versuch vom Fensterkontakt sollte funktionieren können. Wiederholversuche wohl nicht.

Als Alarmanlage wäre mir das so oder so jedoch zu unsicher. Der Fensterkontakt gibt nach 6 Sendeversuchen auf, richtig? Damit dann also Essig mit Meldung.

Gruß,

Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bytechanger am 19 August 2017, 19:18:46
OK, also mit TSCUL gehts besser.

Wirst sie im nächsten Update der neuen Firmware vertreten sein?

Hier ein Log bei dem es augenscheinlich (langes orangenes Licht, dann Grün) auch bei einem weiteren Versuch geklappt hat:
Aber auch wenn grün quittiert wurde am Sensor steht manchmal in FHEM "pending".


2017.08.19 19:12:48.590 4: TSCUL_Parse: CUL0  236749 A F101 09332864 00 0C B2 A641 278291 1DA462 0196C8 -58.5
2017.08.19 19:12:48.592 0: HMLAN_Send:  HMLAN1 I:-278291
2017.08.19 19:12:48.848 4: TSCUL_Parse: CUL0  237007 A F101 09333116 00 0C B2 A241 278291 1DA462 0196C8 -58.5
2017.08.19 19:12:48.851 4: TSCUL_send:  CUL0                         As 11 B2 A002 1DA462 278291 040118427ED28102
2017.08.19 19:12:48.852 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.19 19:12:49.180 4: TSCUL_Parse: CUL0  237340 A F103 09333236 01 11 B2 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:372 -138
2017.08.19 19:12:49.181 4: TSCUL_Parse: CUL0  237340 A F101 09333396 00 19 B2 A203 278291 1DA462 9AF10FFCE703A34C871ECEE17756786C -58
2017.08.19 19:12:49.187 4: TSCUL_send:  CUL0                         As 0E B2 8002 1DA462 278291 004c80eb6f
2017.08.19 19:12:49.187 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:99
2017.08.19 19:12:49.465 4: TSCUL_send:  CUL0                         As 11 B2 8002 1DA462 278291 0101C8004c80eb6f
2017.08.19 19:12:49.465 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102
2017.08.19 19:12:49.468 4: TSCUL_Parse: CUL0  237627 A F103 09333516 01 0E B2 8002 1DA462 278291 00 _CCAdly:4 _dhmSt:120 -138
2017.08.19 19:12:49.725 4: TSCUL_Parse: CUL0  237884 A F103 09333748 01 11 B2 8002 1DA462 278291 01 _CCAdly:4 _dhmSt:352 -138
2017.08.19 19:12:51.840 4: TSCUL_Parse: CUL0  239998 A F101 09336112 00 0C B3 A641 278291 1DA462 019700 -55
2017.08.19 19:12:51.843 4: TSCUL_send:  CUL0                         As 11 B3 A002 1DA462 278291 04707C4DD1C51102
2017.08.19 19:12:51.843 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.19 19:12:52.141 4: TSCUL_Parse: CUL0  240300 A F103 09336232 01 11 B3 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:120 -138
2017.08.19 19:12:52.144 4: TSCUL_Parse: CUL0  240301 A F101 09336392 00 19 B3 A203 278291 1DA462 D524FC2998C98BFFEAA806070225B81F -55
2017.08.19 19:12:52.151 4: TSCUL_send:  CUL0                         As 0E B3 8002 1DA462 278291 002ec600c1
2017.08.19 19:12:52.152 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:99
2017.08.19 19:12:52.456 4: TSCUL_send:  CUL0                         As 11 B3 8002 1DA462 278291 0101C8002ec600c1
2017.08.19 19:12:52.456 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102
2017.08.19 19:12:52.458 4: TSCUL_Parse: CUL0  240618 A F103 09336512 01 0E B3 8002 1DA462 278291 00 _CCAdly:4 _dhmSt:120 -138
2017.08.19 19:12:52.713 4: TSCUL_Parse: CUL0  240873 A F103 09336740 02 11 B3 8002 1DA462 278291 01 _CCAdly:8 _dhmSt:348 -138
2017.08.19 19:12:57.260 1: Perfmon: possible freeze starting at 19:12:54, delay is 3.26
2017.08.19 19:12:57.356 4: TSCUL_Parse: CUL0  245515 A F101 09338364 00 0C B4 A641 278291 1DA462 0198C8 -56.5
2017.08.19 19:12:57.359 4: TSCUL_send:  CUL0                         As 11 B4 A002 1DA462 278291 049BFCA11848C802
2017.08.19 19:12:57.359 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.19 19:12:57.394 4: TSCUL_Parse: CUL0  245551 A F101 09338616 00 0C B4 A241 278291 1DA462 0198C8 -57.5
2017.08.19 19:12:57.396 4: TSCUL_send:  CUL0                         As 11 B4 A002 1DA462 278291 049BFCA11848C802
2017.08.19 19:12:57.397 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.19 19:12:57.400 4: TSCUL_Parse: CUL0  245559 A F101 09339120 00 0C B4 A241 278291 1DA462 0198C8 -57.5
2017.08.19 19:12:57.403 4: TSCUL_send:  CUL0                         As 11 B4 A002 1DA462 278291 049BFCA11848C802
2017.08.19 19:12:57.403 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.19 19:12:57.407 4: TSCUL_Parse: CUL0  245565 A F101 09340136 00 0C B4 A241 278291 1DA462 0198C8 -57.5
2017.08.19 19:12:57.410 4: TSCUL_send:  CUL0                         As 11 B4 A002 1DA462 278291 049BFCA11848C802
2017.08.19 19:12:57.410 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.19 19:12:57.667 4: TSCUL_Parse: CUL0  245826 A F103 09341644 02 11 B4 A002 1DA462 278291 04 _CCAdly:8 -138
2017.08.19 19:12:57.671 4: TSCUL_Parse: CUL0  245830 A F103 09341752 01 11 B4 A002 1DA462 278291 04 _CCAdly:4 -138
2017.08.19 19:12:57.928 4: TSCUL_Parse: CUL0  246087 A F103 09342024 01 11 B4 A002 1DA462 278291 04 _CCAdly:4 -138
2017.08.19 19:12:57.931 4: TSCUL_Parse: CUL0  246089 A F101 09342160 00 0C B4 A241 278291 1DA462 0198C8 -57.5
2017.08.19 19:12:57.933 4: TSCUL_send:  CUL0                         As 11 B4 A002 1DA462 278291 049BFCA11848C802
2017.08.19 19:12:57.934 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.19 19:12:58.193 4: TSCUL_Parse: CUL0  246353 A F103 09342280 01 11 B4 A002 1DA462 278291 04 _CCAdly:4 -138
2017.08.19 19:12:58.196 4: TSCUL_Parse: CUL0  246354 A F101 09342440 00 19 B4 A203 278291 1DA462 E00BC55417EE38A683629F68A7494F6E -57
2017.08.19 19:12:58.202 4: TSCUL_send:  CUL0                         As 0E B4 8002 1DA462 278291 00c4f356b1
2017.08.19 19:12:58.203 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:99
2017.08.19 19:12:58.499 4: TSCUL_send:  CUL0                         As 11 B4 8002 1DA462 278291 0101C800c4f356b1
2017.08.19 19:12:58.499 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102
2017.08.19 19:12:58.502 4: TSCUL_Parse: CUL0  246662 A F103 09342560 01 0E B4 8002 1DA462 278291 00 _CCAdly:4 _dhmSt:120 -138
2017.08.19 19:12:58.756 4: TSCUL_Parse: CUL0  246916 A F103 09342784 02 11 B4 8002 1DA462 278291 01 _CCAdly:8 _dhmSt:344 -138
2017.08.19 19:13:00.338 4: TSCUL_Parse: CUL0  248498 A F101 09344612 00 0C B5 A641 278291 1DA462 019900 -54
2017.08.19 19:13:00.340 4: TSCUL_send:  CUL0                         As 11 B5 A002 1DA462 278291 044C98014825AE02
2017.08.19 19:13:00.340 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.19 19:13:00.611 4: TSCUL_Parse: CUL0  248771 A F103 09344732 01 11 B5 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:120 -138
2017.08.19 19:13:00.874 4: TSCUL_Parse: CUL0  249032 A F101 09344892 00 19 B5 A203 278291 1DA462 1AAE6D40504B7C36C02E3E60125A7F22 -54.5
2017.08.19 19:13:00.880 4: TSCUL_send:  CUL0                         As 0E B5 8002 1DA462 278291 0034c65f12
2017.08.19 19:13:00.881 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:99
2017.08.19 19:13:00.924 4: TSCUL_Parse: CUL0  249082 A F101 09345136 00 0C B5 A241 278291 1DA462 019900 -54.5
2017.08.19 19:13:01.194 4: TSCUL_send:  CUL0                         As 11 B5 8002 1DA462 278291 0101C80034c65f12
2017.08.19 19:13:01.194 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102
2017.08.19 19:13:01.196 4: TSCUL_Parse: CUL0  249356 A F103 09345256 01 0E B5 8002 1DA462 278291 00 _CCAdly:4 _dhmSt:120 -138
2017.08.19 19:13:01.449 4: TSCUL_send:  CUL0                         As 11 B5 A002 1DA462 278291 04336089516FF402
2017.08.19 19:13:01.450 4: TSCUL_XmitDlyHM:  CUL0  id:278291 toms:102 rtoms:1746
2017.08.19 19:13:01.452 4: TSCUL_Parse: CUL0  249612 A F103 09345476 01 11 B5 8002 1DA462 278291 01 _CCAdly:4 _dhmSt:340 -138
2017.08.19 19:13:01.707 4: TSCUL_Parse: CUL0  249866 A F103 09345732 01 11 B5 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:596 -138
2017.08.19 19:13:01.964 4: TSCUL_Parse: CUL0  250123 A F103 09346004 01 11 B5 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:868 -138
2017.08.19 19:13:02.221 4: TSCUL_Parse: CUL0  250380 A F103 09346276 01 11 B5 A002 1DA462 278291 04 _CCAdly:4 _dhmSt:1140 -138
2017.08.19 19:13:02.475 1: TSCUL_ParseTsHM: CUL0 HM repeat failed to 278291/EG_FensterBuero:  250634 A F109 09346544 00 11 B5 A002 1DA462 278291 04 _sfail
2017.08.19 19:13:03.255 4: TSCUL_XmitAwaitTo CUL0: timeout - 278291
2017.08.19 19:13:16.199 4: TSCUL_Parse: CUL0  264359 A F102 09360472 00 15 AABBCCDDAABBCCDDAABBCCDDAABBCCDDAABBCCDDAA _ping -138


Mit der Alarmanlage ist nicht so schlimm, da ich vorrangig den HMLAN benutze. Der CUL sollte als Rückfallebene für einen Stromausfall dienen (der Raspi wird von UPSPico gespeist).
Überlege, ob ich im Falle des Ausfalls von HMLAN1 nicht auf aesReqCommReq verzichte (Notlösung) um eine Öffnung mitzubekommen.

Besteht in FHEM nicht die Möglichkeit, die Kommunikation zwischen FHEM und CUL in einen eignen THREAD zu legen, der sich nur darum kümmert.
Dann wäre die derzeitige Auslastung von FHEM egal.
Der HMLAN macht diese Antworten, die er selbst kann, wohl ja auch eigenständig, daher keine timing Probleme...

Der Raspi scheint ja nicht besonders ausgelastet zu sein, sondern es ist wohl ein "Blocking" Problem von FHEM.

Greets

Byte
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 19 August 2017, 21:18:29
Hallo Byte,

also auf und zu geht grundsätzlich mit der letzten Änderung, wie in Deinem Log zu sehen. Nun stolperts noch an Timingproblemen und "Eigenbehinderung".

ZitatÜberlege, ob ich im Falle des Ausfalls von HMLAN1 nicht auf aesReqCommReq verzichte (Notlösung) um eine Öffnung mitzubekommen.
Mit dem Ausfall müsstest Du dann wohl die Attribute bei den devices auf 0 setzen?!?

ZitatBesteht in FHEM nicht die Möglichkeit, die Kommunikation zwischen FHEM und CUL in einen eignen THREAD zu legen, der sich nur darum kümmert.
Eher in einen eigenen Prozess, der dann lokal über Netzwerkschnittstelle angesprochen würde. Wie Echtzeit fähig das dann wäre, kann ich nicht sagen.

ZitatDer Raspi scheint ja nicht besonders ausgelastet zu sein, sondern es ist wohl ein "Blocking" Problem von FHEM.
Also ich habe schon Spitzen mit 100% Auslastung auf RasPi2. Wann es dann da wo im Gesamtsystem noch blocken kann, kann ich nicht sagen

Es müßte eher in die Firmware um das Timing ausreichend sicher zu stellen. Auf CUL ist es überschaubar, was wann dazwischen funken kann. Man könnte überlegen die verbleibenden Bytes im EEPROM für eine Liste mit aesReqCommReq devices zu verwenden. Die Anzahl wäre dann entsprechend begrenzt. 99 müßten auf einem CUL V3 gehen. CUL muss leider wissen, ob eine Signierung zu einer HMID angefordert werden muss und mit welchem Key. Im RAM ist nicht mehr genug Platz dafür.
Und Flash Speicher müsste auch frei geschaufelt werden, also andere Funktionen entfallen. Parallel zu HM geht aber eh nichts auf einem CUL V3.

ZitatWirst sie im nächsten Update der neuen Firmware vertreten sein?
Mit noch mehr Änderungen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bytechanger am 20 August 2017, 08:59:33
Hi

ZitatEs müßte eher in die Firmware um das Timing ausreichend sicher zu stellen. Auf CUL ist es überschaubar, was wann dazwischen funken kann. Man könnte überlegen die verbleibenden Bytes im EEPROM für eine Liste mit aesReqCommReq devices zu verwenden. Die Anzahl wäre dann entsprechend begrenzt. 99 müßten auf einem CUL V3 gehen. CUL muss leider wissen, ob eine Signierung zu einer HMID angefordert werden muss und mit welchem Key. Im RAM ist nicht mehr genug Platz dafür.
Und Flash Speicher müsste auch frei geschaufelt werden, also andere Funktionen entfallen. Parallel zu HM geht aber eh nichts auf einem CUL V3.

Wie macht es denn der HMLAN? Der weiß doch nicht, für welche Devices eine Signierung angefordert werden muss? Er ist auch problematischer über LAN an FHEM angebunden, da kann es doch eher zu Latenzen kommen.

ZitatMit dem Ausfall müsstest Du dann wohl die Attribute bei den devices auf 0 setzen?!?
Ja, oder ich verzichte völlig auf Signierung bei Sensoren. Dann wäre aber ein "Schabernack" möglich durch absichtliches Senden von falschen Sensorinfos...

Greets

Byte
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 24 August 2017, 18:43:31
Hallo Byte,

ZitatDer weiß doch nicht, für welche Devices eine Signierung angefordert werden muss?
Doch, das bekommt HMLAN von FHEM mit setzen der Attribute mitgeteilt.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bastel-Frank am 01 September 2017, 18:11:30
Hallo Ansgar,

vielen herzlichen Dank für deine stetige Weiterentwicklung. Ich bin bei Version 6 quasi ausgestiegen, da alle meine Probleme gelöst waren und bin sehr erfreut, dass Du weiter gemacht hast. Ich werde in Kürze meine CUL's dann auch auf deine aktuelle Version bringen.

Ich habe aber nun eine andere Frage:
Ich benötige weitere CULs und überlege, ob ich NanoCul's nehmen soll. Gibt es in Bezug auf deine Firmware Nachteile gegenüber den Standard-USB-Cul's?

Viele Grüße & Danke
Frank
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 01 September 2017, 21:04:49
Hallo Frank,

ZitatGibt es in Bezug auf deine Firmware Nachteile gegenüber den Standard-USB-Cul's?

Die nanoCULs haben mit Ihrem Prozessor 0.5kB weniger SRAM. Also 2kB gegenüber 2.5kB beim Busware CUL.
Das zwingt ggf. mal eher zu einer individuell zu konfigurierenden und zu compilierenden Firmware mit weniger Funktionsviefalt on board.

Angebunden ist nanoCUL per serieller Schnittstelle über ein seriell nach USB Interface an den Host. Damit ergibt sich eine größere I/O Latenz und geringere I/O Datenrate gegenüber dem Busware CUL, der mit USB nativ angebunden ist. Für HM ist kurze Latenz von Vorteil.

Mit dem wenigen Speicher können keine großzügigen seriell I/O Buffer eingerichtet werden. Meistens macht es aber bisher nichts aus.

nanoCULs gibt es auch mit 16MHz Takt. Jedoch wird der von der Firmware per Vorteiler wieder auf 8MHz runter geholt, da sonst diverse Timingfunktionen Überläufe erleiden würden. Also bezüglich Firmware derzeit kein Vorteil.

nanoCUL hat viele I/O Pins verfügbar, bietet sich in sofern auch als Bastelbasis für exotischere Eigenprojekte an. Für den der Spass daran hat und programmieren möchte.
Ich habe jedoch keinen und von daher sind User immer Beta-Tester für knappe Systemresourcen. Bisher haut's anscheinend noch hin, so weit es Rückmeldungen gibt.

Mit Busware CUL ist ein Firmwareupdate via FHEM besonders einfach ohne Knopf Drücken durchzuführen.

Ansonsten solltest Du nanoCULs erwischen, die eine individuelle Seriennummer haben oder zumindest dahingehend noch umprogrammierbar sind, wenn Du mehrere an einem Rechner betreiben willst.
Außerdem natürlich vernünftig funktionierende Tranceivermodule mit der richtigen Frequenzanpassung für Dein Nutzungsvorhaben.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bastel-Frank am 02 September 2017, 17:04:54
Hallo Ansgar,

vielen Dank für deine ausführliche Betrachtung. Ich werde daher weiterhin zu den normalen CULs greifen.

Ich werde mich dann mal dran machen, deine letzte Version auf die CULs zu bringen :-).

Viele Grüße & Danke für deine tolle Arbeit
Frank
Titel: Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: RaspiLED am 02 September 2017, 18:29:51
Hi,
ich sage nicht das der Kollege unrecht hat!
Das mit dem mehr Speicher ist mir sogar ganz neu. Ist aber auch nur bei einem Busware CUL ab V3 so. Die alten CUL hatten eh weniger.

Dennoch hat auch der Busware CUL Probleme mit verschlüsselten HM Verbindungen mangels Hardware Chip!
Daher raten hier in Forum die meisten zu HM-UART Lösungen oder halt anderen originalen HM Geräten für HM!

Zwei entscheidende Vorteile hat aber eine nanoCUL Hatdware:
Der Preis hier im Forum aktuell ab 22€ (zusammengebaut mit Allem!) und
man kann nicht nur culfw, a-culfw, sondern auch die Signalduino Firmware flashen!

Damit kann man (die Timing- und die Speichermengenprobleme überkommend) die Demodulation der Funkpakete in FHEM durchführen. Hier im Forum gibt es eine rege Entwicklung neuer Protokolle (z.B. Somfy Rolladen können besser gesteuert und gehört werden ;-)
Ich finde die nanoCUL oder Varianten mit ESP8266 (WLAN Anbindung statt USB) oder MapleCUL (direkt mehrere cc1101 Module auf einem USB Port) die bessere Wahl!
Wenn Du welche testen willst, sag einfach bescheid ;-)
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bastel-Frank am 02 September 2017, 20:32:50
Zitat von: noansi am 01 September 2017, 21:04:49
Das zwingt ggf. mal eher zu einer individuell zu konfigurierenden und zu compilierenden Firmware mit weniger Funktionsviefalt on board.

Zitat von: noansi am 01 September 2017, 21:04:49
Mit Busware CUL ist ein Firmwareupdate via FHEM besonders einfach ohne Knopf Drücken durchzuführen.

Hallo Ansgar,

dann doch noch zwei Fragen:
Die nanoCUL-Firmware ist bei deinem Paket dabei, d.h. ich muss sie nicht selbst kompilieren - oder?

und (OT): Wie kann man den Busware-CUL flashen ohne vorher den Knopf gedrückt zu haben?

Viele Grüße
Frank
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 02 September 2017, 21:04:07
Hallo Arnd,

ZitatDie alten CUL hatten eh weniger.
Richtig und die (CUL V2 und V4) werden auch von tsculfw nicht mehr unterstützt, eben wegen des mangelnden Speichers.

ZitatDennoch hat auch der Busware CUL Probleme mit verschlüsselten HM Verbindungen mangels Hardware Chip!
Das gilt mit tsculfw derzeit nur in eine Richtung, sprich, wenn "aesCommReq" genutzt wird und somit das HM device signieren soll, was derzeit komplett über FHEM laufen muss.

Ist "sign" im HM device gesetzt, dann macht die tsculfw das vom device angeforderte Signieren recht problemlos in Software, auch ohne Hardwarechip.
Welche Probleme hast Du dabei?

ZitatnanoCUL oder Varianten mit ESP8266 (WLAN Anbindung statt USB)
Da über WLAN lange Paketlaufzeiten regelmäßig vorkomen, kann es für HM eigentlich nur problematisch sein. Welche ping Antwortzeiten (von - bis) bekommst Du mit so einer Variante?
Verstehe ich daher nur für andere Protokolle, als HM.

Zitatoder MapleCUL (direkt mehrere cc1101 Module auf einem USB Port)
Hat jemand die tsculfw darauf portiert?

Hier im Thread geht es um die tsculfw.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 02 September 2017, 21:23:31
Hallo Frank,

ZitatDie nanoCUL-Firmware ist bei deinem Paket dabei, d.h. ich muss sie nicht selbst kompilieren - oder?
Es ist ein Kompilat dabei, setzt natürlich vorraus, dass beim Zusammenlöten keine abweichende I/O Konfiguration gewählt wird.

ZitatWie kann man den Busware-CUL flashen ohne vorher den Knopf gedrückt zu haben?
Sofern eine CUL Firmware drauf ist, kann sie über den B Befehl in den Bootloader gestartet werden.
CULflash hatte Rudolf schon entwickelt, um unter Nutzung dieses Befehls ein Update aus FHEM herraus zu ermöglichen.
Daraus habe ich TSCULflash gebaut, um auch die tsculfw aus FHEM heraus flashen zu können.

Also TSCUL_V3.hex Firmware Datei in das fhem Firmware Verzeichnis kopieren.
Dann mit
TSCULflash <CULDeviceName> TSCUL_V3
aus fhem heraus flashen.

Der dfu-programmer muss natürlich zuvor auf dem System installiert sein.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bastel-Frank am 03 September 2017, 12:30:40
Hallo Ansgar,

beim Wechsel von der Version 06 auf 10 habe ich leider Probleme. Die Kommunikation läuft nicht mehr. Die CUL's gehen aufgrund der Re-Send's in den Overload.

Meine Umgebung: 4x Busware CUL mit ser2net angebunden. Ich habe die deinen neuen Module nach FHEM kopiert und die CULs entsprechend programmiert.

Ich bin jetzt wieder auf 06 zurück gegangen.

Hast Du eine Idee woran es liegen könnte?

Viele Grüße
Frank
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 03 September 2017, 18:11:30
Hallo Frank,

ZitatHast Du eine Idee woran es liegen könnte?
Ohne Log, Lists, etc. leider nicht.
Hast Du irgendwas geloggt?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bastel-Frank am 03 September 2017, 19:36:46
Hier der log:
2017.09.03 11:37:10 3: telnetPort: port 7072 opened
2017.09.03 11:37:10 3: WEB: port 8083 opened
2017.09.03 11:37:10 3: WEBphone: port 8084 opened
2017.09.03 11:37:10 3: WEBtablet: port 8085 opened
2017.09.03 11:37:10 2: eventTypes: loaded 8718 events from ./log/eventTypes.txt
2017.09.03 11:37:10 3: additional HM config file loaded: ./FHEM/HMConfig_SenTHPL.pm
2017.09.03 11:37:10 2: TSCUL_condUpdate: CUL_KG new condition disconnected
2017.09.03 11:37:10 3: Opening CUL_KG device /dev/ttyACM0
2017.09.03 11:37:10 3: Setting CUL_KG serial parameters to 9600,8,N,1
2017.09.03 11:37:11 3: CUL_KG: Possible commands: ABCEFGJKMRTUVWXYZeilmtx
2017.09.03 11:37:11 2: TSCUL_condUpdate: CUL_KG new condition init
2017.09.03 11:37:11 1: CUL_KG is VERSION_TS, VTS 0.10 CUL868, CUL_V3.4
2017.09.03 11:37:12 3: CUL_KG device opened
2017.09.03 11:37:12 2: TSCUL_condUpdate: CUL_KG new condition init
2017.09.03 11:37:12 2: Switched CUL_KG rfmode to HomeMatic
2017.09.03 11:37:12 2: TSCUL_condUpdate: CUL_EG new condition disconnected
2017.09.03 11:37:12 3: Opening CUL_EG device odroid:2003
2017.09.03 11:37:17 1: odroid:2003 disconnected, waiting to reappear (CUL_EG)
2017.09.03 11:37:17 1: DevIoTS_SimpleRead CUL_EG: Device Timeout encountered, disconnected
2017.09.03 11:37:17 2: TSCUL_condUpdate: CUL_EG new condition disconnected
2017.09.03 11:37:17 3: ASKSIN not supported
2017.09.03 11:37:17 3: ASKSIN not supported
2017.09.03 11:37:17 0: Strange call for nonexistent <undefined>: IOWriteFn
2017.09.03 11:37:17 0: Strange call for nonexistent <undefined>: IOWriteFn
2017.09.03 11:37:17 0: Strange call for nonexistent <undefined>: IOWriteFn
2017.09.03 11:37:17 2: TSCUL_condUpdate: CUL_EG new condition init
2017.09.03 11:37:17 2: Switched CUL_EG rfmode to HomeMatic
2017.09.03 11:37:18 2: TSCUL_condUpdate: CUL_OG new condition disconnected
2017.09.03 11:37:18 3: Opening CUL_OG device raspi-og:2003
2017.09.03 11:37:19 3: CUL_OG: Possible commands: ABCEFGJKMRTUVWXYZeilmtx
2017.09.03 11:37:19 2: TSCUL_condUpdate: CUL_OG new condition init
2017.09.03 11:37:19 1: CUL_OG is VERSION_TS, VTS 0.10 CUL868, CUL_V3.4
2017.09.03 11:37:19 3: CUL_OG device opened
2017.09.03 11:37:19 2: TSCUL_condUpdate: CUL_OG new condition init
2017.09.03 11:37:19 2: Switched CUL_OG rfmode to HomeMatic
2017.09.03 11:37:20 2: TSCUL_condUpdate: CUL_GH new condition disconnected
2017.09.03 11:37:20 3: Opening CUL_GH device raspi-gh:2003
2017.09.03 11:37:21 3: CUL_GH: Possible commands: ABCEFGJKMRTUVWXYZeilmtx
2017.09.03 11:37:21 2: TSCUL_condUpdate: CUL_GH new condition init
2017.09.03 11:37:21 1: CUL_GH is VERSION_TS, VTS 0.10 CUL868, CUL_V3.4
2017.09.03 11:37:21 3: CUL_GH device opened
2017.09.03 11:37:21 2: TSCUL_condUpdate: CUL_GH new condition init
2017.09.03 11:37:21 2: Switched CUL_GH rfmode to HomeMatic
2017.09.03 11:37:22 1: Including ./log/fhem.save
2017.09.03 11:37:23 1: configfile: ASKSIN not supported
ASKSIN not supported

2017.09.03 11:37:23 3: Device EG.Bad.US added to ActionDetector with 000:10 time
2017.09.03 11:37:23 3: Device EG.Kueche.FK added to ActionDetector with 002:50 time
2017.09.03 11:37:23 3: Device EG.bz.FK added to ActionDetector with 002:50 time
2017.09.03 11:37:23 3: Device EG.eg.SD added to ActionDetector with 000:10 time
2017.09.03 11:37:23 3: Device EG.hwr.FK added to ActionDetector with 002:50 time
2017.09.03 11:37:23 3: Device EG.sz.FK added to ActionDetector with 002:50 time
2017.09.03 11:37:23 3: Device EG.sz.TH added to ActionDetector with 000:10 time
2017.09.03 11:37:23 3: Device EG.tr.mr.IS added to ActionDetector with 002:50 time
2017.09.03 11:37:23 3: Device EG.wc.FK added to ActionDetector with 002:50 time
2017.09.03 11:37:23 3: Device EG.wf.SD added to ActionDetector with 000:10 time
2017.09.03 11:37:23 3: Device EG.wz.SD.lk added to ActionDetector with 000:10 time
2017.09.03 11:37:23 3: Device EG.wz.TH added to ActionDetector with 000:10 time
2017.09.03 11:37:23 3: Device EG.wz.l1.FK added to ActionDetector with 002:50 time
2017.09.03 11:37:23 3: Device EG.wz.l2.FK added to ActionDetector with 002:50 time
2017.09.03 11:37:23 3: Device EG.wz.mr.FK added to ActionDetector with 002:50 time
2017.09.03 11:37:23 3: Device EG.wz.r.FK added to ActionDetector with 002:50 time
2017.09.03 11:37:23 3: Device EG.wz.r1.FK added to ActionDetector with 002:50 time
2017.09.03 11:37:23 3: Device EG.wz.r2.FK added to ActionDetector with 002:50 time
2017.09.03 11:37:23 3: Device GH.ga.TH added to ActionDetector with 000:10 time
2017.09.03 11:37:23 3: Device HM_34264B added to ActionDetector with 000:10 time
2017.09.03 11:37:23 3: Device HM_533300 added to ActionDetector with 000:10 time
2017.09.03 11:37:23 3: Device HM_A24B00 added to ActionDetector with 000:10 time
2017.09.03 11:37:23 3: Device HM_B08100 added to ActionDetector with 000:10 time
2017.09.03 11:37:23 3: Device HM_DDE100 added to ActionDetector with 000:10 time
2017.09.03 11:37:23 3: Device KG.Entkalkung added to ActionDetector with 000:10 time
2017.09.03 11:37:23 3: Device KG.Server added to ActionDetector with 000:10 time
2017.09.03 11:37:23 3: Device KG.az.DI.Drucker added to ActionDetector with 000:10 time
2017.09.03 11:37:23 3: Device KG.az.FK added to ActionDetector with 000:50 time
2017.09.03 11:37:23 3: Device KG.az.TH added to ActionDetector with 000:10 time
2017.09.03 11:37:23 3: Device KG.eb.TH added to ActionDetector with 000:10 time
2017.09.03 11:37:23 3: Device KG.fi.TH added to ActionDetector with 000:10 time
2017.09.03 11:37:23 3: Device KG.gz.TH added to ActionDetector with 000:10 time
2017.09.03 11:37:23 3: Device KG.la.TH added to ActionDetector with 000:10 time
2017.09.03 11:37:23 3: Device KG.vr.TH added to ActionDetector with 000:10 time
2017.09.03 11:37:24 3: Device KS_550 added to ActionDetector with 000:10 time
2017.09.03 11:37:24 3: Device OG.bz.FK added to ActionDetector with 002:50 time
2017.09.03 11:37:24 3: Device OG.k1.TH added to ActionDetector with 000:10 time
2017.09.03 11:37:24 3: Device OG.k1.l.FK added to ActionDetector with 002:50 time
2017.09.03 11:37:24 3: Device OG.k1.r.FK added to ActionDetector with 002:50 time
2017.09.03 11:37:24 3: Device OG.sz.TH added to ActionDetector with 000:10 time
2017.09.03 11:37:24 3: Device OG.sz.l.FK added to ActionDetector with 002:50 time
2017.09.03 11:37:24 3: Device OG.sz.r.FK added to ActionDetector with 002:50 time
2017.09.03 11:37:24 3: Device OG.th.m.FK added to ActionDetector with 002:50 time
2017.09.03 11:37:24 3: Device OG.th.r.FK added to ActionDetector with 002:50 time
2017.09.03 11:37:24 3: Device OG.wz.TH added to ActionDetector with 000:10 time
2017.09.03 11:37:24 3: Device Thermostat added to ActionDetector with 000:10 time
2017.09.03 11:37:24 3: ASKSIN not supported
2017.09.03 11:37:24 1: CUL_HM correct hmId for assigned IO CUL_EG
2017.09.03 11:37:24 1: usb create starting
2017.09.03 11:37:24 3: Probing CUL device /dev/ttyS0
2017.09.03 11:37:24 3: Probing CUL device /dev/ttyS1
2017.09.03 11:37:24 3: Probing CUL device /dev/ttyS10
2017.09.03 11:37:24 1: PERL WARNING: can't getattr: Input/output error at ./FHEM/DevIo.pm line 392.
2017.09.03 11:37:24 3: Can't open /dev/ttyS10: Input/output error
2017.09.03 11:37:24 3: Probing CUL device /dev/ttyS11
2017.09.03 11:37:24 3: Can't open /dev/ttyS11: Input/output error
2017.09.03 11:37:24 3: Probing CUL device /dev/ttyS12
2017.09.03 11:37:24 3: Can't open /dev/ttyS12: Input/output error
2017.09.03 11:37:24 3: Probing CUL device /dev/ttyS13
2017.09.03 11:37:24 3: Can't open /dev/ttyS13: Input/output error
2017.09.03 11:37:24 3: Probing CUL device /dev/ttyS14
2017.09.03 11:37:24 3: Can't open /dev/ttyS14: Input/output error
2017.09.03 11:37:24 3: Probing CUL device /dev/ttyS15
2017.09.03 11:37:24 3: Can't open /dev/ttyS15: Input/output error
2017.09.03 11:37:24 3: Probing CUL device /dev/ttyS16
2017.09.03 11:37:24 3: Can't open /dev/ttyS16: Input/output error
2017.09.03 11:37:24 3: Probing CUL device /dev/ttyS17
2017.09.03 11:37:24 3: Can't open /dev/ttyS17: Input/output error
2017.09.03 11:37:24 3: Probing CUL device /dev/ttyS18
2017.09.03 11:37:24 3: Can't open /dev/ttyS18: Input/output error
2017.09.03 11:37:24 3: Probing CUL device /dev/ttyS19
2017.09.03 11:37:24 3: Can't open /dev/ttyS19: Input/output error
2017.09.03 11:37:24 3: Probing CUL device /dev/ttyS2
2017.09.03 11:37:24 3: Can't open /dev/ttyS2: Input/output error
2017.09.03 11:37:24 3: Probing CUL device /dev/ttyS20
2017.09.03 11:37:24 3: Can't open /dev/ttyS20: Input/output error
2017.09.03 11:37:24 3: Probing CUL device /dev/ttyS21
2017.09.03 11:37:24 3: Can't open /dev/ttyS21: Input/output error
2017.09.03 11:37:24 3: Probing CUL device /dev/ttyS22
2017.09.03 11:37:24 3: Can't open /dev/ttyS22: Input/output error
2017.09.03 11:37:24 3: Probing CUL device /dev/ttyS23
2017.09.03 11:37:24 3: Can't open /dev/ttyS23: Input/output error
2017.09.03 11:37:24 3: Probing CUL device /dev/ttyS24
2017.09.03 11:37:24 3: Can't open /dev/ttyS24: Input/output error
2017.09.03 11:37:24 3: Probing CUL device /dev/ttyS25
2017.09.03 11:37:24 3: Can't open /dev/ttyS25: Input/output error
2017.09.03 11:37:24 3: Probing CUL device /dev/ttyS26
2017.09.03 11:37:24 3: Can't open /dev/ttyS26: Input/output error
2017.09.03 11:37:24 3: Probing CUL device /dev/ttyS27
2017.09.03 11:37:24 3: Can't open /dev/ttyS27: Input/output error
2017.09.03 11:37:24 3: Probing CUL device /dev/ttyS28
2017.09.03 11:37:24 3: Can't open /dev/ttyS28: Input/output error
2017.09.03 11:37:24 3: Probing CUL device /dev/ttyS29
2017.09.03 11:37:24 3: Can't open /dev/ttyS29: Input/output error
2017.09.03 11:37:24 3: Probing CUL device /dev/ttyS3
2017.09.03 11:37:24 3: Can't open /dev/ttyS3: Input/output error
2017.09.03 11:37:24 3: Probing CUL device /dev/ttyS30
2017.09.03 11:37:24 3: Can't open /dev/ttyS30: Input/output error
2017.09.03 11:37:24 3: Probing CUL device /dev/ttyS31
2017.09.03 11:37:24 3: Can't open /dev/ttyS31: Input/output error
2017.09.03 11:37:24 3: Probing CUL device /dev/ttyS4
2017.09.03 11:37:24 3: Can't open /dev/ttyS4: Input/output error
2017.09.03 11:37:24 3: Probing CUL device /dev/ttyS5
2017.09.03 11:37:24 3: Can't open /dev/ttyS5: Input/output error
2017.09.03 11:37:24 3: Probing CUL device /dev/ttyS6
2017.09.03 11:37:24 3: Can't open /dev/ttyS6: Input/output error
2017.09.03 11:37:24 3: Probing CUL device /dev/ttyS7
2017.09.03 11:37:24 3: Can't open /dev/ttyS7: Input/output error
2017.09.03 11:37:24 3: Probing CUL device /dev/ttyS8
2017.09.03 11:37:24 3: Can't open /dev/ttyS8: Input/output error
2017.09.03 11:37:24 3: Probing CUL device /dev/ttyS9
2017.09.03 11:37:24 3: Can't open /dev/ttyS9: Input/output error
2017.09.03 11:37:24 1: usb create end
2017.09.03 11:37:24 3: myOWServer: Opening connection to OWServer localhost:4304...
2017.09.03 11:37:24 3: myOWServer: Successfully connected to localhost:4304.
2017.09.03 11:37:26 2: Messages collected while initializing FHEM: configfile: ASKSIN not supported ASKSIN not supported
2017.09.03 11:37:26 0: Featurelevel: 5.8
2017.09.03 11:37:26 0: Server started with 1035 defined entities (fhem.pl:14854/2017-08-06 perl:5.022001 os:linux user:fhem pid:9069)
2017.09.03 11:37:26 0: Strange call for nonexistent <undefined>: IOCloseFn
2017.09.03 11:37:26 3: CUL_HM set EG.ak.RO statusRequest
2017.09.03 11:37:26 0: Strange call for nonexistent <undefined>: IOCloseFn
2017.09.03 11:37:26 2: TSCUL_condUpdate: CUL_OG new condition ok
2017.09.03 11:37:26 2: TSCUL_condUpdate: CUL_GH new condition ok
2017.09.03 11:37:27 3: CUL_HM set EG.bz.RO statusRequest
2017.09.03 11:37:27 3: CALVIEW Kalender_View - CALENDAR:Kalender_Schalter triggered, updating CALVIEW Kalender_View ...
2017.09.03 11:37:27 1: PERL WARNING: Use of uninitialized value $ics in split at ./FHEM/57_Calendar.pm line 923.
2017.09.03 11:37:28 3: CUL_HM set EG.eg.SD.Sw statusRequest
2017.09.03 11:37:29 3: CUL_HM set EG.hwr.RO statusRequest
2017.09.03 11:37:30 3: CUL_HM set EG.kueche.RO statusRequest
2017.09.03 11:37:31 3: CUL_HM set EG.sz.RO statusRequest
2017.09.03 11:37:32 3: CUL_HM set EG.wc.RO statusRequest
2017.09.03 11:37:34 3: CUL_HM set EG.wf.SD.Sw statusRequest
2017.09.03 11:37:35 3: CUL_HM set EG.wz.DI.dl.Sw statusRequest
2017.09.03 11:37:36 0: Strange call for nonexistent <undefined>: IOCloseFn
2017.09.03 11:37:36 3: CUL_HM set EG.wz.DI.dl.Sw1_V_01 statusRequest
2017.09.03 11:37:37 3: CUL_HM set EG.wz.DI.dl.Sw1_V_02 statusRequest
2017.09.03 11:37:38 3: CUL_HM set KG.az.DI.Drucker getConfig
2017.09.03 11:37:39 3: CUL_HM set EG.wz.DI.dr.Sw statusRequest
2017.09.03 11:37:39 1: PERL WARNING: Use of uninitialized value $minInt in numeric lt (<) at fhem.pl line 4431.
2017.09.03 11:37:40 3: CUL_HM set EG.wz.DI.dr_Sw1_V_01 statusRequest
2017.09.03 11:37:41 3: CUL_HM set EG.wz.DI.dr_Sw1_V_02 statusRequest
2017.09.03 11:37:41 3: CUL_HM set KG.az.DI.Drucker getConfig
2017.09.03 11:37:42 3: CUL_HM set EG.wz.DI.sw.Sw statusRequest
2017.09.03 11:37:43 3: CUL_HM set EG.wz.DI.sw_Sw_V_01 statusRequest
2017.09.03 11:37:44 3: CUL_HM set EG.wz.DI.sw_Sw_V_02 statusRequest
2017.09.03 11:37:45 3: CUL_HM set EG.wz.SD.lk.Sw statusRequest
2017.09.03 11:37:46 3: CUL_HM set EG.wz.l1.RO statusRequest
2017.09.03 11:37:47 3: CUL_HM set EG.wz.l2.RO statusRequest
2017.09.03 11:37:48 3: CUL_HM set EG.wz.ml.RO statusRequest
2017.09.03 11:37:49 3: CUL_HM set EG.wz.mr.RO statusRequest
2017.09.03 11:37:50 3: CUL_HM set EG.wz.r.RO statusRequest
2017.09.03 11:37:51 3: CUL_HM set EG.wz.r1.RO statusRequest
2017.09.03 11:37:52 3: CUL_HM set EG.wz.r2.RO statusRequest
2017.09.03 11:37:53 3: CUL_HM set HM_34264B_Sw statusRequest
2017.09.03 11:37:54 3: CUL_HM set HM_2B36E4_Sw statusRequest
2017.09.03 11:37:55 3: CUL_HM set HM_2B3660_Sw statusRequest
2017.09.03 11:37:56 3: CUL_HM set KG.az.DI.Drucker.Sw statusRequest
2017.09.03 11:37:57 3: CUL_HM set KG.az.RO statusRequest
2017.09.03 11:37:58 3: CUL_HM set KG.gz.RO statusRequest
2017.09.03 11:37:59 3: CUL_HM set KG.hz.01.Sw_01.Gast statusRequest
2017.09.03 11:38:00 3: CUL_HM set KG.hz.01.Sw_02.Fitness statusRequest
2017.09.03 11:38:01 3: CUL_HM set KG.hz.01.Sw_03.Arbeit statusRequest
2017.09.03 11:38:02 3: CUL_HM set KG.hz.01.Sw_04.EB statusRequest
2017.09.03 11:38:03 3: CUL_HM set KG.vt.HS.01.Sw_01.Bel_Treppe_KG_EG statusRequest
2017.09.03 11:38:04 3: CUL_HM set KG.vt.HS.01.Sw_02.Bel_Treppe_EG_OG statusRequest
2017.09.03 11:38:05 3: CUL_HM set KG.vt.HS.01.Sw_03.Bel_Treppe_HWR statusRequest
2017.09.03 11:38:06 3: CUL_HM set KG.vt.HS.01.Sw_04 statusRequest
2017.09.03 11:38:07 3: CUL_HM set KG.vt.HS.02.Sw_01.Bel_Windfang statusRequest
2017.09.03 11:38:08 3: CUL_HM set KG.vt.HS.02.Sw_02 statusRequest
2017.09.03 11:38:09 3: CUL_HM set KG.vt.HS.02.Sw_03 statusRequest
2017.09.03 11:38:10 3: CUL_HM set KG.vt.HS.02.Sw_04 statusRequest
2017.09.03 11:38:11 3: CUL_HM set KG.vt.HS.03.Sw_01.Ter_Markise.R.Ein_Aus statusRequest
2017.09.03 11:38:12 3: CUL_HM set KG.vt.HS.03.Sw_02.Ter_Markise.R.Umschalt statusRequest
2017.09.03 11:38:13 3: CUL_HM set KG.vt.HS.03.Sw_03.Ter_Markise.L.Ein_Aus statusRequest
2017.09.03 11:38:14 3: CUL_HM set KG.vt.HS.03.Sw_04.Ter_Markise.L.Umschalt statusRequest
2017.09.03 11:38:15 3: CUL_HM set KG.vt.HS.04.Sw_01.Vert_Markise.R.Ein_Aus statusRequest
2017.09.03 11:38:16 3: CUL_HM set KG.vt.HS.04.Sw_02.Vert_Markise.R.Umschalt statusRequest
2017.09.03 11:38:22 3: CUL_HM set KG.vt.HS.04.Sw_03.Vert_Markise.L.Ein_Aus statusRequest
2017.09.03 11:38:23 3: CUL_HM set KG.vt.HS.04.Sw_04.Vert_Markise.L.Umschalt statusRequest
2017.09.03 11:38:24 3: CUL_HM set OG.bz.RO statusRequest
2017.09.03 11:38:25 1: TSCUL_ParseTsHM: CUL_OG HM repeat failed to 2CAC61/OG.bz.RO:  196603 A F109 01718124 00 0B F5 A001 738396 2CAC61 01 _sfail
2017.09.03 11:38:25 3: CUL_HM set OG.hz.01.Sw_01.k1 statusRequest
2017.09.03 11:38:26 3: CUL_HM set OG.hz.01.Sw_02 statusRequest
2017.09.03 11:38:27 3: CUL_HM set OG.hz.01.Sw_03 statusRequest
2017.09.03 11:38:28 3: CUL_HM set OG.hz.01.Sw_04 statusRequest
2017.09.03 11:38:29 3: CUL_HM set OG.hz.02.Sw_01.k2 statusRequest
2017.09.03 11:38:30 1: TSCUL_ParseTsHM: CUL_OG HM repeat failed to 2CAC61/OG.bz.RO:  201370 A F109 01722892 00 0B F5 A001 738396 2CAC61 01 _sfail
2017.09.03 11:38:30 3: CUL_HM set OG.hz.02.Sw_02.schlafen statusRequest
2017.09.03 11:38:31 3: CUL_HM set OG.hz.02.Sw_03.wohnen statusRequest
2017.09.03 11:38:32 3: CUL_HM set OG.hz.02.Sw_04 statusRequest
2017.09.03 11:38:33 3: CUL_HM set OG.k1.l.RO statusRequest
2017.09.03 11:38:34 3: CUL_HM set OG.k1.r.RO statusRequest
2017.09.03 11:38:35 1: TSCUL_ParseTsHM: CUL_OG HM repeat failed to 2CAC61/OG.bz.RO:  207002 A F109 01728340 00 0B F5 A001 738396 2CAC61 01 _sfail
2017.09.03 11:38:35 3: CUL_HM set OG.k2.RO statusRequest
2017.09.03 11:38:36 3: CUL_HM set OG.kueche.RO statusRequest
2017.09.03 11:38:37 3: CUL_HM set OG.sz.l.RO statusRequest
2017.09.03 11:38:38 3: CUL_HM set OG.sz.r.RO statusRequest
2017.09.03 11:38:39 3: CUL_HM set OG.th.l.RO statusRequest
2017.09.03 11:38:40 1: TSCUL_ParseTsHM: CUL_OG HM repeat failed to 2CAC61/OG.bz.RO:  211982 A F109 01733436 00 0B F5 A001 738396 2CAC61 01 _sfail
2017.09.03 11:38:40 3: CUL_HM set OG.th.m.RO statusRequest
2017.09.03 11:38:41 3: CUL_HM set OG.th.r.RO statusRequest
2017.09.03 11:38:42 3: CUL_HM set OG.wz.l.RO statusRequest
2017.09.03 11:38:43 3: CUL_HM set OG.wz.m.RO statusRequest
2017.09.03 11:38:44 3: CUL_HM set OG.wz.r.RO statusRequest
2017.09.03 11:38:45 3: CUL_HM set Schalter statusRequest
2017.09.03 11:38:46 3: CUL_HM set Test_Schalter statusRequest
2017.09.03 11:38:50 3: CUL_HM set EG.eg.SD getConfig
2017.09.03 11:38:54 3: CUL_HM set EG.wf.SD.Sw getConfig
2017.09.03 11:38:56 3: CUL_HM set KS_550 getConfig
2017.09.03 11:38:58 3: CUL_HM set EG.wf.SD.Pwr getConfig
2017.09.03 11:39:02 3: CUL_HM set EG.wf.SD.SenPwr getConfig
2017.09.03 11:39:06 3: CUL_HM set EG.wf.SD.SenI getConfig
2017.09.03 11:39:10 3: CUL_HM set EG.wf.SD.SenU getConfig
2017.09.03 11:39:14 3: CUL_HM set EG.wf.SD.SenF getConfig
2017.09.03 11:39:18 3: CUL_HM set EG.wz.mr.RO getConfig
2017.09.03 11:39:27 0: Strange call for nonexistent <undefined>: IOCloseFn
2017.09.03 11:39:36 0: Strange call for nonexistent <undefined>: IOCloseFn
2017.09.03 11:39:43 3: CUL_HM set KG.la.TH.Climate getConfig
2017.09.03 11:39:45 1: PERL WARNING: Use of uninitialized value $cmd in pattern match (m//) at fhem.pl line 1002.
2017.09.03 11:39:52 3: CUL_HM set KG.vr.TH getConfig
2017.09.03 11:40:00 3: CUL_GH: Unknown code A0D3986104DF1700000000601000E::-47.5:CUL_GH, help me!
2017.09.03 11:40:00 3: CUL_HM set OG.k1.l.RO getConfig
2017.09.03 11:40:24 3: CUL_HM set OG.th.m.RO getConfig
2017.09.03 11:40:49 3: CUL_HM set OG.wz.r.RO getConfig
2017.09.03 11:41:09 3: CUL_HM set Test_Schalter getConfig
2017.09.03 11:41:27 0: Strange call for nonexistent <undefined>: IOCloseFn
2017.09.03 11:41:41 0: Strange call for nonexistent <undefined>: IOCloseFn
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 03 September 2017, 21:39:10
Hallo Frank,

ZitatSetting CUL_KG serial parameters to 9600,8,N,1
Lässt mich vermuten, dass Du den direkt am System hängenden CUL mit @9600 statt @12000000 definiert hast.
Dieser CUL wird aber ansonsten korrekt erkannt.

Bei CUL_EG sieht es anders aus
Zitat2017.09.03 11:37:17 0: Strange call for nonexistent <undefined>: IOWriteFn
Erkannt wird er auch nicht.

Bei CUL_OG kommt was zurück. und sieht erst mal gut aus, wie bei CUL_KG.
CUL_GH ebenfalls.

Wie sehen die Definitionen der CULs in der fhem.cfg aus?
Hast Du auch sicher sowohl 00_TSCUL.pm, als auch DevIoTS.pm bei Deinem Versuch ausgetauscht?

Hier antwortet ein HM-Device nicht. Mit verbose 4 beim CUL_OG oder/und allen CULs könnte man ggf. mehr sehen.
Zitat2017.09.03 11:38:25 1: TSCUL_ParseTsHM: CUL_OG HM repeat failed to 2CAC61/OG.bz.RO:  196603 A F109 01718124 00 0B F5 A001 738396 2CAC61 01 _sfail

Zitat2017.09.03 11:38:50 3: CUL_HM set EG.eg.SD getConfig
Da ist wohl das Attribut autoReadReg nicht auf 5 eingestellt?
Wie auch bei den weiteren, bei denen ein getConfig ausgelöst wird?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bastel-Frank am 05 September 2017, 20:43:35
Hallo Ansgar,

ich werde mir eine Testumgebung aufbauen und die aktuelle Version dort zunächst verproben. Sollte diese dort laufen, wovon ich ausgehe, dann werde ich nochmal in die Produktivumgebung gehen.

Du hast recht, der CUL_KG hängt direkt im System (ohne ser2net). Mit dem CUL_EG werde ich mir speziell nochmal ansehen.

Ich hatte alle Dateien aus deinem ZIP, Ordner FHEM in meine Umgebung kopiert.

Was macht das autoReadReg? Ich höre dies zum ersten Mal.

Viele Grüße
Frank
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 05 September 2017, 21:16:14
Hallo Frank,

ZitatWas macht das autoReadReg? Ich höre dies zum ersten Mal.
Es steht standardmäßig auf 4, was bedeutet, dass bei jedem Systemstart für alle HM devices auch ein getConfig ausgeführt wird.

Mit 5 wird nur ein getConfig ausgeführt, wenn keine gespeicherten Registerwerte vorliegen. Zusammen mit HMinfo und autoArchive zu nutzen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bastel-Frank am 06 September 2017, 07:44:49
Zitat von: noansi am 05 September 2017, 21:16:14
Mit 5 wird nur ein getConfig ausgeführt, wenn keine gespeicherten Registerwerte vorliegen. Zusammen mit HMinfo und autoArchive zu nutzen.

Ahh, Sehr gut, dann werde ich alles umstellen ...
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 07 September 2017, 23:12:32
Hallo Frank,

mir ist aufgefallen, dass 00_TSCUL.pm noch ein Problem bei Nutzung mehrerer TSCULs für HM hat, wenn diese auch die HM devices eines anderen empfangen der gerade gesendet hat.

Im Anhang eine Aktualisierung zum Testen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bastel-Frank am 08 September 2017, 07:27:38
Zitat von: noansi am 07 September 2017, 23:12:32
mir ist aufgefallen, dass 00_TSCUL.pm noch ein Problem bei Nutzung mehrerer TSCULs für HM hat, wenn diese auch die HM devices eines anderen empfangen der gerade gesendet hat.

... dann müßte dieses Problem nach der Version 06 dazugekommen sein, weil ich mit der 06 seit einigen Wochen produktiv bin (mit den 4 CULs).
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 08 September 2017, 22:16:01
Hallo Frank,

Zitatdann müßte dieses Problem nach der Version 06 dazugekommen sein
War da auch schon drin. Es fällt erst beim genaueren Hinsehen auf, z.B. getConfig dass recht lange benötigt, wenn ein langsam angebundener CUL benutzt wird. Die Sendewarteschlange des langsamen wird langsam abgearbeitet, da empfangene Antworten nicht als solche erkannt werden, weil der schnellere CUL schon die Flags ablöscht.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bastel-Frank am 10 September 2017, 11:44:05
Hallo Ansgar,

ich bin jetzt auf die Version 10 gewechselt und alles läuft wieder  ;D. Ich nehme an, das Problem hingt tatsächlich mit dem autoReadReg der Devices zusammen. Beim Start hat das das System schlichtweg überlastet. Ich habe jetzt alle auf autoReadReg=5 stehen und es ist Ruhe eingekehrt.

Bei den ersten Versuchen mit der Versuchen 10 ist mit aufgefallen, dass die weiter entfernten Devices mit kritischem Empfang jetzt spontan reagieren. Dies kann aber auch andere Gründe haben oder es ist Zufall. Oder hast Du die Firmware dahingehend optimiert?

Viele Grüße
Frank



Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 11 September 2017, 20:14:02
Hallo Frank,

ZitatBei den ersten Versuchen mit der Versuchen 10 ist mit aufgefallen, dass die weiter entfernten Devices mit kritischem Empfang jetzt spontan reagieren.
Hast Du die letzte Version 00_TSCUL.pm (vom 7.9.17) jetzt im Einsatz?
Dann wir es eher an der liegen, da Du vermutlich weiter entfernte Devices über die per sernet angebundenen CULs nutzt?!?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: Bastel-Frank am 11 September 2017, 20:42:02
Zitat von: noansi am 11 September 2017, 20:14:02
Hast Du die letzte Version 00_TSCUL.pm (vom 7.9.17) jetzt im Einsatz?

Ja, klar, die habe ich genommen.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 14 Oktober 2017, 01:12:29
Hallo Testwillige,

hier eine neue Version 0.15 der Timestamp Firmware und der dazu benötigten FHEM Module.

Geändert ist diesmal eine Verbesserung bezüglich der Wiederholung von AESCommReq Nachrichten seitens des devices, wenn der erste Versuch nur am Empfang der abschließenden Quittung seitens des devices gescheitert ist. In der Version 0.14 wurde dann eine erneute Challenge gesendet, was mein Testdevice jedoch wenig interessiert hat. Nun wird diese Challenge durch TSCUL mit der schon bekannten Abschlussquittung ersetzt. Dies funktioniert und damit wird diese Kommunikation noch stabiler.

Außerdem ist mir noch sicherheitskritisch aufgefallen, dass bei low Battery Warnung wegen des zusätzlich gesetzten Bits im Channel Byte keine Signierung von der Version 0.14 angefordert wurde. Dies ist in dieser neuen Version behoben.

Diese Version bietet AESCommReq Unterstützung durch die tsculfw. Dazu wird im EEPROM des CULs eine Liste mit AESCommReq Kanälen und deren zu nutzende KeyNummer verwaltet. In einem CUL V3 ist die Liste auf 81 Einträge begrenzt. Ein SCC oder COC kann bis zu 209 Einträge verwalten.
Trifft nun eine Triggernachricht ein, so sendet tsculfw eine Challenge und prüft die Antwort auf gültige Authentifizierung, so (ähnlich) wie es der AES-Code von Michael Gernoth in 10_CUL_HM.pm für CULs macht. Nur bei gültiger Authentifizierung wird die auslösende Empfangsnachricht mit AUTH-Bytes durch die tsculfw an FHEM weiter gereicht. 10_CUL_HM.pm muss abschließend einen ACK mit den AUTH-Bytes senden. Dazu ist eine entsprechend modifizierte 10_CUL_HM.pm beigefügt (Ich hoffe, Martin übernimmt das wieder in den Standard).
Damit läuft der Authentifizierungsprozess in der Firmware mit dem Vorteil des stabilen Timings ab. FHEM muss also nur die ACKs zeitgerecht liefern, wie es bisher auch ohne AES der Fall ist.

Die Nutzung ist unverändert zu Standard CUL, sprich, beim gewünschten Gerät/Kanal aesCommReq auf 1 setzen und ggf. noch aesKey passend zum verteilten Key setzen.
Es werden von tsculfw nur die Keys 0 (Default Key) bis 3 unterstützt.

Diese Erweiterung erfordert jedoch auch zusätzliche Empfangspuffer im knappen Speicher des CULs. Ein CUL V3 nutzt bis zu 5 Empfangspuffer. Auch der FlashSpeicherbdarf ist angestiegen, so dass einige Protokolle nicht mehr gleichzeitig in ein Kompilat passen. Das sollte aber weniger tragisch sein, da im ASKSIN Modus ohnehin nur HM empfangen werden kann.

Bei der ungetesteten nanoCUL und miniCUL Version habe ich nur 3 Empfangspuffer vorgesehen, um den Restpeicher für den Stack zu erhalten. Vielleicht hat jemand die Möglichkeit, die max. Stacknutzung mal ausgiebig zu testen, damit der verbleibende Speicher optimal "ausgequetscht" werden kann???

Bei CUL V2 reicht der verfügbare Speicher leider hinten und vorne nicht aus, um diese Version nutzen zu können.

Im Anhang ist in TSCUL_fwcode_00_15_FHEM_Modules_00_16.zip wieder die Timestamp Firmware zu finden. Getestet habe ich TSCUL_V3, TSCOC, TSCUNO2 und TSSCC. Jedoch nur mit einem AESCommReq tauglichen Bewegungsmelder.

Die tsculfw Firmware kann für TSCUL_V3 und TSPIGATOR (an CUNX) mit FHEM mit dem TSCULflash geflashed werden. Die anderen müssen mit dem jeweiligen Flash Programmer geflashed werden.
So z.B. https://forum.fhem.de/index.php/topic,24436.msg631743.html#msg631743 kann es mit einem USB CUL Stick gehen, wenn man nicht TSCULflash verwendet.

Es gibt nicht den Luxus des Downloads beim TSCULflash, sondern die Firmware muss händisch in den FHEM/firmware Ordner kopiert werden. Der Typ ist dann TSCUL_V3.
Beispiel:
TSCULflash MeinCulDevice TSCUL_V3

Wichtig für SCC Nutzer. TSSTACKED ist entfallen und wird nicht mehr unterstützt.
Statt dessen gibt es das neue Modul STACKABLETS (als Abwandlung von Rudolfs STACKABLE).
Dieses wird sozusagen zwischen die Stackteilnehmer eingebaut.

Beispiel für fhem.cfg:
#erstes SCC Modul als Basis
define SCC_WS868 TSCUL /dev/ttyAMA0@38400 0000
attr SCC_WS868 event-on-change-reading Ints_per_sec,IntCalcStat,MatchStat
attr SCC_WS868 rfmode SlowRF
attr SCC_WS868 room Receiver
attr SCC_WS868 sendpool CUL_HM868,SCC_WS868
attr SCC_WS868 verbose 1

#neues STACKABLETS virtuelles IO device
define STACK_1 STACKABLETS SCC_WS868
attr STACK_1 verbose 1

#zweites SCC Modul
define SCC_HM868 TSCUL FHEM:DEVIO:STACK_1:38400 1034
attr SCC_HM868 event-on-change-reading cond
attr SCC_HM868 hmId F11034


Ergänzender Hinweis zu USB CULs: 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_08\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 1234
bzw.
define CUL_433 TSCUL /dev/CUL433_0@12000000 0000
definiert 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 Zip Datei sind ebenfalls die ergänzten Module zu finden, die zur Nutzung der Firmware erforderlich sind.

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
16_STACKABLETS.pm -> statt der 16_STACKABLE.pm, aus STACKABLE werden damit STACKABLETS devices in der fhem.cfg (händisch anzupassen)

10_UNIRoll_TS.pm  -> statt der 10_UNIRoll.pm, mit TSCUL 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 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 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 IO-devices zu verwenden, aus CUL_WS wird dann TSCUL_WS  in der fhem.cfg (händisch anzupassen)
15_TSCUL_EM.pm   -> statt der 15_CUL_EM.pm, mit TSCUL IO-devices zu verwenden, aus CUL_EM wird dann TSCUL_EM  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.

Außerdem:

10_CUL_HM.pm         -> angepasste Version zur Nutzung mit TSCUL/tsculfw. Derzeit ist die Nutzung dieses Moduls zwingend erforderlich!!!
98_TSCULflash.pm     -> Zum Flash von TSCUL_V3, TSPIGATOR (an CUNX) mit Datei in FHEM/firmware

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 10_CUL_HM.pm 00_TSCUL.pm 16_STACKABLETS.pm DevIoTS.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.pm CalcUtil.pm 98_TSCULflash.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` }

Noch ein Hinweis: TSCUL fragt auch die Firmwareversion der tsculfw auf 0.15 ab. Eine ältere Version wird also nicht unterstützt, da sich diesmal auch das Timestamp Protokoll (inkompatibel zum vorherigen Stand) geändert hat, so dass mit dem Austausch der FHEM Module auch ein Firmwareupdate des CUL devices erforderlich ist!

EDIT: Da ich für gewöhnlich nur einen CUL für HM nutze ist mir erst bei einem Test mit 2 CULs im HM Modus aufgefallen, dass die Mehr-CUL Nutzung noch erhebliche Probleme mit der IODev Zuordnung machte. Daher ein Update der Module 00_TSCUL.pm und 10_CUL_HM.pm mit der TSCUL_fwcode_00_15_FHEM_Modules_00_16.zip.
Damit verbunden noch ein Tip zur Haltbarkeit des CULs. Jedesmal, wenn einem HM-Device mit gesetzem aesCommReq=1 das IODev neu zugeordnet wird, führt das zu EEPROM Schreibvorgängen in den beteiligten CULs. Die Lebensdauer des EEPROMs ist begrenzt (100000 Schreibzyklen laut Datenblatt). Daher rate ich zur Nutzung des VorzugsIOs beim Device Attribut IOgrp. Also nicht einfach stumpf
attr HMdeviceName IOgrp VCCU
setzen, sondern
attr HMdeviceName IOgrp VCCU:CUL_mit_gutem_Empfang_fuer_Device
sofern die Roaming Funktionalität entsprechend RSSI für das jeweilige device nicht zwingend benötigt wird. Ein Fallback auf einen anderen CUL bleibt dennoch möglich.

Gruß, Ansgar.

Vorherige Version ohne AESCommReq: https://forum.fhem.de/index.php/topic,24436.msg640892.html#msg640892 (https://forum.fhem.de/index.php/topic,24436.msg640892.html#msg640892)
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 21 Oktober 2017, 14:00:19
Hallo Testwillige,

die Firmware (und Module) im vorherigen Beitrag ist aktualisiert auf Version 0.15.

Mir noch sicherheitskritisch aufgefallen, dass bei low Battery Warnung wegen des zusätzlich gesetzten Bits im Channel Byte entsprechender Nachrichten keine Signierung von der Version 0.14 angefordert wurde. Dies ist in der neuen Version behoben.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN Teil1
Beitrag von: noansi am 28 Oktober 2017, 20:16:20
Hallo Testwillige,

ich habe den vorvorherigen Beitrag nochmal geändert, da mir Probleme bei MehrCUL Nutzung im HM Modus aufgefallen sind. Siehe auch EDIT.
00_TSCUL.pm und 10_CUL_HM.pm zur Firmware VTS 0.15 sind aktualisiert, wie auch hier angehangen.

Gruß, Ansgar.
Titel: Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.17
Beitrag von: noansi am 02 November 2017, 19:52:38
Hallo Testwillige,

hier eine neue Version 0.17 der Timestamp Firmware und der dazu benötigten FHEM Module.

Ergänzt ist diesmal ein Auto ACK für default Quittungen zusätzlich zur AESCommReq Unterstützung. D.h. tsculfw sendet diese für bekannte HM-Devices/-Kanäle, für die eine Liste im EEPROM geführt wird. Ein CUL kann bis zu 210 Eintrage verwalten, ein COC oder SCC bis zu 254.

Die Nutzung ist unverändert zu Standard CUL, sprich, beim gewünschten Gerät/Kanal aesCommReq auf 1 setzen und ggf. noch aesKey passend zum verteilten Key setzen.
Es werden von tsculfw nur die Keys 0 (Default Key) bis 3 unterstützt.

Diese Erweiterung erfordert jedoch auch zusätzliche Empfangspuffer im knappen Speicher des CULs. Ein CUL V3 nutzt bis zu 5 Empfangspuffer. Auch der FlashSpeicherbdarf ist angestiegen, so dass einige Protokolle nicht mehr gleichzeitig in ein Kompilat passen. Das sollte aber weniger tragisch sein, da im ASKSIN Modus ohnehin nur HM empfangen werden kann.

Bei der ungetesteten nanoCUL und miniCUL Version habe ich nur 3 Empfangspuffer vorgesehen, um den Restpeicher für den Stack zu erhalten. Vielleicht hat jemand die Möglichkeit, die max. Stacknutzung mal ausgiebig zu testen, damit der verbleibende Speicher optimal "ausgequetscht" werden kann???

Bei CUL V2 reicht der verfügbare Speicher leider hinten und vorne nicht aus, um diese Version nutzen zu können.

Im Anhang ist in TSCUL_fwcode_00_17_FHEM_Modules_00_18.zip wieder die Timestamp Firmware zu finden. Getestet habe ich TSCUL_V3, TSCOC, TSCUNO2 und TSSCC. Jedoch nur mit einem AESCommReq tauglichen Bewegungsmelder für AES.

Die tsculfw Firmware kann für TSCUL_V3 und TSPIGATOR (an CUNX) mit FHEM mit dem TSCULflash geflashed werden. Die anderen müssen mit dem jeweiligen Flash Programmer geflashed werden.
So z.B. https://forum.fhem.de/index.php/topic,24436.msg631743.html#msg631743 kann es mit einem USB CUL Stick gehen, wenn man nicht TSCULflash verwendet.
TSCULflash ist erweitert auf COC, SCC, CCD, rpiaddon, CUNO2 und CUNO. Jedoch ist es nicht ganz so einfach zu handhaben, da zum einen teilweise die Taste zu drücken ist und bei Raspberry PI Modulen die Rechteproblematik für den Zugriff auf die IO-Pins überwunden werden muss. Tips dazu in der Command-Ref auch bei RPI_GPIO.
Bei einem Stapel aus SCC mit aufgesetztem COC, CCD oder (rpiaddon?) ist unbedingt beim SCC Flash darauf zu achten, die Taste am gewünschten Modul zu drücken. Sonst wird das oberste Nicht-SCC Modul mit der SCC Firmware geflashed.
Mit CUNO2 ist das flashen noch nicht getestet (nur über USB!). Wichtig, aber auch hier, die Taste zu drücken.

Es gibt nicht den Luxus des Downloads beim TSCULflash, sondern die Firmware muss händisch in den FHEM/firmware Ordner kopiert werden. Der Typ ist dann TSCUL_V3.
Beispiel:
TSCULflash MeinCulDevice TSCUL_V3

Wichtig für SCC Nutzer. TSSTACKED ist entfallen und wird nicht mehr unterstützt.
Statt dessen gibt es das neue Modul STACKABLETS (als Abwandlung von Rudolfs STACKABLE).
Dieses wird sozusagen zwischen die Stackteilnehmer eingebaut.

Beispiel für fhem.cfg:
#erstes SCC Modul als Basis
define SCC_WS868 TSCUL /dev/ttyAMA0@38400 0000
attr SCC_WS868 event-on-change-reading Ints_per_sec,IntCalcStat,MatchStat
attr SCC_WS868 rfmode SlowRF
attr SCC_WS868 room Receiver
attr SCC_WS868 sendpool CUL_HM868,SCC_WS868
attr SCC_WS868 verbose 1

#neues STACKABLETS virtuelles IO device
define STACK_1 STACKABLETS SCC_WS868
attr STACK_1 verbose 1

#zweites SCC Modul
define SCC_HM868 TSCUL FHEM:DEVIO:STACK_1:38400 1034
attr SCC_HM868 event-on-change-reading cond
attr SCC_HM868 hmId F11034


Ergänzender Hinweis zu USB CULs: 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_08\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 1234
bzw.
define CUL_433 TSCUL /dev/CUL433_0@12000000 0000
definiert 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 Zip Datei sind ebenfalls die ergänzten Module zu finden, die zur Nutzung der Firmware erforderlich sind.

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
16_STACKABLETS.pm -> statt der 16_STACKABLE.pm, aus STACKABLE werden damit STACKABLETS devices in der fhem.cfg (händisch anzupassen)

10_UNIRoll_TS.pm  -> statt der 10_UNIRoll.pm, mit TSCUL 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 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 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 IO-devices zu verwenden, aus CUL_WS wird dann TSCUL_WS  in der fhem.cfg (händisch anzupassen)
15_TSCUL_EM.pm   -> statt der 15_CUL_EM.pm, mit TSCUL IO-devices zu verwenden, aus CUL_EM wird dann TSCUL_EM  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.

Außerdem:

10_CUL_HM.pm         -> angepasste Version zur Nutzung mit TSCUL/tsculfw. Derzeit ist die Nutzung dieses Moduls zwingend erforderlich!!!
98_TSCULflash.pm     -> Zum Flash von TSCUL_V3, TSPIGATOR (an CUNX) mit Datei in FHEM/firmware

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 10_CUL_HM.pm 00_TSCUL.pm 16_STACKABLETS.pm DevIoTS.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.pm CalcUtil.pm 98_TSCULflash.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` }

Noch ein Hinweis: TSCUL fragt auch die Firmwareversion der tsculfw auf 0.17 ab. Eine ältere Version wird also nicht unterstützt, da sich diesmal auch wieder das Timestamp Protokoll (inkompatibel zum vorherigen Stand) geändert hat, so dass mit dem Austausch der FHEM Module auch ein Firmwareupdate des CUL devices erforderlich ist!

Noch ein Tip zur Haltbarkeit des CULs. Jedesmal, wenn einem HM-Device das IODev durch Roaming neu zugeordnet wird, führt das zu EEPROM Schreibvorgängen in den beteiligten CULs. Die Lebensdauer des EEPROMs ist begrenzt (100000 Schreibzyklen laut Datenblatt). Daher rate ich zur Nutzung des VorzugsIOs beim Device Attribut IOgrp. Also nicht einfach stumpf
attr HMdeviceName IOgrp VCCU
setzen, sondern
attr HMdeviceName IOgrp VCCU:CUL_mit_gutem_Empfang_fuer_Device
sofern die Roaming Funktionalität entsprechend RSSI für das jeweilige device nicht zwingend benötigt wird. Ein Fallback auf einen anderen CUL bleibt dennoch möglich.

Gruß, Ansgar.

Vorherige Version ohne Auto Ack: https://forum.fhem.de/index.php/topic,24436.msg699202.html#msg699202 (https://forum.fhem.de/index.php/topic,24436.msg699202.html#msg699202)

EDIT: Aktualisiert auf TSCUL_fwcode_00_17_FHEM_Modules_00_18 wegen Matchkorrekturen und -optimierungen in Modulen. Firmware unverändert.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.18
Beitrag von: noansi am 07 November 2017, 22:01:53
Hallo Testwillige,

hier eine neue Version 0.18 der Timestamp Firmware und der dazu benötigten FHEM Module.

Diesmal sind die Module nochmal bezüglich Matches überarbeitet.
In der Firmware ist das Timing noch etwas verkürzt. In meiner Testumgebung verbessert das die AES Kommunikation inbesondere zu Batteriebetriebenen devices.
Außerdem ist noch etwas mehr Flash Speicher durch komplett optionale Verwendung von FastRF für die Verwaltung von HM-Devices/-Kanälen frei geworden, so dass nun auf einem CUL V3 220 Kanäle möglich sind.
Die EEPROM Versionsnummer hat sich danit auch geändert, was zur Folge hat, dass das EEPROM nach dem Flashen auf Defaultwerte zurück gesetzt wird. (also ggf. vor dem Flashen individuelle Einstellung notieren)

In TSCULflash ist der Versuch des Flashens auch von NanoCULs und MiniCULs ergänzt. Da ich es aber mangels Hardware nicht testen kann, bitte ich um Feedback, ob es funktioniert. Vor dem Flashen wird ein "B00" also Reset für die TSCUL Firmware an den nano/Mini geschickt, 1 Sekunde gewartet und dann versucht mit avrdude zu flashen. Wäre nett, wenn das mal jemand testen und Feedback geben könnte.
Also erst die Firmware in den FHEM/Firmware Ordner kopieren und dann in FHEM mit
TSCULflash <nanodevicename> TSnanoCUL
bzw.
TSCULflash <minidevicename> TSminiCUL
versuchen zu Flashen. Im Log sollte danach (dauert etwas) die avrdude Ausgabe zu finden sein.

AESCommReq wird. Die Nutzung ist unverändert zu Standard CUL, sprich, beim gewünschten Gerät/Kanal aesCommReq auf 1 setzen und ggf. noch aesKey passend zum verteilten Key setzen.
Es werden von tsculfw nur die Keys 0 (Default Key) bis 3 unterstützt.

Diese Erweiterung erfordert jedoch auch zusätzliche Empfangspuffer im knappen Speicher des CULs. Ein CUL V3 nutzt bis zu 5 Empfangspuffer. Auch der FlashSpeicherbdarf ist angestiegen, so dass einige Protokolle nicht mehr gleichzeitig in ein Kompilat passen. Das sollte aber weniger tragisch sein, da im ASKSIN Modus ohnehin nur HM empfangen werden kann.

Bei der ungetesteten nanoCUL und miniCUL Version habe ich nur 3 Empfangspuffer vorgesehen, um den Restpeicher für den Stack zu erhalten. Vielleicht hat jemand die Möglichkeit, die max. Stacknutzung mal ausgiebig zu testen, damit der verbleibende Speicher optimal "ausgequetscht" werden kann???

Bei CUL V2 reicht der verfügbare Speicher leider hinten und vorne nicht aus, um diese Version nutzen zu können.

Im Anhang ist in TSCUL_fwcode_00_18_FHEM_Modules_00_19.zip wieder die Timestamp Firmware zu finden. Getestet habe ich TSCUL_V3, TSCOC, TSCUNO2 und TSSCC. Jedoch nur mit einem AESCommReq tauglichen Bewegungsmelder für AES.

Die tsculfw Firmware kann für TSCUL_V3 und TSPIGATOR (an CUNX) mit FHEM mit dem TSCULflash geflashed werden. Die anderen müssen mit dem jeweiligen Flash Programmer geflashed werden.
So z.B. https://forum.fhem.de/index.php/topic,24436.msg631743.html#msg631743 kann es mit einem USB CUL Stick gehen, wenn man nicht TSCULflash verwendet.
TSCULflash ist erweitert auf COC, SCC, CCD, rpiaddon, CUNO2 und CUNO. Jedoch ist es nicht ganz so einfach zu handhaben, da zum einen teilweise die Taste zu drücken ist und bei Raspberry PI Modulen die Rechteproblematik für den Zugriff auf die IO-Pins überwunden werden muss. Tips dazu in der Command-Ref auch bei RPI_GPIO.
Bei einem Stapel aus SCC mit aufgesetztem COC, CCD oder (rpiaddon?) ist unbedingt beim SCC Flash darauf zu achten, die Taste am gewünschten Modul zu drücken. Sonst wird das oberste Nicht-SCC Modul mit der SCC Firmware geflashed.
Mit CUNO2 ist das flashen noch nicht getestet (nur über USB!). Wichtig, aber auch hier, die Taste zu drücken.

Es gibt nicht den Luxus des Downloads beim TSCULflash, sondern die Firmware muss händisch in den FHEM/firmware Ordner kopiert werden. Der Typ ist dann TSCUL_V3.
Beispiel:
TSCULflash MeinCulDevice TSCUL_V3

Wichtig für SCC Nutzer. TSSTACKED ist entfallen und wird nicht mehr unterstützt.
Statt dessen gibt es das neue Modul STACKABLETS (als Abwandlung von Rudolfs STACKABLE).
Dieses wird sozusagen zwischen die Stackteilnehmer eingebaut.

Beispiel für fhem.cfg:
#erstes SCC Modul als Basis
define SCC_WS868 TSCUL /dev/ttyAMA0@38400 0000
attr SCC_WS868 event-on-change-reading Ints_per_sec,IntCalcStat,MatchStat
attr SCC_WS868 rfmode SlowRF
attr SCC_WS868 room Receiver
attr SCC_WS868 sendpool CUL_HM868,SCC_WS868
attr SCC_WS868 verbose 1

#neues STACKABLETS virtuelles IO device
define STACK_1 STACKABLETS SCC_WS868
attr STACK_1 verbose 1

#zweites SCC Modul
define SCC_HM868 TSCUL FHEM:DEVIO:STACK_1:38400 1034
attr SCC_HM868 event-on-change-reading cond
attr SCC_HM868 hmId F11034


Ergänzender Hinweis zu USB CULs: 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_08\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 1234
bzw.
define CUL_433 TSCUL /dev/CUL433_0@12000000 0000
definiert 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 Zip Datei sind ebenfalls die ergänzten Module zu finden, die zur Nutzung der Firmware erforderlich sind.

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
16_STACKABLETS.pm -> statt der 16_STACKABLE.pm, aus STACKABLE werden damit STACKABLETS devices in der fhem.cfg (händisch anzupassen)

10_UNIRoll_TS.pm  -> statt der 10_UNIRoll.pm, mit TSCUL 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 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 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 IO-devices zu verwenden, aus CUL_WS wird dann TSCUL_WS  in der fhem.cfg (händisch anzupassen)
15_TSCUL_EM.pm   -> statt der 15_CUL_EM.pm, mit TSCUL IO-devices zu verwenden, aus CUL_EM wird dann TSCUL_EM  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.

Außerdem:

10_CUL_HM.pm         -> angepasste Version zur Nutzung mit TSCUL/tsculfw. Derzeit ist die Nutzung dieses Moduls zwingend erforderlich!!!
98_TSCULflash.pm     -> Zum Flash von TSCUL_V3, TSPIGATOR (an CUNX) mit Datei in FHEM/firmware

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 10_CUL_HM.pm 00_TSCUL.pm 16_STACKABLETS.pm DevIoTS.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.pm CalcUtil.pm 98_TSCULflash.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` }

Noch ein Hinweis: TSCUL fragt auch die Firmwareversion der tsculfw auf 0.16 ab. Eine ältere Version wird also nicht unterstützt, da sich diesmal auch wieder das Timestamp Protokoll (inkompatibel zum vorherigen Stand) geändert hat, so dass mit dem Austausch der FHEM Module auch ein Firmwareupdate des CUL devices erforderlich ist!

Noch ein Tip zur Haltbarkeit des CULs. Jedesmal, wenn einem HM-Device das IODev durch Roaming neu zugeordnet wird, führt das zu EEPROM Schreibvorgängen in den beteiligten CULs. Die Lebensdauer des EEPROMs ist begrenzt (100000 Schreibzyklen laut Datenblatt). Daher rate ich zur Nutzung des VorzugsIOs beim Device Attribut IOgrp. Also nicht einfach stumpf
attr HMdeviceName IOgrp VCCU
setzen, sondern
attr HMdeviceName IOgrp VCCU:CUL_mit_gutem_Empfang_fuer_Device
sofern die Roaming Funktionalität entsprechend RSSI für das jeweilige device nicht zwingend benötigt wird. Ein Fallback auf einen anderen CUL bleibt dennoch möglich.

Gruß, Ansgar.

Vorherige Version: https://forum.fhem.de/index.php/topic,24436.msg708709.html#msg708709 (https://forum.fhem.de/index.php/topic,24436.msg708709.html#msg708709)
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.18
Beitrag von: klausw am 08 November 2017, 23:46:07
Hallo noansi,

habe die 0.18 mit TSCULflash auf einen NanoCUL  geflashed

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e952b
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "./FHEM/firmware/TSnanoCUL.hex"
avrdude: input file ./FHEM/firmware/TSnanoCUL.hex auto detected as Intel Hex
avrdude: writing flash (28372 bytes):

Writing | ################################################## | 100% 12.13s

avrdude: 28372 bytes of flash written
avrdude: verifying flash memory against ./FHEM/firmware/TSnanoCUL.hex:
avrdude: load data flash data from input file ./FHEM/firmware/TSnanoCUL.hex:
avrdude: input file ./FHEM/firmware/TSnanoCUL.hex auto detected as Intel Hex
avrdude: input file ./FHEM/firmware/TSnanoCUL.hex contains 28372 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 12.05s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x133d
         0x94 != 0xe0
avrdude: verification error; content mismatch

avrdude done.  Thank you.


Gab zwar verification Fehler, aber das liegt evtl. an der Hardware.
Es scheint trotzdem alles zu funktionieren.
Super Arbeit

Wie kann ich denn die max. Stacknutzung testen?

Grüße
Klaus
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.18
Beitrag von: noansi am 09 November 2017, 07:22:01
Hallo Klaus,

danke für den Test. Er geht also in den Bootloader und flashen ist möglich.

Die Datenrate für das Flashen ist beim Nano hoch, aber das gibt der Bootloader vor. Die 57600  habe ich dem Makefile der Standard Firmware entnommen.
Kannst Du den Wert bestätigen, z.B. aus der Doku?
Läuft die Firmware denn? Oder zeigen sich Merkwürdigkeiten? Antwortet die Versionsabfrage?

ZitatWie kann ich denn die max. Stacknutzung testen?
Ohne Zugriff auf die Debugging Schnittstelle des Prozessors:
Wenn der verfügbare Stackspeicher nicht reicht, sollten Verhaltensfehler bis zum spontanen Neustart auftreten.
Die Uptime sollte der Laufzeit entsprechen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.18
Beitrag von: klausw am 09 November 2017, 14:21:48
Hi Noansi,

Zitat von: noansi am 09 November 2017, 07:22:01
danke für den Test. Er geht also in den Bootloader und flashen ist möglich.
purer Eigennutz  8)
Zitat von: noansi am 09 November 2017, 07:22:01
Die Datenrate für das Flashen ist beim Nano hoch, aber das gibt der Bootloader vor. Die 57600  habe ich dem Makefile der Standard Firmware entnommen.
Kannst Du den Wert bestätigen, z.B. aus der Doku?
Bisher habe ich immer mit 56k geflashed. Auch die Kommunikation mit FHEM läuft problemlos.
Schreiben lief  auch fehlerfrei (was bei Flash Speicher länger dauert als das lesen)
Nur der verification error ist seltsam. Aber wie gesagt, das sind Nano Clone aus China. Wer weiß an welcher Stelle die Controller aus der Linie gefallen sind. Vielleicht ist es auch B-Ware.
Zitat von: noansi am 09 November 2017, 07:22:01
Läuft die Firmware denn? Oder zeigen sich Merkwürdigkeiten? Antwortet die Versionsabfrage?
Ohne Zugriff auf die Debugging Schnittstelle des Prozessors:
Wenn der verfügbare Stackspeicher nicht reicht, sollten Verhaltensfehler bis zum spontanen Neustart auftreten.
Die Uptime sollte der Laufzeit entsprechen.
version => VTS 0.18 CSM868
uptime => 0 14:39:39 (also seit dem flashen kein Neustart)

Ich habe nur 4 Komponenten dran (ist mein Testsystem)
Aber die sind erreichbar.

Nur dies scheint mir neu:
2017.11.09 13:42:30 2: TSCUL_ReceiveDelayed: culNano  C 00=07 01=2E 02=01 03=42 04=E9 05=CA 06=31 07=0C 08=45 09=00 0A=00 0B=06 0C=F3 0D=21 0E=65 0F=6A 10=C8 11=93 12=03 13=22 14=F8 15=34 16=07 17=3C 18=18 19=16 1A=6C 1B=43 1C=67 1D=91 1E=87 1F=6B 20=F8 21=56 22=10 23=AC 24=2C 25=14 26=11 27=41 28=00 29=59 2A=7F 2B=3E 2C=81 2D=35 2E=0B 2F=00 30=00 31=14 32=F3 33=00 34=AC 35=0D 36=00 37=00 38=30 39=CD 3A=00 3B=00 3C=00 3D=00
Aber seit Gestern habe ich auch testweise Rauchmelder dran, die vorher nicht gepairt waren.

Grüße
Klaus
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.18
Beitrag von: noansi am 09 November 2017, 19:30:07
Hallo Klaus,

ZitatNur der verification error ist seltsam
Das hängt etwas davon ab, wie viel auf Deinem Testsystem sonst noch läuft. Es bedeutet nicht zwangsläufig, dass das Flashen schief gegangen ist. Wohler wäre mir aber auch, wenn das Verify Ergebnis positiv wäre.

Ich habe bei mir bei CUNO2 mit 38400 auch eine erfolgreiche Verifikation geschafft, mit Flashen über FHEM mit TSCULflash. Dabei wird FHEM eigentlich großenteils angehalten.
Flashe ich den nebenher, also nur mit avrdude und FHEM gleichzeitig laufend, dann bekomme ich auch meißtens Verfikationsfehler, wohl weil dann schlicht irgendwo ein Puffer überläuft (vermutlich der vom seriell nach USB Interface Chip auf dem nanoCUL) und somit Empfangsdaten verloren gehen, was dann zu einem "falschen Verifikationsfehler" führt.

ZitatNur dies scheint mir neu:
Wenn TSCUL längere Zeit (900s) nichts vom CUL empfängt, dann wird ein Register Read angestoßen. Das ist gedacht, um zu sehen, ob der cc1101 chip nicht im PLL-Lock State ist (war hier nicht der Fall) und wenn ja, ob daraus ein Grund abzulesen ist.
Wenn Du keine HM-Sensoren hast, die innerhalb dieses Intervalls Daten senden, die der nanoCUL empfangen kann, dann kann das aber natürlich auch so mal auftreten.

Wenn Du ordentlich testen willst, dann nutze bitte auch sign und aesCommReq.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.18
Beitrag von: klausw am 09 November 2017, 22:42:33
sign und aesCommReq muss ich später testen im produktiv System testen
habe hier nur 3 alte Rauchmelder die kein AES können und nen Dimmer
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.18
Beitrag von: RaspiLED am 10 November 2017, 07:46:05
Hey Klausw,
man testet aber im Testsystem und nicht Produktiv ;-)
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.18
Beitrag von: handy80 am 11 November 2017, 19:20:40
Hallo Ansgar,
vielen Dank erstmal, dass du dich der Firmware annimmst. Ich habe auch das Problem mit dem Klingelsensor.
Hab mir daher die neuste Version deiner FW als ZIP auf meinen RPI3 geladen, entpackt und wollte nun meinen USB CUL V3.4 (aufgedruckt auf dem Board des CULs) flashen (TSCULflash CUL1 TSCUL_V3) . Bekomme aber dabei in FHEM die Fehlermeldung:

dfu-programmer: no device present.

Eine Ahnung was ich überprüfen muss/kann?
DEF vom CUL ist bei mir: /dev/ttyACM0@38400 0000
Ich weiß aber nicht mehr aus welchem Blog ich die Definition geholt habe. Sie tut aber soweit bei mir mit culfw 1.66

Gruß Holger
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.18
Beitrag von: klausw am 11 November 2017, 19:44:55
Zitat von: handy80 am 11 November 2017, 19:20:40
Eine Ahnung was ich überprüfen muss/kann?
DEF vom CUL ist bei mir: /dev/ttyACM0@38400 0000
Ich weiß aber nicht mehr aus welchem Blog ich die Definition geholt habe. Sie tut aber soweit bei mir mit culfw 1.66

versuche es mal mit 57600 Baud das funktionierte bei mir
die tty könnte passen, bei mehreren Arduinos am Pi ist es über /dev/serial/by-id/ aber sicherer
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.18
Beitrag von: handy80 am 12 November 2017, 02:47:10
Hallo Klaus,
habe das fw-update hinbekommen. Keine Ahnung wie, nach dem 15 mal hat es geklappt.
ABER, warum bekomme ich nun bei allen HM Geräten beim ein oder aus schalten ein
"missing ACK"
Gruß Holger
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.18
Beitrag von: noansi am 12 November 2017, 09:54:58
Hallo Holger,

zunächst, hast Du die Module aus dem FHEM Ordner der zip Datei in den FHEM Unterordner Deiner FHEM Installation kopiert? (vorher natürlich exisitierende gesichert)

Sofern Du nur einen CUL im System hast lautet die richtige TSCUL Definition Deines CUL V3 dann:
define CUL1 TSCUL /dev/ttyACM0@12000000 0000
da Du einen CUL mit direkter USB Anbindung hast.

@Klaus: 38400 ist für einen nanoCUL richtig, da der mit 38400 über einen USB nach seriell Baustein angebunden ist.

Dann muss es auch weiter passen, sprich die Attribute müssen passen:
Zitatattr CUL1 hmId F12345
attr CUL1 rfmode HomeMatic
attr CUL1 hmLanQlen 3_normal
attr CUL1 verbose 1
attr CUL1 room Receiver
Die "F12345" musst Du entsprechend Deiner bisher verwendeten hmId anpassen.

Dann FHEM Neustart, damit das auch übernommen wird.
Wenn AES zuvor nicht aktiv war, dann sollte es klappen, sofern die HM-Devices auch richtig und erfolgreich gepairt worden sind und natürlich in Funkreichweite sind.

Ansonsten:
Musst Du auch mehr Infos liefern, also List vom TSCUL und List vom device. Ggf. auch Mitschnitt der Kommunikation eines Schaltvorganges zu einem Problemdevice mit CUL1 auf verbose 4.

Hast Du zuvor AES verwendet? Sprich einen Schlüssel verteilt und sign in den HM-Devices auf 1 gesetzt?
Dann muss CUL1 den/die Schlüssel auch kennen...

Und die VCCU Nutzung ist nötig.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: noansi am 12 November 2017, 11:45:30
Hallo Testwillige,

hier eine neue Version 0.19 der Timestamp Firmware und der dazu benötigten FHEM Module.

Diesmal ist eine Prüfung auf Stacküberlauf eingebaut. Am Anfang des heap werden zwei Byte mit einem Bitmuster beschrieben. Wird das verändert, dann ist der Speicher wahrscheinlich korrumpiert, was durch einen Stacküberlauf ausgelöst sein sollte. Sofern der CUL dann noch kann sendet er ein "C_M" an TSCUL, was zu einem entsprechenden Log Eintrag führt.
Damit kann man vorsichtig die Speichergrenzen ausloten. Ein langer Testzeitraum ist aber erforderlich, um einigermaßen sicher zu sein, dass der worst case auch mal durchlaufen worden ist.
Außerdem ist ein Kommando mU (je nach Firmware) eingebaut, mit dem man den vom Stack ungenutzen heap in etwa auslesen kann (auch als get unusedstack in TSCUL verfügbar). Auch hier gilt, nur nach langer Laufzeit einigermaßen sinnvoll. Es macht sicher keinen Sinn auf Grund des Wertes den Speicher bis auf das letzte Byte auszuquetschen, denn weiterhin hängt die Stacknutzung vom gewählten Protokoll und Einstellungen ab.

In TSCULflash ist der Versuch des Flashens auch von NanoCULs und MiniCULs ergänzt. Da ich es aber mangels Hardware nicht testen kann, bitte ich um Feedback, ob es funktioniert. Vor dem Flashen wird ein "B00" also Reset für die TSCUL Firmware an den nano/Mini geschickt, 1 Sekunde gewartet und dann versucht mit avrdude zu flashen. Wäre nett, wenn das mal jemand testen und Feedback geben könnte.
Also erst die Firmware in den FHEM/Firmware Ordner kopieren und dann in FHEM mit
TSCULflash <nanodevicename> TSnanoCUL
bzw.
TSCULflash <minidevicename> TSminiCUL
versuchen zu Flashen. Im Log sollte danach (dauert etwas) die avrdude Ausgabe zu finden sein.

AESCommReq wird. Die Nutzung ist unverändert zu Standard CUL, sprich, beim gewünschten Gerät/Kanal aesCommReq auf 1 setzen und ggf. noch aesKey passend zum verteilten Key setzen.
Es werden von tsculfw nur die Keys 0 (Default Key) bis 3 unterstützt.

Diese Erweiterung erfordert jedoch auch zusätzliche Empfangspuffer im knappen Speicher des CULs. Ein CUL V3 nutzt bis zu 5 Empfangspuffer. Auch der FlashSpeicherbdarf ist angestiegen, so dass einige Protokolle nicht mehr gleichzeitig in ein Kompilat passen. Das sollte aber weniger tragisch sein, da im ASKSIN Modus ohnehin nur HM empfangen werden kann.

Bei der ungetesteten nanoCUL und miniCUL Version habe ich nur 3 Empfangspuffer vorgesehen, um den Restpeicher für den Stack zu erhalten. Vielleicht hat jemand die Möglichkeit, die max. Stacknutzung mal ausgiebig zu testen, damit der verbleibende Speicher optimal "ausgequetscht" werden kann???

Bei CUL V2 reicht der verfügbare Speicher leider hinten und vorne nicht aus, um diese Version nutzen zu können.

Im Anhang ist in TSCUL_fwcode_00_19_FHEM_Modules_00_23.zip wieder die Timestamp Firmware zu finden. Getestet habe ich TSCUL_V3, TSCOC, TSCUNO2 und TSSCC. Jedoch nur mit einem AESCommReq tauglichen Bewegungsmelder für AES.

Die tsculfw Firmware kann für TSCUL_V3 und TSPIGATOR (an CUNX) mit FHEM mit dem TSCULflash geflashed werden. Die anderen müssen mit dem jeweiligen Flash Programmer geflashed werden.
So z.B. https://forum.fhem.de/index.php/topic,24436.msg631743.html#msg631743 kann es mit einem USB CUL Stick gehen, wenn man nicht TSCULflash verwendet.
TSCULflash ist erweitert auf COC, SCC, CCD, rpiaddon, CUNO2 und CUNO. Jedoch ist es nicht ganz so einfach zu handhaben, da zum einen teilweise die Taste zu drücken ist und bei Raspberry PI Modulen die Rechteproblematik für den Zugriff auf die IO-Pins überwunden werden muss. Tips dazu in der Command-Ref auch bei RPI_GPIO.
Bei einem Stapel aus SCC mit aufgesetztem COC, CCD oder (rpiaddon?) ist unbedingt beim SCC Flash darauf zu achten, die Taste am gewünschten Modul zu drücken. Sonst wird das oberste Nicht-SCC Modul mit der SCC Firmware geflashed.
Mit CUNO2 ist das flashen noch nicht getestet (nur über USB!). Wichtig, aber auch hier, die Taste zu drücken.

Es gibt nicht den Luxus des Downloads beim TSCULflash, sondern die Firmware muss händisch in den FHEM/firmware Ordner kopiert werden. Der Typ ist dann TSCUL_V3.
Beispiel:
TSCULflash MeinCulDevice TSCUL_V3

Wichtig für SCC Nutzer. TSSTACKED ist entfallen und wird nicht mehr unterstützt.
Statt dessen gibt es das neue Modul STACKABLETS (als Abwandlung von Rudolfs STACKABLE).
Dieses wird sozusagen zwischen die Stackteilnehmer eingebaut.

Beispiel für fhem.cfg:
#erstes SCC Modul als Basis
define SCC_WS868 TSCUL /dev/ttyAMA0@38400 0000
attr SCC_WS868 event-on-change-reading Ints_per_sec,IntCalcStat,MatchStat
attr SCC_WS868 rfmode SlowRF
attr SCC_WS868 room Receiver
attr SCC_WS868 sendpool CUL_HM868,SCC_WS868
attr SCC_WS868 verbose 1

#neues STACKABLETS virtuelles IO device
define STACK_1 STACKABLETS SCC_WS868
attr STACK_1 verbose 1

#zweites SCC Modul
define SCC_HM868 TSCUL FHEM:DEVIO:STACK_1:38400 1034
attr SCC_HM868 event-on-change-reading cond
attr SCC_HM868 hmId F11034


Ergänzender Hinweis zu USB CULs: 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_08\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 1234
bzw.
define CUL_433 TSCUL /dev/CUL433_0@12000000 0000
definiert 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 Zip Datei sind ebenfalls die ergänzten Module zu finden, die zur Nutzung der Firmware erforderlich sind.

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
16_STACKABLETS.pm -> statt der 16_STACKABLE.pm, aus STACKABLE werden damit STACKABLETS devices in der fhem.cfg (händisch anzupassen)

10_UNIRoll_TS.pm  -> statt der 10_UNIRoll.pm, mit TSCUL 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 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 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 IO-devices zu verwenden, aus CUL_WS wird dann TSCUL_WS  in der fhem.cfg (händisch anzupassen)
15_TSCUL_EM.pm   -> statt der 15_CUL_EM.pm, mit TSCUL IO-devices zu verwenden, aus CUL_EM wird dann TSCUL_EM  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.

Außerdem:

10_CUL_HM.pm         -> angepasste Version zur Nutzung mit TSCUL/tsculfw. Derzeit ist die Nutzung dieses Moduls zwingend erforderlich!!!
98_TSCULflash.pm     -> Zum Flash von TSCUL_V3, TSPIGATOR (an CUNX) mit Datei in FHEM/firmware

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 10_CUL_HM.pm 00_TSCUL.pm 16_STACKABLETS.pm DevIoTS.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.pm CalcUtil.pm 98_TSCULflash.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` }

Noch ein Hinweis: TSCUL fragt auch die Firmwareversion der tsculfw auf 0.16 ab. Eine ältere Version wird also nicht unterstützt, da sich diesmal auch wieder das Timestamp Protokoll (inkompatibel zum vorherigen Stand) geändert hat, so dass mit dem Austausch der FHEM Module auch ein Firmwareupdate des CUL devices erforderlich ist!

Noch ein Tip zur Haltbarkeit des CULs. Jedesmal, wenn einem HM-Device das IODev durch Roaming neu zugeordnet wird, führt das zu EEPROM Schreibvorgängen in den beteiligten CULs. Die Lebensdauer des EEPROMs ist begrenzt (100000 Schreibzyklen laut Datenblatt). Daher rate ich zur Nutzung des VorzugsIOs beim Device Attribut IOgrp. Also nicht einfach stumpf
attr HMdeviceName IOgrp VCCU
setzen, sondern
attr HMdeviceName IOgrp VCCU:CUL_mit_gutem_Empfang_fuer_Device
sofern die Roaming Funktionalität entsprechend RSSI für das jeweilige device nicht zwingend benötigt wird. Ein Fallback auf einen anderen CUL bleibt dennoch möglich.

Gruß, Ansgar.

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

EDIT1: 00_TSCUL.pm und 10_CUL_HM.pm aktualisert
EDIT2: 00_TSCUL.pm und 10_CUL_HM.pm aktualisert, roaming stabilisiert und "define %" wieder entfernt entspr. https://forum.fhem.de/index.php/topic,79858.0.html (https://forum.fhem.de/index.php/topic,79858.0.html)
EDIT3: 00_TSCUL.pm hmId Rückstellung bei virtuellen HM Sensoren
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: noansi am 12 November 2017, 15:04:34
Hallo Holger,

zum Flashproblem mit TSCULflash
Zitatdfu-programmer: no device present.

TSCULflash versucht den CUL mittels B01 Befehl in den Bootloader zu restarten.

Wenn das nicht sauber funktioniert, dann sieht dfu-programmer keinen Atmel Chip, den er flashen könnte.
Ob die CUL V1.66 Firmware dabei Probleme bereitet, kann ich nicht sagen.
Mit der TSCUL Firmware klappt es so zuverlässig auf meinem RasPi.

Dann gibt es alternativ noch die Möglichkeit, den CUL zuvor mittels "Programmiertaste gedrückt halten und in den USB Port einstecken" in den Bootloader zu starten.
Damit sollte es dann funktionieren.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: Bytechanger am 16 November 2017, 06:31:01
Guten Morgen,

leider muss ich vermelden, dass in meiner Kombination (VCCU mit HMLAN und CUL V3) es weiterhin Probleme mit den HM-SEC-SC-2 gibt.
Bei eingeschaltetem aesCommReq wird nur das Öffnen fehlerfrei übertragen, beim schließen wird reproduzierbar:

aesCommToDev fail
trig_aes_vccu fail:40

angezeigt und damit der Statuswechsel nicht aktzeptiert!
Wenn ich Zeit habe, werde ich sniffingdaten liefern.
Welche werden benötigt?
Derzeit ist es so, dass die HM-SEC-SC-2 auf den HMLAN geschaltet sind.
IOgrp  vccu:HMLAN1

Beim Umschalten auf CUL werden in beiden wechseln die o.g. Fehler angezeigt, aber der Statuswechsel akzeptiert?!
Allerdings hatte ich noch nicht die Zeit mal den HMLAN abzustecken.
Möglicherweise stören sich die Geräte in der Kombination.

Welche Logs soll ich senden, zur Analyse?

Greets

Byte
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: noansi am 16 November 2017, 23:18:50
Hallo Byte,

hast Du den letzten Stand TSCUL_fwcode_00_19_FHEM_Modules_00_20.zip getestet? Und hast Du auch die beigefügte 10_CUL_HM benutzt?

Ein HM-SEC-SC-2 ist bei mir im Zulauf. Damit werde ich dann mal testen, wie der sich so verhält.

Wie schaltest Du auf CUL um?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: noansi am 17 November 2017, 21:24:29
Hallo Byte,

wie Du hier https://forum.fhem.de/index.php/topic,79145.msg717324.html#msg717324 (https://forum.fhem.de/index.php/topic,79145.msg717324.html#msg717324) lesen kannst, habe ich mit dem HM-SEC-SC-2 keine Probleme.

Hast Du mal mit dem aktuellesten Stand getestet?

Ansonsten Logs mit verbose 4 beim TSCUL und Rohdaten vom HMLAN.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: klausw am 18 November 2017, 00:39:17
Hi Ansgar,

mir ist gerade die passende 10_CUL_HM.pm zur
00_TSCUL.pm     4 2016-11-05 19:41:39Z noansi
abhanden gekommen.
Da sich das System dummerweise in 400km Entfernung befindet möchte ich nur ungern den nanoCul mit der aktuellen Firmware flashen.
Könntest du die alte Version bitte nochmal online stellen?
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: noansi am 18 November 2017, 02:18:56
Hallo Klaus,

ZitatKönntest du die alte Version bitte nochmal online stellen?
??? Was willst Du mit dem uralten Stand?

Den veralteten Stand von damals findest Du im Anhang.
Allerdings hatte Martin da auch im Anschluss Änderungen von mir übernommen, so dass im Anschluss die normale CUL_HM genutzt werden konnte.

Es macht allerdings wenig Sinn, einen so alten Modulstand mit aktuellem oder fast aktuellem Firmwarestand zu verwenden.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: Bytechanger am 18 November 2017, 16:24:18
Hallo,

also klar, neueste Version und FHEM auch auf dem neuesten Stand. Derzeit scheinen aber nicht alle Fensterkontakte die Probleme zu haben.

hier ein Log das immer Fehlerhaft kam:
2017.11.18 16:19:16.881 4: TSCUL_Parse: CUL0  417936 A F00C 11064576 00 0C 63 A641 5590C0 1DA462 016100 -50.5dB _AEScommReq -50.5
2017.11.18 16:19:17.192 4: TSCUL_Parse: CUL0  418248 A F103 11064676 01 11 63 A002 1DA462 5590C0 04463B1462140A02 _CCAdly:4 _dhmSt:100
2017.11.18 16:19:17.196 4: TSCUL_Parse: CUL0  418248 A F10E 11064832 00 19 63 A203 5590C0 1DA462 9A08832A86E93F4F288C60457885E745 -51.5dB _AESauth -51.5
2017.11.18 16:19:17.197 4: TSCUL_Parse: CUL0  418248 A F101 11064832 00 0C 63 A641 5590C0 1DA462 016100 -50.5dB -50.5
2017.11.18 16:19:17.218 0: HMLAN_Send:  HMLAN1 S:SCFB66330 stat:  00 t:00000000 d:01 r:CFB66330 m:63 8002 1DA462 5590C0 0101C8006F74A7A3
2017.11.18 16:19:17.263 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0100 t:5DE82266 d:FF r:FFC9     m:63 A641 5590C0 1DA462 016100
2017.11.18 16:19:17.292 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0050 t:5DE82266 d:01 r:FFC9     m:63 A641 5590C0 1DA462 016100
2017.11.18 16:19:17.577 4: TSCUL_Parse: CUL0  418633 A F103 11064932 01 0E 63 8002 1DA462 5590C0 006F74A7A3 _CCAdly:4 _dhmSt:100
2017.11.18 16:19:17.578 4: TSCUL_Parse: CUL0  418633 A F101 11065116 00 11 63 8002 1DA462 5590C0 0101C8006F74A7A3 -49.5dB -49.5
2017.11.18 16:19:17.582 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5DE823E4 d:FF r:FFCD     m:63 8002 1DA462 5590C0 006F74A7A3
2017.11.18 16:19:17.586 0: HMLAN_Parse: HMLAN1 R:RCFB66330 stat:0002 t:00000000 d:FF r:7FFF     m:63 8002 1DA462 5590C0 0101C8006F74A7A3
2017.11.18 16:19:20.471 4: TSCUL_Parse: CUL0  421527 A F101 11068008 00 0C 26 8670 20DACE 000000 00424E -95.5dB -95.5
2017.11.18 16:19:20.474 0: HMLAN_Parse: HMLAN1 R:E20DACE   stat:0000 t:5DE82FCE d:FF r:FF9C     m:26 8670 20DACE 000000 00424E
2017.11.18 16:19:29.148 4: TSCUL_Parse: CUL0  430204 A F00C 11076828 00 0C 64 A641 5590C0 1DA462 0162C8 -49.5dB _AEScommReq -49.5
2017.11.18 16:19:29.179 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0100 t:5DE85244 d:FF r:FFC8     m:64 A641 5590C0 1DA462 0162C8
2017.11.18 16:19:29.435 4: TSCUL_Parse: CUL0  430490 A F103 11076928 01 11 64 A002 1DA462 5590C0 0457834C841C8002 _CCAdly:4 _dhmSt:100
2017.11.18 16:19:29.441 4: TSCUL_Parse: CUL0  430490 A F10E 11077084 00 19 64 A203 5590C0 1DA462 2545751B74B2C96D04A4B02CA5C8BA1E -51.5dB _AESauth -51.5
2017.11.18 16:19:29.443 4: TSCUL_Parse: CUL0  430490 A F101 11077084 00 0C 64 A641 5590C0 1DA462 0162C8 -49.5dB -49.5
2017.11.18 16:19:29.470 0: HMLAN_Send:  HMLAN1 S:SCFB69308 stat:  00 t:00000000 d:01 r:CFB69308 m:64 8002 1DA462 5590C0 0101C800E2EEC804
2017.11.18 16:19:29.547 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0050 t:5DE85244 d:01 r:FFC8     m:64 A641 5590C0 1DA462 0162C8
2017.11.18 16:19:29.581 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5DE853C3 d:FF r:FFCD     m:64 8002 1DA462 5590C0 00E2EEC804
2017.11.18 16:19:29.856 4: TSCUL_Parse: CUL0  430912 A F103 11077184 01 0E 64 8002 1DA462 5590C0 00E2EEC804 _CCAdly:4 _dhmSt:100
2017.11.18 16:19:29.857 4: TSCUL_Parse: CUL0  430912 A F101 11077368 00 11 64 8002 1DA462 5590C0 0101C800E2EEC804 -49.5dB -49.5
2017.11.18 16:19:29.860 0: HMLAN_Parse: HMLAN1 R:RCFB69308 stat:0002 t:00000000 d:FF r:7FFF     m:64 8002 1DA462 5590C0 0101C800E2EEC804


Steht derzeit auf
IODev HMLAN1
IOgrp  vccu:HMLAN1

Wenn ich auf CUL0 stelle:
IODev CUL0
IOgrp  vccu:CUL0

folgendes Log:
Hier kommt es nur manchmal zu Fehlern:

2017.11.18 16:23:09.346 0: HMLAN_Parse: HMLAN1 R:E206B03   stat:0000 t:5DEBADFA d:FF r:FF9A     m:3B 8670 206B03 000000 003B4C
2017.11.18 16:23:11.284 4: TSCUL_Parse: CUL0  128050 A F00C 11298856 00 0C 65 A641 5590C0 1DA462 016300 -46dB _AEScommReq -46
2017.11.18 16:23:11.346 4: TSCUL_Parse: CUL0  128050 A F103 11298956 01 11 65 A002 1DA462 5590C0 04204C22C6F09F02 _CCAdly:4 _dhmSt:100
2017.11.18 16:23:11.349 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0100 t:5DEBB5AD d:FF r:FFC9     m:65 A641 5590C0 1DA462 016300
2017.11.18 16:23:11.604 4: TSCUL_Parse: CUL0  128372 A F10E 11299112 00 19 65 A203 5590C0 1DA462 B43F412ADA182106D7A1BC770DB6FB00 -46dB _AESauth -46
2017.11.18 16:23:11.605 4: TSCUL_Parse: CUL0  128372 A F101 11299112 00 0C 65 A641 5590C0 1DA462 016300 -46dB -46
2017.11.18 16:23:11.609 4: TSCUL_send:  CUL0  128377                 As 11 65 8002 1DA462 5590C0 0101C800B70C251D
2017.11.18 16:23:11.655 4: TSCUL_Parse: CUL0  128372 A F103 11299212 01 0E 65 8002 1DA462 5590C0 00B70C251D _CCAdly:4 _dhmSt:100
2017.11.18 16:23:11.656 4: TSCUL_Parse: CUL0  128372 A F10C 11299308 00 0C 66 A641 5590C0 1DA462 0164C8 -53.5dB _AEScommReq -53.5
2017.11.18 16:23:11.685 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0050 t:5DEBB5AD d:01 r:FFC9     m:65 A641 5590C0 1DA462 016300
2017.11.18 16:23:11.717 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5DEBB72D d:FF r:FFCC     m:65 8002 1DA462 5590C0 00B70C251D
2017.11.18 16:23:11.720 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0100 t:5DEBB772 d:FF r:FFBA     m:66 A641 5590C0 1DA462 0164C8
2017.11.18 16:23:12.004 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0040 t:5DEBB772 d:01 r:FFBA     m:66 A641 5590C0 1DA462 0164C8
2017.11.18 16:23:12.008 4: TSCUL_send:  CUL0  128777                 As 0D 66 8002 1DA462 5590C0 0101C800
2017.11.18 16:23:12.076 4: TSCUL_Parse: CUL0  128843 A F101 11299436 00 11 66 A002 1DA462 5590C0 04CD5BFDB3D2EF02 -50dB -50
2017.11.18 16:23:12.082 4: TSCUL_Parse: CUL0  128843 A F101 11299564 00 19 66 A203 5590C0 1DA462 7A72485F7A4C42EA84A1925C0C5D6C81 -52.5dB -52.5
2017.11.18 16:23:12.091 4: TSCUL_Parse: CUL0  128843 A F101 11299684 00 0E 66 8002 1DA462 5590C0 0010CB7DB1 -50dB -50
2017.11.18 16:23:12.351 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5DEBB957 d:FF r:FFCC     m:65 8002 1DA462 5590C0 0101C800B70C251D
2017.11.18 16:23:12.355 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5DEBB9C2 d:FF r:FFCB     m:66 8002 1DA462 5590C0 00
2017.11.18 16:23:12.358 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5DEBBA2C d:FF r:FFCC     m:66 8002 1DA462 5590C0 0101C800
2017.11.18 16:23:12.362 4: TSCUL_Parse: CUL0  129130 A F103 11299764 01 11 65 8002 1DA462 5590C0 0101C800B70C251D _CCAdly:4 _dhmSt:200
2017.11.18 16:23:12.363 4: TSCUL_Parse: CUL0  129130 A F103 11299876 01 0A 66 8002 1DA462 5590C0 00 _CCAdly:4 _dhmSt:312
2017.11.18 16:23:12.363 4: TSCUL_Parse: CUL0  129130 A F103 11299980 01 0D 66 8002 1DA462 5590C0 0101C800 _CCAdly:4 _dhmSt:416
2017.11.18 16:23:16.837 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0100 t:5DEBCB2A d:FF r:FFC6     m:67 A641 5590C0 1DA462 016500
2017.11.18 16:23:16.896 4: TSCUL_Parse: CUL0  133663 A F10C 11304356 00 0C 67 A641 5590C0 1DA462 016500 -52dB _AEScommReq -52
2017.11.18 16:23:16.901 4: TSCUL_Parse: CUL0  133663 A F103 11304456 01 11 67 A002 1DA462 5590C0 042B9982EFB0AD02 _CCAdly:4 _dhmSt:100
2017.11.18 16:23:17.162 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0050 t:5DEBCB2A d:01 r:FFC6     m:67 A641 5590C0 1DA462 016500
2017.11.18 16:23:17.222 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5DEBCCA9 d:FF r:FFCC     m:67 8002 1DA462 5590C0 008A385DB8
2017.11.18 16:23:17.229 4: TSCUL_Parse: CUL0  133997 A F10E 11304612 00 19 67 A203 5590C0 1DA462 AFA2235C38D6C1ED06DD30B13EF4C7CD -51.5dB _AESauth -51.5
2017.11.18 16:23:17.230 4: TSCUL_Parse: CUL0  133997 A F101 11304612 00 0C 67 A641 5590C0 1DA462 016500 -52dB -52
2017.11.18 16:23:17.236 4: TSCUL_send:  CUL0  134004                 As 11 67 8002 1DA462 5590C0 0101C8008A385DB8
2017.11.18 16:23:17.302 4: TSCUL_Parse: CUL0  133997 A F103 11304712 01 0E 67 8002 1DA462 5590C0 008A385DB8 _CCAdly:4 _dhmSt:100
2017.11.18 16:23:17.555 4: TSCUL_Parse: CUL0  134323 A F103 11304960 02 11 67 8002 1DA462 5590C0 0101C8008A385DB8 _CCAdly:8 _dhmSt:348
2017.11.18 16:23:21.355 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0100 t:5DEBDCBF d:FF r:FFC6     m:68 A641 5590C0 1DA462 0166C8
2017.11.18 16:23:21.409 4: TSCUL_Parse: CUL0  138177 A F10C 11308856 00 0C 68 A641 5590C0 1DA462 0166C8 -53.5dB _AEScommReq -53.5
2017.11.18 16:23:21.415 4: TSCUL_Parse: CUL0  138177 A F103 11308956 01 11 68 A002 1DA462 5590C0 04909D7EA97CDB02 _CCAdly:4 _dhmSt:100
2017.11.18 16:23:21.670 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0050 t:5DEBDCBF d:01 r:FFC6     m:68 A641 5590C0 1DA462 0166C8
2017.11.18 16:23:21.702 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5DEBDE3E d:FF r:FFCD     m:68 8002 1DA462 5590C0 0035943477
2017.11.18 16:23:21.706 4: TSCUL_Parse: CUL0  138473 A F10E 11309112 00 19 68 A203 5590C0 1DA462 122A115440595625177E6FEDDD0A2705 -53.5dB _AESauth -53.5
2017.11.18 16:23:21.706 4: TSCUL_Parse: CUL0  138473 A F101 11309112 00 0C 68 A641 5590C0 1DA462 0166C8 -53.5dB -53.5
2017.11.18 16:23:21.709 4: TSCUL_send:  CUL0  138478                 As 11 68 8002 1DA462 5590C0 0101C80035943477
2017.11.18 16:23:21.751 4: TSCUL_Parse: CUL0  138473 A F103 11309212 01 0E 68 8002 1DA462 5590C0 0035943477 _CCAdly:4 _dhmSt:100
2017.11.18 16:23:22.022 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5DEBDF1A d:FF r:FFCD     m:68 8002 1DA462 5590C0 0101C80035943477
2017.11.18 16:23:22.027 4: TSCUL_Parse: CUL0  138794 A F103 11309428 01 11 68 8002 1DA462 5590C0 0101C80035943477 _CCAdly:4 _dhmSt:316
2017.11.18 16:23:24.614 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0100 t:5DEBE971 d:FF r:FFC6     m:69 A641 5590C0 1DA462 016700
2017.11.18 16:23:24.668 4: TSCUL_Parse: CUL0  141435 A F10C 11312104 00 0C 69 A641 5590C0 1DA462 016700 -53.5dB _AEScommReq -53.5
2017.11.18 16:23:24.673 4: TSCUL_Parse: CUL0  141435 A F103 11312204 01 11 69 A002 1DA462 5590C0 04F53AE22F678D02 _CCAdly:4 _dhmSt:100
2017.11.18 16:23:24.678 4: TSCUL_Parse: CUL0  141435 A F10E 11312360 00 19 69 A203 5590C0 1DA462 24D7DA28EA02C055DF6F3A9F38251441 -53.5dB _AESauth -53.5
2017.11.18 16:23:24.679 4: TSCUL_Parse: CUL0  141435 A F101 11312360 00 0C 69 A641 5590C0 1DA462 016700 -53.5dB -53.5
2017.11.18 16:23:24.685 4: TSCUL_send:  CUL0  141453                 As 11 69 8002 1DA462 5590C0 0101C8004D4458C3
2017.11.18 16:23:25.012 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0050 t:5DEBE971 d:01 r:FFC6     m:69 A641 5590C0 1DA462 016700
2017.11.18 16:23:25.044 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5DEBEAEF d:FF r:FFCC     m:69 8002 1DA462 5590C0 004D4458C3
2017.11.18 16:23:25.047 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5DEBEB5D d:FF r:FFCC     m:69 8002 1DA462 5590C0 0101C8004D4458C3
2017.11.18 16:23:25.052 4: TSCUL_Parse: CUL0  141819 A F103 11312460 01 0E 69 8002 1DA462 5590C0 004D4458C3 _CCAdly:4 _dhmSt:100
2017.11.18 16:23:25.053 4: TSCUL_Parse: CUL0  141819 A F103 11312568 01 11 69 8002 1DA462 5590C0 0101C8004D4458C3 _CCAdly:4 _dhmSt:208
2017.11.18 16:23:27.396 4: TSCUL_Parse: CUL0  144163 A F10C 11315108 00 0C 6A A641 5590C0 1DA462 0168C8 -54dB _AEScommReq -54
2017.11.18 16:23:27.703 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0100 t:5DEBF52A d:FF r:FFC6     m:6A A641 5590C0 1DA462 0168C8
2017.11.18 16:23:27.705 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0050 t:5DEBF52A d:01 r:FFC6     m:6A A641 5590C0 1DA462 0168C8
2017.11.18 16:23:27.738 4: TSCUL_Parse: CUL0  144505 A F103 11315208 01 11 6A A002 1DA462 5590C0 04CF67ACF9EE9E02 _CCAdly:4 _dhmSt:100
2017.11.18 16:23:27.766 4: TSCUL_Parse: CUL0  144505 A F10E 11315364 00 19 6A A203 5590C0 1DA462 0AF781E1873E33F2FD053A779496C3DB -53.5dB _AESauth -53.5
2017.11.18 16:23:27.766 4: TSCUL_Parse: CUL0  144506 A F101 11315364 00 0C 6A A641 5590C0 1DA462 0168C8 -54dB -54
2017.11.18 16:23:27.770 4: TSCUL_send:  CUL0  144538                 As 11 6A 8002 1DA462 5590C0 0101C8001F82455E
2017.11.18 16:23:28.065 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5DEBF6AB d:FF r:FFCC     m:6A 8002 1DA462 5590C0 001F82455E
2017.11.18 16:23:28.069 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5DEBF719 d:FF r:FFCC     m:6A 8002 1DA462 5590C0 0101C8001F82455E
2017.11.18 16:23:28.073 4: TSCUL_Parse: CUL0  144841 A F103 11315464 01 0E 6A 8002 1DA462 5590C0 001F82455E _CCAdly:4 _dhmSt:100
2017.11.18 16:23:28.074 4: TSCUL_Parse: CUL0  144841 A F103 11315572 01 11 6A 8002 1DA462 5590C0 0101C8001F82455E _CCAdly:4 _dhmSt:208
2017.11.18 16:23:30.280 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0100 t:5DEBFFEA d:FF r:FFC6     m:6B A641 5590C0 1DA462 016900
2017.11.18 16:23:30.346 4: TSCUL_Parse: CUL0  147113 A F10C 11317856 00 0C 6B A641 5590C0 1DA462 016900 -53.5dB _AEScommReq -53.5
2017.11.18 16:23:30.351 4: TSCUL_Parse: CUL0  147113 A F103 11317956 01 11 6B A002 1DA462 5590C0 04903E5730F3A002 _CCAdly:4 _dhmSt:100
2017.11.18 16:23:30.608 4: TSCUL_Parse: CUL0  147376 A F10E 11318112 00 19 6B A203 5590C0 1DA462 8AFC461320C8F54B1AB7692DF45A9653 -54dB _AESauth -54
2017.11.18 16:23:30.609 4: TSCUL_Parse: CUL0  147376 A F101 11318112 00 0C 6B A641 5590C0 1DA462 016900 -53.5dB -53.5
2017.11.18 16:23:30.612 4: TSCUL_send:  CUL0  147380                 As 11 6B 8002 1DA462 5590C0 0101C80021C128C8
2017.11.18 16:23:30.657 4: TSCUL_Parse: CUL0  147376 A F103 11318212 01 0E 6B 8002 1DA462 5590C0 0021C128C8 _CCAdly:4 _dhmSt:100
2017.11.18 16:23:30.729 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0050 t:5DEBFFEA d:01 r:FFC6     m:6B A641 5590C0 1DA462 016900
2017.11.18 16:23:30.761 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5DEC0167 d:FF r:FFCC     m:6B 8002 1DA462 5590C0 0021C128C8
2017.11.18 16:23:30.765 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5DEC01E2 d:FF r:FFCC     m:6B 8002 1DA462 5590C0 0101C80021C128C8
2017.11.18 16:23:31.023 4: TSCUL_Parse: CUL0  147791 A F103 11318332 01 11 6B 8002 1DA462 5590C0 0101C80021C128C8 _CCAdly:4 _dhmSt:220
2017.11.18 16:23:33.069 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0100 t:5DEC0AA8 d:FF r:FFC4     m:6C A641 5590C0 1DA462 016AC8
2017.11.18 16:23:33.125 4: TSCUL_Parse: CUL0  149892 A F10C 11320608 00 0C 6C A641 5590C0 1DA462 016AC8 -53.5dB _AEScommReq -53.5
2017.11.18 16:23:33.128 4: TSCUL_Parse: CUL0  149892 A F103 11320708 01 11 6C A002 1DA462 5590C0 041D8766C97FAB02 _CCAdly:4 _dhmSt:100
2017.11.18 16:23:33.384 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0050 t:5DEC0AA8 d:01 r:FFC4     m:6C A641 5590C0 1DA462 016AC8
2017.11.18 16:23:33.415 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5DEC0C27 d:FF r:FFCE     m:6C 8002 1DA462 5590C0 00BC83F2A4
2017.11.18 16:23:33.429 4: TSCUL_Parse: CUL0  150197 A F10E 11320864 00 19 6C A203 5590C0 1DA462 043C5586E9B22BE578AB01E6EDDA4210 -53.5dB _AESauth -53.5
2017.11.18 16:23:33.430 4: TSCUL_Parse: CUL0  150197 A F101 11320864 00 0C 6C A641 5590C0 1DA462 016AC8 -53.5dB -53.5
2017.11.18 16:23:33.433 4: TSCUL_send:  CUL0  150202                 As 11 6C 8002 1DA462 5590C0 0101C800BC83F2A4
2017.11.18 16:23:33.475 4: TSCUL_Parse: CUL0  150197 A F103 11320964 01 0E 6C 8002 1DA462 5590C0 00BC83F2A4 _CCAdly:4 _dhmSt:100
2017.11.18 16:23:33.728 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5DEC0CE7 d:FF r:FFCF     m:6C 8002 1DA462 5590C0 0101C800BC83F2A4
2017.11.18 16:23:33.735 4: TSCUL_Parse: CUL0  150502 A F103 11321152 01 11 6C 8002 1DA462 5590C0 0101C800BC83F2A4 _CCAdly:4 _dhmSt:288
2017.11.18 16:23:35.646 4: TSCUL_Parse: CUL0  152414 A F10C 11323356 00 0C 6D A641 5590C0 1DA462 016B00 -54dB _AEScommReq -54
2017.11.18 16:23:35.926 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0100 t:5DEC1566 d:FF r:FFC6     m:6D A641 5590C0 1DA462 016B00
2017.11.18 16:23:35.928 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0050 t:5DEC1566 d:01 r:FFC6     m:6D A641 5590C0 1DA462 016B00
2017.11.18 16:23:35.960 4: TSCUL_Parse: CUL0  152727 A F103 11323456 01 11 6D A002 1DA462 5590C0 04F833A800297B02 _CCAdly:4 _dhmSt:100
2017.11.18 16:23:35.987 4: TSCUL_Parse: CUL0  152727 A F10E 11323612 00 19 6D A203 5590C0 1DA462 9DD5E27EE74DA2EA75C7E985A0B206E2 -54.5dB _AESauth -54.5
2017.11.18 16:23:35.988 4: TSCUL_Parse: CUL0  152727 A F101 11323612 00 0C 6D A641 5590C0 1DA462 016B00 -54dB -54
2017.11.18 16:23:35.991 4: TSCUL_send:  CUL0  152760                 As 11 6D 8002 1DA462 5590C0 0101C8001778E548
2017.11.18 16:23:36.289 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5DEC16E4 d:FF r:FFCD     m:6D 8002 1DA462 5590C0 001778E548
2017.11.18 16:23:36.292 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5DEC1752 d:FF r:FFCC     m:6D 8002 1DA462 5590C0 0101C8001778E548
2017.11.18 16:23:36.298 4: TSCUL_Parse: CUL0  153065 A F103 11323712 01 0E 6D 8002 1DA462 5590C0 001778E548 _CCAdly:4 _dhmSt:100
2017.11.18 16:23:36.299 4: TSCUL_Parse: CUL0  153065 A F103 11323820 01 11 6D 8002 1DA462 5590C0 0101C8001778E548 _CCAdly:4 _dhmSt:208
2017.11.18 16:23:38.039 0: HMLAN_Parse: HMLAN1 R:E17E2BB   stat:0000 t:5DEC1E99 d:FF r:FF9A     m:2F A002 17E2BB 1C5801 04ADB35145392D02
2017.11.18 16:23:38.092 4: TSCUL_Parse: CUL0  154860 A F101 11325712 00 11 2F A002 17E2BB 1C5801 04ADB35145392D02 -95dB -95
2017.11.18 16:23:38.346 0: HMLAN_Parse: HMLAN1 R:E17E2BB   stat:0000 t:5DEC1F9B d:FF r:FF98     m:2F 8002 17E2BB 1C5801 00D05E9941
2017.11.18 16:23:38.348 4: TSCUL_Parse: CUL0  155116 A F101 11325968 00 0E 2F 8002 17E2BB 1C5801 00D05E9941 -95.5dB -95.5
2017.11.18 16:23:38.601 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0100 t:5DEC2026 d:FF r:FFC3     m:6E A641 5590C0 1DA462 016CC8
2017.11.18 16:23:38.629 4: TSCUL_Parse: CUL0  155397 A F10C 11326108 00 0C 6E A641 5590C0 1DA462 016CC8 -53.5dB _AEScommReq -53.5
2017.11.18 16:23:38.632 4: TSCUL_Parse: CUL0  155397 A F103 11326208 01 11 6E A002 1DA462 5590C0 04CCE230CE767202 _CCAdly:4 _dhmSt:100
2017.11.18 16:23:38.887 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0050 t:5DEC2026 d:01 r:FFC3     m:6E A641 5590C0 1DA462 016CC8
2017.11.18 16:23:38.946 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5DEC21A4 d:FF r:FFCD     m:6E 8002 1DA462 5590C0 009CFE9A5D
2017.11.18 16:23:38.953 4: TSCUL_Parse: CUL0  155720 A F10E 11326364 00 19 6E A203 5590C0 1DA462 F587CA368346588B33D1FC3C0482FAE4 -53.5dB _AESauth -53.5
2017.11.18 16:23:38.954 4: TSCUL_Parse: CUL0  155720 A F101 11326364 00 0C 6E A641 5590C0 1DA462 016CC8 -53.5dB -53.5
2017.11.18 16:23:38.959 4: TSCUL_send:  CUL0  155728                 As 11 6E 8002 1DA462 5590C0 0101C8009CFE9A5D
2017.11.18 16:23:39.016 4: TSCUL_Parse: CUL0  155720 A F103 11326464 01 0E 6E 8002 1DA462 5590C0 009CFE9A5D _CCAdly:4 _dhmSt:100
2017.11.18 16:23:39.270 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5DEC2280 d:FF r:FFCD     m:6E 8002 1DA462 5590C0 0101C8009CFE9A5D
2017.11.18 16:23:39.276 4: TSCUL_Parse: CUL0  156044 A F103 11326680 01 11 6E 8002 1DA462 5590C0 0101C8009CFE9A5D _CCAdly:4 _dhmSt:316
2017.11.18 16:23:41.396 4: TSCUL_Parse: CUL0  158163 A F10C 11329108 00 0C 6F A641 5590C0 1DA462 016D00 -54dB _AEScommReq -54
2017.11.18 16:23:41.701 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0100 t:5DEC2BDE d:FF r:FFC4     m:6F A641 5590C0 1DA462 016D00
2017.11.18 16:23:41.704 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0050 t:5DEC2BDE d:01 r:FFC4     m:6F A641 5590C0 1DA462 016D00
2017.11.18 16:23:41.768 4: TSCUL_Parse: CUL0  158535 A F103 11329208 01 11 6F A002 1DA462 5590C0 04D3BB65553D4902 _CCAdly:4 _dhmSt:100
2017.11.18 16:23:41.819 4: TSCUL_Parse: CUL0  158535 A F10E 11329364 00 19 6F A203 5590C0 1DA462 823F072FD155850779DCD35E17CBF36E -54.5dB _AESauth -54.5
2017.11.18 16:23:41.820 4: TSCUL_Parse: CUL0  158535 A F101 11329364 00 0C 6F A641 5590C0 1DA462 016D00 -54dB -54
2017.11.18 16:23:41.823 4: TSCUL_send:  CUL0  158592                 As 11 6F 8002 1DA462 5590C0 0101C8004DD6BA8F
2017.11.18 16:23:42.121 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5DEC2D5D d:FF r:FFCD     m:6F 8002 1DA462 5590C0 004DD6BA8F
2017.11.18 16:23:42.127 4: TSCUL_Parse: CUL0  158895 A F103 11329464 01 0E 6F 8002 1DA462 5590C0 004DD6BA8F _CCAdly:4 _dhmSt:100
2017.11.18 16:23:42.128 4: TSCUL_Parse: CUL0  158895 A F103 11329572 01 11 6F 8002 1DA462 5590C0 0101C8004DD6BA8F _CCAdly:4 _dhmSt:208
2017.11.18 16:23:44.207 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0100 t:5DEC369D d:FF r:FFC3     m:70 A641 5590C0 1DA462 016EC8
2017.11.18 16:23:44.260 4: TSCUL_Parse: CUL0  161027 A F10C 11331856 00 0C 70 A641 5590C0 1DA462 016EC8 -53.5dB _AEScommReq -53.5
2017.11.18 16:23:44.516 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0050 t:5DEC369D d:01 r:FFC3     m:70 A641 5590C0 1DA462 016EC8
2017.11.18 16:23:44.577 4: TSCUL_Parse: CUL0  161344 A F103 11331956 01 11 70 A002 1DA462 5590C0 044B26A0B3E14C02 _CCAdly:4 _dhmSt:100
2017.11.18 16:23:44.629 4: TSCUL_Parse: CUL0  161344 A F10E 11332112 00 19 70 A203 5590C0 1DA462 9DB599667DF173E2009E36A94A3952FD -53dB _AESauth -53
2017.11.18 16:23:44.630 4: TSCUL_Parse: CUL0  161344 A F101 11332112 00 0C 70 A641 5590C0 1DA462 016EC8 -53.5dB -53.5
2017.11.18 16:23:44.634 4: TSCUL_send:  CUL0  161403                 As 11 70 8002 1DA462 5590C0 0101C800FA2CE4B1
2017.11.18 16:23:44.676 4: TSCUL_Parse: CUL0  161344 A F103 11332212 01 0E 70 8002 1DA462 5590C0 00FA2CE4B1 _CCAdly:4 _dhmSt:100
2017.11.18 16:23:44.928 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5DEC381A d:FF r:FFCE     m:70 8002 1DA462 5590C0 00FA2CE4B1
2017.11.18 16:23:44.932 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5DEC38AC d:FF r:FFCD     m:70 8002 1DA462 5590C0 0101C800FA2CE4B1
2017.11.18 16:23:44.938 4: TSCUL_Parse: CUL0  161705 A F103 11332356 02 11 70 8002 1DA462 5590C0 0101C800FA2CE4B1 _CCAdly:8 _dhmSt:244

2017.11.18 16:24:42.151 4: TSCUL_Parse: CUL0  218919 A F10C 11389864 00 0C 71 A641 5590C0 1DA462 016F00 -54.5dB _AEScommReq -54.5
2017.11.18 16:24:42.435 4: TSCUL_Parse: CUL0  219203 A F103 11389964 01 11 71 A002 1DA462 5590C0 04E360A1F36CD502 _CCAdly:4 _dhmSt:100
2017.11.18 16:24:42.439 4: TSCUL_Parse: CUL0  219203 A F10E 11390120 00 19 71 A203 5590C0 1DA462 0FCB6251EAC1215A3ECD59E3F00829C5 -54dB _AESauth -54
2017.11.18 16:24:42.440 4: TSCUL_Parse: CUL0  219203 A F101 11390120 00 0C 71 A641 5590C0 1DA462 016F00 -54.5dB -54.5
2017.11.18 16:24:42.445 4: TSCUL_send:  CUL0  219213                 As 11 71 8002 1DA462 5590C0 0101C800806AB1C0
2017.11.18 16:24:42.494 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0100 t:5DED193B d:FF r:FFC5     m:71 A641 5590C0 1DA462 016F00
2017.11.18 16:24:42.525 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0050 t:5DED193B d:01 r:FFC5     m:71 A641 5590C0 1DA462 016F00
2017.11.18 16:24:42.815 4: TSCUL_Parse: CUL0  219582 A F103 11390220 01 0E 71 8002 1DA462 5590C0 00806AB1C0 _CCAdly:4 _dhmSt:100
2017.11.18 16:24:42.817 4: TSCUL_Parse: CUL0  219582 A F103 11390328 01 11 71 8002 1DA462 5590C0 0101C800806AB1C0 _CCAdly:4 _dhmSt:208
2017.11.18 16:24:42.819 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5DED1AB9 d:FF r:FFCC     m:71 8002 1DA462 5590C0 00806AB1C0
2017.11.18 16:24:42.828 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5DED1B27 d:FF r:FFCD     m:71 8002 1DA462 5590C0 0101C800806AB1C0
2017.11.18 16:24:51.258 4: TSCUL_Parse: CUL0  228025 A F10C 11398868 00 0C 72 A641 5590C0 1DA462 0170C8 -56.5dB _AEScommReq -56.5
2017.11.18 16:24:51.313 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0100 t:5DED3C65 d:FF r:FFC3     m:72 A641 5590C0 1DA462 0170C8
2017.11.18 16:24:51.569 4: TSCUL_Parse: CUL0  228337 A F103 11398968 01 11 72 A002 1DA462 5590C0 04AB45673C019702 _CCAdly:4 _dhmSt:100
2017.11.18 16:24:51.572 4: TSCUL_Parse: CUL0  228337 A F10E 11399124 00 19 72 A203 5590C0 1DA462 FB3EA3374D997BC25986F19398F5DF70 -57dB _AESauth -57
2017.11.18 16:24:51.573 4: TSCUL_Parse: CUL0  228337 A F101 11399124 00 0C 72 A641 5590C0 1DA462 0170C8 -56.5dB -56.5
2017.11.18 16:24:51.576 4: TSCUL_send:  CUL0  228344                 As 11 72 8002 1DA462 5590C0 0101C8002A3A401F
2017.11.18 16:24:51.618 4: TSCUL_Parse: CUL0  228337 A F103 11399224 01 0E 72 8002 1DA462 5590C0 002A3A401F _CCAdly:4 _dhmSt:100
2017.11.18 16:24:51.619 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0050 t:5DED3C65 d:01 r:FFC3     m:72 A641 5590C0 1DA462 0170C8
2017.11.18 16:24:51.651 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5DED3DE6 d:FF r:FFCC     m:72 8002 1DA462 5590C0 002A3A401F
2017.11.18 16:24:51.907 4: TSCUL_Parse: CUL0  228674 A F103 11399332 01 11 72 8002 1DA462 5590C0 0101C8002A3A401F _CCAdly:4 _dhmSt:208
2017.11.18 16:24:51.907 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5DED3E54 d:FF r:FFCD     m:72 8002 1DA462 5590C0 0101C8002A3A401F
2017.11.18 16:24:55.478 4: TSCUL_Parse: CUL0  232245 A F10C 11403116 00 0C 73 A641 5590C0 1DA462 017100 -54.5dB _AEScommReq -54.5
2017.11.18 16:24:55.532 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0100 t:5DED4D00 d:FF r:FFC7     m:73 A641 5590C0 1DA462 017100
2017.11.18 16:24:55.788 4: TSCUL_Parse: CUL0  232556 A F103 11403216 01 11 73 A002 1DA462 5590C0 04B8B955BDAA0902 _CCAdly:4 _dhmSt:100
2017.11.18 16:24:55.791 4: TSCUL_Parse: CUL0  232556 A F10C 11403360 00 0C 73 A241 5590C0 1DA462 017100 -54.5dB _AEScommReq -54.5
2017.11.18 16:24:55.794 4: TSCUL_Parse: CUL0  232556 A F103 11403460 01 11 73 A002 1DA462 5590C0 04B8B955BDAA0902 _CCAdly:4 _dhmSt:100
2017.11.18 16:24:55.798 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0050 t:5DED4D00 d:01 r:FFC7     m:73 A641 5590C0 1DA462 017100
2017.11.18 16:24:56.094 3: LogHist CUL0:  219203 A F10E 11390120 00 19 71 A203 5590C0 1DA462 0FCB6251EAC1215A3ECD59E3F00829C5 -54dB _AESauth
2017.11.18 16:24:56.095 3: LogHist CUL0:  219203 A F101 11390120 00 0C 71 A641 5590C0 1DA462 016F00 -54.5dB
2017.11.18 16:24:56.095 3: LogHist CUL0:  219213                 As 11 71 8002 1DA462 5590C0 0101C800806AB1C0
2017.11.18 16:24:56.095 3: LogHist CUL0:  219582 A F103 11390220 01 0E 71 8002 1DA462 5590C0 00806AB1C0 _CCAdly:4 _dhmSt:100
2017.11.18 16:24:56.095 3: LogHist CUL0:  219582 A F103 11390328 01 11 71 8002 1DA462 5590C0 0101C800806AB1C0 _CCAdly:4 _dhmSt:208
2017.11.18 16:24:56.095 3: LogHist CUL0:  228025 A F10C 11398868 00 0C 72 A641 5590C0 1DA462 0170C8 -56.5dB _AEScommReq
2017.11.18 16:24:56.095 3: LogHist CUL0:  228337 A F103 11398968 01 11 72 A002 1DA462 5590C0 04AB45673C019702 _CCAdly:4 _dhmSt:100
2017.11.18 16:24:56.095 3: LogHist CUL0:  228337 A F10E 11399124 00 19 72 A203 5590C0 1DA462 FB3EA3374D997BC25986F19398F5DF70 -57dB _AESauth
2017.11.18 16:24:56.095 3: LogHist CUL0:  228337 A F101 11399124 00 0C 72 A641 5590C0 1DA462 0170C8 -56.5dB
2017.11.18 16:24:56.096 3: LogHist CUL0:  228344                 As 11 72 8002 1DA462 5590C0 0101C8002A3A401F
2017.11.18 16:24:56.096 3: LogHist CUL0:  228337 A F103 11399224 01 0E 72 8002 1DA462 5590C0 002A3A401F _CCAdly:4 _dhmSt:100
2017.11.18 16:24:56.096 3: LogHist CUL0:  228674 A F103 11399332 01 11 72 8002 1DA462 5590C0 0101C8002A3A401F _CCAdly:4 _dhmSt:208
2017.11.18 16:24:56.096 3: LogHist CUL0:  232245 A F10C 11403116 00 0C 73 A641 5590C0 1DA462 017100 -54.5dB _AEScommReq
2017.11.18 16:24:56.096 3: LogHist CUL0:  232556 A F103 11403216 01 11 73 A002 1DA462 5590C0 04B8B955BDAA0902 _CCAdly:4 _dhmSt:100
2017.11.18 16:24:56.096 3: LogHist CUL0:  232556 A F10C 11403360 00 0C 73 A241 5590C0 1DA462 017100 -54.5dB _AEScommReq
2017.11.18 16:24:56.096 3: LogHist CUL0:  232556 A F103 11403460 01 11 73 A002 1DA462 5590C0 04B8B955BDAA0902 _CCAdly:4 _dhmSt:100
2017.11.18 16:24:56.096 3: TSCUL_ParseTsHM: CUL0 HM repeat failed to 5590C0/HWR_Wasser:  232862 A F109 11403732 00 11 73 A002 1DA462 5590C0 04B8B955BDAA0902 _sfail _noAnsw
2017.11.18 16:24:56.097 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0050 t:5DED4DF4 d:01 r:FFC8     m:73 A241 5590C0 1DA462 017100
2017.11.18 16:24:56.458 4: TSCUL_Parse: CUL0  233225 A F10C 11403848 00 0C 73 A241 5590C0 1DA462 017100 -55dB _AEScommReq -55
2017.11.18 16:24:56.512 4: TSCUL_Parse: CUL0  233225 A F103 11403948 01 11 73 A002 1DA462 5590C0 04D70C3ADF3DAD02 _CCAdly:4 _dhmSt:100
2017.11.18 16:24:56.516 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0100 t:5DED4FDB d:FF r:FFC7     m:73 A241 5590C0 1DA462 017100
2017.11.18 16:24:56.520 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0050 t:5DED4FDB d:01 r:FFC7     m:73 A241 5590C0 1DA462 017100
2017.11.18 16:24:56.829 3: LogHist CUL0:  219582 A F103 11390220 01 0E 71 8002 1DA462 5590C0 00806AB1C0 _CCAdly:4 _dhmSt:100
2017.11.18 16:24:56.830 3: LogHist CUL0:  219582 A F103 11390328 01 11 71 8002 1DA462 5590C0 0101C800806AB1C0 _CCAdly:4 _dhmSt:208
2017.11.18 16:24:56.830 3: LogHist CUL0:  228025 A F10C 11398868 00 0C 72 A641 5590C0 1DA462 0170C8 -56.5dB _AEScommReq
2017.11.18 16:24:56.830 3: LogHist CUL0:  228337 A F103 11398968 01 11 72 A002 1DA462 5590C0 04AB45673C019702 _CCAdly:4 _dhmSt:100
2017.11.18 16:24:56.830 3: LogHist CUL0:  228337 A F10E 11399124 00 19 72 A203 5590C0 1DA462 FB3EA3374D997BC25986F19398F5DF70 -57dB _AESauth
2017.11.18 16:24:56.830 3: LogHist CUL0:  228337 A F101 11399124 00 0C 72 A641 5590C0 1DA462 0170C8 -56.5dB
2017.11.18 16:24:56.830 3: LogHist CUL0:  228344                 As 11 72 8002 1DA462 5590C0 0101C8002A3A401F
2017.11.18 16:24:56.830 3: LogHist CUL0:  228337 A F103 11399224 01 0E 72 8002 1DA462 5590C0 002A3A401F _CCAdly:4 _dhmSt:100
2017.11.18 16:24:56.830 3: LogHist CUL0:  228674 A F103 11399332 01 11 72 8002 1DA462 5590C0 0101C8002A3A401F _CCAdly:4 _dhmSt:208
2017.11.18 16:24:56.831 3: LogHist CUL0:  232245 A F10C 11403116 00 0C 73 A641 5590C0 1DA462 017100 -54.5dB _AEScommReq
2017.11.18 16:24:56.831 3: LogHist CUL0:  232556 A F103 11403216 01 11 73 A002 1DA462 5590C0 04B8B955BDAA0902 _CCAdly:4 _dhmSt:100
2017.11.18 16:24:56.831 3: LogHist CUL0:  232556 A F10C 11403360 00 0C 73 A241 5590C0 1DA462 017100 -54.5dB _AEScommReq
2017.11.18 16:24:56.831 3: LogHist CUL0:  232556 A F103 11403460 01 11 73 A002 1DA462 5590C0 04B8B955BDAA0902 _CCAdly:4 _dhmSt:100
2017.11.18 16:24:56.831 3: LogHist CUL0:  232862 A F109 11403732 00 11 73 A002 1DA462 5590C0 04B8B955BDAA0902 _sfail _noAnsw
2017.11.18 16:24:56.831 3: LogHist CUL0:  233225 A F10C 11403848 00 0C 73 A241 5590C0 1DA462 017100 -55dB _AEScommReq
2017.11.18 16:24:56.831 3: LogHist CUL0:  233225 A F103 11403948 01 11 73 A002 1DA462 5590C0 04D70C3ADF3DAD02 _CCAdly:4 _dhmSt:100
2017.11.18 16:24:56.831 3: TSCUL_ParseTsHM: CUL0 HM repeat failed to 5590C0/HWR_Wasser:  233597 A F109 11404220 00 11 73 A002 1DA462 5590C0 04D70C3ADF3DAD02 _sfail _noAnsw
2017.11.18 16:24:57.108 4: TSCUL_Parse: CUL0  233875 A F10C 11404824 00 0C 73 A241 5590C0 1DA462 017100 -55dB _AEScommReq -55
2017.11.18 16:24:57.389 4: TSCUL_Parse: CUL0  234156 A F103 11404924 01 11 73 A002 1DA462 5590C0 049CB715D9A82302 _CCAdly:4 _dhmSt:100
2017.11.18 16:24:57.394 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0100 t:5DED53AA d:FF r:FFC8     m:73 A241 5590C0 1DA462 017100
2017.11.18 16:24:57.651 3: LogHist CUL0:  228337 A F103 11398968 01 11 72 A002 1DA462 5590C0 04AB45673C019702 _CCAdly:4 _dhmSt:100
2017.11.18 16:24:57.651 3: LogHist CUL0:  228337 A F10E 11399124 00 19 72 A203 5590C0 1DA462 FB3EA3374D997BC25986F19398F5DF70 -57dB _AESauth
2017.11.18 16:24:57.651 3: LogHist CUL0:  228337 A F101 11399124 00 0C 72 A641 5590C0 1DA462 0170C8 -56.5dB
2017.11.18 16:24:57.652 3: LogHist CUL0:  228344                 As 11 72 8002 1DA462 5590C0 0101C8002A3A401F
2017.11.18 16:24:57.652 3: LogHist CUL0:  228337 A F103 11399224 01 0E 72 8002 1DA462 5590C0 002A3A401F _CCAdly:4 _dhmSt:100
2017.11.18 16:24:57.652 3: LogHist CUL0:  228674 A F103 11399332 01 11 72 8002 1DA462 5590C0 0101C8002A3A401F _CCAdly:4 _dhmSt:208
2017.11.18 16:24:57.652 3: LogHist CUL0:  232245 A F10C 11403116 00 0C 73 A641 5590C0 1DA462 017100 -54.5dB _AEScommReq
2017.11.18 16:24:57.652 3: LogHist CUL0:  232556 A F103 11403216 01 11 73 A002 1DA462 5590C0 04B8B955BDAA0902 _CCAdly:4 _dhmSt:100
2017.11.18 16:24:57.653 3: LogHist CUL0:  232556 A F10C 11403360 00 0C 73 A241 5590C0 1DA462 017100 -54.5dB _AEScommReq
2017.11.18 16:24:57.653 3: LogHist CUL0:  232556 A F103 11403460 01 11 73 A002 1DA462 5590C0 04B8B955BDAA0902 _CCAdly:4 _dhmSt:100
2017.11.18 16:24:57.653 3: LogHist CUL0:  232862 A F109 11403732 00 11 73 A002 1DA462 5590C0 04B8B955BDAA0902 _sfail _noAnsw
2017.11.18 16:24:57.653 3: LogHist CUL0:  233225 A F10C 11403848 00 0C 73 A241 5590C0 1DA462 017100 -55dB _AEScommReq
2017.11.18 16:24:57.653 3: LogHist CUL0:  233225 A F103 11403948 01 11 73 A002 1DA462 5590C0 04D70C3ADF3DAD02 _CCAdly:4 _dhmSt:100
2017.11.18 16:24:57.654 3: LogHist CUL0:  233597 A F109 11404220 00 11 73 A002 1DA462 5590C0 04D70C3ADF3DAD02 _sfail _noAnsw
2017.11.18 16:24:57.654 3: LogHist CUL0:  233875 A F10C 11404824 00 0C 73 A241 5590C0 1DA462 017100 -55dB _AEScommReq
2017.11.18 16:24:57.654 3: LogHist CUL0:  234156 A F103 11404924 01 11 73 A002 1DA462 5590C0 049CB715D9A82302 _CCAdly:4 _dhmSt:100
2017.11.18 16:24:57.654 3: TSCUL_ParseTsHM: CUL0 HM repeat failed to 5590C0/HWR_Wasser:  234419 A F109 11405196 00 11 73 A002 1DA462 5590C0 049CB715D9A82302 _sfail _noAnsw
2017.11.18 16:24:57.655 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0050 t:5DED53AA d:01 r:FFC8     m:73 A241 5590C0 1DA462 017100
2017.11.18 16:24:59.258 4: TSCUL_Parse: CUL0  236025 A F10C 11406772 00 0C 73 A241 5590C0 1DA462 017100 -55.5dB _AEScommReq -55.5
2017.11.18 16:24:59.312 4: TSCUL_Parse: CUL0  236025 A F103 11406872 01 11 73 A002 1DA462 5590C0 0456F7A5D7F3E602 _CCAdly:4 _dhmSt:100
2017.11.18 16:24:59.317 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0100 t:5DED5B47 d:FF r:FFC6     m:73 A241 5590C0 1DA462 017100
2017.11.18 16:24:59.574 3: LogHist CUL0:  228344                 As 11 72 8002 1DA462 5590C0 0101C8002A3A401F
2017.11.18 16:24:59.574 3: LogHist CUL0:  228337 A F103 11399224 01 0E 72 8002 1DA462 5590C0 002A3A401F _CCAdly:4 _dhmSt:100
2017.11.18 16:24:59.574 3: LogHist CUL0:  228674 A F103 11399332 01 11 72 8002 1DA462 5590C0 0101C8002A3A401F _CCAdly:4 _dhmSt:208
2017.11.18 16:24:59.575 3: LogHist CUL0:  232245 A F10C 11403116 00 0C 73 A641 5590C0 1DA462 017100 -54.5dB _AEScommReq
2017.11.18 16:24:59.575 3: LogHist CUL0:  232556 A F103 11403216 01 11 73 A002 1DA462 5590C0 04B8B955BDAA0902 _CCAdly:4 _dhmSt:100
2017.11.18 16:24:59.575 3: LogHist CUL0:  232556 A F10C 11403360 00 0C 73 A241 5590C0 1DA462 017100 -54.5dB _AEScommReq
2017.11.18 16:24:59.575 3: LogHist CUL0:  232556 A F103 11403460 01 11 73 A002 1DA462 5590C0 04B8B955BDAA0902 _CCAdly:4 _dhmSt:100
2017.11.18 16:24:59.575 3: LogHist CUL0:  232862 A F109 11403732 00 11 73 A002 1DA462 5590C0 04B8B955BDAA0902 _sfail _noAnsw
2017.11.18 16:24:59.576 3: LogHist CUL0:  233225 A F10C 11403848 00 0C 73 A241 5590C0 1DA462 017100 -55dB _AEScommReq
2017.11.18 16:24:59.576 3: LogHist CUL0:  233225 A F103 11403948 01 11 73 A002 1DA462 5590C0 04D70C3ADF3DAD02 _CCAdly:4 _dhmSt:100
2017.11.18 16:24:59.576 3: LogHist CUL0:  233597 A F109 11404220 00 11 73 A002 1DA462 5590C0 04D70C3ADF3DAD02 _sfail _noAnsw
2017.11.18 16:24:59.576 3: LogHist CUL0:  233875 A F10C 11404824 00 0C 73 A241 5590C0 1DA462 017100 -55dB _AEScommReq
2017.11.18 16:24:59.577 3: LogHist CUL0:  234156 A F103 11404924 01 11 73 A002 1DA462 5590C0 049CB715D9A82302 _CCAdly:4 _dhmSt:100
2017.11.18 16:24:59.577 3: LogHist CUL0:  234419 A F109 11405196 00 11 73 A002 1DA462 5590C0 049CB715D9A82302 _sfail _noAnsw
2017.11.18 16:24:59.577 3: LogHist CUL0:  236025 A F10C 11406772 00 0C 73 A241 5590C0 1DA462 017100 -55.5dB _AEScommReq
2017.11.18 16:24:59.577 3: LogHist CUL0:  236025 A F103 11406872 01 11 73 A002 1DA462 5590C0 0456F7A5D7F3E602 _CCAdly:4 _dhmSt:100
2017.11.18 16:24:59.578 3: TSCUL_ParseTsHM: CUL0 HM repeat failed to 5590C0/HWR_Wasser:  236341 A F109 11407144 00 11 73 A002 1DA462 5590C0 0456F7A5D7F3E602 _sfail _noAnsw
2017.11.18 16:24:59.579 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0050 t:5DED5B47 d:01 r:FFC6     m:73 A241 5590C0 1DA462 017100
2017.11.18 16:25:02.955 4: TSCUL_Parse: CUL0  239722 A F10C 11410668 00 0C 73 A241 5590C0 1DA462 017100 -54.5dB _AEScommReq -54.5
2017.11.18 16:25:03.236 4: TSCUL_Parse: CUL0  240004 A F103 11410768 01 11 73 A002 1DA462 5590C0 04398D0C87728A02 _CCAdly:4 _dhmSt:100
2017.11.18 16:25:03.239 4: TSCUL_Parse: CUL0  240004 A F10E 11410924 00 19 73 A203 5590C0 1DA462 031ABD10B082652343FB4C0C079B2A2E -55dB _AESauth -55
2017.11.18 16:25:03.240 4: TSCUL_Parse: CUL0  240004 A F101 11410924 00 0C 73 A241 5590C0 1DA462 017100 -54.5dB -54.5
2017.11.18 16:25:03.243 4: TSCUL_send:  CUL0  240012                 As 11 73 8002 1DA462 5590C0 0101C800B82C9D83
2017.11.18 16:25:03.288 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0100 t:5DED6A82 d:FF r:FFC4     m:73 A241 5590C0 1DA462 017100
2017.11.18 16:25:03.316 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0050 t:5DED6A82 d:01 r:FFC4     m:73 A241 5590C0 1DA462 017100
2017.11.18 16:25:03.602 4: TSCUL_Parse: CUL0  240368 A F103 11411024 01 0E 73 8002 1DA462 5590C0 00B82C9D83 _CCAdly:4 _dhmSt:100
2017.11.18 16:25:03.603 4: TSCUL_Parse: CUL0  240368 A F10C 11411120 00 0C 74 A641 5590C0 1DA462 0172C8 -54dB _AEScommReq -54
2017.11.18 16:25:03.657 4: TSCUL_Parse: CUL0  240368 A F101 11411248 00 11 74 A002 1DA462 5590C0 043EA80E40211C02 -50dB -50
2017.11.18 16:25:03.661 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5DED6BFF d:FF r:FFCC     m:73 8002 1DA462 5590C0 00B82C9D83
2017.11.18 16:25:03.667 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0100 t:5DED6C45 d:FF r:FFC6     m:74 A641 5590C0 1DA462 0172C8
2017.11.18 16:25:03.671 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5DED6D32 d:FF r:FFCC     m:73 8002 1DA462 5590C0 0101C800B82C9D83
2017.11.18 16:25:03.934 4: TSCUL_Parse: CUL0  240702 A F103 11411328 01 11 73 8002 1DA462 5590C0 0101C800B82C9D83 _CCAdly:4 _dhmSt:208
2017.11.18 16:25:03.935 4: TSCUL_Parse: CUL0  240702 A F10C 11411608 00 0C 74 A241 5590C0 1DA462 0172C8 -54.5dB _AEScommReq -54.5
2017.11.18 16:25:03.941 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0050 t:5DED6C45 d:01 r:FFC6     m:74 A641 5590C0 1DA462 0172C8
2017.11.18 16:25:04.004 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0100 t:5DED6E2D d:FF r:FFC6     m:74 A241 5590C0 1DA462 0172C8
2017.11.18 16:25:04.313 4: TSCUL_Parse: CUL0  241081 A F103 11411708 01 11 74 A002 1DA462 5590C0 045362342365CC02 _CCAdly:4 _dhmSt:100
2017.11.18 16:25:04.316 4: TSCUL_Parse: CUL0  241081 A F10E 11411864 00 19 74 A203 5590C0 1DA462 01BDCF6C359F684C78C2F4C6891EE980 -54.5dB _AESauth -54.5
2017.11.18 16:25:04.316 4: TSCUL_Parse: CUL0  241081 A F101 11411864 00 0C 74 A241 5590C0 1DA462 0172C8 -54.5dB -54.5
2017.11.18 16:25:04.320 4: TSCUL_send:  CUL0  241088                 As 11 74 8002 1DA462 5590C0 0101C80057E3FF33
2017.11.18 16:25:04.362 4: TSCUL_Parse: CUL0  241081 A F103 11411964 01 0E 74 8002 1DA462 5590C0 0057E3FF33 _CCAdly:4 _dhmSt:100
2017.11.18 16:25:04.363 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0050 t:5DED6E2D d:01 r:FFC6     m:74 A241 5590C0 1DA462 0172C8
2017.11.18 16:25:04.394 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5DED6FAB d:FF r:FFCC     m:74 8002 1DA462 5590C0 0057E3FF33
2017.11.18 16:25:04.650 4: TSCUL_Parse: CUL0  241417 A F103 11412072 01 11 74 8002 1DA462 5590C0 0101C80057E3FF33 _CCAdly:4 _dhmSt:208
2017.11.18 16:25:04.651 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5DED701A d:FF r:FFCC     m:74 8002 1DA462 5590C0 0101C80057E3FF33
2017.11.18 16:25:07.905 4: TSCUL_Parse: CUL0  244672 A F10C 11415620 00 0C 75 A641 5590C0 1DA462 017300 -53.5dB _AEScommReq -53.5
2017.11.18 16:25:08.212 4: TSCUL_Parse: CUL0  244980 A F103 11415720 01 11 75 A002 1DA462 5590C0 0430C2A794F16902 _CCAdly:4 _dhmSt:100
2017.11.18 16:25:08.215 4: TSCUL_Parse: CUL0  244980 A F10C 11415864 00 0C 75 A241 5590C0 1DA462 017300 -53.5dB _AEScommReq -53.5
2017.11.18 16:25:08.218 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0100 t:5DED7DD7 d:FF r:FFC8     m:75 A641 5590C0 1DA462 017300
2017.11.18 16:25:08.220 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0050 t:5DED7DD7 d:01 r:FFC8     m:75 A641 5590C0 1DA462 017300
2017.11.18 16:25:08.504 4: TSCUL_Parse: CUL0  245272 A F103 11415964 01 11 75 A002 1DA462 5590C0 0430C2A794F16902 _CCAdly:4 _dhmSt:100
2017.11.18 16:25:08.532 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0050 t:5DED7ECB d:01 r:FFC9     m:75 A241 5590C0 1DA462 017300
2017.11.18 16:25:08.813 3: LogHist CUL0:  240012                 As 11 73 8002 1DA462 5590C0 0101C800B82C9D83
2017.11.18 16:25:08.813 3: LogHist CUL0:  240368 A F103 11411024 01 0E 73 8002 1DA462 5590C0 00B82C9D83 _CCAdly:4 _dhmSt:100
2017.11.18 16:25:08.813 3: LogHist CUL0:  240368 A F10C 11411120 00 0C 74 A641 5590C0 1DA462 0172C8 -54dB _AEScommReq
2017.11.18 16:25:08.813 3: LogHist CUL0:  240368 A F101 11411248 00 11 74 A002 1DA462 5590C0 043EA80E40211C02 -50dB
2017.11.18 16:25:08.814 3: LogHist CUL0:  240702 A F103 11411328 01 11 73 8002 1DA462 5590C0 0101C800B82C9D83 _CCAdly:4 _dhmSt:208
2017.11.18 16:25:08.814 3: LogHist CUL0:  240702 A F10C 11411608 00 0C 74 A241 5590C0 1DA462 0172C8 -54.5dB _AEScommReq
2017.11.18 16:25:08.814 3: LogHist CUL0:  241081 A F103 11411708 01 11 74 A002 1DA462 5590C0 045362342365CC02 _CCAdly:4 _dhmSt:100
2017.11.18 16:25:08.814 3: LogHist CUL0:  241081 A F10E 11411864 00 19 74 A203 5590C0 1DA462 01BDCF6C359F684C78C2F4C6891EE980 -54.5dB _AESauth
2017.11.18 16:25:08.814 3: LogHist CUL0:  241081 A F101 11411864 00 0C 74 A241 5590C0 1DA462 0172C8 -54.5dB
2017.11.18 16:25:08.815 3: LogHist CUL0:  241088                 As 11 74 8002 1DA462 5590C0 0101C80057E3FF33
2017.11.18 16:25:08.815 3: LogHist CUL0:  241081 A F103 11411964 01 0E 74 8002 1DA462 5590C0 0057E3FF33 _CCAdly:4 _dhmSt:100
2017.11.18 16:25:08.815 3: LogHist CUL0:  241417 A F103 11412072 01 11 74 8002 1DA462 5590C0 0101C80057E3FF33 _CCAdly:4 _dhmSt:208
2017.11.18 16:25:08.815 3: LogHist CUL0:  244672 A F10C 11415620 00 0C 75 A641 5590C0 1DA462 017300 -53.5dB _AEScommReq
2017.11.18 16:25:08.815 3: LogHist CUL0:  244980 A F103 11415720 01 11 75 A002 1DA462 5590C0 0430C2A794F16902 _CCAdly:4 _dhmSt:100
2017.11.18 16:25:08.816 3: LogHist CUL0:  244980 A F10C 11415864 00 0C 75 A241 5590C0 1DA462 017300 -53.5dB _AEScommReq
2017.11.18 16:25:08.816 3: LogHist CUL0:  245272 A F103 11415964 01 11 75 A002 1DA462 5590C0 0430C2A794F16902 _CCAdly:4 _dhmSt:100
2017.11.18 16:25:08.816 3: TSCUL_ParseTsHM: CUL0 HM repeat failed to 5590C0/HWR_Wasser:  245580 A F109 11416236 00 11 75 A002 1DA462 5590C0 0430C2A794F16902 _sfail _noAnsw
2017.11.18 16:25:08.818 4: TSCUL_Parse: CUL0  245580 A F10C 11416348 00 0C 75 A241 5590C0 1DA462 017300 -53.5dB _AEScommReq -53.5
2017.11.18 16:25:08.872 4: TSCUL_Parse: CUL0  245580 A F103 11416448 01 11 75 A002 1DA462 5590C0 04C0AC0A5F6EE102 _CCAdly:4 _dhmSt:100
2017.11.18 16:25:08.877 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0100 t:5DED80B3 d:FF r:FFC8     m:75 A241 5590C0 1DA462 017300
2017.11.18 16:25:09.135 3: LogHist CUL0:  240368 A F101 11411248 00 11 74 A002 1DA462 5590C0 043EA80E40211C02 -50dB
2017.11.18 16:25:09.135 3: LogHist CUL0:  240702 A F103 11411328 01 11 73 8002 1DA462 5590C0 0101C800B82C9D83 _CCAdly:4 _dhmSt:208
2017.11.18 16:25:09.136 3: LogHist CUL0:  240702 A F10C 11411608 00 0C 74 A241 5590C0 1DA462 0172C8 -54.5dB _AEScommReq
2017.11.18 16:25:09.136 3: LogHist CUL0:  241081 A F103 11411708 01 11 74 A002 1DA462 5590C0 045362342365CC02 _CCAdly:4 _dhmSt:100
2017.11.18 16:25:09.136 3: LogHist CUL0:  241081 A F10E 11411864 00 19 74 A203 5590C0 1DA462 01BDCF6C359F684C78C2F4C6891EE980 -54.5dB _AESauth
2017.11.18 16:25:09.136 3: LogHist CUL0:  241081 A F101 11411864 00 0C 74 A241 5590C0 1DA462 0172C8 -54.5dB
2017.11.18 16:25:09.136 3: LogHist CUL0:  241088                 As 11 74 8002 1DA462 5590C0 0101C80057E3FF33
2017.11.18 16:25:09.136 3: LogHist CUL0:  241081 A F103 11411964 01 0E 74 8002 1DA462 5590C0 0057E3FF33 _CCAdly:4 _dhmSt:100
2017.11.18 16:25:09.136 3: LogHist CUL0:  241417 A F103 11412072 01 11 74 8002 1DA462 5590C0 0101C80057E3FF33 _CCAdly:4 _dhmSt:208
2017.11.18 16:25:09.136 3: LogHist CUL0:  244672 A F10C 11415620 00 0C 75 A641 5590C0 1DA462 017300 -53.5dB _AEScommReq
2017.11.18 16:25:09.136 3: LogHist CUL0:  244980 A F103 11415720 01 11 75 A002 1DA462 5590C0 0430C2A794F16902 _CCAdly:4 _dhmSt:100
2017.11.18 16:25:09.136 3: LogHist CUL0:  244980 A F10C 11415864 00 0C 75 A241 5590C0 1DA462 017300 -53.5dB _AEScommReq
2017.11.18 16:25:09.137 3: LogHist CUL0:  245272 A F103 11415964 01 11 75 A002 1DA462 5590C0 0430C2A794F16902 _CCAdly:4 _dhmSt:100
2017.11.18 16:25:09.137 3: LogHist CUL0:  245580 A F109 11416236 00 11 75 A002 1DA462 5590C0 0430C2A794F16902 _sfail _noAnsw
2017.11.18 16:25:09.137 3: LogHist CUL0:  245580 A F10C 11416348 00 0C 75 A241 5590C0 1DA462 017300 -53.5dB _AEScommReq
2017.11.18 16:25:09.137 3: LogHist CUL0:  245580 A F103 11416448 01 11 75 A002 1DA462 5590C0 04C0AC0A5F6EE102 _CCAdly:4 _dhmSt:100
2017.11.18 16:25:09.137 3: TSCUL_ParseTsHM: CUL0 HM repeat failed to 5590C0/HWR_Wasser:  245903 A F109 11416720 00 11 75 A002 1DA462 5590C0 04C0AC0A5F6EE102 _sfail _noAnsw
2017.11.18 16:25:09.138 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0050 t:5DED80B3 d:01 r:FFC8     m:75 A241 5590C0 1DA462 017300
2017.11.18 16:25:09.671 4: TSCUL_Parse: CUL0  246438 A F10C 11417324 00 0C 75 A241 5590C0 1DA462 017300 -53dB _AEScommReq -53
2017.11.18 16:25:09.724 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0100 t:5DED8482 d:FF r:FFC9     m:75 A241 5590C0 1DA462 017300
2017.11.18 16:25:09.981 4: TSCUL_Parse: CUL0  246748 A F103 11417424 01 11 75 A002 1DA462 5590C0 04DE478071176502 _CCAdly:4 _dhmSt:100
2017.11.18 16:25:09.986 3: LogHist CUL0:  241081 A F103 11411708 01 11 74 A002 1DA462 5590C0 045362342365CC02 _CCAdly:4 _dhmSt:100
2017.11.18 16:25:09.986 3: LogHist CUL0:  241081 A F10E 11411864 00 19 74 A203 5590C0 1DA462 01BDCF6C359F684C78C2F4C6891EE980 -54.5dB _AESauth
2017.11.18 16:25:09.986 3: LogHist CUL0:  241081 A F101 11411864 00 0C 74 A241 5590C0 1DA462 0172C8 -54.5dB
2017.11.18 16:25:09.987 3: LogHist CUL0:  241088                 As 11 74 8002 1DA462 5590C0 0101C80057E3FF33
2017.11.18 16:25:09.987 3: LogHist CUL0:  241081 A F103 11411964 01 0E 74 8002 1DA462 5590C0 0057E3FF33 _CCAdly:4 _dhmSt:100
2017.11.18 16:25:09.987 3: LogHist CUL0:  241417 A F103 11412072 01 11 74 8002 1DA462 5590C0 0101C80057E3FF33 _CCAdly:4 _dhmSt:208
2017.11.18 16:25:09.987 3: LogHist CUL0:  244672 A F10C 11415620 00 0C 75 A641 5590C0 1DA462 017300 -53.5dB _AEScommReq
2017.11.18 16:25:09.987 3: LogHist CUL0:  244980 A F103 11415720 01 11 75 A002 1DA462 5590C0 0430C2A794F16902 _CCAdly:4 _dhmSt:100
2017.11.18 16:25:09.988 3: LogHist CUL0:  244980 A F10C 11415864 00 0C 75 A241 5590C0 1DA462 017300 -53.5dB _AEScommReq
2017.11.18 16:25:09.988 3: LogHist CUL0:  245272 A F103 11415964 01 11 75 A002 1DA462 5590C0 0430C2A794F16902 _CCAdly:4 _dhmSt:100
2017.11.18 16:25:09.989 3: LogHist CUL0:  245580 A F109 11416236 00 11 75 A002 1DA462 5590C0 0430C2A794F16902 _sfail _noAnsw
2017.11.18 16:25:09.989 3: LogHist CUL0:  245580 A F10C 11416348 00 0C 75 A241 5590C0 1DA462 017300 -53.5dB _AEScommReq
2017.11.18 16:25:09.989 3: LogHist CUL0:  245580 A F103 11416448 01 11 75 A002 1DA462 5590C0 04C0AC0A5F6EE102 _CCAdly:4 _dhmSt:100
2017.11.18 16:25:09.990 3: LogHist CUL0:  245903 A F109 11416720 00 11 75 A002 1DA462 5590C0 04C0AC0A5F6EE102 _sfail _noAnsw
2017.11.18 16:25:09.990 3: LogHist CUL0:  246438 A F10C 11417324 00 0C 75 A241 5590C0 1DA462 017300 -53dB _AEScommReq
2017.11.18 16:25:09.990 3: LogHist CUL0:  246748 A F103 11417424 01 11 75 A002 1DA462 5590C0 04DE478071176502 _CCAdly:4 _dhmSt:100
2017.11.18 16:25:09.991 3: TSCUL_ParseTsHM: CUL0 HM repeat failed to 5590C0/HWR_Wasser:  246748 A F109 11417696 00 11 75 A002 1DA462 5590C0 04DE478071176502 _sfail _noAnsw
2017.11.18 16:25:09.992 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0050 t:5DED8482 d:01 r:FFC9     m:75 A241 5590C0 1DA462 017300
2017.11.18 16:25:10.306 4: TSCUL_Parse: CUL0  247073 A F101 11417832 00 14 25 845E 5AAAEA 000000 800E7200000000000918FE -71.5dB -71.5
2017.11.18 16:25:10.379 0: HMLAN_Parse: HMLAN1 R:E5AAAEA   stat:0000 t:5DED867C d:FF r:FFBF     m:25 845E 5AAAEA 000000 800E7200000000000918FE
2017.11.18 16:25:11.655 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0100 t:5DED8C1F d:FF r:FFBB     m:75 A241 5590C0 1DA462 017300
2017.11.18 16:25:11.727 4: TSCUL_Parse: CUL0  248493 A F10C 11419276 00 0C 75 A241 5590C0 1DA462 017300 -53dB _AEScommReq -53
2017.11.18 16:25:11.732 4: TSCUL_Parse: CUL0  248493 A F103 11419376 01 11 75 A002 1DA462 5590C0 04B9BBA9B8DD4902 _CCAdly:4 _dhmSt:100
2017.11.18 16:25:11.986 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0050 t:5DED8C1F d:01 r:FFBB     m:75 A241 5590C0 1DA462 017300
2017.11.18 16:25:12.015 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5DED8DA0 d:FF r:FFCC     m:75 8002 1DA462 5590C0 00D16D45F0
2017.11.18 16:25:12.029 4: TSCUL_Parse: CUL0  248797 A F10E 11419532 00 19 75 A203 5590C0 1DA462 C3D40A3CA7715ABB32323C4326BC8AF0 -49.5dB _AESauth -49.5
2017.11.18 16:25:12.029 4: TSCUL_Parse: CUL0  248797 A F101 11419532 00 0C 75 A241 5590C0 1DA462 017300 -53dB -53
2017.11.18 16:25:12.033 4: TSCUL_send:  CUL0  248802                 As 11 75 8002 1DA462 5590C0 0101C800D16D45F0
2017.11.18 16:25:12.079 4: TSCUL_Parse: CUL0  248797 A F103 11419632 01 0E 75 8002 1DA462 5590C0 00D16D45F0 _CCAdly:4 _dhmSt:100
2017.11.18 16:25:12.334 4: TSCUL_Parse: CUL0  249101 A F103 11419760 02 11 75 8002 1DA462 5590C0 0101C800D16D45F0 _CCAdly:8 _dhmSt:228
2017.11.18 16:25:12.446 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5DED8E22 d:FF r:FFCC     m:75 8002 1DA462 5590C0 0101C800D16D45F0
2017.11.18 16:25:15.556 4: TSCUL_Parse: CUL0  252323 A F10C 11423120 00 0C 76 A641 5590C0 1DA462 0174C8 -53.5dB _AEScommReq -53.5
2017.11.18 16:25:15.610 4: TSCUL_Parse: CUL0  252323 A F103 11423220 01 11 76 A002 1DA462 5590C0 0432390922F6AC02 _CCAdly:4 _dhmSt:100
2017.11.18 16:25:15.615 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0100 t:5DED9B26 d:FF r:FFC6     m:76 A641 5590C0 1DA462 0174C8
2017.11.18 16:25:15.871 4: TSCUL_Parse: CUL0  252639 A F10E 11423376 00 19 76 A203 5590C0 1DA462 4595EA8C85181BA598FBFFB3E868308A -53.5dB _AESauth -53.5
2017.11.18 16:25:15.872 4: TSCUL_Parse: CUL0  252639 A F101 11423376 00 0C 76 A641 5590C0 1DA462 0174C8 -53.5dB -53.5
2017.11.18 16:25:15.875 4: TSCUL_send:  CUL0  252644                 As 11 76 8002 1DA462 5590C0 0101C80072772AF5
2017.11.18 16:25:15.918 4: TSCUL_Parse: CUL0  252639 A F103 11423476 01 0E 76 8002 1DA462 5590C0 0072772AF5 _CCAdly:4 _dhmSt:100
2017.11.18 16:25:15.918 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0050 t:5DED9B26 d:01 r:FFC6     m:76 A641 5590C0 1DA462 0174C8
2017.11.18 16:25:15.949 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5DED9CA5 d:FF r:FFCC     m:76 8002 1DA462 5590C0 0072772AF5
2017.11.18 16:25:16.207 4: TSCUL_Parse: CUL0  252975 A F103 11423600 02 11 76 8002 1DA462 5590C0 0101C80072772AF5 _CCAdly:8 _dhmSt:224
2017.11.18 16:25:16.208 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5DED9D23 d:FF r:FFCC     m:76 8002 1DA462 5590C0 0101C80072772AF5
2017.11.18 16:25:17.482 4: TSCUL_Parse: CUL0  254249 A F101 11425184 00 14 73 845E 5AAAFA 000000 80048600000000000902FF -77.5dB -77.5
2017.11.18 16:25:17.486 0: HMLAN_Parse: HMLAN1 R:E5AAAFA   stat:0000 t:5DEDA337 d:FF r:FFC9     m:73 845E 5AAAFA 000000 80048600000000000902FF
2017.11.18 16:25:20.903 0: HMLAN_Parse: HMLAN1 R:E206B03   stat:0000 t:5DEDAFC2 d:FF r:FF9A     m:3C 8670 206B03 000000 003B4C


Greets

Byte
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: noansi am 18 November 2017, 17:24:34
Hallo Byte,

Zitatalso klar, neueste Version und FHEM auch auf dem neuesten Stand. Derzeit scheinen aber nicht alle Fensterkontakte die Probleme zu haben.

Wohl vermutlich doch noch nicht ganz klar.
Neuester Stand von FHEM, aber danach neuester Stand Firmware (VTS 0.19) und Module inklusive 10_CUL_HM.pm (ein FHEM update würde das überschreiben).

Martin hat nicht alles übernommen, was leider bei der Zuweisung der devices zu den IOs Fehlern führen kann.

Zumindest sieht Dein Log danach aus, also ob sowohl CUL0 also auch HMLAN1 dem device mit einer Challenenge antworten. Das kann häufig nicht gut gehen.

Mit get assignIDs kannst Du Dir bei CUL0 und HMLAN1 anzeigen lassen, welche devices jeweils zugeordnet sind.
Devices dürfen nicht bei beiden IOs gleichzeitig auftauchen.

Ich kann nur mit zwei CUL IOs testen und damit funktioniert der letzte Stand bezüglich der IO Zuordnung.
Ob HMLAN sauber setzt und löscht, müsstest Du weiter testen, aber bitte mit den richtigen Modulen.

Außerdem versuchst Du wohl immer noch den unrealistisch schnellen und häufigen Öffnen/Schließen Vorgang. ;)

Ich habe den Eindruck, die devices verweigern dann schon mal die Antwort. Oder die 1% Regel schlägt dann in den devices teilweise zu, sprich sie senden noch die Zustandsänderung, aber verweigern AES?!?
Meinen Testbewegungsmelder habe ich wieder auf default 240s Bewegungsmittelungslimit gestellt und damit ist er wesentlich AES-Antwortbereiter.

Gruß, Ansgar.

Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: Bytechanger am 18 November 2017, 18:08:23
Hallo,

ich habe natürlich die 10_CUL_HM.pm  aus der ZIP genommen UND wie beschrieben sie vom Update ausgeschlossen!!
Es ist also die aktuellste, gewünschte Konsterlation.

In der Tat taucht das betroffene Gerät in beiden Stationen (HMLAN und CUL bei get assignID) auf?!
Wie kann ich das verhindern?
Nach meinem Erkenntnisstand wird die Zuordnung über
IODev  CUL0
IOgrp vccu:CUL0
vorgenommen...

Die Geschwindigkeit macht es nicht aus. Ein Log mit längerer Wartezeit:

2017.11.18 18:07:35.257 4: TSCUL_Parse: CUL0  100568 A F001 00785828 00 0F C2 865E 3BD2E7 000000 F7F92D0089E4 -86.5dB -86.5
2017.11.18 18:07:35.267 4: TSCUL_Parse: CUL0  100568 A F00C 00785868 00 0C 7B A641 5590C0 1DA462 017900 -60.5dB _AEScommReq -60.5
2017.11.18 18:07:35.322 0: HMLAN_Parse: HMLAN1 R:E3BD2E7   stat:0000 t:5E4B4E27 d:FF r:FFAC     m:C2 865E 3BD2E7 000000 F7F92D0089E4
2017.11.18 18:07:35.325 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0100 t:5E4B4E4F d:FF r:FFBF     m:7B A641 5590C0 1DA462 017900
2017.11.18 18:07:35.583 4: TSCUL_Parse: CUL0  100894 A F103 00785968 01 11 7B A002 1DA462 5590C0 043973AF6A03DB02 _CCAdly:4 _dhmSt:100
2017.11.18 18:07:35.586 4: TSCUL_Parse: CUL0  100894 A F10E 00786124 00 19 7B A203 5590C0 1DA462 343B77CD2FC707564B855A76B08A7FB8 -60.5dB _AESauth -60.5
2017.11.18 18:07:35.587 4: TSCUL_Parse: CUL0  100894 A F101 00786124 00 0C 7B A641 5590C0 1DA462 017900 -60.5dB -60.5
2017.11.18 18:07:35.591 4: TSCUL_send:  CUL0  100904                 As 11 7B 8002 1DA462 5590C0 0101C800E5AD36CD
2017.11.18 18:07:35.636 4: TSCUL_Parse: CUL0  100894 A F103 00786224 01 0E 7B 8002 1DA462 5590C0 00E5AD36CD _CCAdly:4 _dhmSt:100
2017.11.18 18:07:35.637 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0050 t:5E4B4E4F d:01 r:FFBF     m:7B A641 5590C0 1DA462 017900
2017.11.18 18:07:35.670 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5E4B4FCE d:FF r:FFCB     m:7B 8002 1DA462 5590C0 00E5AD36CD
2017.11.18 18:07:35.926 4: TSCUL_Parse: CUL0  101238 A F103 00786332 01 11 7B 8002 1DA462 5590C0 0101C800E5AD36CD _CCAdly:4 _dhmSt:208
2017.11.18 18:07:35.927 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5E4B503D d:FF r:FFCB     m:7B 8002 1DA462 5590C0 0101C800E5AD36CD
2017.11.18 18:07:52.290 4: TSCUL_Parse: CUL0  117601 A F001 00802940 00 0C 51 8670 20DACE 000000 004151 -95.5dB -95.5
2017.11.18 18:07:56.091 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0100 t:5E4B9F62 d:FF r:FFC1     m:7C A641 5590C0 1DA462 017AC8
2017.11.18 18:07:56.147 4: TSCUL_Parse: CUL0  121459 A F00C 00806620 00 0C 7C A641 5590C0 1DA462 017AC8 -62.5dB _AEScommReq -62.5
2017.11.18 18:07:56.153 4: TSCUL_Parse: CUL0  121459 A F103 00806720 01 11 7C A002 1DA462 5590C0 04D7D3C262FA3002 _CCAdly:4 _dhmSt:100
2017.11.18 18:07:56.156 4: TSCUL_Parse: CUL0  121459 A F10C 00806864 00 0C 7C A241 5590C0 1DA462 017AC8 -63dB _AEScommReq -63
2017.11.18 18:07:56.411 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0050 t:5E4B9F62 d:01 r:FFC1     m:7C A641 5590C0 1DA462 017AC8
2017.11.18 18:07:56.445 4: TSCUL_Parse: CUL0  121757 A F103 00806964 01 11 7C A002 1DA462 5590C0 04D7D3C262FA3002 _CCAdly:4 _dhmSt:100
2017.11.18 18:07:56.743 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0050 t:5E4BA056 d:01 r:FFC0     m:7C A241 5590C0 1DA462 017AC8
2017.11.18 18:07:56.772 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0100 t:5E4BA23D d:FF r:FFC0     m:7C A241 5590C0 1DA462 017AC8
2017.11.18 18:07:56.802 3: LogHist CUL0:  084122 A F109 00769236 00 11 7A A002 1DA462 5590C0 04AE0AA692440202 _sfail _noAnsw
2017.11.18 18:07:56.802 3: LogHist CUL0:  084122 A F101 00769240 00 0E 7A 8002 1DA462 5590C0 00E2691F82 -51dB
2017.11.18 18:07:56.802 3: LogHist CUL0:  084122 A F103 00769492 01 0D 7A 8002 1DA462 5590C0 0101C800 _CCAdly:4 _dhmSt:356
2017.11.18 18:07:56.803 3: LogHist CUL0:  100568 A F001 00785828 00 0F C2 865E 3BD2E7 000000 F7F92D0089E4 -86.5dB
2017.11.18 18:07:56.803 3: LogHist CUL0:  100568 A F00C 00785868 00 0C 7B A641 5590C0 1DA462 017900 -60.5dB _AEScommReq
2017.11.18 18:07:56.803 3: LogHist CUL0:  100894 A F103 00785968 01 11 7B A002 1DA462 5590C0 043973AF6A03DB02 _CCAdly:4 _dhmSt:100
2017.11.18 18:07:56.803 3: LogHist CUL0:  100894 A F10E 00786124 00 19 7B A203 5590C0 1DA462 343B77CD2FC707564B855A76B08A7FB8 -60.5dB _AESauth
2017.11.18 18:07:56.803 3: LogHist CUL0:  100894 A F101 00786124 00 0C 7B A641 5590C0 1DA462 017900 -60.5dB
2017.11.18 18:07:56.803 3: LogHist CUL0:  100904                 As 11 7B 8002 1DA462 5590C0 0101C800E5AD36CD
2017.11.18 18:07:56.804 3: LogHist CUL0:  100894 A F103 00786224 01 0E 7B 8002 1DA462 5590C0 00E5AD36CD _CCAdly:4 _dhmSt:100
2017.11.18 18:07:56.804 3: LogHist CUL0:  101238 A F103 00786332 01 11 7B 8002 1DA462 5590C0 0101C800E5AD36CD _CCAdly:4 _dhmSt:208
2017.11.18 18:07:56.805 3: LogHist CUL0:  117601 A F001 00802940 00 0C 51 8670 20DACE 000000 004151 -95.5dB
2017.11.18 18:07:56.805 3: LogHist CUL0:  121459 A F00C 00806620 00 0C 7C A641 5590C0 1DA462 017AC8 -62.5dB _AEScommReq
2017.11.18 18:07:56.805 3: LogHist CUL0:  121459 A F103 00806720 01 11 7C A002 1DA462 5590C0 04D7D3C262FA3002 _CCAdly:4 _dhmSt:100
2017.11.18 18:07:56.805 3: LogHist CUL0:  121459 A F10C 00806864 00 0C 7C A241 5590C0 1DA462 017AC8 -63dB _AEScommReq
2017.11.18 18:07:56.805 3: LogHist CUL0:  121757 A F103 00806964 01 11 7C A002 1DA462 5590C0 04D7D3C262FA3002 _CCAdly:4 _dhmSt:100
2017.11.18 18:07:56.806 3: TSCUL_ParseTsHM: CUL0 HM repeat failed to 5590C0/HWR_Wasser:  122114 A F109 00807236 00 11 7C A002 1DA462 5590C0 04D7D3C262FA3002 _sfail _noAnsw
2017.11.18 18:07:56.807 4: TSCUL_Parse: CUL0  122114 A F10C 00807352 00 0C 7C A241 5590C0 1DA462 017AC8 -63dB _AEScommReq -63
2017.11.18 18:07:56.811 4: TSCUL_Parse: CUL0  122114 A F103 00807452 01 11 7C A002 1DA462 5590C0 04587A75CABFA902 _CCAdly:4 _dhmSt:100
2017.11.18 18:07:57.145 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0050 t:5E4BA23D d:01 r:FFC0     m:7C A241 5590C0 1DA462 017AC8
2017.11.18 18:07:57.189 3: LogHist CUL0:  100568 A F001 00785828 00 0F C2 865E 3BD2E7 000000 F7F92D0089E4 -86.5dB
2017.11.18 18:07:57.190 3: LogHist CUL0:  100568 A F00C 00785868 00 0C 7B A641 5590C0 1DA462 017900 -60.5dB _AEScommReq
2017.11.18 18:07:57.190 3: LogHist CUL0:  100894 A F103 00785968 01 11 7B A002 1DA462 5590C0 043973AF6A03DB02 _CCAdly:4 _dhmSt:100
2017.11.18 18:07:57.190 3: LogHist CUL0:  100894 A F10E 00786124 00 19 7B A203 5590C0 1DA462 343B77CD2FC707564B855A76B08A7FB8 -60.5dB _AESauth
2017.11.18 18:07:57.190 3: LogHist CUL0:  100894 A F101 00786124 00 0C 7B A641 5590C0 1DA462 017900 -60.5dB
2017.11.18 18:07:57.190 3: LogHist CUL0:  100904                 As 11 7B 8002 1DA462 5590C0 0101C800E5AD36CD
2017.11.18 18:07:57.191 3: LogHist CUL0:  100894 A F103 00786224 01 0E 7B 8002 1DA462 5590C0 00E5AD36CD _CCAdly:4 _dhmSt:100
2017.11.18 18:07:57.191 3: LogHist CUL0:  101238 A F103 00786332 01 11 7B 8002 1DA462 5590C0 0101C800E5AD36CD _CCAdly:4 _dhmSt:208
2017.11.18 18:07:57.191 3: LogHist CUL0:  117601 A F001 00802940 00 0C 51 8670 20DACE 000000 004151 -95.5dB
2017.11.18 18:07:57.191 3: LogHist CUL0:  121459 A F00C 00806620 00 0C 7C A641 5590C0 1DA462 017AC8 -62.5dB _AEScommReq
2017.11.18 18:07:57.192 3: LogHist CUL0:  121459 A F103 00806720 01 11 7C A002 1DA462 5590C0 04D7D3C262FA3002 _CCAdly:4 _dhmSt:100
2017.11.18 18:07:57.192 3: LogHist CUL0:  121459 A F10C 00806864 00 0C 7C A241 5590C0 1DA462 017AC8 -63dB _AEScommReq
2017.11.18 18:07:57.192 3: LogHist CUL0:  121757 A F103 00806964 01 11 7C A002 1DA462 5590C0 04D7D3C262FA3002 _CCAdly:4 _dhmSt:100
2017.11.18 18:07:57.192 3: LogHist CUL0:  122114 A F109 00807236 00 11 7C A002 1DA462 5590C0 04D7D3C262FA3002 _sfail _noAnsw
2017.11.18 18:07:57.193 3: LogHist CUL0:  122114 A F10C 00807352 00 0C 7C A241 5590C0 1DA462 017AC8 -63dB _AEScommReq
2017.11.18 18:07:57.193 3: LogHist CUL0:  122114 A F103 00807452 01 11 7C A002 1DA462 5590C0 04587A75CABFA902 _CCAdly:4 _dhmSt:100
2017.11.18 18:07:57.193 3: TSCUL_ParseTsHM: CUL0 HM repeat failed to 5590C0/HWR_Wasser:  122501 A F109 00807724 00 11 7C A002 1DA462 5590C0 04587A75CABFA902 _sfail _noAnsw
2017.11.18 18:07:57.606 4: TSCUL_Parse: CUL0  122917 A F10C 00808324 00 0C 7C A241 5590C0 1DA462 017AC8 -63dB _AEScommReq -63
2017.11.18 18:07:57.885 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0100 t:5E4BA60C d:FF r:FFC0     m:7C A241 5590C0 1DA462 017AC8
2017.11.18 18:07:57.891 4: TSCUL_Parse: CUL0  123202 A F103 00808424 01 11 7C A002 1DA462 5590C0 046719E8A0A93B02 _CCAdly:4 _dhmSt:100
2017.11.18 18:07:58.151 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0050 t:5E4BA60C d:01 r:FFC0     m:7C A241 5590C0 1DA462 017AC8
2017.11.18 18:07:58.207 3: LogHist CUL0:  100894 A F10E 00786124 00 19 7B A203 5590C0 1DA462 343B77CD2FC707564B855A76B08A7FB8 -60.5dB _AESauth
2017.11.18 18:07:58.207 3: LogHist CUL0:  100894 A F101 00786124 00 0C 7B A641 5590C0 1DA462 017900 -60.5dB
2017.11.18 18:07:58.207 3: LogHist CUL0:  100904                 As 11 7B 8002 1DA462 5590C0 0101C800E5AD36CD
2017.11.18 18:07:58.208 3: LogHist CUL0:  100894 A F103 00786224 01 0E 7B 8002 1DA462 5590C0 00E5AD36CD _CCAdly:4 _dhmSt:100
2017.11.18 18:07:58.208 3: LogHist CUL0:  101238 A F103 00786332 01 11 7B 8002 1DA462 5590C0 0101C800E5AD36CD _CCAdly:4 _dhmSt:208
2017.11.18 18:07:58.208 3: LogHist CUL0:  117601 A F001 00802940 00 0C 51 8670 20DACE 000000 004151 -95.5dB
2017.11.18 18:07:58.208 3: LogHist CUL0:  121459 A F00C 00806620 00 0C 7C A641 5590C0 1DA462 017AC8 -62.5dB _AEScommReq
2017.11.18 18:07:58.208 3: LogHist CUL0:  121459 A F103 00806720 01 11 7C A002 1DA462 5590C0 04D7D3C262FA3002 _CCAdly:4 _dhmSt:100
2017.11.18 18:07:58.209 3: LogHist CUL0:  121459 A F10C 00806864 00 0C 7C A241 5590C0 1DA462 017AC8 -63dB _AEScommReq
2017.11.18 18:07:58.209 3: LogHist CUL0:  121757 A F103 00806964 01 11 7C A002 1DA462 5590C0 04D7D3C262FA3002 _CCAdly:4 _dhmSt:100
2017.11.18 18:07:58.209 3: LogHist CUL0:  122114 A F109 00807236 00 11 7C A002 1DA462 5590C0 04D7D3C262FA3002 _sfail _noAnsw
2017.11.18 18:07:58.209 3: LogHist CUL0:  122114 A F10C 00807352 00 0C 7C A241 5590C0 1DA462 017AC8 -63dB _AEScommReq
2017.11.18 18:07:58.209 3: LogHist CUL0:  122114 A F103 00807452 01 11 7C A002 1DA462 5590C0 04587A75CABFA902 _CCAdly:4 _dhmSt:100
2017.11.18 18:07:58.210 3: LogHist CUL0:  122501 A F109 00807724 00 11 7C A002 1DA462 5590C0 04587A75CABFA902 _sfail _noAnsw
2017.11.18 18:07:58.210 3: LogHist CUL0:  122917 A F10C 00808324 00 0C 7C A241 5590C0 1DA462 017AC8 -63dB _AEScommReq
2017.11.18 18:07:58.210 3: LogHist CUL0:  123202 A F103 00808424 01 11 7C A002 1DA462 5590C0 046719E8A0A93B02 _CCAdly:4 _dhmSt:100
2017.11.18 18:07:58.210 3: TSCUL_ParseTsHM: CUL0 HM repeat failed to 5590C0/HWR_Wasser:  123518 A F109 00808696 00 11 7C A002 1DA462 5590C0 046719E8A0A93B02 _sfail _noAnsw
2017.11.18 18:07:59.767 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0100 t:5E4BADA8 d:FF r:FFC6     m:7C A241 5590C0 1DA462 017AC8
2017.11.18 18:07:59.820 4: TSCUL_Parse: CUL0  125131 A F10C 00810276 00 0C 7C A241 5590C0 1DA462 017AC8 -48.5dB _AEScommReq -48.5
2017.11.18 18:07:59.825 4: TSCUL_Parse: CUL0  125131 A F103 00810376 01 11 7C A002 1DA462 5590C0 04522FF509B70D02 _CCAdly:4 _dhmSt:100
2017.11.18 18:08:00.085 0: HMLAN_Parse: HMLAN1 R:E5590C0   stat:0050 t:5E4BADA8 d:01 r:FFC6     m:7C A241 5590C0 1DA462 017AC8
2017.11.18 18:08:00.137 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5E4BAF29 d:FF r:FFCB     m:7C 8002 1DA462 5590C0 007358A8AC
2017.11.18 18:08:00.143 4: TSCUL_Parse: CUL0  125455 A F10E 00810532 00 19 7C A203 5590C0 1DA462 32D7FAEA43224261AD0DAB8193BC85E5 -47.5dB _AESauth -47.5
2017.11.18 18:08:00.145 4: TSCUL_Parse: CUL0  125455 A F101 00810532 00 0C 7C A241 5590C0 1DA462 017AC8 -48.5dB -48.5
2017.11.18 18:08:00.150 4: TSCUL_send:  CUL0  125463                 As 11 7C 8002 1DA462 5590C0 0101C8007358A8AC
2017.11.18 18:08:00.209 4: TSCUL_Parse: CUL0  125455 A F103 00810632 01 0E 7C 8002 1DA462 5590C0 007358A8AC _CCAdly:4 _dhmSt:100
2017.11.18 18:08:00.461 0: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:5E4BB023 d:FF r:FFCB     m:7C 8002 1DA462 5590C0 0101C8007358A8AC
2017.11.18 18:08:00.466 4: TSCUL_Parse: CUL0  125777 A F103 00810880 02 11 7C 8002 1DA462 5590C0 0101C8007358A8AC _CCAdly:8 _dhmSt:348



Kann es sein, dass der HMLAN immer diese Challenge-Antworten gibt-unabhängig was die Zentrale will- ??

Greets

Byte
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: noansi am 18 November 2017, 18:41:26
Hallo Byte,

ZitatNach meinem Erkenntnisstand wird die Zuordnung über
IODev  CUL0
IOgrp vccu:CUL0
vorgenommen...
Dem stimme ich zu.
Im laufenden Betrieb sollte es sogar genügen, nur IOgrp entsprechend zu ändern.

ZitatIn der Tat taucht das betroffene Gerät in beiden Stationen (HMLAN und CUL bei get assignID) auf?!
Wie kann ich das verhindern?
Hmm, das ist merkwürdig und soll so gerade nicht passieren. Mal schauen, ob ich das im Code noch rausfinde.

ZitatKann es sein, dass der HMLAN immer diese Challenge-Antworten gibt-unabhängig was die Zentrale will- ??
Sollte nicht, aber wenn es noch in assignIDs bei HMLAN auftaucht, dann hat es damit blöderweise recht.

ZitatDie Geschwindigkeit macht es nicht aus. Ein Log mit längerer Wartezeit:
Was ist 5590C0/HWR_Wasser für ein device? List?
Zieh bitte HMLAN mal den Stecker und teste nur mit CUL0 allein.
Vielleicht geht es dam jetzt mit den Antworten auch etwas schnell. Allerdings habe ich mit der 100ms Antwortzeit bisher bessere Erfahrungen gemacht, als mit ursprünglich 120ms.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: klausw am 18 November 2017, 19:08:46
Zitat von: noansi am 18 November 2017, 02:18:56
Hallo Klaus,
??? Was willst Du mit dem uralten Stand?

Auf dem NanoCul ist noch die alte Firmware drauf. Aus irgendeinem Grund hat sich das excludefromupdate verflüchtigt und die Datei wurde überschrieben. Das muss aber schon eine Weile her sein. In den Backups ist sie nicht mehr drin.
Wenn die aktuelle CUL-HM läuft dann kann ich auch die lassen (aber das scheint nicht 100%ig der Fall zu sein).
Der NanoCul wird demnächst auf eine aktuelle Version gebracht. Aber dazu will ich vor Ort sein...
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: noansi am 18 November 2017, 21:07:57
Hallo Klaus,

ZitatAuf dem NanoCul ist noch die alte Firmware drauf.
welche Version denn?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: klausw am 19 November 2017, 00:14:51
Hallo Ansgar,
Zitat von: noansi am 18 November 2017, 21:07:57
welche Version denn?

   VERSION    VTS 0.02 nanoCUL868
   VERSION_HW nanoCUL_V1.x


Grüße
Klaus
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: noansi am 19 November 2017, 03:35:52
Hallo Klaus,

ZitatVERSION    VTS 0.02 nanoCUL868
Dann war die in der angehängten zip der Stand von damals.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: noansi am 19 November 2017, 15:00:16
Hallo Byte,

ZitatIn der Tat taucht das betroffene Gerät in beiden Stationen (HMLAN und CUL bei get assignID) auf?!
Wie kann ich das verhindern?

Kannst Du bitte nochmal mit den angehängten Modulen testen, ob die Doppelzuweisung damit weg ist?

Danke und Gruß,
Ansgar.

EDIT: 00_TSCUL.pm und 10_CUL_HM.pm aktualisert, roaming stabilisiert und "define %" wieder entfernt entspr. https://forum.fhem.de/index.php/topic,79858.0.html (https://forum.fhem.de/index.php/topic,79858.0.html)
EDIT: 00_TSCUL.pm hmId Rückstellung bei virtuellen HM Sensoren
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: OiledAmoeba am 30 November 2017, 17:19:17
Moin,

scheinbar bin ich zu bl*d... Ich wollte diese Firmware auf meinen nanoCUL schieben, weil ich AES mit keiner anderen Firmware hinbekommen habe. Weder mit a-culfw (V 1.26.01 a-culfw Build: 271) noch mit der "offiziellen" 1.67
Da ich aber, weil er schick war, einen optischen Fenstersensor (mit AES-out-of-the-Box=on) habe, wollte ich zumindest solange AES nutzen, bis ich das Ding auf R-sign=off bekommen habe.

Zum Problem: Definiert ist "TSCUL TSCUL /dev/ttyU0@38400 0000". Schiebe ich die Firmware mit "TSCULflash TSCUL TSnanoCUL" auf den nano, bekomme ich eine positive Rückmeldung von avrdude. Jetzt knallt er mir im Sekundenrythmus das Log zu mit "initialized", "disconnected" oder "unknowncode <unlesbare Steuerzeichen>".
Nach einem fhem-Neustart kommt ein freundliches: Messages collected while initializing FHEM:
configfile: ASKSIN not supported
ASKSIN not supported

Autosave deactivated
Wo ist mein Fehler? Vor allem, was heißt "configfile: ASKSIN not supported", muss ich noch was in der fhem-Conf machen?

Gruß
Florian
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: noansi am 30 November 2017, 19:18:24
Hallo Florian,

Zitatbekomme ich eine positive Rückmeldung von avrdude.

Was steht im Log als positive Rückmeldung?

ZitatJetzt knallt er mir im Sekundenrythmus das Log zu mit "initialized", "disconnected" oder "unknowncode <unlesbare Steuerzeichen>".
Vielleicht hat das Flashen doch nicht so erfolgreich geklappt. Möglicherweise redet FHEM gerade mit dem Bootloader?!

ZitatVor allem, was heißt "configfile: ASKSIN not supported",
Das bedeutet, dass beim Auslesen der möglichen Befehle "A" nicht dabei war, bzw. so wie Du es bisher schilderst, wohl eher gar keine mögliche Befehle.

Versuch den nano mal "normal", also nicht mit TSCUL zu flashen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: OiledAmoeba am 30 November 2017, 21:54:27
Hallo Ansgar,

da mir diese Steuerzeichen DbLog abschmieren lassen, habe ich den Flash nochmal ohne fhem gemacht.

Console mit a-culfw:
root@fhem:/fhem/FHEM/firmware/a-culfw/nanoCUL # avrdude -p atmega328p -P /dev/ttyU0 -c arduino -b 57600 -U flash:w:nanoCUL868.hex

avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "nanoCUL868.hex"
avrdude: input file nanoCUL868.hex auto detected as Intel Hex
avrdude: writing flash (14574 bytes):

Writing | ################################################## | 100% 7.31s

avrdude: 14574 bytes of flash written
avrdude: verifying flash memory against nanoCUL868.hex:
avrdude: load data flash data from input file nanoCUL868.hex:
avrdude: input file nanoCUL868.hex auto detected as Intel Hex
avrdude: input file nanoCUL868.hex contains 14574 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 6.12s

avrdude: verifying ...
avrdude: 14574 bytes of flash verified

avrdude: safemode: Fuses OK (E:00, H:00, L:00)

avrdude done.  Thank you.

root@fhem:/fhem/FHEM/firmware/a-culfw/nanoCUL #

laut fhem.cfg definiert als:define CUL CUL /dev/ttyU0@38400 0000
attr CUL hmId F23102
attr CUL icon cul_cul
attr CUL model nanoCUL
attr CUL rfmode HomeMatic
attr CUL room System
attr CUL showtime 1
attr CUL verbose 4

Mit obigen Verbose4 kommt dann das:
2017.11.30 21:17:25.010 1: Including fhem.cfg
2017.11.30 21:17:53.411 1: Including ./log/fhem.save
2017.11.30 21:17:54.517 1: configfile: ASKSIN not supported
ASKSIN not supported

2017.11.30 21:18:12.381 1: usb create starting
2017.11.30 21:18:12.677 1: usb create end
2017.11.30 21:18:13.347 2: Messages collected while initializing FHEM: configfile: ASKSIN not supported ASKSIN not supported  Autosave deactivated
2017.11.30 21:18:13.347 0: Featurelevel: 5.8
2017.11.30 21:18:13.348 0: Server started with 242 defined entities (fhem.pl:15482/2017-11-23 perl:5.024003 os:freebsd user:root pid:32231)
2017.11.30 21:17:47.119 2: Switched CUL rfmode to HomeMatic
2017.11.30 21:18:41.861 4: CUL_Parse: CUL A 0F 83 8610 530F30 000000 0A88C40C000010 -66
2017.11.30 21:18:43.850 4: CUL_Parse: CUL A 0F 86 8610 51C812 000000 0A60B30C000018 -62
2017.11.30 21:20:34.589 0: Server shutdown
2017.11.30 21:20:35.189 2: DbLog logdb waiting for shutdown

Und list CUL:
Internals:
   CMDS       ABCEeFfGiKlMNRTtUVWXxZ
   CUL_MSGCNT 7
   CUL_TIME   2017-11-30 21:19:49
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        /dev/ttyU0@38400 0000
   DeviceName /dev/ttyU0@38400
   FD         13
   FHTID      0000
   NAME       CUL
   NR         175
   NR_CMD_LAST_H 6
   PARTIAL
   RAWMSG     A0E87801051C5AFF23102020800000006
   RSSI       -71
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.26.01 a-culfw Build: 271 (2017-09-18_20-23-44) nanoCUL868 (F-Band: 868MHz)
   initString X21
Ar
   owner_CCU  VCCU
   .clientArray:
     CUL_HM
   MatchList:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2017-11-30 18:02:50   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
     2017-11-30 21:17:47   cmds             A B C E e F f G i K l M N R T t U V W X x Z
     2017-11-30 21:19:49   state           Initialized

     2017-11-30 01:41:10   version         V 1.26.01 a-culfw Build: 271 (2017-09-18_20-23-44) nanoCUL868 (F-Band: 868MHz)
   XMIT_TIME:
     1512073123.85961
     1512073123.95686
     1512073186.91534
     1512073187.01288
     1512073188.68134
     1512073188.97801
   helper:
     51C5AF:
       QUEUE:
     51C812:
       QUEUE:
Attributes:
   hmId       F23102
   icon       cul_cul
   model      nanoCUL
   rfmode     HomeMatic
   room       System
   showtime   1
   verbose    4


Und nun das ganze mit TSnanoCUL:
root@fhem:/fhem/FHEM/firmware # avrdude -p atmega328p -P /dev/ttyU0 -c arduino -b 57600 -U flash:w:TSnanoCUL.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "TSnanoCUL.hex"
avrdude: input file TSnanoCUL.hex auto detected as Intel Hex
avrdude: writing flash (28346 bytes):

Writing | ################################################## | 100% 14.14s

avrdude: 28346 bytes of flash written
avrdude: verifying flash memory against TSnanoCUL.hex:
avrdude: load data flash data from input file TSnanoCUL.hex:
avrdude: input file TSnanoCUL.hex auto detected as Intel Hex
avrdude: input file TSnanoCUL.hex contains 28346 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 11.94s

avrdude: verifying ...
avrdude: 28346 bytes of flash verified

avrdude: safemode: Fuses OK (E:00, H:00, L:00)

avrdude done.  Thank you.

root@fhem:/fhem/FHEM/firmware #

laut fhem.cfg definiert als:define TSCUL TSCUL /dev/ttyU0@38400 0000
attr TSCUL hmId F23102
attr TSCUL hmLanQlen 1_min
attr TSCUL rfmode HomeMatic
attr TSCUL icon cul_cul
attr TSCUL model nanoCUL
attr TSCUL room System
attr TSCUL verbose 4

Mit obigen Verbose4 kommt dann das:
2017.11.30 21:37:18.251 1: Including fhem.cfg
2017.11.30 21:37:45.620 2: TSCUL_condUpdateHM: TSCUL new condition disconnected
2017.11.30 21:37:52.438 1: /dev/ttyU0 disconnected, waiting to reappear TSCUL
2017.11.30 21:37:54.773 2: TSCUL_condUpdateHM: TSCUL new condition disconnected
2017.11.30 21:37:54.839 2: TSCUL: Mode HomeMatic not supported, wrong firmware?!?
2017.11.30 21:37:54.856 1: Including ./log/fhem.save
2017.11.30 21:37:55.890 1: configfile: ASKSIN not supported
ASKSIN not supported
TSCUL: Mode HomeMatic not supported, wrong firmware?!?

2017.11.30 21:37:55.912 2: TSCUL: Mode HomeMatic not supported, wrong firmware?!?
2017.11.30 21:37:55.915 1: CUL_HM correct hmId for assigned IO TSCUL
2017.11.30 21:38:13.155 1: usb create starting
2017.11.30 21:38:13.265 1: usb create end
2017.11.30 21:38:13.949 2: Messages collected while initializing FHEM: configfile: ASKSIN not supported ASKSIN not supported TSCUL: Mode HomeMatic not supported, wrong firmware?!?  Autosave deactivated
2017.11.30 21:38:13.960 0: Featurelevel: 5.8
2017.11.30 21:38:13.960 0: Server started with 242 defined entities (fhem.pl:15482/2017-11-23 perl:5.024003 os:freebsd user:root pid:56859)
2017.11.30 21:38:59.933 0: TSCUL_Parse: TSCUL External Reset Restart detected: C_RE
2017.11.30 21:38:59.960 1: TSCUL_Parse: TSCUL Restart detected: C_ReadyCSM868
2017.11.30 21:39:00.475 3: TSCUL: Possible commands: ABCEFGJKMNRUVWXYZeilmtx
2017.11.30 21:39:01.145 1: TSCUL is VERSION_TS, VTS 0.19 CSM868, nanoCUL_V1.x
2017.11.30 21:39:01.598 2: TSCUL_condUpdateHM: TSCUL new condition non-HM
2017.11.30 21:39:05.006 1: /dev/ttyU0 disconnected, waiting to reappear TSCUL
2017.11.30 21:39:05.826 2: TSCUL_condUpdateHM: TSCUL new condition disconnected
2017.11.30 21:39:21.639 3: Setting TSCUL serial parameters to 38400,8,N,1
2017.11.30 21:39:24.100 2: TSCUL_Parse: TSCUL unknown message 秷<Anm.: Symbole rausgenommen, kommt das Forum nicht mit klar>
2017.11.30 21:39:24.121 0: TSCUL_Parse: TSCUL External Reset Restart detected: C_RE
2017.11.30 21:39:24.122 1: TSCUL_Parse: TSCUL Restart detected: C_ReadyCSM868
2017.11.30 21:39:24.616 3: TSCUL: Possible commands: ABCEFGJKMNRUVWXYZeilmtx
2017.11.30 21:39:25.302 1: TSCUL is VERSION_TS, VTS 0.19 CSM868, nanoCUL_V1.x
2017.11.30 21:39:25.751 2: TSCUL_condUpdateHM: TSCUL new condition non-HM
2017.11.30 21:39:29.413 1: /dev/ttyU0 disconnected, waiting to reappear TSCUL
2017.11.30 21:39:30.083 2: TSCUL_condUpdateHM: TSCUL new condition disconnected
2017.11.30 21:39:37.077 3: Setting TSCUL serial parameters to 38400,8,N,1
2017.11.30 21:39:39.293 2: TSCUL_Parse: TSCUL unknown message sK^<Anm.: Symbole rausgenommen, kommt das Forum nicht mit klar>
2017.11.30 21:39:39.318 0: TSCUL_Parse: TSCUL External Reset Restart detected: C_RE
2017.11.30 21:39:39.319 1: TSCUL_Parse: TSCUL Restart detected: C_ReadyCSM868
2017.11.30 21:39:39.810 3: TSCUL: Possible commands: ABCEFGJKMNRUVWXYZeilmtx
2017.11.30 21:39:40.495 1: TSCUL is VERSION_TS, VTS 0.19 CSM868, nanoCUL_V1.x
2017.11.30 21:39:40.948 2: TSCUL_condUpdateHM: TSCUL new condition non-HM
2017.11.30 21:39:44.937 1: /dev/ttyU0 disconnected, waiting to reappear TSCUL
2017.11.30 21:39:46.030 2: TSCUL_condUpdateHM: TSCUL new condition disconnected
2017.11.30 21:39:48.568 3: Setting TSCUL serial parameters to 38400,8,N,1
2017.11.30 21:39:50.139 0: TSCUL_Parse: TSCUL External Reset Restart detected: C_RE
2017.11.30 21:39:50.140 1: TSCUL_Parse: TSCUL Restart detected: C_ReadyCSM868
2017.11.30 21:39:50.649 3: TSCUL: Possible commands: ABCEFGJKMNRUVWXYZeilmtx
2017.11.30 21:39:51.334 1: TSCUL is VERSION_TS, VTS 0.19 CSM868, nanoCUL_V1.x
2017.11.30 21:39:51.790 2: TSCUL_condUpdateHM: TSCUL new condition non-HM
2017.11.30 21:39:53.820 2: TSCUL_Parse: TSCUL unknown message T071F003200
2017.11.30 21:39:54.822 1: /dev/ttyU0 disconnected, waiting to reappear TSCUL
2017.11.30 21:39:55.277 2: TSCUL_condUpdateHM: TSCUL new condition disconnected
usw.

Und list TSCUL:
Internals:
   CMDS       Noanswer
   Clients    STACKABLETS:STACKABLE:HMS:TSKS300:TSCUL_WS:TSCUL_TX:UNIRoll_TS:CUL_IR:IT:CUL_HOERMANN:TSCUL_EM
   DEF        /dev/ttyU0@38400 0000
   DevIoJustClosed 1
   DeviceName /dev/ttyU0@38400
   FHTID      0000
   NAME       TSCUL
   NEXT_OPEN  1512074618
   NR         275
   PARTIAL
   STATE      disconnected
   SlowRF_BitBufferOvrfl 0
   SlowRF_BucketOvrfl 0
   TYPE       TSCUL
   VERSION    VTS 0.19 CSM868
   VERSION_HW nanoCUL_V1.x
   VERSION_TS yes AES ChTblSize:220
   XmitOpen   0
   initString X21
AM5
AHF23102
   owner_CCU  VCCU
   Helper:
     DBLOG:
       Xmit-Events:
         logdb:
           TIME       1512074557.52021
           VALUE      non-HM:20 disconnected:22
       cond:
         logdb:
           TIME       1512074557.52021
           VALUE      disconnected
       prot_disconnected:
         logdb:
           TIME       1512074557.52021
           VALUE      last
       prot_non-HM:
         logdb:
           TIME       1512074555.09708
           VALUE      last
       state:
         logdb:
           TIME       1512074558.52258
           VALUE      disconnected
   MatchList:
     1:STACKABLETS ^\*
     2:STACKABLE ^\*
     E:HMS      ^810e04....(1|5|9).a001
     F:TSKS300  ^810d04..4027a001
     G:TSCUL_WS ^K.....
     H:TSCUL_EM ^E0.................
     K:CUL_HOERMANN ^R..........
     M:CUL_IR   ^I............
     N:TSCUL_TX ^TX..........
     P:IT       ^i.(:.|.....)
     Q:UNIRoll_TS ^[\dA-F][\dA-F][\dA-F][\dA-F][\dA-F](B|D|E)
   READINGS:
     2017-11-30 21:42:37   Xmit-Events     non-HM:20 disconnected:22
     2017-11-30 21:42:38   cmds            No answer
     2017-11-30 21:42:37   cond            disconnected
     2017-11-30 21:42:37   prot_disconnected last
     2017-11-30 17:22:42   prot_init       last
     2017-11-30 21:42:34   prot_non-HM     last
     2017-11-30 21:42:38   state           disconnected
   helper:
     ChkPart    0
     RA_Timeout 0
     VTS        1
     VTS_ACK    1
     VTS_AES    1
     hmTSAt1Add
     DEVIO:
       RXfailTO
     HM:
       ChTblSize  220
       HMactive   0
       hmCrdts    9
       ChTbl:
     cnd:
       250        20
       253        22
     hmLogHist:
















     q:
       HMcndN     253
       hmLanQlen  1
       cap:
         sum        0
     ref:
       doNbyterate 50
       ioByteRate 3840
       ioByteRateMeas 0
       lHMt       4294967295
       lSys       1598474265.66246
       pngFrc     1
       pngLm      70
       pngMax     -100000000
       pngMaxTot  -100000000
       pngMin     100000000
       pngRef     100000000
       scF        1
       scFN       1
       scHT       4294967295
       scST       1598474265.66246
Attributes:
   hmId       F23102
   hmLanQlen  1_min
   icon       cul_cul
   model      nanoCUL
   room       System
   verbose    4

Aber er meldet sich zwischendrin mit "Possible commands: ABCEFGJKMNRUVWXYZeilmtx"

Ich schiebe jetzt erst mal wieder die a-culfw drauf, mein Wohnzimmer wird kalt ;-)
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: noansi am 30 November 2017, 22:42:37
Hallo Florian,

hmm, hast Du einen 16MHz nano oder einen 8MHz?
Die Firmware ist für 16MHz.

Dann habe ich in der 0.19 mehr HM Puffer eingestellt und damit das RAM weiter ausgereizt.
Das könnte auch Merkwürdigketen auslösen.

Ich habe mal eine neue Firmware für 16MHz nano aber etwas reduzierter Speichelast angehangen.
Wenn die läuft können wir weiter testen, was ggf. noch an Speicher raus zu holen sein kann.

FS20 konnte ich auch noch nicht testen. Du hast aber FS20 Geräte, die ggf. beim Start für ein Problem sorgen könnten, bis auf HM umgeschaltet ist.
Ein T code ist aber durchgekommen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: noansi am 30 November 2017, 22:53:50
Hallo Florian,

bei der nano Beschaltung bist Du bei der "Standard"-Schaltung geblieben? Oder gibt es Besonderheiten?

Die Resets wundern mich noch, oder hast Du den nano selbst abgezogen und angesteckt?

Mangels eigener Hardware kann ich leider nano und mini nicht selber testen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: OiledAmoeba am 01 Dezember 2017, 01:08:14
Scheinbar war's der Speicher. Er springt jetzt nicht mehr ständig weg. Aber er liest jetzt fleißig meine verbliebenen FHT's (als "Raumtemperatursensor" noch halbwegs brauchbar) und lässt sich nicht umstellen. HomeMatic not supported, wrong Firmware?

Die verschiedenen gets sehen so aus:
TSCUL ITSndFreq => 433.920MHz
TSCUL SlowRFSndFreq => 868.300MHz
get TSCUL assignIDs needs rfmode HomeMaticTSCUL ccconf => freq:868.300MHz freqOffs:0.000kHz bWidth:325kHz freqIF:177.73kHz rAmpl:42dB sens:12dB dRate:2.461kBit/s
agcPrio:1 agcWait:32 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:0 AGC_FREEZE:0
CCAmode:1 csRelThr:10dB csAbsThr:4dB
TSCUL cmds =>  A B C E F G J K M N R U V W X Y Z e i l m t x
TSCUL credit10ms => 1592
SlowRF TSCUL Receive Statistic:

freq:868.300MHz freqOffs:0.000kHz bWidth:325kHz freqIF:177.73kHz rAmpl:42dB sens:12dB dRate:2.461kBit/s
agcPrio:1 agcWait:32 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:0 AGC_FREEZE:0
CCAmode:1 csRelThr:10dB csAbsThr:4dB
TSCUL fhtbuf => No answer

Weiter bin ich nicht gekommen.
get fhtbuf hat ihn abgeschossen. (obwohl er im SlowRF war)
set reload führte dazu, das er wieder toggelte und Sonderzeichen ausspuckte.
Nachdem ich ihn aus- und wieder eingesteckt hatte, fing er gleich wieder an zu toggeln.

Dann habe ich ihn (ohne die DEF zu ändern!) auf dummy=1, rfmode=HomeMatic gesetzt (er hat ja auf get cmds mit A geantwortet) und anschließend das Attribut dummy wieder gelöscht. Wie bin ich auf Dummy gekommen? Eigentlich wollte ich ihn abschalten, weil ich ihn auf a-culfw zurückflashen wollte..
Und nu? Er funkt fein im HomeMatic-Modus.
Verbose hab ich wieder auf 2 runter, nicht, dass da morgen die Festplatte voll ist ;-)
Morgen nach er Arbeit probiere ich dann sein Verhalten bei AES.

Also bleibe ich erst mal bei "Scheinbar war's der Speicher".

Ach, fast vergessen: Den nanoCUL habe ich nicht selbst gebaut (ich hatte ihn aus der Bucht, glaub ich) und dank meiner alten Befestigung mit Malerkrepp sind durch den Schrumpfschlauch nur noch die LED's zu erkennen... Vielleicht schaffe ich es mal, ihn zu reinigen. Dann kann ich sicher genauere Info's geben.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: Bytechanger am 01 Dezember 2017, 09:15:22
HAllo noansi,

vielen Dank. Aber ich sehe keine Anlage in Deinem Post.

Greets

Byte
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: OiledAmoeba am 01 Dezember 2017, 20:15:21
Hmpf, da bin ich wieder. Never touch, oder so...
Wollte gerade den Fensterkontakt anlernen, siehe da, der TSCUL sendet nicht mehr, trotz Condition OK. Empfangen hat er hm noch fleißig.
Tja, fhem neu gestartet (vorher attr global motd none und save):
2017.12.01 19:43:36.767 3 : Setting TSCUL serial parameters to 38400,8,N,1
2017.12.01 19:43:38.337 0 : TSCUL_Parse: TSCUL External Reset Restart detected: C_RE
2017.12.01 19:43:38.339 1 : TSCUL_Parse: TSCUL Restart detected: C_ReadyCSM868
2017.12.01 19:43:38.850 3 : TSCUL: Possible commands: ABCEFGJKMNRUVWXYZeilmtx
2017.12.01 19:43:39.530 1 : TSCUL is VERSION_TS, VTS 0.19 CSM868, nanoCUL_V1.x
2017.12.01 19:43:39.978 2 : TSCUL_condUpdateHM: TSCUL new condition non-HM
2017-12-01 19:43:40.715 TSCUL TSCUL cond: non-HM
2017-12-01 19:43:40.715 TSCUL TSCUL Xmit-Events: disconnected:2 non-HM:1
2017-12-01 19:43:40.715 TSCUL TSCUL prot_non-HM: last
2017-12-01 19:43:41.600 CUL_HM VCCU TSCUL:non-HM,
2017-12-01 19:43:42.690 TSCUL TSCUL Initialized
2017.12.01 19:43:42.795 1 : /dev/ttyU0 disconnected, waiting to reappear TSCUL
2017-12-01 19:43:43.346 TSCUL TSCUL DISCONNECTED
2017.12.01 19:43:43.346 2 : TSCUL_condUpdateHM: TSCUL new condition disconnected
2017-12-01 19:43:43.931 TSCUL TSCUL cond: disconnected
2017-12-01 19:43:43.931 TSCUL TSCUL Xmit-Events: disconnected:3 non-HM:1
2017-12-01 19:43:43.931 TSCUL TSCUL prot_disconnected: last
2017-12-01 19:43:44.522 CUL_HM VCCU TSCUL:disconnected,
2017-12-01 19:43:45.006 TSCUL TSCUL disconnected


Messages collected while initializing FHEM:
configfile: ASKSIN not supported
ASKSIN not supported

Autosave deactivated


Was mich irritiert: TSCUL External Reset Restart detected: C_RE - muss das so?

Nächste Schritte: (Log darunter)
attr TSCUL dummy 1
set TSCUL reopen
im Log tauchen nun T-Protokolle auf, also attr TSCUL rfmode HomeMatic. Jetzt werden A-Protokolle empfangen.
Leider kann er noch immer nicht senden, da ich die hmId nicht setzen kann: "ASKSIN not supported". Kein Wunder, während des Init war es ein Dummy. Damit "Nocmdsfordummies", also auch kein A...

Hier das Log:2017.12.01 19:56:31.941 3 : Setting TSCUL serial parameters to 38400,8,N,1
2017.12.01 19:56:33.518 0 : TSCUL_Parse: TSCUL External Reset Restart detected: C_RE
2017.12.01 19:56:33.523 1 : TSCUL_Parse: TSCUL Restart detected: C_ReadyCSM868
2017.12.01 19:56:34.190 3 : TSCUL: Possible commands: Nocmdsfordummies
2017.12.01 19:56:34.193 1 : TSCUL is VERSION_TS, VTS 0.19 CSM868, nanoCUL_V1.x
2017.12.01 19:56:34.198 2 : TSCUL_condUpdateHM: TSCUL new condition non-HM
2017-12-01 19:56:35.102 TSCUL TSCUL cond: non-HM
2017-12-01 19:56:35.102 TSCUL TSCUL Xmit-Events: disconnected:3 non-HM:4
2017-12-01 19:56:35.102 TSCUL TSCUL prot_non-HM: last
2017-12-01 19:56:35.123 CUL_HM VCCU TSCUL:non-HM,
2017-12-01 19:56:35.976 TSCUL TSCUL Initialized
2017.12.01 19:56:40.446 3 : TSCUL: Possible commands: Nocmdsfordummies
2017.12.01 19:56:40.793 1 : TSCUL is VERSION_TS, VTS 0.19 CSM868, nanoCUL_V1.x
2017.12.01 19:56:40.811 2 : TSCUL_condUpdateHM: TSCUL new condition non-HM
2017-12-01 19:56:41.802 TSCUL TSCUL cond: non-HM
2017-12-01 19:56:41.802 TSCUL TSCUL Xmit-Events: disconnected:3 non-HM:5
2017-12-01 19:56:41.802 TSCUL TSCUL prot_non-HM: last
2017-12-01 19:56:41.815 CUL_HM VCCU TSCUL:non-HM,
2017-12-01 19:56:42.034 TSCUL TSCUL Initialized
2017.12.01 19:56:42.036 1 : /dev/ttyU0 reappeared (TSCUL)
2017-12-01 19:56:42.475 TSCUL TSCUL CONNECTED
2017.12.01 19:56:42.835 2 : TSCUL_condUpdateHM: TSCUL new condition non-HM
2017-12-01 19:56:43.450 TSCUL TSCUL cond: non-HM
2017-12-01 19:56:43.450 TSCUL TSCUL Xmit-Events: disconnected:3 non-HM:6
2017-12-01 19:56:43.450 TSCUL TSCUL prot_non-HM: last
2017-12-01 19:56:43.463 CUL_HM VCCU TSCUL:non-HM,
2017.12.01 19:56:43.464 4 : TSCUL_Parse: TSCUL 007482 A F702 00009160 00 15 AA001122AA001122AA001122AA001122AA001122AA _ping
2017-12-01 19:56:59.169 TSCUL TSCUL UNKNOWNCODE T071F002200
2017.12.01 19:56:59.171 2 : TSCUL_Parse: TSCUL unknown message T071F0022002017-12-01 19:56:59.795 TSCUL TSCUL UNKNOWNCODE T4135002200
2017.12.01 19:56:59.797 2 : TSCUL_Parse: TSCUL unknown message T41350022002017-12-01 19:57:00.218 ROOMMATE rr_Florian durTimerAbsence_cr: 53
2017.12.01 19:57:01.199 2 : TSCUL_condUpdateHM: TSCUL new condition init
2017.12.01 19:57:01.202 1 : PERL WARNING: Use of uninitialized value in numeric ge (>=) at ./FHEM/00_TSCUL.pm line 4579.
2017-12-01 19:57:01.645 TSCUL TSCUL cond: init
2017-12-01 19:57:01.645 TSCUL TSCUL Xmit-Events: init:1 disconnected:3 non-HM:6
2017-12-01 19:57:01.645 TSCUL TSCUL prot_init: last
2017-12-01 19:57:02.072 CUL_HM VCCU TSCUL:init,
2017.12.01 19:57:02.072 2 : Switched TSCUL rfmode to HomeMatic
2017-12-01 19:57:02.514 Global global ATTR TSCUL rfmode HomeMatic
2017.12.01 19:57:03.227 4 : TSCUL_SendPingHM TSCUL ApC0 send. Throttle continue
2017.12.01 19:57:03.821 4 : TSCUL_ParseTsHM: TSCUL Xmit release ping received, XmitOpen ->2 : 028437 A F702 00029724 00 01 C0 _ping
2017.12.01 19:57:04.026 4 : TSCUL_SendPingHM TSCUL ApC0 send. Throttle continue
2017.12.01 19:57:04.045 4 : TSCUL_ParseTsHM: TSCUL Xmit release ping received, XmitOpen ->1 : 028710 A F702 00030520 00 01 C0 _ping
2017.12.01 19:57:09.340 4 : TSCUL_Parse: TSCUL 033995 A F702 00035528 00 15 AA001122AA001122AA001122AA001122AA001122AA _ping
2017.12.01 19:57:31.383 1 : PERL WARNING: Use of uninitialized value in numeric gt (>) at ./FHEM/00_TSCUL.pm line 1544.
2017.12.01 19:57:31.455 4 : TSCUL_Parse: TSCUL 056041 A F701 00057844 00 0F A0 8610 51C812 000000 0AB0F00C0700 -82dB -82


Irgendwas klemmt da noch...

EDIT: Nach deleteattr TSCUL dummy sendet er auch wieder. Trotzdem finde ich den Weg, ihn zum laufen zu bringen etwas holprig...
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: noansi am 01 Dezember 2017, 21:11:26
Hallo Florian,

was kommt auf ein "get unusedstack" ?

Zitatget fhtbuf hat ihn abgeschossen.
FHT80b ist nicht in der Firmware konfiguriert. Daher wird auf T03 (was damit an den nano gesendet wird) nicht mit der erwarteten Antwort geantwortet, sondern das als Disconnected interpretiert. Da kann ich wohl den Match noch modifizieren.

Du kannst mal get raw T03 eingeben. Da müsste dann unknow command gefolgt von der Befehlsliste kommen.

Kannst Du verbose mal auf 5 stellen. Vielleicht ist dann zu sehen, was das Verschlucken auslöst.

Gruß, Ansgar.

Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: noansi am 01 Dezember 2017, 21:32:52
Hallo Florian,

ZitatWas mich irritiert: TSCUL External Reset Restart detected: C_RE - muss das so?

Es ist ein nano Neustart aufgetreten sagt die Meldung. Eigentlich sollte External Reset dann die Reset Ursache sein. Macht der nano das eventuell, wenn die Baudrate umgestellt wird?
Der Watchdog hat jedenfalls nicht zugeschlagen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: noansi am 01 Dezember 2017, 21:33:37
Hallo Byte,

hängt aber dran. Warst Du nicht eingeloggt?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: Bytechanger am 02 Dezember 2017, 09:55:43
Oops, stimmt.

Habs kopiert, FHEM neu gestartet. Leider ohne Erfolg.
Wie lange braucht es, bis es sich durchsetzt?
Ich habe beim CUL die beiden neuen Sensoren und einen Rauchmelder in den IDs, obwohl alle erstmal dem HMLAN zugewiesen sind!

Greets

Byte
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: noansi am 02 Dezember 2017, 10:30:17
Hallo Byte,

ZitatWie lange braucht es, bis es sich durchsetzt?
Beim Senden ans device sollte der Wechsel stattfinden. (grob gesagt. es ist noch komplizierter)

Zitatobwohl alle erstmal dem HMLAN zugewiesen sind
Was steht bei den devices oben in den Internals jeweils bei IODev?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: Bytechanger am 02 Dezember 2017, 10:42:34
OK,

also habe ich ein getConfig gesendet und zusätzlich bei den "passiven" Fensterkontakten mal den Sabotagealarm durch Öffnen des Gehäuses ausgelöst.
Damit sind die Devices nun alle beim HMLAN, was auch die Eintragungen jetzt in den INTERNALS zeigen.

Greets

Byte

(Sabotagealarm, da ich die Fensterkontakte als "Wassersensoren" missbraucht habe und an den Reedkontakt Kabel angelötet habe; damit war ein einfaches Öffnen/Schließen jetzt auf die Schnelle nicht möglich)
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: noansi am 02 Dezember 2017, 10:49:21
Hallo Byte,

welche Firmware Version hast Du jetzt auf dem nano drauf?

Wenn es die VTS 0.19 ist, was sagt get unusedstack bei dem nano?

Oder kannst Du mit der VTS 0.19 die Probleme von OiledAmoeba nachvollziehen?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: Bytechanger am 02 Dezember 2017, 10:52:45
Also ich habe einen CUL V3.4.
Ich dachte, ich hätte V0.19 drauf, wenn ich aber in die INTERNALS schaue, sehe ich

VERSION
VTS 0.18 CUL868
VERSION_HW  CUL_V3.4
VERSION_TS  yes AES ChTblSize:220

Readings:
version   VTS 0.10 CUL868



CUL0 unusedstack => No answer
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: noansi am 02 Dezember 2017, 11:03:39
Hallo Byte,

ZitatAlso ich habe einen CUL V3.4.
Ja stimmt, dann vergiss es, kein sinnvoller Vergleich zum nano.

ZitatVTS 0.18 CUL868
ZitatCUL0 unusedstack => No answer
VTS 0.18 kann das noch nicht.

ZitatReadings:
version   VTS 0.10 CUL868
kannst Du über get version aktualisieren.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: Bytechanger am 02 Dezember 2017, 12:52:48
Sorry, ging davon aus, dass V0.19 drauf ist.

Nun ergibt
CUL0 unusedstack => 439


Messages collected while initializing FHEM:
configfile: ASKSIN not supported
ASKSIN not supported

hatte ich auch schon mal gesehen.
Hatte vermutet, dass ich nicht alle .pm Dateien aktualisiert hatte.



Byte
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: OiledAmoeba am 02 Dezember 2017, 23:46:30
Moin,
bin leider jetzt erst wieder am PC. Hatte heute morgen mal einen "Syncverlust" und meine Versuche der Rettung mit Verbose 5 mitgeschrieben.
Dabei habe ich ihn mindestens einmal stromlos gemacht, weiß leider nicht mehr, wann das genau war. Da das Log wieder mit Steuerzeichen gefüllt wurde, die ich hier nicht reinkopieren kann, habe ich das als Datei rangehängt.

Derzeit behelfe ich mir mit einem Notify, denn wenn sich die Verbindung verabschiedet hat, geht er nicht sofort auf disconnected, worauf man triggern könnte, sondern hm meldet IOErr:define n_TSCULreset notify hm..*:IOErr|cr:reset \
{fhem ("attr TSCUL dummy 1")};; {fhem("sleep 2;; set TSCUL reopen")};; {fhem("sleep 7;; attr TSCUL rfmode SlowRF")};; {fhem("sleep 8;; attr TSCUL rfmode HomeMatic")};; {fhem("sleep 10;; deleteattr TSCUL dummy")};; {fhem("set cr ok")}

hm..* mit zwei Punkten, damit das Notify nicht hm und die Heizungen verwechselt (die alle mit hm. beginnen). Kann ich dann automatisiert über IOErr oder manuell über den dummy cr auslösen und klappt erstmal. Natürlich nicht die Lösung, denn laut Wiki soll bei 1% auch IOErr kommen, also seeeehr unsauber, mein Lösungsweg...
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: klausw am 03 Dezember 2017, 00:04:01
Hallo Ansgar,

Zitat von: noansi am 02 Dezember 2017, 10:49:21
Oder kannst Du mit der VTS 0.19 die Probleme von OiledAmoeba nachvollziehen?

Die Frage galt zwar nicht mir, aber ich habe die gleichen Probleme wie OiledAmoeba mit dem NanoCUL VTS 0.19 und VTS 0.18

Das Logfile füllt sich mit
TSCUL_Parse: TSCUL External Reset Restart detected: C_RE

Im Testsystem lief alles (da habe ich aber nur nen Dimmer und Rauchmelder dringehabt. Alles Ohne AES)
Beim aufspielen auf das Produktivsystem lief nix mehr.
Derzeit kann ich nicht testen, da ich nicht mehr vor Ort bin. Ich bin erstmal wieder auf die TSCUL_fwcode_00_10_FHEM_Modules_00_11 gegangen.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: OiledAmoeba am 03 Dezember 2017, 00:24:47
Hab noch unusedstack vergessen: TSCUL unusedstack => 313
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: noansi am 03 Dezember 2017, 00:50:08
Hallo Florian, hallo Klaus,

ok, nun denke ich, zu wissen, was passiert.

Das Öffnen der seriellen Schnittstelle toggelt wohl DTR auf dem nano, was einen Reset auslöst, vgl. Schaltplan.
Die wilden Zeichen kommen wohl daher, dass der nano im Bootloader auf 57600 gesetzt wird und damit was wildes bei der seriellen Schnittstelle ankommt, die auf 38400 (USB/seriell Interfacebaustein) eingestellt ist.

Damit werden meine Reset Detektionsmessages mit dem Abschluss des Reboot des nanos ausgelöst.
Beim Abfragen der möglichen Befehle kommt es dann zum Problem, da die Reset Detektionsmessages durch den Parser laufen und dort wieder eine Initialisierungssequenz anstoßen (die im Normalfall auch sinnvoll ist). Die läuft auch schön nach Log durch.
Im Anschluss kommt ein Timeout für die ursrüngliche Abfrage der möglichen Kommandos, da es einfach zu lange dauert, respektive die Antwort nicht kommt.
Das wird als "totes" device interpretiert und die Schnittstelle wird wieder geschlossen und erneut geöffnet, was den Teufelskreis wieder anstößt. Blöd.

Ich melde mich, wenn ich dazu eine Code Lösung habe. Leider habe ich kein Testdevice, bei dem dieser Fall auftritt.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: noansi am 03 Dezember 2017, 03:03:00
Hallo Florian, hallo Klaus,

hier ein neuer Satz Module und Firmware.

Bitte gebt mir Bescheid, ob es damit auch wieder mit dem nano klappt.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: OiledAmoeba am 03 Dezember 2017, 03:27:13
Hallo Ansgar,

Du hast Recht! Ich habe ein wenig gegoogelt und dabei kam raus, dass das ein gewünschtes Verhalten des Arduino als "Entwicklerboard" ist. Mir ist da noch das in die Finger gefallen:import os
import sys
import termios
import fcntl

        self.fd = sys.stdin.fileno()

        # Stop resetting the arduino on serial connect

        self.newattr = termios.tcgetattr(self.fd)
        self.newattr[2] = self.newattr[2] & ~termios.HUPCL
        termios.tcsetattr(self.fd, termios.TCSANOW, self.newattr)

Das soll den Neustart beim Connect verhindern. Sieht auf den ersten Blick nach ein paar Zeilen aus einem Sketch aus...  Da ich hier keine Entwicklungsumgebung für HomeBrew habe, kann ich da leider nicht näher prüfen.
Ich habe auch eine Codezeile für Perl gefunden, die softwaremäßig beim Zugriff das Verhalten unterbinden soll. Leider unterstützt freeBSD das scheinbar nicht   $po->dtr_active(0);



edit 03.38h: V0.20 läuft bei mir!
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.19
Beitrag von: noansi am 03 Dezember 2017, 05:54:56
Hallo Florian,

ZitatV0.20 läuft bei mir!
Schön.  :) Ohne Modifikationen denke ich.

Wie ist der unusedstack Stand nach einiger Laufzeit?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.20
Beitrag von: noansi am 03 Dezember 2017, 13:48:15
Hallo Testwillige,

hier eine neue Version 0.20 der Timestamp Firmware und der dazu benötigten FHEM Module.

Diese Version sollte Initialisierungsprobleme bei nanoCUL und miniCUL, bedingt durch deren Reboot beim Öffnen der Schnittstelle, beheben.

Außerdem Verbesserungen bei der HM-Devicezuordnung mit mehreren HM IOs, insbesondere nach einem Neustart von FHEM.

Es ist eine Prüfung auf Stacküberlauf eingebaut. Am Anfang des heap werden zwei Byte mit einem Bitmuster beschrieben. Wird das verändert, dann ist der Speicher wahrscheinlich korrumpiert, was durch einen Stacküberlauf ausgelöst sein sollte. Sofern der CUL dann noch kann sendet er ein "C_M" an TSCUL, was zu einem entsprechenden Log Eintrag führt.
Damit kann man vorsichtig die Speichergrenzen ausloten. Ein langer Testzeitraum ist aber erforderlich, um einigermaßen sicher zu sein, dass der worst case auch mal durchlaufen worden ist.
Außerdem ist ein Kommando mU (je nach Firmware) eingebaut, mit dem man den vom Stack ungenutzen heap in etwa auslesen kann (auch als get unusedstack in TSCUL verfügbar). Auch hier gilt, nur nach langer Laufzeit einigermaßen sinnvoll. Es macht sicher keinen Sinn auf Grund des Wertes den Speicher bis auf das letzte Byte auszuquetschen, denn weiterhin hängt die Stacknutzung vom gewählten Protokoll und Einstellungen ab.

In TSCULflash ist der Versuch des Flashens auch von NanoCULs und MiniCULs ergänzt. Da ich es aber mangels Hardware nicht testen kann, bitte ich um Feedback, ob es funktioniert. Vor dem Flashen wird ein "B00" also Reset für die TSCUL Firmware an den nano/Mini geschickt, 1 Sekunde gewartet und dann versucht mit avrdude zu flashen. Wäre nett, wenn das mal jemand testen und Feedback geben könnte.
Also erst die Firmware in den FHEM/Firmware Ordner kopieren und dann in FHEM mit
TSCULflash <nanodevicename> TSnanoCUL
bzw.
TSCULflash <minidevicename> TSminiCUL
versuchen zu Flashen. Im Log sollte danach (dauert etwas) die avrdude Ausgabe zu finden sein.

AESCommReq wird. Die Nutzung ist unverändert zu Standard CUL, sprich, beim gewünschten Gerät/Kanal aesCommReq auf 1 setzen und ggf. noch aesKey passend zum verteilten Key setzen.
Es werden von tsculfw nur die Keys 0 (Default Key) bis 3 unterstützt.

Diese Erweiterung erfordert jedoch auch zusätzliche Empfangspuffer im knappen Speicher des CULs. Ein CUL V3 nutzt bis zu 6 Empfangspuffer. Auch der FlashSpeicherbdarf ist angestiegen, so dass einige Protokolle nicht mehr gleichzeitig in ein Kompilat passen. Das sollte aber weniger tragisch sein, da im ASKSIN Modus ohnehin nur HM empfangen werden kann.

Bei der nanoCUL und miniCUL Version habe ich nur 3 Empfangspuffer vorgesehen, um den Restpeicher für den Stack zu erhalten. Vielleicht hat jemand die Möglichkeit, die max. Stacknutzung mal ausgiebig zu testen, damit der verbleibende Speicher optimal "ausgequetscht" werden kann???

Bei CUL V2 reicht der verfügbare Speicher leider hinten und vorne nicht aus, um diese Version nutzen zu können.

Im Anhang ist in TSCUL_fwcode_00_20b_FHEM_Modules_00_25.zip wieder die Timestamp Firmware zu finden. Getestet habe ich TSCUL_V3, TSCOC, TSCUNO2 und TSSCC.

Die tsculfw Firmware kann für TSCUL_V3 und TSPIGATOR (an CUNX) mit FHEM mit dem TSCULflash geflashed werden. Die anderen müssen mit dem jeweiligen Flash Programmer geflashed werden.
So z.B. https://forum.fhem.de/index.php/topic,24436.msg631743.html#msg631743 kann es mit einem USB CUL Stick gehen, wenn man nicht TSCULflash verwendet.
TSCULflash ist erweitert auf COC, SCC, CCD, rpiaddon, CUNO2 und CUNO. Jedoch ist es nicht ganz so einfach zu handhaben, da zum einen teilweise die Taste zu drücken ist und bei Raspberry PI Modulen die Rechteproblematik für den Zugriff auf die IO-Pins überwunden werden muss. Tips dazu in der Command-Ref auch bei RPI_GPIO.
Bei einem Stapel aus SCC mit aufgesetztem COC, CCD oder (rpiaddon?) ist unbedingt beim SCC Flash darauf zu achten, die Taste am gewünschten Modul zu drücken. Sonst wird das oberste Nicht-SCC Modul mit der SCC Firmware geflashed.
Mit CUNO2 ist das flashen noch nicht getestet (nur über USB!). Wichtig, aber auch hier, die Taste zu drücken.

Es gibt nicht den Luxus des Downloads beim TSCULflash, sondern die Firmware muss händisch in den FHEM/firmware Ordner kopiert werden. Der Typ ist dann TSCUL_V3.
Beispiel:
TSCULflash MeinCulDevice TSCUL_V3

Wichtig für SCC Nutzer. TSSTACKED ist entfallen und wird nicht mehr unterstützt.
Statt dessen gibt es das neue Modul STACKABLETS (als Abwandlung von Rudolfs STACKABLE).
Dieses wird sozusagen zwischen die Stackteilnehmer eingebaut.

Beispiel für fhem.cfg:
#erstes SCC Modul als Basis
define SCC_WS868 TSCUL /dev/ttyAMA0@38400 0000
attr SCC_WS868 event-on-change-reading Ints_per_sec,IntCalcStat,MatchStat
attr SCC_WS868 rfmode SlowRF
attr SCC_WS868 room Receiver
attr SCC_WS868 sendpool CUL_HM868,SCC_WS868
attr SCC_WS868 verbose 1

#neues STACKABLETS virtuelles IO device
define STACK_1 STACKABLETS SCC_WS868
attr STACK_1 verbose 1

#zweites SCC Modul
define SCC_HM868 TSCUL FHEM:DEVIO:STACK_1:38400 1034
attr SCC_HM868 event-on-change-reading cond
attr SCC_HM868 hmId F11034


Ergänzender Hinweis zu USB CULs: 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_08\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 1234
bzw.
define CUL_433 TSCUL /dev/CUL433_0@12000000 0000
definiert 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 Zip Datei sind ebenfalls die ergänzten Module zu finden, die zur Nutzung der Firmware erforderlich sind.

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
16_STACKABLETS.pm -> statt der 16_STACKABLE.pm, aus STACKABLE werden damit STACKABLETS devices in der fhem.cfg (händisch anzupassen)

10_UNIRoll_TS.pm  -> statt der 10_UNIRoll.pm, mit TSCUL 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 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 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 IO-devices zu verwenden, aus CUL_WS wird dann TSCUL_WS  in der fhem.cfg (händisch anzupassen)
15_TSCUL_EM.pm   -> statt der 15_CUL_EM.pm, mit TSCUL IO-devices zu verwenden, aus CUL_EM wird dann TSCUL_EM  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.

Außerdem:

10_CUL_HM.pm         -> angepasste Version zur Nutzung mit TSCUL/tsculfw. Derzeit ist die Nutzung dieses Moduls zwingend erforderlich!!!
98_TSCULflash.pm     -> Zum Flash von TSCUL_V3, TSPIGATOR (an CUNX) mit Datei in FHEM/firmware

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 10_CUL_HM.pm 00_TSCUL.pm 16_STACKABLETS.pm DevIoTS.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.pm CalcUtil.pm 98_TSCULflash.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` }

Noch ein Hinweis: TSCUL fragt auch die Firmwareversion der tsculfw auf 0.16 ab. Eine ältere Version wird also nicht unterstützt, da sich diesmal auch wieder das Timestamp Protokoll (inkompatibel zum vorherigen Stand) geändert hat, so dass mit dem Austausch der FHEM Module auch ein Firmwareupdate des CUL devices erforderlich ist!

Noch ein Tip zur Haltbarkeit des CULs. Jedesmal, wenn einem HM-Device das IODev durch Roaming neu zugeordnet wird, führt das zu EEPROM Schreibvorgängen in den beteiligten CULs. Die Lebensdauer des EEPROMs ist begrenzt (100000 Schreibzyklen laut Datenblatt). Daher rate ich zur Nutzung des VorzugsIOs beim Device Attribut IOgrp. Also nicht einfach stumpf
attr HMdeviceName IOgrp VCCU
setzen, sondern
attr HMdeviceName IOgrp VCCU:CUL_mit_gutem_Empfang_fuer_Device
sofern die Roaming Funktionalität entsprechend RSSI für das jeweilige device nicht zwingend benötigt wird. Ein Fallback auf einen anderen CUL bleibt dennoch möglich.

Ergänzt ist auch noch ein set TX3Send.
Damit lassen sich TX3 Sensordatentelegramme auf 433er CULs versenden.
Beispiel:

define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 TX3Send H:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." SID:23 U")}

define NF_HumOut notify Sen_Aussen:humidity.* {fhem("set TSCUL_WS433 TX3Send H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." SID:23 U")}


Gruß, Ansgar.

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

EDIT: 00_TSCUL.pm nochmal etwas fehlerkorrigiert.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.20
Beitrag von: noansi am 03 Dezember 2017, 18:41:36
Hallo Zusammen,

mir sind noch 3 Fehler in der letzten Änderung von 00_TSCUL.pm aufgefallen. Bitte die aktuelle Version oben verwenden.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.20
Beitrag von: OiledAmoeba am 03 Dezember 2017, 19:30:07
Mit der Version von heute Nacht:
TSCUL uptime => 0 14:50:10
TSCUL unusedstack => 311


Mir ist noch aufgefallen heute Nacht, dass er state overload nicht ändert, wenn cond zurück auf ok geht. Ich hatte eine Situation, da war credit10ms > 2000 und state war noch immer overload (auch nach über 1h).

Ach ja, mein kleines Rettungs-Notify ist abgeschaltet.

Gesendet von meinem SM-G900F mit Tapatalk

Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.20
Beitrag von: noansi am 03 Dezember 2017, 20:42:03
Hallo Florian,

ZitatMit der Version von heute Nacht
Nimm bitte die letzte Version von Firmware und Modulen.

Zitatdass er state overload nicht ändert, wenn cond zurück auf ok geht
Soll nicht so sein.

Es gibt drei Möglichkeiten, die einen overload erzeugen.
Zum einen die credits.
Und zum anderen kein freier Sendepuffer oder AES-Puffer.

Sendest Du dauernd etwas?
Oder hast Du AES noch nicht sauber eingerichtet, so dass devices häufig versuchen erneut zu senden?
Oder läuft da noch ein getConfig im Hintergrund?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.20
Beitrag von: noansi am 04 Dezember 2017, 00:12:46
Hallo Florian,

Zitatdass er state overload nicht ändert, wenn cond zurück auf ok geht
Soll nicht nur so nicht sein, sondern kann nach Code eigentlich nicht. Nach Code sollte dann auf Initialized gewechselt werden
Nur wenn Du STATE statt state betrachtest. Vielleicht mal ein reload im Browser ausführen?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.20
Beitrag von: pte am 04 Dezember 2017, 10:57:47
Hallo Asanger,

ich teste seit Anfang August Deine TSCUL Software in meiner Installation. Diese besteht Homematic-seitig aus 2x HMLAN Konfigurationsadapter und einem über ser2net angebundenen CUL866 V3.4. Alle drei an eine VCCU gebunden.
Aktuell verwende ich noch Deinen Stand TSCUL_fwcode_00_19_FHEM_Modules_00_23.
Grundsätzlich hat sich die Stabilität des Homaticnetzes sehr verbessert, kaum resend oder gar error bei in Summe ca. 80 Homematic-Geräten.

Ich habe aber ein Problem mit einer (energiemessenden) Schaltsteckdose HM-ES-PMSw1-Pl-DN-R1. Geschaltet wird eine Warmwasserzirkulationspumpe, also eher geringe Leistung.
Es kommt immer wieder vor (anfänglich aller paar Wochen, aktuell fast täglich), dass das device sich nach einem Schaltvorgang regelrecht aufhängt und mit set_off oder set_on im state stehen bleibt, keine Befehle mehr annimmt und sich nicht einmal mehr am Harwaretaster der Schaltdose schalten lässt. Erst ein Neustart durch abziehen und anstecken hilft.
Ich habe das Gerät schon ausgetauscht, gleicher Effekt, also eher kein Exemplarfehler.

Nun zum Thema, warum ich meine Frage in diesem Thread stelle:

Deaktiviert eine attr TSCUL dummy 1 den CUL vollständig?
Wenn ja:
Dann ist der TSCUL nicht nämlich nicht schuld, denn das Problem trat auch in dieser Situation auf.
Dann gehört das ganze Thema wohl nicht hierher.

Wenn nicht:
Kann ein (fehlerhaftes) Homematic-Packet ein Gerät nach Deinen Erfahrungen derart abschießen?
Kann dies mit timing Problemen zwischen den HMLAN's und dem TSCUL zusammenhängen? Kann es zu Überlagerungen durch gleichzeitiges Senden der HMLAN und des CUL kommen oder wird dies durch die VCCU verhindert? Soweit ich es verstanden habe, senden die HMLAN selbständig ACK und wiederholen die zugehörigen Befehle.


Hast Du einen Vorschlag, wie ich dem Problem etwas näher kommen könnte?
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.20
Beitrag von: noansi am 04 Dezember 2017, 21:55:12
Hallo pte,

Zitatund sich nicht einmal mehr am Harwaretaster der Schaltdose schalten lässt. Erst ein Neustart durch abziehen und anstecken hilft.
ZitatGeschaltet wird eine Warmwasserzirkulationspumpe, also eher geringe Leistung.
Also ein nicht ohmscher Verbraucher. Bei Schaltvorgängen kann das Spannungspitzen zur Folge haben. Diese könnten die Schaltdose unglücklich stören.
Um das als Problemursache auszuschließen könntest Du statt der Pumpe mal eine Glühbirne (rein ohmscher Verbraucher) schalten. Wenn es damit nicht auftritt, dann wärest Du der Ursache ein Stück näher gerückt.
Tritt es nur bei Funkschaltvorgängen auf oder auch beim Schalten mit dem Dosentaster?

Zitatdass das device sich nach einem Schaltvorgang regelrecht aufhängt und mit set_off oder set_on im state stehen bleibt
Hat es dann den Schaltvorgang auch schon ausgeführt? Sprich, meldet ihn dann nicht zurück?

Ich habe 4 HM-ES-PMSw1-Pl mit Firmware V2.5 und so ein Problem noch bei keiner feststellen können, schalte sie aber nicht häufig (2-mal am Tag). Und auch keine induktiven Verbraucher.
Die Firmware für beide Modelle ist aber zumindest unterschiedlich.

ZitatDeaktiviert eine attr TSCUL dummy 1 den CUL vollständig?
Seit AES und Auto-Ack in der Firmware nein. Denn wenn noch ein device dem CUL zugewiesen ist, dann steckt die Einstellung im EEPROM. D.h. er würde seine automatischen Antwortabläufe ggf. noch ausführen.
Sicher aus bedeutet CUL vom USB Port abziehen.

ZitatKann ein (fehlerhaftes) Homematic-Packet ein Gerät nach Deinen Erfahrungen derart abschießen?
Sollte nicht, denn das sollte eine gut programmierte Firmware abfangen.
Ich kann jedoch von HM-WDS30-OT2-SM berichten, die nach einem getConfig nicht immer auch wieder schlafen gehen, wie sie sollten. Möglicherweise empfangen die dann schlicht das abschließende ACK nicht und bleiben einfach wach. Damit saugen die dann jedenfalls recht zügig die Batterie leer. Das hat aber wohl nichts mit Deinem Problem zu tun, ist aber ein Beispiel für ein Firmwareproblem und/oder Protokollumsetzungsproblem.

Hast den Firmwarestand 2.5 auf dem HM-ES-PMSw1-Pl-DN-R1?

Hast Du AES bei der Schaltdose aktiv? Wenn AES aktiv ist, dann deaktiviere es testweise oder aktiviere es, wenn es inaktiv ist. Damit änderst Du zumindest was am Protokollablauf und vielleicht hilft es, wenn einer der vorherigen Vorschläge nichts bringt.

ZitatAktuell verwende ich noch Deinen Stand TSCUL_fwcode_00_19_FHEM_Modules_00_23.
Gibt es mehrfach Zuweisungen eines HM-devices zu mehreren IOs (get assignIDs)?
Ich kann nur mit CULs testen. HMLAN Nebenwirkungen kann ich nur versuchen zu vermeiden.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.20
Beitrag von: noansi am 04 Dezember 2017, 23:00:58
Hallo pte,

ZitatKann dies mit timing Problemen zwischen den HMLAN's und dem TSCUL zusammenhängen?
Die sollten nicht miteinander reden.  ;)

ZitatKann es zu Überlagerungen durch gleichzeitiges Senden der HMLAN und des CUL kommen oder wird dies durch die VCCU verhindert?
Es wird über das jeweils zugewiesene IO mit den HM-Devices geredet. Überlagern sollte sich daher nichts.

Sollte dennoch HMLAN mal was senden, was tsculfw auch senden möchte und kann tsculfw das in der CCA Phase empfangen, dann wird das Senden dieser Nachricht seitens tsculfw seit VTS 0.16 abgebrochen.

ZitatSoweit ich es verstanden habe, senden die HMLAN selbständig ACK und wiederholen die zugehörigen Befehle.
tsculfw tut so was zunehmend auch seit VTS 0.14 zu zugewiesenen Devices.  :)
Mit der Zuweisung der HM-Devices zu den IOs wird auch den IOs mitgeteilt, ob sie "zuständig" sind und somit, ob sie automatisch antworten.
Nur wenn Doppelzuweisungen auftreten, würden zwei IOs einem Device antworten. Insbesondere bei AES geht das dann eher schief.

Nimm den letzten Stand, da habe ich noch etwas verbessert, um das insbesondere beim Wiederverbinden eines CUL zu verbessern.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.20
Beitrag von: pte am 04 Dezember 2017, 23:16:33
Hallo Asanger,
danke für die ausführlichen Ausführungen.
Test mit abgezogenen CUL habe ich schon probiert. Fehler tritt dennoch auf, also kein TSCUL Problem.
Die Dose hat den jeweils letzten Befehl noch ausgeführt, hängt also irgendwie beim ACK.
Ohmsche Last teste ich noch.
Ob das auch beim Schalten an der Dose passiert teste ich auch noch mal.


Gesendet von iPhone mit Tapatalk
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.20
Beitrag von: pte am 04 Dezember 2017, 23:18:09
AES nutze ich hier nicht.


Gesendet von iPhone mit Tapatalk
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.20
Beitrag von: pte am 05 Dezember 2017, 08:58:54
Noch ein paar Antworten zu Deinen Fragen:
über den Hardwaretaster ist es mir nicht gelungen, dies zu provozieren. Ist aber unsichher, da auch über Funk durchaus mehrere (20-30) Befehle fehlerfrei hintereinander ausgeführt werden.

Firmewarestand ist 2.5.

Ich bin mir inzwischen relativ sicher, dass es stets nach dem Schalten während der ACK Phase zum Absturz kommt. Ich hatte dann heute früh noch beobachtet, dass nach einem Funkbefehl die Dose schaltete ohne Rückmeldung an FHEM, dann die LED 3x gelb blinkte und danach FHEM die Quittung bekam. Darauffolgende Befehle wurden wieder normal ausgeführt und quittiert.

Ein paar Doppelzuweisung "assignIDs" habe ich gefunden (betreffen aber nicht die Dose). Wie krieg ich die wieder weg? Sollten die nach einem Neustart mit Deiner aktuellen Version verschwinden?

Bezüglich Deiner Aussage, dass immer nur über ein IO kommuniziert wird habe ich in Erinnerung im Log schon betreffend einer Kommunikation mehrere beteiligte IO's gesehen zu haben. Das können aber auch nur Empfangsnachrichten gewesen sein. Die leiten doch wohl alle IO's an FHEM weiter und erst dort werden die Duplikate gefiltert, richtig?

Ich werde das noch mal genauer prüfen und Dir dann mal einen Logmitschnitt schicken.

Hab erst mal einen angenehmen Tag.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.20
Beitrag von: noansi am 05 Dezember 2017, 19:47:56
Hallo pte,

Zitatdann die LED 3x gelb blinkte
Leider kann ich nicht sagen, was das Gerät damit sagen will?

Wie sieht der RSSI aus?

Mit TSCUL auf verbose 4 könntest Du aber Schaltvortgänge inklusive Timing Information schön mit loggen.

ZitatSollten die nach einem Neustart mit Deiner aktuellen Version verschwinden?
Ja, wenn ich alles richtig gemacht habe.  ;)
Allerdings kann ich das nur von 10_TSCUL.pm in Verbindung mit der modifzierten 10_CUL_HM.pm behaupten.
Bitte TSCUL Firmware und Module auf aktuellen Stand, siehe oben, bringen.

Die im CUL EEPROM gespeicherten Zuweisungen lassen sich grundsätzlich auch einzeln oder komplett löschen. Aber damit wäre die Änderung FHEM nocht nicht bekannt gegeben. Und wenn es bisher schon dazu gekommen ist, wird es mit dem alten Stand wohl auch wieder passieren können.

ZitatDas können aber auch nur Empfangsnachrichten gewesen sein.
Das sehr wahrscheinlich, da alle IOs im Empfangsbreich die Nachricht auch empfangen.
Du mußt bei der Interpretation schon darauf achten, ob es Sendenachrichten von IOs sind, die doppelt kommen.
Außerdem empfangen die IOs ja auch die Sendenachrichten der anderen IOs, sofern im Empfangsbereich. Da kann man sich auch schon mal vergucken.

Wenn Du Doppelzuweisungen bei IOs hast, dann würden auch alle diese IOs versuchen ihre automatische Antwort los zu werden.

ZitatDie leiten doch wohl alle IO's an FHEM weiter und erst dort werden die Duplikate gefiltert, richtig?
So ist es.
Und sollte es mal nicht so sein, ist es zumindest in 10_CUL_HM.pm so gedacht.  ;)

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.20
Beitrag von: pte am 05 Dezember 2017, 20:43:40
RSSI liegen bei -72, ich würde sagen grün/gelber Bereich
hatte heute Testschleife (1min an, 1min aus) laufen ohne Last (also ohne Pumpe). Lief 3h ohne Probleme.
Dann mit Pumpe -> keine 5 min.

Du hattest wohl den Finger drauf bezüglich Spannungsspitzen durch induktive Last. :)

Test läuft jetzt mit einem zusätzlichen Motorschutzkondensator in der Leitung zwischen Dose und Pumpe.

Werde berichten.

Firmeware und Module update ich dann nach dem Test.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.20
Beitrag von: noansi am 05 Dezember 2017, 21:02:18
Hallo pte,

ZitatDu hattest wohl den Finger drauf bezüglich Spannungsspitzen durch induktive Last.
Noch ergänzend zur Vermutung, hier https://homematic-forum.de/forum/viewtopic.php?f=19&t=29975&start=10 (https://homematic-forum.de/forum/viewtopic.php?f=19&t=29975&start=10) sind die Datenblätter zu HM-ES-PMSw1-Pl-DN-R1 und HM-ES-PMSw1-Pl im Vergleich zu sehen.

Beim HM-ES-PMSw1-Pl-DN-R1 ist ohmsche Last als Lastart angegeben.

Beim HM-ES-PMSw1-Pl gibt es keine Angabe dazu.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.20
Beitrag von: pte am 05 Dezember 2017, 21:20:36
Mit dem Datenblatt hast Du natürlich recht. Ich habe da bisher eher die Probleme Abbrand durch Funkenerosion (induktive Last) bzw. Verkleben durch Einschaltstrom (kapazitive Last wie LED Lampen). Das die Dinger auf EMV so empfindlich reagieren hätte ich nicht vermutet. Die Pumpe hat ja auch ca. 10Watt (ich weiß, auf die Höhe der Spannungsspitzen hat das nur bedingt Einfluss, wohl aber auf deren Energiegehalt).
Da ist das Design der Dose in dieser Hinsicht wohl doch etwas schwach.

Der Kondensator scheint übrigens zu wirken.


Gesendet von iPhone mit Tapatalk
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 17 Dezember 2017, 11:24:29
Hallo Testwillige,

hier eine neue Version 0.21 der Timestamp Firmware und der dazu benötigten FHEM Module.

Diese Version verbessert das K Kommando und macht es nutzbarer.

Außerdem Verbesserungen bei der HM-Devicezuordnung mit mehreren HM IOs, insbesondere nach einem Neustart von FHEM.

Es ist eine Prüfung auf Stacküberlauf eingebaut. Am Anfang des heap werden zwei Byte mit einem Bitmuster beschrieben. Wird das verändert, dann ist der Speicher wahrscheinlich korrumpiert, was durch einen Stacküberlauf ausgelöst sein sollte. Sofern der CUL dann noch kann sendet er ein "C_M" an TSCUL, was zu einem entsprechenden Log Eintrag führt.
Damit kann man vorsichtig die Speichergrenzen ausloten. Ein langer Testzeitraum ist aber erforderlich, um einigermaßen sicher zu sein, dass der worst case auch mal durchlaufen worden ist.
Außerdem ist ein Kommando mU (je nach Firmware) eingebaut, mit dem man den vom Stack ungenutzen heap in etwa auslesen kann (auch als get unusedstack in TSCUL verfügbar). Auch hier gilt, nur nach langer Laufzeit einigermaßen sinnvoll. Es macht sicher keinen Sinn auf Grund des Wertes den Speicher bis auf das letzte Byte auszuquetschen, denn weiterhin hängt die Stacknutzung vom gewählten Protokoll und Einstellungen ab.

In TSCULflash ist der Versuch des Flashens auch von NanoCULs und MiniCULs ergänzt. Da ich es aber mangels Hardware nicht testen kann, bitte ich um Feedback, ob es funktioniert. Vor dem Flashen wird ein "B00" also Reset für die TSCUL Firmware an den nano/Mini geschickt, 1 Sekunde gewartet und dann versucht mit avrdude zu flashen. Wäre nett, wenn das mal jemand testen und Feedback geben könnte.
Also erst die Firmware in den FHEM/Firmware Ordner kopieren und dann in FHEM mit
TSCULflash <nanodevicename> TSnanoCUL
bzw.
TSCULflash <minidevicename> TSminiCUL
versuchen zu Flashen. Im Log sollte danach (dauert etwas) die avrdude Ausgabe zu finden sein.

AESCommReq wird. Die Nutzung ist unverändert zu Standard CUL, sprich, beim gewünschten Gerät/Kanal aesCommReq auf 1 setzen und ggf. noch aesKey passend zum verteilten Key setzen.
Es werden von tsculfw nur die Keys 0 (Default Key) bis 3 unterstützt.

Diese Erweiterung erfordert jedoch auch zusätzliche Empfangspuffer im knappen Speicher des CULs. Ein CUL V3 nutzt bis zu 6 Empfangspuffer. Auch der FlashSpeicherbdarf ist angestiegen, so dass einige Protokolle nicht mehr gleichzeitig in ein Kompilat passen. Das sollte aber weniger tragisch sein, da im ASKSIN Modus ohnehin nur HM empfangen werden kann.

Bei der nanoCUL und miniCUL Version habe ich nur 3 Empfangspuffer vorgesehen, um den Restpeicher für den Stack zu erhalten. Vielleicht hat jemand die Möglichkeit, die max. Stacknutzung mal ausgiebig zu testen, damit der verbleibende Speicher optimal "ausgequetscht" werden kann???

Bei CUL V2 reicht der verfügbare Speicher leider hinten und vorne nicht aus, um diese Version nutzen zu können.

Im Anhang ist in TSCUL_fwcode_00_21_FHEM_Modules_00_33.zip wieder die Timestamp Firmware zu finden. Getestet habe ich TSCUL_V3, TSCOC, TSCUNO2 und TSSCC.

Die tsculfw Firmware kann für TSCUL_V3 und TSPIGATOR (an CUNX) mit FHEM mit dem TSCULflash geflashed werden. Die anderen müssen mit dem jeweiligen Flash Programmer geflashed werden.
So z.B. https://forum.fhem.de/index.php/topic,24436.msg631743.html#msg631743 kann es mit einem USB CUL Stick gehen, wenn man nicht TSCULflash verwendet.
TSCULflash ist erweitert auf COC, SCC, CCD, rpiaddon, CUNO2 und CUNO. Jedoch ist es nicht ganz so einfach zu handhaben, da zum einen teilweise die Taste zu drücken ist und bei Raspberry PI Modulen die Rechteproblematik für den Zugriff auf die IO-Pins überwunden werden muss. Tips dazu in der Command-Ref auch bei RPI_GPIO.
Bei einem Stapel aus SCC mit aufgesetztem COC, CCD oder (rpiaddon?) ist unbedingt beim SCC Flash darauf zu achten, die Taste am gewünschten Modul zu drücken. Sonst wird das oberste Nicht-SCC Modul mit der SCC Firmware geflashed.
Mit CUNO2 ist das flashen noch nicht getestet (nur über USB!). Wichtig, aber auch hier, die Taste zu drücken.

Es gibt nicht den Luxus des Downloads beim TSCULflash, sondern die Firmware muss händisch in den FHEM/firmware Ordner kopiert werden. Der Typ ist dann TSCUL_V3.
Beispiel:
TSCULflash MeinCulDevice TSCUL_V3

Wichtig für SCC Nutzer. TSSTACKED ist entfallen und wird nicht mehr unterstützt.
Statt dessen gibt es das neue Modul STACKABLETS (als Abwandlung von Rudolfs STACKABLE).
Dieses wird sozusagen zwischen die Stackteilnehmer eingebaut.

Beispiel für fhem.cfg:
#erstes SCC Modul als Basis
define SCC_WS868 TSCUL /dev/ttyAMA0@38400 0000
attr SCC_WS868 event-on-change-reading Ints_per_sec,IntCalcStat,MatchStat
attr SCC_WS868 rfmode SlowRF
attr SCC_WS868 room Receiver
attr SCC_WS868 sendpool CUL_HM868,SCC_WS868
attr SCC_WS868 verbose 1

#neues STACKABLETS virtuelles IO device
define STACK_1 STACKABLETS SCC_WS868
attr STACK_1 verbose 1

#zweites SCC Modul
define SCC_HM868 TSCUL FHEM:DEVIO:STACK_1:38400 1034
attr SCC_HM868 event-on-change-reading cond
attr SCC_HM868 hmId F11034


Ergänzender Hinweis zu USB CULs: 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_08\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 1234
bzw.
define CUL_433 TSCUL /dev/CUL433_0@12000000 0000
definiert 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 Zip Datei sind ebenfalls die ergänzten Module zu finden, die zur Nutzung der Firmware erforderlich sind.

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
16_STACKABLETS.pm -> statt der 16_STACKABLE.pm, aus STACKABLE werden damit STACKABLETS devices in der fhem.cfg (händisch anzupassen)

10_UNIRoll_TS.pm  -> statt der 10_UNIRoll.pm, mit TSCUL 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 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 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 IO-devices zu verwenden, aus CUL_WS wird dann TSCUL_WS  in der fhem.cfg (händisch anzupassen)
15_TSCUL_EM.pm   -> statt der 15_CUL_EM.pm, mit TSCUL IO-devices zu verwenden, aus CUL_EM wird dann TSCUL_EM  in der fhem.cfg (händisch anzupassen)
CalcUtil.pm               -> Hilfsrechenroutinen für Taupunkt und Windstärkeindex
97_timerTS.pm        -> Austausch Timerroutinen (inkompatibel zu 30_MilightBridge.pm vgl. https://forum.fhem.de/index.php/topic,81365.msg734828.html#msg734828 (https://forum.fhem.de/index.php/topic,81365.msg734828.html#msg734828)). Wenn es nicht genutzt werden soll, dann löschen oder umbennen.

Da diese Module ergänzt werden (müssen!), überleben sie auch ein Update von FHEM.

Außerdem:

10_CUL_HM.pm         -> angepasste Version zur Nutzung mit TSCUL/tsculfw. Derzeit ist die Nutzung dieses Moduls zwingend erforderlich!!!
HMConfig.pm             -> Einstelllimits für HM-CC-RT-DN Regler P und I Anteil erweitert. Damit kann man mit R-regAdaptive offDeter deutlich mehr an den Regelparametern spielen.
98_TSCULflash.pm     -> Zum Flash von TSCUL_V3, TSPIGATOR (an CUNX) mit Datei in FHEM/firmware
98_apptime.pm          -> apptime zur Nutzung mit 97_timerTS.pm

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 10_CUL_HM.pm 00_TSCUL.pm 16_STACKABLETS.pm DevIoTS.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.pm CalcUtil.pm 98_TSCULflash.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` }

Noch ein Hinweis: TSCUL fragt auch die Firmwareversion der tsculfw auf 0.16 ab. Eine ältere Version wird also nicht unterstützt, da sich diesmal auch wieder das Timestamp Protokoll (inkompatibel zum vorherigen Stand) geändert hat, so dass mit dem Austausch der FHEM Module auch ein Firmwareupdate des CUL devices erforderlich ist!

Noch ein Tip zur Haltbarkeit des CULs. Jedesmal, wenn einem HM-Device das IODev durch Roaming neu zugeordnet wird, führt das zu EEPROM Schreibvorgängen in den beteiligten CULs. Die Lebensdauer des EEPROMs ist begrenzt (100000 Schreibzyklen laut Datenblatt). Daher rate ich zur Nutzung des VorzugsIOs beim Device Attribut IOgrp. Also nicht einfach stumpf
attr HMdeviceName IOgrp VCCU
setzen, sondern
attr HMdeviceName IOgrp VCCU:CUL_mit_gutem_Empfang_fuer_Device
sofern die Roaming Funktionalität entsprechend RSSI für das jeweilige device nicht zwingend benötigt wird. Ein Fallback auf einen anderen CUL bleibt dennoch möglich.

Ergänzt ist auch noch ein set TX3Send.
Damit lassen sich TX3 Sensordatentelegramme auf 433er CULs versenden.
Beispiel:

define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 TX3Send T:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." SID:23 U")}

define NF_HumOut notify Sen_Aussen:humidity.* {fhem("set TSCUL_WS433 TX3Send H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." SID:23 U")}


Ergänzt ist auch noch ein set KSSend.
Damit lassen sich WS Sensordatentelegramme versenden.
Beispiel:

define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 KSSend T:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." Code:2")}


Gruß, Ansgar.

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

EDIT: aktualisiert auf TSCUL_fwcode_00_21_FHEM_Modules_00_27, Martins letzte Änderungen eingepflegt daher ist auch 98_HMtemplate.pm in Martins aktueller Version dabei, da erforderlich. Modifiziertes apptime vgl. https://forum.fhem.de/index.php/topic,81365.msg734513.html#msg734513 (https://forum.fhem.de/index.php/topic,81365.msg734513.html#msg734513), um auch Timeraufrufe mit Code Referenz sinnvoll anzuzeigen und geänderte Timerwarteschlangenabarbeitung zu berücksichigen.

EDIT2: aktualisiert auf TSCUL_fwcode_00_21_FHEM_Modules_00_28, in 10_CUL_HM.pm das attribut "rssiSwichHyst" in "rssiSwitchHyst" korrigiert. Außerdem hat mich AssignIO in den jeweiligen Modulen mit Verzögerungen gestört.

EDIT3: aktualisiert auf TSCUL_fwcode_00_21_FHEM_Modules_00_29, kleinere Modul Korrekturen und 10_CUL_HM.pm entspr. Martins Änderung aktualisiert.

EDIT4: aktualisiert auf TSCUL_fwcode_00_21_FHEM_Modules_00_30, kleinere Modul Korrekturen, Verbesserungen und 10_CUL_HM.pm entspr. Martins Änderung aktualisiert. Bitte Martins aktuelles 98_HMtemplate.pm nutzen!

EDIT5: aktualisiert auf TSCUL_fwcode_00_21_FHEM_Modules_00_31, kleinere Modul Korrekturen, Bug in DevIoTS.pm behoben, 10_CUL_HM.pm entspr. Martins Änderung aktualisiert. Bitte Martins aktuelles 98_HMtemplate.pm nutzen!

EDIT6: aktualisiert auf TSCUL_fwcode_00_21_FHEM_Modules_00_32, 10_CUL_HM.pm entspr. Martins Änderung aktualisiert. Bitte Martins aktuelles 98_HMtemplate.pm nutzen! In TSCUL erfolgt message Dispatch nun in einem Timer.

EDIT7: aktualisiert auf TSCUL_fwcode_00_21_FHEM_Modules_00_33, 10_CUL_HM.pm entspr. Martins Änderung aktualisiert. Bitte Martins aktuelles 98_HMtemplate.pm nutzen! 97_timerTS.pm ergänzt.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: Bastel-Frank am 17 Dezember 2017, 11:48:35
Hallo Ansgar,

wieder mal ein fettes Danke von mir für deine unermüdliche und super Arbeit  ;D

Viele Grüße
Frank
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: klausw am 18 Dezember 2017, 23:08:51
Version 0.21 funktioniert seit gestern Abend stabil bei mir.
Ebenso wie TSCULflash mit dem nanocul
Daumen hoch  :D
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 21 Dezember 2017, 13:29:47
Hallo Testwillige,

ich habe hier https://forum.fhem.de/index.php/topic,24436.msg732585.html#msg732585 (https://forum.fhem.de/index.php/topic,24436.msg732585.html#msg732585) nochmal eine Aktualisierung der Module angehangen. Bitte diesen letzten Stand nutzen.

@Klaus und @Frank: Danke für die positive Rückmeldung.
Normalerweise kann ich nur annehmen, dass keine Probleme auftreten :) , bis ich selbst mal drüber stolpere.  ;)

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: Bastel-Frank am 21 Dezember 2017, 15:00:08
Ich habe die neuen Versionen noch nicht in Produktion. Daher kann ich auch kein Feedback geben. Da ich mir keine Ausfälle leisten kann und inzwischen 5 CULs im Einsatz habe, ist der Aufwand für ein Update und ein evtl. zurückgehen auf eine vorherige Version leider ziemlich aufwendig. Ich warte daher immer erst etwas ab  :o
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 21 Dezember 2017, 15:28:10
Hallo Frank,

ZitatIch habe die neuen Versionen noch nicht in Produktion.

Bei welchem Stand bist Du denn jetzt?

ZitatDa ich mir keine Ausfälle leisten kann und inzwischen 5 CULs im Einsatz habe
Redundanzfunktionen können nie schaden. :o
Gerade dann wäre es interessant, ob die MultiIO Zuordnung stets sauber funktioniert. :) Genau genommen hat Deine Problematik meine Neugier geweckt, mich dem anzunehmen.
Ich teste selber mit maximal 2 CULs, es läuft bei mir aber prima mit einem.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: Bastel-Frank am 21 Dezember 2017, 15:42:27
Ich hatte bis vor kurzem zu 0.10 im Einsatz, jetzt ist es die 0.15. Beide Versionen laufen TipTop in meiner Umgebung.

Zwischen den Feiertagen werde ich deine 0.21 testen.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 21 Dezember 2017, 17:12:49
Hallo Frank,

ZitatZwischen den Feiertagen werde ich deine 0.21 testen.
Dann beherzige dabei bitte auch die Hinweise zur IO Zuordnung der HM devices Stichwort "VorzugsIOs" und Haltbarkeit EEPROM.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: Bastel-Frank am 21 Dezember 2017, 19:24:19
Zitat von: noansi am 21 Dezember 2017, 17:12:49
Hallo Frank,
Dann beherzige dabei bitte auch die Hinweise zur IO Zuordnung der HM devices Stichwort "VorzugsIOs" und Haltbarkeit EEPROM.
Gruß, Ansgar.

Ja, ich das werde ich machen  ;). Vielen Dank nochmal für deinen Hinweis.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 21 Dezember 2017, 23:55:52
Halllo Testwillige,

ich habe hier https://forum.fhem.de/index.php/topic,24436.msg732585.html#msg732585 (https://forum.fhem.de/index.php/topic,24436.msg732585.html#msg732585) nochmal die Module nach neuesten Erkenntnissen auf TSCUL_fwcode_00_21_FHEM_Modules_00_28.zip aktualisiert.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: Bastel-Frank am 22 Dezember 2017, 14:34:03
Mal ne' andere Frage:
Wann wird deine Firmware endlich (!) offiziell übernommen? Ich finde, es wird "langsam Zeit" dafür. Deine Firmware läuft sehr, sehr stabil und behebt Fehler der offiziellen Firmware. Einige Devices laufen nur, weil deine Firmware dies (im Gegensatz zur offiziellen Firmware) kann.
Kann man sich dafür irgendwo stark machen?
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 22 Dezember 2017, 15:10:17
Hallo Frank,

ich weiß nicht, wie meine ganzen Abwandlungen von Modulen ankommen würden. Auf die möchte ich selber jedoch nicht verzichten. Andere Maintainer mit einer Anpassung zu überlasten wird es wohl nicht bringen.
Bei SlowRF gibt es mittlerweile eine nette Empfangsstatistik zusammen mit den Sondermodulen, die man mit "get dispSRFStat" anzeigen lassen kann, ähnlich wir Martins HMInfo.

Beispiel:
SlowRF CUL_WS868 Receive Statistic:

freq:868.300MHz freqOffs:0.000kHz bWidth:325kHz freqIF:177.73kHz rAmpl:42dB sens:12dB dRate:2.461kBit/s
agcPrio:1 agcWait:32 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:0 AGC_FREEZE:0
CCAmode:1 csRelThr:10dB csAbsThr:4dB

Ints_per_sec  SI: 15.80240  TI: 0.37657  S: 0.13330  L: 0.00000  U: 0.00333  M: 0.00000

SlowRF_TmMatchStat  Mean: 55.0  Max: 464.0

TSCUL_WS
Cd   Name                 Type Active RSSILast RSSIMin RSSIAvg RSSIMax     TdLast     TdMin     TdAvg     TdMax       Count EstQual
11   CUL_WS_1                1  alive    -43.5   -43.5  -43.50   -43.5     177.02    176.87   180.170    353.96          56  98.241
13   CUL_WS_13               3  alive    -53.5   -54.0  -53.51   -53.5     169.00    168.55   174.729    338.43          59  96.721
14   CUL_WS_14               4  alive    -53.5   -53.5  -53.50   -53.5     165.00    164.98   165.000    165.02          62 100.000
17   CUL_WS_17               7  alive    -53.5   -53.5  -53.50   -53.5     152.98    152.01   152.995    153.98          66 100.000
21   CUL_WS_2                1  alive    -32.5   -33.0  -32.87   -32.5     176.51    176.39   176.507    176.63          58  99.996
31   CUL_WS_3                1  alive    -46.5   -46.5  -46.38   -45.5     176.01    175.88   179.095    352.02          57  98.272
41   CUL_WS_4                1  alive    -43.5   -43.5  -43.50   -43.5     175.55    175.46   175.508    175.56          58  99.996
51   CUL_WS_5                1  alive    -33.0   -33.0  -32.87   -32.5     175.01    174.83   178.074    350.01          57  98.274
61   CUL_WS_6                1  alive    -37.5   -38.0  -37.52   -37.5     174.51    174.40   174.506    174.61          58  99.996
71   CUL_WS_7                1  alive    -50.0   -50.5  -49.88   -49.5     174.01    173.90   174.010    174.12          58  99.995
80   CUL_WS_80               0  alive    -53.5   -53.5  -53.50   -53.5     354.99    177.32   180.614    354.99          57  98.276
81   CUL_WS_8                1  alive    -32.0   -32.0  -31.91   -31.5     173.54    173.47   176.496    347.01          58  98.303
82   CUL_WS_82               2  alive    -53.5   -53.5  -53.50   -53.5     169.48    169.15   169.500    169.85          60 100.000
83   CUL_WS_83               3  alive    -53.5   -53.5  -53.50   -53.5     165.49    165.44   165.500    165.57          62 100.000
84   CUL_WS_84               4  alive    -53.5   -53.5  -53.50   -53.5     161.50    161.10   161.500    161.90          63 100.000
85   CUL_WS_85               5  alive    -53.5   -53.5  -53.50   -53.5     157.19    157.16   160.000    315.00          63  98.438


TSKS300
Cd   Name                 Type Active RSSILast RSSIMin RSSIAvg RSSIMax     TdLast     TdMin     TdAvg     TdMax       Count EstQual
1234 CUL_WS_KS300           KS  alive    -53.5   -53.5  -53.50   -53.5     152.15    152.15   157.265    305.01          64  96.970


TSCUL_TX
Cd   Name                 Type Active RSSILast RSSIMin RSSIAvg RSSIMax     TdLast     TdMin     TdAvg     TdMax       Count EstQual
23   CUL_TX_23              TH  alive    -53.5   -53.5  -53.41   -52.5     230.00     53.46   215.319    231.01          47  26.705


Die Firmware kann nur mit den abgewandelten Modulen vernünftig laufen.

Eine Sonderform von 10_CUL_HM.pm möchte ich eigentlich nicht noch aufmachen. Aber der letzte Versuch, die IO Zuordnungsänderungen bei Martin komplett durch zu bekommen war nicht so erfolgreich. Ich habe aber noch einiges geändert, was das erleichtern könnte und Martins sonstige Änderungen derweil immer nachgezogen. Das ist für mich noch ein Knackpunkt.

Ein weiterer Knackpunkt für mich ist, dass nicht alle Funktionalitäten der Firmware getestet sind, da ich selber keine Testhardware dafür habe. Was an möglichen Befehlen in {CMD} gemeldet wird, soll auch funktionieren, nicht nur 'A'.  ;)
Das Feedback hier ist recht gering, respektive der Mut zur Lücke die man ausmerzen könnte nicht sehr groß. Gut könnte mal ein bischen frisch werden, derzeit.  ;)

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: Bastel-Frank am 28 Dezember 2017, 10:49:17
Hallo Ansgar,

ich habe damit begonnen, die aktuelle Firmware zu installieren. Nach dem Update des ersten CUL's und den neuen Modulen in FHEM bekomme ich von dem umgestellten CUL sehr viele Log-Einträge in der Art:
2017.12.28 10:44:21 3: LogHist CUL_OG:  133272 A F603 00778052 01 0E B7 A011 738396 370AA2 0201000000 _CCAdly:4
2017.12.28 10:44:21 3: LogHist CUL_OG:  133544 A F603 00778328 01 0E B7 A011 738396 370AA2 0201000000 _CCAdly:4
2017.12.28 10:44:21 3: LogHist CUL_OG:  133817 A F603 00778600 01 0E B7 A011 738396 370AA2 0201000000 _CCAdly:4
2017.12.28 10:44:21 3: LogHist CUL_OG:  134056 A F609 00778868 00 0E B7 A011 738396 370AA2 0201000000 _sfail _noAnsw
2017.12.28 10:44:21 3: LogHist CUL_OG:  134114 A F602 00778924 00 15 AA001122AA001122AA001122AA001122AA001122AA _ping
2017.12.28 10:44:21 3: LogHist CUL_OG:  134340 A F601 00779152 00 0D 84 A410 2A327B 738396 0601C840 -98dB
2017.12.28 10:44:21 3: LogHist CUL_OG:  134470 A F603 00779256 01 0A 84 8002 738396 2A327B 00 _CCAdly:4 _dhmSt:104
2017.12.28 10:44:21 3: LogHist CUL_OG:  135007 A F601 00779816 00 14 A2 845E 34264B 000000 80024D000000000008EFFE -103dB
2017.12.28 10:44:21 3: LogHist CUL_OG:  136192 A F601 00781004 00 0C B2 865A 27128B 000000 B0DC31 -79dB
2017.12.28 10:44:21 3: LogHist CUL_OG:  138005 A F602 00782816 00 01 CC _ping
2017.12.28 10:44:21 3: LogHist CUL_OG:  138300 A F601 00783112 00 0D 84 A410 2A327B 738396 0601C840 -100dB
2017.12.28 10:44:21 3: LogHist CUL_OG:  138424                 As 0E B7 A011 738396 370AA2 0201000000
2017.12.28 10:44:21 3: LogHist CUL_OG:  138429 A F603 00783216 01 0A 84 8002 738396 2A327B 00 _CCAdly:4 _dhmSt:104
2017.12.28 10:44:21 3: LogHist CUL_OG:  138537 A F603 00783320 01 0E B7 A011 738396 370AA2 0201000000 _CCAdly:4
2017.12.28 10:44:21 3: LogHist CUL_OG:  138809 A F603 00783592 01 0E B7 A011 738396 370AA2 0201000000 _CCAdly:4
2017.12.28 10:44:21 3: LogHist CUL_OG:  139080 A F603 00783864 01 0E B7 A011 738396 370AA2 0201000000 _CCAdly:4


Kann man die Anzahl der Log-Einträge eindämmen?

Viele Grüße
Frank
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 28 Dezember 2017, 11:11:31
Hallo Frank,

Du kannst die Logeinträge abschalten, indem Du das Attribut "hmLogLev" größer einstellst, als das Attribut "verbose" für Deinen CUL.
Also z.B. hmLogLev auf 2 und verbose auf 1.

Und hmLogLev = verbose, wenn Du die Ausgabe aktivieren möchtest, da damit bei Fehler recht gut eine kurze zeitliche Vorgeschichte sichtbar wird, was bei der Fehlersuche hilfreich sein kann.

So scheint das device mit der ID 370AA2 von Deinem CUL_OG aus anscheinend entweder nicht erreichbar zu sein oder es antwortet nicht, z.B. weil es sich nicht angesprochen fühlt, mangels Pairing.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: Bastel-Frank am 28 Dezember 2017, 13:22:00
Hallo Ansgar,

ich habe alle CULs umgestellt. Das System war zunächst eine Weile recht träge, nach einer Stunde läuft jetzt aber wieder alles. Das Log ist jetzt auch ruhig, es gibt keine größeren Einträge mehr.

Soweit so gut, ich behalte alles im Auge und werde berichten. Gibt es irgendwas besonderes, worauf ich achten soll?

Viele Grüße
Frank
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 28 Dezember 2017, 14:04:41
Hallo Frank,

schau mal mit get assignIDs bei den einzelnen IOs, ob es so bei Deinen IOs passt, wie Du es eingestellt hast, respektive ganz wichtig, ob es keine Doppelzuordnung zu zwei IOs gleichzeitig gibt.

Und natürlich, ob es irgendwelche Schaltprobleme gibt.

ZitatDas System war zunächst eine Weile recht träge
War das, als die LogHist Einträge noch geschrieben wurden?

Die kannst Du auch mal durchgehen. Da wo _sfail und/oder _noAnsw steht, ist was schief gegangen, was auf eine ungünstige IO Zuweisung für die jeweilige ID hindeuten könnte.
Normal ist nur, dass es gelegentlich mal schief geht, weil z.B. ein anderes Device dazwischen quaselt. In kurzer Abfolge aber zeigt es eher ein Einstellungs- oder Erreichbarkeitsproblem.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: Bastel-Frank am 28 Dezember 2017, 15:54:14
Zitat von: noansi am 28 Dezember 2017, 14:04:41
War das, als die LogHist Einträge noch geschrieben wurden?

Nein, es wurde nach und nach besser. Ich habe den Eindruck, dass es mit den Änderungen der IOgrp's von "vccu" auf "vccu:CUL_XX" zusammen hing. Irgendwie hatte ich den Eindruck, dass fhem in dieser Zeit mit sich selbst beschäftigt war und Prozesse im Hintergrund liefen, die ich nicht einschätzen kann. Aktionen in der Oberfläche musste ich sehr oft doppelt anklicken bis etwas passierte.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: Torsten_MG am 30 Dezember 2017, 08:48:12
Mal hier hin verschoben:

Zitat von: Torsten_MG am 29 Dezember 2017, 14:41:09
OK, dann werde ich jetzt mal alles auf 0 setzen und von vorne Anfangen!

Kann mir dann bitte jemand eine Schritt-für-Schritt-Anleitung zur Verfügung stellen, wie ich die Alternative fw für den CUL drauf bekomme und was ich mit den ganzen Dateien im Firmware-Ordner machen muss.

VIELEN DANK! schonmal

Zitat von: noansi am 29 Dezember 2017, 23:49:22
Hallo Thorsten,

...
Dort kann dann ggf. auch jemand anderes Deine Installationsfragestellungen und Antworten zur tsculfw und TSCUL nachlesen.

Und im Firmware Ordner gibt es mehrere .hex Dateien. Du musst die zu Deinem CUL Modell passende auf Deinen CUL flashen. Und das genauso, als würdest Du die "Standard" Firmware flashen, jedoch natürlich mit der richtigen .hex Datei. der tsculfw.

Das wäre Step 1.

Step 2 wäre, Dein fhem zu stoppen und in der fhem.cfg aus "CUL" "TSCUL" bei der Definition Deines CUL1 zu machen und FHEM wieder zu starten.
Welche hmID Du verwendest, ist im Prinzip wurscht, aber in dichter Besiedlung mit anderen Homatic Nachbarn halt sehr sinnvoll, was eher indivduelles zu wählen. Und das ganze mit 6 hex Ziffern groß geschrieben.

Wenn Du mit der Installation Firmware und Umstellung auf TSCUL dann mal durch bist, kannst Du in Deinem Ausgangsthread ggf. zum Anlernen Deines HM-Sen-MDIR-WM55 weiter fragen, falls es immer noch Probleme gibt.
Grundsätzlich ist es aber immer guter Stil, erst mal verfügbare Anleitungen zu lesen. Also z.B. wie setze ich meinen
HM-Sen-MDIR-WM55 in den Auslieferungszustand zurück, wenn ich bei 0 anfangen möchte.. Das solltest in Papierform haben.

Gruß, Ansgar.

Ich tue mich schon mit Step 1 schwer. Als ich den CUL (CC1101 CULV3-OEM) das erste mal geflasht habe, habe ich es wie in diesem https://haus-automatisierung.com/hardware/fhem/2016/05/08/fhem-tutorial-reihe-part-4-cul-flashen-und-erste-geraete-anlernen.html (https://haus-automatisierung.com/hardware/fhem/2016/05/08/fhem-tutorial-reihe-part-4-cul-flashen-und-erste-geraete-anlernen.html) Tutorial gemacht. Muß ich jetzt nur deine *.hex in den Ordner von dem damals heuntergeladenen Ordner austauschen, diesen Ordner auf meinen Raspi schieben und wie im Tutorial neu flashen? Und was muß ich mit den Dateien im tsculfw-code-459-trunk_lufa_00_21-Ordner machen?
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: Bytechanger am 30 Dezember 2017, 09:42:01
Guten Morgen,

wurden die Änderungen zwischenzeitlich in die 10_CUL_HM.pm   übernommen, oder muss ich sie weiterhin vom Update ausschließen?

Greets

Byte
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 30 Dezember 2017, 12:18:36
Hallo Byte,

Zitatwurden die Änderungen zwischenzeitlich in die 10_CUL_HM.pm   übernommen, oder muss ich sie weiterhin vom Update ausschließen?
Leider noch nicht übernommen, daher bleibt es vorerst noch beim Update Ausschluss.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 30 Dezember 2017, 12:52:36
Hallo Torsten,

dfu-programmer, der für das Flashen eines CUL V3 benötigt wird, hast Du also demnach schon installiert.

Zum Flashen findest Du unter http://busware.de/tiki-index.php?page=CUL (http://busware.de/tiki-index.php?page=CUL):

CUL Stick in den Bootloader bringen, z.B. mit set CUL1 raw B01
oder mit gedrücktem Bootloadertaster in den USB-Port einstecken.
Dann müßte für die Standard Firmware die Du jetzt nicht flashen möchtest, in einem Shell Fenster:
dfu-programmer atmega32u4 erase
dfu-programmer atmega32u4 flash CUL_V3.hex
dfu-programmer atmega32u4 reset

und somit also für die tsculfw:
sudo dfu-programmer atmega32u4 erase
sudo dfu-programmer atmega32u4 flash TSCUL_V3.hex
sudo dfu-programmer atmega32u4 reset

nachdem Du zuvor mit "cd" in das Verzeichnis gewechselt hast, in das Du die TSCUL_V3.hex hinein kopiert hast, z.B. Dein Home Verzeichnis auf dem RasPi. Das zusätzliche sudo wirst Du sehr wahrscheinlich benötigen, damit Du nicht an den Zugriffsrechten auf die Schnittstelle scheiterst.

Prinzipiell geht es auch mit TSCULflash unter fhem, wenn Du die TSCUL_V3.hex in das FHEM/Firmware Verzeichnis kopiert hast. Aber nur, wenn Du zuvor auch die Zugriffsrechte für FHEM dazu ausreichend eingestellt hast. Wie das geht ist per Hinweisen aus der CommandRef und Suche herraus zu finden. Daher versuchs besser erst mal mit dem obigen Weg, statt eine neue Baustelle aufzumachen.
EDIT: z.B. so https://forum.fhem.de/index.php/topic,81823.msg738963.html#msg738963 (https://forum.fhem.de/index.php/topic,81823.msg738963.html#msg738963)
Nachdem Du die .pm Dateien in den FHEM Ordner kopiert hast, kannst Du noch das FHEM CommandRef aktualisieren, wie in dem Beitrag mit der Firmwaredatei angegeben.

In Deinem link Artikel wird noch nicht das Attribut "hmId" genannt.
Das Attribut "hmId" musst Du für Deinen CUL1 auch noch auf Deine gewünschte Homematic-ID einstellen.

Besser wäre es wohl direkt auf eine VCCU zu gehen, wenn Du vor hast FHEM längerfristig zu nutzen, siehe auch https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU (https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU).

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: Torsten_MG am 30 Dezember 2017, 16:16:00
Zitat von: noansi am 30 Dezember 2017, 12:52:36
...
dfu-programmer atmega32u4 erase --force
dfu-programmer atmega32u4 flash CUL_V3.hex
dfu-programmer atmega32u4 reset


...

Gruß, Ansgar.

Anscheinend bin ich selbst dafür zu doof  :-[

Ich verbinde mich mit putty

und wenn ich dfu-programmer atmega32u4 erase --force und anschließend dfu-programmer atmega32u4 flash CUL_V3.hex eingebe kommt folgendes:

pi@raspberrypi:~ $ dfu-programmer atmega32u4 erase --force
Usage: dfu-programmer target[:usb-bus,usb-addr] command [options] [global-options] [file|data]

global-options:
        --quiet
        --debug level    (level is an integer specifying level of detail)
        Global options can be used with any command and must come
        after the command and before any file or data value

commands:
        configure {BSB|SBV|SSB|EB|HSB} [--suppress-validation] data
        dump
        dump-eeprom
        dump-user
        erase [--suppress-validation]
        flash [--suppress-validation] [--suppress-bootloader-mem]
                     [--serial=hexdigits:offset] {file|STDIN}
        flash-eeprom [--suppress-validation]
                     [--serial=hexdigits:offset] {file|STDIN}
        flash-user   [--suppress-validation]
                     [--serial=hexdigits:offset] {file|STDIN}
        get     {bootloader-version|ID1|ID2|BSB|SBV|SSB|EB|
                 manufacturer|family|product-name|
                 product-revision|HSB}
        getfuse {LOCK|EPFL|BOOTPROT|BODLEVEL|BODHYST|
                 BODEN|ISP_BOD_EN|ISP_IO_COND_EN|
                 ISP_FORCE}
        setfuse {LOCK|EPFL|BOOTPROT|BODLEVEL|BODHYST|
                 BODEN|ISP_BOD_EN|ISP_IO_COND_EN|
                 ISP_FORCE} data
        setsecure
        reset
        start
pi@raspberrypi:~ $ dfu-programmer atmega32u4 flash CUL_V3.hex
dfu-programmer: no device present.
pi@raspberrypi:~ $


PS: Woran erkenne ich, ob der CUL wirklich im Bootloader-Modus ist?
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 30 Dezember 2017, 16:27:03
Hallo Torsten,

dann versuch's mal mit
sudo dfu-programmer atmega32u4 erase
sudo dfu-programmer atmega32u4 flash TSCUL_V3.hex
sudo dfu-programmer atmega32u4 reset


"--force" mag er wohl nicht.
Außerdem möchtest Du doch wohl TSCUL_V3.hex flashen und nicht die CUL_V3.hex, denke ich.

dmesg
verrät Dir, was gerade am System geändert wurde, also auch, als was der CUL erkannt wurde.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: Torsten_MG am 30 Dezember 2017, 16:32:17
ok, war wohl irritiert mit deiner beschreibung. Dachte ich müsse das obere auch durchführen. Sollte wohl das Gehirn besser nutzen. Das flashen scheint jetzt funktioniert zu haben

pi@raspberrypi:~/test $ sudo dfu-programmer atmega32u4 erase
pi@raspberrypi:~/test $ sudo dfu-programmer atmega32u4 flash TSCUL_V3.hex
Validating...
28632 bytes used (99.86%)
pi@raspberrypi:~/test $ sudo dfu-programmer atmega32u4 reset
pi@raspberrypi:~/test $



Melde mich dann später nochmal, falls ich mit dem Rest probleme bekomme.

Vielen Dank erstmal!

PS: Da der Cul wieder blinkt, scheint das zu funktionieren
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: dora71 am 31 Dezember 2017, 14:33:23
Hallo zusammen,

habe seit gestern auch die Firmware 0.21 auf meinem CUL V3.4 geflasht. Alles ohne Probleme, alle Homematic Komponenten werden korrekt erkannt und Konflikte sind nirgendwo zu erkennen. Vielen Dank an Ansgar für die tolle Arbeit.

Eine Frage habe ich noch: Kann ich darüber auch Firmware-Updates der Homematic Komponenten durchführen oder muss ich dann noch etwas spezielles beachten?

Nochmals vielen Dank und schon allen Lesern ein guten Rutsch ins neue Jahr.

Gruß Rainer
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: MadMax-FHEM am 31 Dezember 2017, 16:55:22
Zitat von: dora71 am 31 Dezember 2017, 14:33:23
Eine Frage habe ich noch: Kann ich darüber auch Firmware-Updates der Homematic Komponenten durchführen oder muss ich dann noch etwas spezielles beachten?

Hatte zwar zuletzt "nur" eine ältere Version der Spezial-FW drauf und auch noch auf einem nanoCUL...
...aber damit gingen FW-Updates problemlos.

Zu beachten: zu viele (bzw. wahrscheinlich nur ein oder 2) FW-Updates hintereinander (und auch Versuche nach evtl. Abbruch) gehen nicht wegen der 1%-Regel (kein Senden mehr erlaubt)...

EDIT: hat aber natürlich nichts mit CUL oder der Spezial-FW zu tun...

Gruß und viel Erfolg, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 31 Dezember 2017, 19:11:07
Hallo Joachim, hallo Rainer,

ZitatZu beachten: zu viele (bzw. wahrscheinlich nur ein oder 2) FW-Updates hintereinander (und auch Versuche nach evtl. Abbruch) gehen nicht wegen der 1%-Regel (kein Senden mehr erlaubt)...

EDIT: hat aber natürlich nichts mit CUL oder der Spezial-FW zu tun...

Die tsculfw rechnet da gnadenlos mit, um die 1% Regel einzuhalten. Also erst warten bis die credit10ms des CUL auf Maximum 2700 sind. Dann erst einen FW-Updateversuch starten.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: waage am 01 Januar 2018, 08:57:25
Guten Morgen und ein Gesundes Neue Jahr
Ich habe heute versucht meinen nanoCul auf TScul zu flashen.
Das flashen scheint funktioniert zu haben, aber dennoch erhalte
ich eine Fehlermeldung. Die Dateien habe ich in FHEM ersetzt.
Kann mir jemand einen Tip geben.
Danke waage
LOG:
2018.01.01 08:44:27 0: TSCULflash: TSCUL is not of TSCUL type
2018.01.01 08:44:27 1: PERL WARNING: Use of uninitialized value in numeric ne (!=) at ./FHEM/00_TSCUL.pm line 4964.
2018.01.01 08:44:27 1: PERL WARNING: Use of uninitialized value in numeric eq (==) at ./FHEM/00_TSCUL.pm line 4968.
2018.01.01 08:44:27 1: /dev/ttyUSB0 disconnected, waiting to reappear TSCUL
2018.01.01 08:44:28 0: Flash-Data: type=TSnanoCUL device=TSCUL basedevice=TSCUL devport=/dev/ttyUSB0 filepath=./FHEM/firmware/TSnanoCUL.hex -> avrdude -p atmega328p -P /dev/ttyUSB0 -c arduino -b 57600 -U flash:w:./FHEM/firmware/TSnanoCUL.hex;
2018.01.01 08:44:28 1: TSCULflash avrdude -p atmega328p -P /dev/ttyUSB0 -c arduino -b 57600 -U flash:w:./FHEM/firmware/TSnanoCUL.hex;
2018.01.01 08:44:45 1: TSCULflash
avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e950f
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "./FHEM/firmware/TSnanoCUL.hex"
avrdude: input file ./FHEM/firmware/TSnanoCUL.hex auto detected as Intel Hex
avrdude: writing flash (28262 bytes):

Writing | ################################################## | 100% 8.62s

avrdude: 28262 bytes of flash written
avrdude: verifying flash memory against ./FHEM/firmware/TSnanoCUL.hex:
avrdude: load data flash data from input file ./FHEM/firmware/TSnanoCUL.hex:
avrdude: input file ./FHEM/firmware/TSnanoCUL.hex auto detected as Intel Hex
avrdude: input file ./FHEM/firmware/TSnanoCUL.hex contains 28262 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 6.52s

avrdude: verifying ...
avrdude: 28262 bytes of flash verified

avrdude done.  Thank you.


2018.01.01 08:44:47 3: Setting TSCUL serial parameters to 38400,8,N,1
2018.01.01 08:44:47 4: CUL_Parse: TSCUL �     
2018.01.01 08:44:47 3: TSCUL: Unknown code �, help me!
2018.01.01 08:44:48 4: CUL_Parse: TSCUL       
2018.01.01 08:44:48 1: PERL WARNING: Exiting subroutine via next at ./FHEM/00_CUL.pm line 864.
2018.01.01 08:44:48 4: CUL_Parse: TSCUL C _R E   
2018.01.01 08:44:48 3: TSCUL: Unknown code C_RE, help me!
2018.01.01 08:44:48 4: CUL_Parse: TSCUL C _R ea dyCS M868 
2018.01.01 08:44:48 3: TSCUL: Unknown code C_ReadyCSM868, help me!
2018.01.01 08:44:51 3: TSCUL: Possible commands: ABCEFGJKMNRUVWXYZeilmtx
2018.01.01 08:44:51 2: Setting TSCUL fhtid from ? (T01 is unknown) Use one of A B C E F G J K M N R U V W X Y Z e i l m t x to 0000
2018.01.01 08:44:51 1: /dev/ttyUSB0 reappeared (TSCUL)
2018.01.01 08:44:52 4: CUL_Parse: TSCUL ?  ( T0 1000 0 is u nknown ) Use one of A B C E F G J K M N R U V W X Y Z e i l m t x
2018.01.01 08:44:52 3: TSCUL: Unknown code ? (T010000 is unknown) Use one of A B C E F G J K M N R U V W X Y Z e i l m t x, help me!

Beim Versuch eines HM-LC-Sw1PBU-FM zu pairen steht folgendes in log:
2018.01.01 10:41:27 4: CUL_Parse: TSCUL A F7 01 0000 6D5700 1A0184 005F6B7A0000002800694F4551313135343236331001010045 -39.5
2018.01.01 10:41:27 2: CUL_HM Unknown device HM_6D5700 is now defined
2018.01.01 10:41:27 2: autocreate: define HM_6D5700 CUL_HM 6D5700
2018.01.01 10:41:27 2: autocreate: define FileLog_HM_6D5700 FileLog ./log/HM_6D5700-%Y.log HM_6D5700
2018.01.01 10:41:27 1: PERL WARNING: Use of uninitialized value in split at ./FHEM/10_CUL_HM.pm line 6325.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 01 Januar 2018, 11:02:04
Frohes neues Jahr alle zusammen!

Hallo waage,

danke für den Test von TSCULflash.  Hat funktioniert. :)

wenn Du jetzt in der fhem.cfg noch aus
define TSCUL CUL ...
define TSCUL TSCUL ...
machst, wie beschrieben, dann benutzt Du auch das richtige Modul 00_TSCUL.pm statt 00_CUL.pm.

Ich würde aber einen anderen Namen als "TSCUL" für das CUL IO nutzen, um nicht so leicht durcheinander zu kommen.

Die Fehlermeldungen unten kommen daher, dass von 00_CUL.pm versucht wird eine FHTID zu setzen, obwohl das 'T' Kommando nicht von der Firmware unterstützt wird. Das könnte Rudolf mal bei Gelegenheit ändern.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: waage am 01 Januar 2018, 11:50:49
Hallo Ansgar
Danke für Deine schnelle Antwort. Mit dem Umbenennen muß ich wohl Überlesen haben.
Jetzt hat TSCUL den Schalter sofort erkannt. Und funktioniert einwandfrei.
Super Arbeit!   
Danke nochmal waage
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: dora71 am 01 Januar 2018, 12:53:54
Zitat von: noansi am 31 Dezember 2017, 19:11:07
Hallo Joachim, hallo Rainer,

Die tsculfw rechnet da gnadenlos mit, um die 1% Regel einzuhalten. Also erst warten bis die credit10ms des CUL auf Maximum 2700 sind. Dann erst einen FW-Updateversuch starten.

Gruß, Ansgar.

Hallo Ansgar,

frohes neues Jahr 2018. Vielen Dank für den Hinweis. Ist ja auch nicht mehr als richtig  :)

Für alle, die nicht wissen, wo man das findet:
get CUL_0 credit10ms
Im Webfrontend ganz oben bei den set / get Optionen zu finden. Dann erscheint ein Pop-Up Fenster und dort steht der Wert.

Gruß Rainer
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 01 Januar 2018, 13:43:25
Hallo zusammen,

es gibt hier https://forum.fhem.de/index.php/topic,24436.msg732585.html#msg732585 (https://forum.fhem.de/index.php/topic,24436.msg732585.html#msg732585) nochmal ein Update der Module.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: waage am 01 Januar 2018, 14:06:21
Hallo Ansgar
Habe soeben die neuen Module reinkopiert und neu gestartet, es funktioniert mit meinem nanoCUL.
mfg waage
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 01 Januar 2018, 14:22:32
Hallo waage,

danke für das Feedback!

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 03 Januar 2018, 21:53:36
Hallo zusammen,

es gibt hier https://forum.fhem.de/index.php/topic,24436.msg732585.html#msg732585 (https://forum.fhem.de/index.php/topic,24436.msg732585.html#msg732585) nochmal ein Update der Module.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 08 Januar 2018, 22:21:10
Hallo zusammen,

es gibt hier https://forum.fhem.de/index.php/topic,24436.msg732585.html#msg732585 (https://forum.fhem.de/index.php/topic,24436.msg732585.html#msg732585) wieder ein Update der Module.
Ich bitte um Feedback, ob Probleme damit auftreten.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: Bastel-Frank am 09 Januar 2018, 08:09:49
Hallo Angar,

seit einer Woche habe ich die Version 0.21 drauf, seit heute morgen auch die aktuellen fhem-Module 32.

Bisher läuft alles fast wie gewohnt. Ich habe zwei Auffälligkeiten:

Zum Einen gab es regelmäßig von einem CUL einen ASKSIN-Fehler im Log:
2018.01.08 20:56:07 1: TSCUL_Parse: CUL_KG received ASKSIN error message: A?AX31D0AD3F

Und dann hatte ich auf der fhem-Startseite eine Fehlermeldung ungefähr in der Art, dass die "ASKSIN-Bibliothek nicht installiert" sei. Die genaue Fehlermeldung habe ich leider nicht. Falls ich diese nochmal bekomme, dann melde ich dir die genaue Beschreibung.

[Edit: Ich habe die Fehler dazu im Log gefunden]
2018.01.04 18:29:11 1: configfile: ASKSIN not supported
ASKSIN not supported
CUL_EG: Mode HomeMatic not supported, wrong firmware?!?
ASKSIN not supported
ASKSIN not supported
CUL_OG: Mode HomeMatic not supported, wrong firmware?!?
ASKSIN not supported
ASKSIN not supported
CUL_GH: Mode HomeMatic not supported, wrong firmware?!?



Aktuell überlege ich mir, ob mich an das Thema AES mal herantraue. Ich habe damit noch keine Erfahrung und keine Berührung gehabt. Kannst Du mir/uns bitte etwas über die Vor-/ und Nachteile aus deiner Erfahrung berichten und wie man den Umstieg in eine AES-Kommunikation möglichst einfach realisieren kann?

Viele Grüße
Frank

Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 09 Januar 2018, 21:32:03
Hallo Frank,

ZitatZum Einen gab es regelmäßig von einem CUL einen ASKSIN-Fehler im Log:
2018.01.08 20:56:07 1: TSCUL_Parse: CUL_KG received ASKSIN error message: A?AX31D0AD3F
Gab es dazu einen Zusammenhang? Z.B. Neustart? Wie regelmäßig?
Die Meldung besagt, dass versucht wurde die Device Zuordnung der Id 31D0AD aus der EEPROM Liste zu löschen, die aber auf dem CUL nicht gefunden wurde.
Sollte eigentlich nicht passieren, außer eventuell bei einem EEPROM Rücksetzen. Hast Du mehr Log drumherum? Wie viele devices sind dem CUL zugeordnet (get assignIDs)?

ZitatUnd dann hatte ich auf der fhem-Startseite eine Fehlermeldung ungefähr in der Art, dass die "ASKSIN-Bibliothek nicht installiert" sei. Die genaue Fehlermeldung habe ich leider nicht. Falls ich diese nochmal bekomme, dann melde ich dir die genaue Beschreibung.
Auch mit der aktuellen Version noch?
War das nach dem Flashen vor Tausch der Module? Oder nach dem Anstecken des CUL?
Stehen die auf Initialized? List bitte.
Das sind die, die per ser2net angebunden sind, richtig?

ZitatAktuell überlege ich mir, ob mich an das Thema AES mal herantraue. Ich habe damit noch keine Erfahrung und keine Berührung gehabt. Kannst Du mir/uns bitte etwas über die Vor-/ und Nachteile aus deiner Erfahrung berichten und wie man den Umstieg in eine AES-Kommunikation möglichst einfach realisieren kann?
Siehe Wiki https://wiki.fhem.de/wiki/AES_Encryption (https://wiki.fhem.de/wiki/AES_Encryption). Die Einrichtung erfolgt genauso.

Aktives AES bei HM Classic sorgt dafür, dass der Sender von Änderungskommandos aufgefordert wird, eine Signierung dazu zu senden. Bleibt die Signierung aus oder ist sie falsch, dann wird das Kommando/die Änderung nicht ausgeführt (sofern keine Bugs in der Device Firmware vorliegen).
Die Nutzdaten an sich werden nicht verschlüsselt, bleiben also von Außen beobachtbar.
Schaltvorgänge werden etwas verzögert, da die Signierung noch zusätzlich ausgetauscht werden muss.
Ebenfalls geht natürlich der Batterieverbrauch entsprechend etwas hoch wegen der zusätzlichen "wach" und Sende-/Empfangszeit.

Vorraussetzung ist, das beide Seiten den gleichen Schlüssel nutzen, der nicht der Default Schlüssel sein sollte (da bekannt).

Also erst Schlüssel in FHEM bei der VCCU setzen (Schlüssel notieren + nicht vergessen!!!), und dann an den devices mit "set assignHmKey" setzen, die AES nutzen sollen (und können).

Danach kann dann die Nutzung aktiviert werden.

Ein device, dass eine Signierung anfordern soll, also ein Schaltaktor oder RT Clima Channel, muss im betreffenden Channel mit "set sign on" dazu aktiviert werden.

Umgekehrt, also wenn FHEM eine Signierung eines Schaltbefehls von z.B einem Schalter oder Fensterkontakt etc. anfordern soll, dann muss das Attribut "aesCommReq" beim Schalterdevice und ggf. beim betreffenden Channel auf 1 gesetzt werden.

Beim Peering von devices muss ggf. noch den devices mitgeteilt werden, dass der gegenüber AES erwartet. Das geht dann mit setzen des Registers ...expectAES auf on für den jeweiligen peer im channel.

Da man sich mit dem "was muss wo sinnvollerweise aktiviert werden" erst mal klar werden muss, ist es wohl sinnvoll schrittweise dabei vorzugehen. Also mal mit einem unkritischen "Opfer" ;) anfangen. Suche und Homematic Forumsbereich helfen. Damit möchte ich den Thread hier ungern aufblasen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: Gonzo am 11 Januar 2018, 22:01:00
Kein ausführliches Feedback, nur ein kurzer Kommentar von mir...
Ich bin jetzt von culfw auf diese Firmware umgestiegen nachdem ich fast verzweifelt bin bei dem Versuch meine HM Rauchmelder zu einem Team zu peeren (Fehler: Missing Ack). Hier hat es auf Anhieb geklappt!

Vielen, vielen Dank für die Arbeit!

Etwas mulmig war mir schon, wegen dem händischen anpassen (bin noch FHEM Neuling). Aber letztlich hat alles ohne Probleme funktioniert und auch das Flashen des nanoCULs verlief reibungslos.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: Heggeg am 15 Januar 2018, 22:19:41
Hallo zusammen,

ich habe mir heute die ts_culfw auf meinen busware v.3.4 CUL USB Light Stick geflasht. Vorweg ich bin ein ziemlicher Noob was CUL, RF u. co angeht.

Ich bin wie folgt vorgegangen:
1. TSCUL_fwcode_00_21_FHEM_Modules_00_32.zip hier aus dem Board ins Home Verzeichnis von meiner Ubuntu 16.04 LTS VM geladen.
2. TSCUL_fwcode_00_21_FHEM_Modules_00_32.zip entpackt mit folgendem Befehl:
tar -xf TSCUL_fwcode_00_21_FHEM_Modules_00_32.zip
3. *.pm Files aus dem FHEM Ordner in /opt/fhem/FHEM verschoben und chown fhem:dialout auf alle Files gemacht.
4. Nun habe ich die TSCUL_V3.hex auf meinen CUL Stick mit dem dfuprogrammer geflasht mit:
sudo dfu-programmer atmega32u4 erase
sudo dfu-programmer atmega32u4 flash TSCUL_V3.hex
sudo dfu-programmer atmega32u4 start
5. CUL in Fhem mitfolgendem Befehl definiert:
define CUL_01 TSCUL /dev/ttyACM0@12000000 1034
6. attr global exclude_from_update 10_CUL_HM.pm 00_TSCUL.pm 16_STACKABLETS.pm DevIoTS.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.pm CalcUtil.pm 98_TSCULflash.pm ausgeführt.
7. { `perl contrib/commandref_join.pl` } ausgeführt
8. Eine VCCU definiert mit folgendem Befehl:
define VCCU CUL_HM C58719
attr VCCU model CCU-FHEM
attr VCCU IOList CUL_01
attr VCCU subType virtual
attr VCCU webCmd virtual:update
9. Und nun meinen ersten Aktor gepairt:
set VCCU hmPairForSec 600
Config Knopf an einem HM-LC-Bl1PBU-FN Rollladenaktor gedrückt.
10. Pairing erfolgreich!

Nun habe ich aber das Problem das der Aktor total langsam reagiert und die VCCU und der CUL ständig reconnectet bzw auf disconnectet steht. Und die Befehle zum Aktor werden teilweise erst Minuten später ausgeführt.

Vielleicht habt Ihr eine Idee woran es liegen kann.

Logs und Lists:

FHEM Log:

2018.01.15 21:17:24 2: TSCUL_condUpdateHM: CUL_868 new condition disconnected
2018.01.15 21:17:24 3: Opening CUL_868 device /dev/CUL868_0
2018.01.15 21:17:24 3: Can't open /dev/CUL868_0: No such file or directory
2018.01.15 21:17:32 2: TSCUL_condUpdateHM: CUL_868 new condition disconnected
2018.01.15 21:17:32 3: Opening CUL_868 device /dev/CUL868_0
2018.01.15 21:17:32 3: Can't open /dev/CUL868_0: No such file or directory
2018.01.15 21:22:12 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:22:12 3: Opening CUL_01 device /dev/ttyACM0
2018.01.15 21:22:12 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:22:13 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:22:13 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:22:14 2: TSCUL_condUpdateHM: CUL_01 new condition non-HM
2018.01.15 21:22:14 3: CUL_01 device opened
2018.01.15 21:24:34 1: Error: >CUL_868< has no TYPE, but following keys: >helper<
2018.01.15 21:25:29 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 21:25:29 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.001
2018.01.15 21:25:29 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 21:25:29 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 21:25:29 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:25:29 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 21:25:36 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:25:37 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:25:38 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:25:38 2: TSCUL_condUpdateHM: CUL_01 new condition non-HM
2018.01.15 21:25:38 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 21:25:44 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 21:25:44 2: Switched CUL_01 rfmode to HomeMatic
2018.01.15 21:26:00 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 21:26:00 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.002
2018.01.15 21:26:00 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 21:26:00 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 21:26:00 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:26:00 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 21:26:08 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:26:09 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:26:09 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:26:10 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 21:26:10 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 21:26:12 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 21:26:44 1: TSCUL_SendPingHM CUL_01 fatal: ApC0 timed out! Failsafe release send.
2018.01.15 21:27:06 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 21:27:06 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.003
2018.01.15 21:27:06 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 21:27:06 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 21:27:06 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:27:06 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 21:27:14 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:27:15 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:27:16 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:27:16 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 21:27:16 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 21:27:16 3: CUL_HM set VCCU hmPairForSec 600
2018.01.15 21:27:16 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 21:27:57 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 21:27:57 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.004
2018.01.15 21:27:57 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 21:27:57 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 21:27:57 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:27:57 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 21:28:04 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:28:05 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:28:05 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:28:06 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 21:28:06 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 21:28:08 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 21:28:23 3: CUL_HM set VCCU virtual 1
2018.01.15 21:28:54 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 21:28:54 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.005
2018.01.15 21:28:54 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 21:28:54 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 21:28:54 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:28:54 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 21:29:01 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:29:02 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:29:03 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:29:03 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 21:29:04 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 21:29:05 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 21:29:50 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 21:29:50 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.006
2018.01.15 21:29:50 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 21:29:50 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 21:29:50 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:29:50 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 21:29:57 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:29:58 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:29:59 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:29:59 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 21:29:59 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 21:30:01 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 21:30:50 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 21:30:50 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.007
2018.01.15 21:30:50 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 21:30:50 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 21:30:50 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:30:50 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 21:30:50 3: CUL_HM set VCCU update
2018.01.15 21:30:58 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:30:59 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:30:59 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:31:00 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 21:31:00 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 21:31:02 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 21:31:17 3: CUL_HM set VCCU hmPairForSec
2018.01.15 21:31:39 3: CUL_HM set VCCU hmPairForSec 600
2018.01.15 21:31:41 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 21:31:41 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.008
2018.01.15 21:31:41 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 21:31:41 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 21:31:41 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:31:41 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 21:31:50 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:31:51 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:31:52 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:31:52 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 21:31:53 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 21:31:54 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 21:31:54 2: CUL_HM Unknown device HM_605665 is now defined
2018.01.15 21:31:54 2: autocreate: define HM_605665 CUL_HM 605665
2018.01.15 21:31:54 2: autocreate: define FileLog_HM_605665 FileLog ./log/HM_605665-%Y.log HM_605665
2018.01.15 21:31:54 3: CUL_HM pair: HM_605665 blindActuator, model HM-LC-Bl1PBU-FM serialNr
2018.01.15 21:31:54 1: Error: >CUL_868< has no TYPE, but following keys: >helper<
2018.01.15 21:31:58 3: CUL_HM set HM_605665 getConfig
2018.01.15 21:32:00 3: CUL_HM set HM_605665 statusRequest
2018.01.15 21:32:04 3: CUL_HM set HM_605665 getConfig
2018.01.15 21:32:27 3: CUL_HM set HM_605665 pct 60
2018.01.15 21:32:34 3: CUL_HM set HM_605665 pct 70
2018.01.15 21:32:40 3: CUL_HM set HM_605665 pct 0
2018.01.15 21:32:42 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 21:32:42 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.009
2018.01.15 21:32:42 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 21:32:42 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 21:32:42 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:32:42 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 21:32:44 3: CUL_HM set HM_605665 down
2018.01.15 21:32:49 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:32:50 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:32:50 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:32:51 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 21:32:51 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 21:32:53 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 21:32:57 1: TSCUL_RecoverHMQlen: CUL_01 recovered from Qlen lock
2018.01.15 21:32:57 3: CUL_HM set HM_605665 off
2018.01.15 21:32:59 3: CUL_HM set HM_605665 on
2018.01.15 21:33:00 3: CUL_HM set HM_605665 up
2018.01.15 21:33:07 3: CUL_HM set HM_605665 down
2018.01.15 21:33:12 3: CUL_HM set HM_605665 pct 0
2018.01.15 21:33:15 3: CUL_HM set HM_605665 pct 100
2018.01.15 21:33:27 1: TSCUL_SendPingHM CUL_01 fatal: ApC0 timed out! Failsafe release send.
2018.01.15 21:33:33 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 21:33:33 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.01
2018.01.15 21:33:33 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 21:33:33 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 21:33:33 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:33:33 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 21:33:40 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:33:41 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:33:41 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:33:42 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 21:33:42 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 21:33:44 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 21:33:57 1: TSCUL_RecoverHMQlen: CUL_01 recovered from Qlen lock
2018.01.15 21:34:17 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 21:34:17 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.011
2018.01.15 21:34:17 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 21:34:17 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 21:34:17 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:34:17 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 21:34:23 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:34:24 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:34:25 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:34:25 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 21:34:26 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 21:34:27 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 21:34:28 1: TSCUL_SendPingHM CUL_01 fatal: ApC0 timed out! Failsafe release send.
2018.01.15 21:35:07 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 21:35:07 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.012
2018.01.15 21:35:07 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 21:35:07 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 21:35:07 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:35:07 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 21:35:16 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:35:17 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:35:18 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:35:18 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 21:35:19 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 21:35:20 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 21:35:49 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 21:35:49 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.013
2018.01.15 21:35:49 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 21:35:49 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 21:35:49 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:35:49 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 21:35:56 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:35:57 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:35:58 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:35:58 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 21:35:58 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 21:36:00 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 21:36:13 3: CUL_HM set HM_605665 pct 0
2018.01.15 21:36:22 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 21:36:22 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.014
2018.01.15 21:36:22 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 21:36:22 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 21:36:22 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:36:22 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 21:36:29 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:36:30 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:36:30 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:36:31 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 21:36:31 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 21:36:32 3: CUL_HM set HM_605665 statusRequest
2018.01.15 21:36:32 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 21:36:55 3: CUL_HM set HM_605665 pct 50
2018.01.15 21:37:13 1: TSCUL_SendPingHM CUL_01 fatal: ApC0 timed out! Failsafe release send.
2018.01.15 21:37:17 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 21:37:17 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.015
2018.01.15 21:37:17 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 21:37:17 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 21:37:17 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:37:17 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 21:37:24 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:37:25 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:37:25 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:37:26 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 21:37:26 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 21:37:27 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 21:37:44 1: TSCUL_RecoverHMQlen: CUL_01 recovered from Qlen lock
2018.01.15 21:38:14 1: TSCUL_SendPingHM CUL_01 fatal: ApC0 timed out! Failsafe release send.
2018.01.15 21:38:23 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 21:38:23 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.016
2018.01.15 21:38:23 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 21:38:23 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 21:38:23 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:38:23 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 21:38:30 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:38:31 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:38:31 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:38:32 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 21:38:32 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 21:38:34 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 21:38:44 1: TSCUL_RecoverHMQlen: CUL_01 recovered from Qlen lock
2018.01.15 21:39:06 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 21:39:06 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.017
2018.01.15 21:39:06 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 21:39:06 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 21:39:06 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:39:06 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 21:39:13 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:39:14 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:39:15 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:39:15 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 21:39:16 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 21:39:16 1: TSCUL_SendPingHM CUL_01 fatal: ApC0 timed out! Failsafe release send.
2018.01.15 21:39:16 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 21:39:53 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 21:39:53 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.018
2018.01.15 21:39:53 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 21:39:53 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 21:39:53 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:39:53 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 21:40:02 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:40:03 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:40:04 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:40:04 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 21:40:05 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 21:40:05 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 21:40:39 3: CUL_HM set HM_605665 toggleDir
2018.01.15 21:40:48 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 21:40:48 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.019
2018.01.15 21:40:48 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 21:40:48 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 21:40:48 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:40:48 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 21:40:55 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:40:56 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:40:57 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:40:57 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 21:40:57 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 21:40:59 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 21:41:09 1: TSCUL_RecoverHMQlen: CUL_01 recovered from Qlen lock
2018.01.15 21:41:18 3: CUL_HM set HM_605665 statusRequest
2018.01.15 21:41:40 1: TSCUL_SendPingHM CUL_01 fatal: ApC0 timed out! Failsafe release send.
2018.01.15 21:41:45 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 21:41:45 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.02
2018.01.15 21:41:45 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 21:41:45 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 21:41:45 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:41:45 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 21:41:52 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:41:53 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:41:54 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:41:54 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 21:41:54 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 21:41:56 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 21:42:10 1: TSCUL_RecoverHMQlen: CUL_01 recovered from Qlen lock
2018.01.15 21:42:30 3: CUL_HM set HM_605665 down
2018.01.15 21:42:41 1: TSCUL_SendPingHM CUL_01 fatal: ApC0 timed out! Failsafe release send.
2018.01.15 21:42:55 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 21:42:55 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.021
2018.01.15 21:42:55 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 21:42:55 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 21:42:55 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:42:55 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 21:43:02 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:43:03 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:43:03 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:43:04 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 21:43:04 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 21:43:05 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 21:43:11 1: TSCUL_RecoverHMQlen: CUL_01 recovered from Qlen lock
2018.01.15 21:43:41 1: TSCUL_SendPingHM CUL_01 fatal: ApC0 timed out! Failsafe release send.
2018.01.15 21:43:53 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 21:43:53 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.022
2018.01.15 21:43:53 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 21:43:53 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 21:43:53 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:43:53 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 21:44:00 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:44:01 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:44:02 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:44:02 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 21:44:03 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 21:44:05 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 21:44:11 1: TSCUL_RecoverHMQlen: CUL_01 recovered from Qlen lock
2018.01.15 21:44:20 3: SONOS1: Transport-Subscription for ZonePlayer "RINCON_B8E9375200DC01400_MR" has expired and is now renewed.
2018.01.15 21:44:20 3: SONOS1: Rendering-Subscription for ZonePlayer "RINCON_B8E9375200DC01400_MR" has expired and is now renewed.
2018.01.15 21:44:20 3: SONOS1: GroupRendering-Subscription for ZonePlayer "RINCON_B8E9375200DC01400_MR" has expired and is now renewed.
2018.01.15 21:44:20 3: SONOS1: ContentDirectory-Subscription for ZonePlayer "RINCON_B8E9375200DC01400_MR" has expired and is now renewed.
2018.01.15 21:44:20 3: SONOS1: Alarm-Subscription for ZonePlayer "RINCON_B8E9375200DC01400_MR" has expired and is now renewed.
2018.01.15 21:44:20 3: SONOS1: ZoneGroupTopology-Subscription for ZonePlayer "RINCON_B8E9375200DC01400_MR" has expired and is now renewed.
2018.01.15 21:44:20 3: SONOS1: DeviceProperties-Subscription for ZonePlayer "RINCON_B8E9375200DC01400_MR" has expired and is now renewed.
2018.01.15 21:44:20 3: SONOS1: MusicServices-Subscription for ZonePlayer "RINCON_B8E9375200DC01400_MR" has expired and is now renewed.
2018.01.15 21:44:20 3: SONOS1: Transport-Subscription for ZonePlayer "RINCON_B8E937B7BCF801400_MR" has expired and is now renewed.
2018.01.15 21:44:20 3: SONOS1: Rendering-Subscription for ZonePlayer "RINCON_B8E937B7BCF801400_MR" has expired and is now renewed.
2018.01.15 21:44:20 3: SONOS1: GroupRendering-Subscription for ZonePlayer "RINCON_B8E937B7BCF801400_MR" has expired and is now renewed.
2018.01.15 21:44:20 3: SONOS1: ContentDirectory-Subscription for ZonePlayer "RINCON_B8E937B7BCF801400_MR" has expired and is now renewed.
2018.01.15 21:44:20 3: SONOS1: Alarm-Subscription for ZonePlayer "RINCON_B8E937B7BCF801400_MR" has expired and is now renewed.
2018.01.15 21:44:20 3: SONOS1: ZoneGroupTopology-Subscription for ZonePlayer "RINCON_B8E937B7BCF801400_MR" has expired and is now renewed.
2018.01.15 21:44:20 3: SONOS1: DeviceProperties-Subscription for ZonePlayer "RINCON_B8E937B7BCF801400_MR" has expired and is now renewed.
2018.01.15 21:44:20 3: SONOS1: MusicServices-Subscription for ZonePlayer "RINCON_B8E937B7BCF801400_MR" has expired and is now renewed.
2018.01.15 21:44:20 3: SONOS1: Transport-Subscription for ZonePlayer "RINCON_B8E9378846C601400_MR" has expired and is now renewed.
2018.01.15 21:44:20 3: SONOS1: Rendering-Subscription for ZonePlayer "RINCON_B8E9378846C601400_MR" has expired and is now renewed.
2018.01.15 21:44:20 3: SONOS1: GroupRendering-Subscription for ZonePlayer "RINCON_B8E9378846C601400_MR" has expired and is now renewed.
2018.01.15 21:44:20 3: SONOS1: ContentDirectory-Subscription for ZonePlayer "RINCON_B8E9378846C601400_MR" has expired and is now renewed.
2018.01.15 21:44:20 3: SONOS1: Alarm-Subscription for ZonePlayer "RINCON_B8E9378846C601400_MR" has expired and is now renewed.
2018.01.15 21:44:20 3: SONOS1: ZoneGroupTopology-Subscription for ZonePlayer "RINCON_B8E9378846C601400_MR" has expired and is now renewed.
2018.01.15 21:44:20 3: SONOS1: DeviceProperties-Subscription for ZonePlayer "RINCON_B8E9378846C601400_MR" has expired and is now renewed.
2018.01.15 21:44:20 3: SONOS1: MusicServices-Subscription for ZonePlayer "RINCON_B8E9378846C601400_MR" has expired and is now renewed.
2018.01.15 21:44:42 1: TSCUL_SendPingHM CUL_01 fatal: ApC0 timed out! Failsafe release send.
2018.01.15 21:44:51 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 21:44:51 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.023
2018.01.15 21:44:51 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 21:44:51 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 21:44:51 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:44:51 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 21:44:57 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:44:58 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:44:59 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:44:59 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 21:45:00 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 21:45:02 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 21:45:12 1: TSCUL_RecoverHMQlen: CUL_01 recovered from Qlen lock
2018.01.15 21:45:42 1: TSCUL_SendPingHM CUL_01 fatal: ApC0 timed out! Failsafe release send.
2018.01.15 21:45:48 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 21:45:48 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.024
2018.01.15 21:45:48 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 21:45:48 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 21:45:48 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:45:48 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 21:45:54 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:45:55 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:45:56 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:45:56 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 21:45:57 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 21:45:58 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 21:46:13 1: TSCUL_RecoverHMQlen: CUL_01 recovered from Qlen lock
2018.01.15 21:46:38 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 21:46:38 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.025
2018.01.15 21:46:38 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 21:46:38 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 21:46:38 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:46:38 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 21:46:43 1: TSCUL_SendPingHM CUL_01 fatal: ApC0 timed out! Failsafe release send.
2018.01.15 21:46:45 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:46:46 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:46:46 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:46:47 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 21:46:47 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 21:46:47 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 21:47:14 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 21:47:14 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.026
2018.01.15 21:47:14 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 21:47:14 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 21:47:14 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:47:14 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 21:47:22 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:47:23 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:47:24 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:47:24 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 21:47:25 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 21:47:26 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 21:48:48 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 21:48:48 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.027
2018.01.15 21:48:48 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 21:48:48 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 21:48:48 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:48:48 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 21:49:00 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:49:01 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:49:01 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:49:02 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 21:49:02 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 21:49:03 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 21:49:42 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 21:49:42 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.028
2018.01.15 21:49:42 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 21:49:42 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 21:49:42 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:49:42 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 21:49:52 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:49:53 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:49:54 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:49:54 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 21:49:54 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 21:49:55 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 21:51:06 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 21:51:06 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.029
2018.01.15 21:51:06 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 21:51:06 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 21:51:06 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:51:06 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 21:51:15 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:51:16 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:51:16 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:51:17 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 21:51:17 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 21:51:19 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 21:51:54 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 21:51:54 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.03
2018.01.15 21:51:54 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 21:51:54 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 21:51:54 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:51:54 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 21:52:02 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:52:03 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:52:04 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:52:04 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 21:52:04 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 21:52:06 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 21:53:25 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 21:53:25 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.031
2018.01.15 21:53:25 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 21:53:25 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 21:53:25 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:53:25 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 21:53:33 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:53:34 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:53:35 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:53:35 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 21:53:36 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 21:53:38 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 21:54:07 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 21:54:07 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.032
2018.01.15 21:54:07 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 21:54:07 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 21:54:07 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:54:07 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 21:54:16 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:54:17 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:54:17 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:54:18 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 21:54:18 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 21:54:19 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 21:55:06 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 21:55:06 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.033
2018.01.15 21:55:06 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 21:55:06 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 21:55:06 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:55:06 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 21:55:13 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:55:14 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:55:15 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:55:15 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 21:55:16 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 21:55:18 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 21:55:59 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 21:55:59 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.034
2018.01.15 21:55:59 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 21:55:59 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 21:55:59 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:55:59 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 21:56:06 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:56:07 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:56:07 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:56:08 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 21:56:08 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 21:56:10 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 21:57:07 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 21:57:07 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.035
2018.01.15 21:57:07 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 21:57:07 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 21:57:07 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:57:07 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 21:57:15 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:57:16 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:57:17 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:57:17 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 21:57:18 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 21:57:19 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 21:58:00 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 21:58:00 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.036
2018.01.15 21:58:00 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 21:58:00 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 21:58:00 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:58:00 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 21:58:08 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:58:09 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:58:10 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:58:10 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 21:58:11 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 21:58:12 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 21:59:04 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 21:59:04 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.037
2018.01.15 21:59:04 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 21:59:04 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 21:59:04 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 21:59:04 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 21:59:16 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 21:59:17 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 21:59:18 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 21:59:18 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 21:59:18 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 21:59:20 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 22:00:30 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 22:00:30 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.038
2018.01.15 22:00:30 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 22:00:30 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 22:00:30 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 22:00:30 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 22:00:38 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 22:00:39 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 22:00:40 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 22:00:40 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 22:00:41 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 22:00:41 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 22:01:25 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 22:01:25 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.039
2018.01.15 22:01:25 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 22:01:25 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 22:01:25 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 22:01:25 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 22:01:36 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 22:01:37 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 22:01:37 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 22:01:38 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 22:01:38 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 22:01:40 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 22:02:10 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 22:02:10 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.04
2018.01.15 22:02:10 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 22:02:10 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 22:02:10 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 22:02:10 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 22:02:17 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 22:02:18 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 22:02:18 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 22:02:19 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 22:02:19 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 22:02:20 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 22:03:06 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 22:03:06 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.041
2018.01.15 22:03:06 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 22:03:06 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 22:03:06 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 22:03:06 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 22:03:14 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 22:03:15 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 22:03:16 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 22:03:16 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 22:03:16 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 22:03:17 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 22:04:38 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 22:04:38 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.042
2018.01.15 22:04:38 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 22:04:38 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 22:04:38 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 22:04:38 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 22:04:46 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 22:04:47 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 22:04:48 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 22:04:48 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 22:04:49 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 22:04:50 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 22:06:00 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 22:06:00 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.043
2018.01.15 22:06:00 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 22:06:00 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 22:06:00 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 22:06:00 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 22:06:08 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 22:06:09 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 22:06:10 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 22:06:10 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 22:06:11 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 22:06:12 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 22:07:02 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 22:07:02 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.044
2018.01.15 22:07:02 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 22:07:02 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 22:07:02 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 22:07:02 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 22:07:10 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 22:07:11 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 22:07:11 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 22:07:12 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 22:07:12 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 22:07:13 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 22:08:42 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 22:08:42 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.045
2018.01.15 22:08:42 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 22:08:42 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 22:08:42 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 22:08:42 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 22:08:49 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 22:08:50 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 22:08:50 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 22:08:51 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 22:08:51 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 22:08:53 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 22:09:37 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 22:09:37 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.046
2018.01.15 22:09:37 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 22:09:37 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 22:09:37 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 22:09:37 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 22:09:44 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 22:09:45 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 22:09:46 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 22:09:46 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 22:09:47 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 22:09:48 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 22:10:51 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 22:10:51 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.047
2018.01.15 22:10:51 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 22:10:51 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 22:10:51 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 22:10:51 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 22:10:59 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 22:11:00 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 22:11:00 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 22:11:01 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 22:11:01 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 22:11:01 1: FHEMWEB SSL/HTTPS error:  SSL accept attempt failed because of handshake problems (peer: 192.168.178.31)
2018.01.15 22:11:01 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 22:11:54 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 22:11:54 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.048
2018.01.15 22:11:54 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 22:11:54 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 22:11:54 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 22:11:54 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.15 22:12:03 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.15 22:12:04 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.15 22:12:04 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.15 22:12:05 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.15 22:12:05 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.15 22:12:06 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.15 22:13:57 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.15 22:13:57 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.049
2018.01.15 22:13:57 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.15 22:13:57 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.15 22:13:57 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.15 22:13:57 1: TSCUL_Read CUL_01: no data read or disconnected


list CUL_01:
[code]
Internals:
   CFGFN     
   CMDS       ABCFGJKRUVWXYeilmtx
   CUL_01_MSGCNT 82
   CUL_01_TIME 2018-01-15 22:14:58
   Clients    STACKABLETS:STACKABLE:CUL_HM:HMS:CUL_IR
   DEF        /dev/ttyACM0@12000000 1034
   DeviceName /dev/ttyACM0@12000000
   FD         19
   FHTID      1034
   NAME       CUL_01
   NR         242
   PARTIAL   
   RAWMSG     A0D02804142EAB045E23B07900080::-100.5:CUL_01:
   RSSI       -100.5
   ReReadTO   0.05
   STATE      Initialized
   TYPE       TSCUL
   VERSION    VTS 0.21 CUL868
   VERSION_HW CUL_V3.4
   VERSION_TS yes AES ChTblSize:220
   XmitOpen   1
   assignUpdCntI 2
   assignedIDsCnt 2
   initString X21
Ar
AM5
AHC58719
   owner_CCU  VCCU
   MatchList:
     1:STACKABLETS ^\*
     2:STACKABLE ^\*
     A:CUL_HM   ^A[FIXHLO(\?A)]
     B:CUL_IR   ^I............
     C:HMS      ^810e04......a001
   READINGS:
     2018-01-15 22:14:55   Xmit-Events     disconnected:51 init:50 ok:49 non-HM:2
     2018-01-15 22:14:52   cmds             A B C F G J K R U V W X Y e i l m t x
     2018-01-15 22:14:55   cond            ok
     2018-01-15 22:14:43   prot_disconnected last
     2018-01-15 22:14:53   prot_init       last
     2018-01-15 21:25:38   prot_non-HM     last
     2018-01-15 22:14:55   prot_ok         last
     2018-01-15 21:28:10   scF             5433.08333333333
     2018-01-15 22:14:54   state           Initialized
   helper:
     CUrun      0
     ChkPart    0
     RA_Timeout 0
     VTS        1
     VTS_ACK    1
     VTS_AES    1
     assIdCnt   2
     assIdRep   2
     hmTSAt1Add
     rmsg       A0D02804142EAB045E23B07900080::-100.5:CUL_01:
     DEVIO:
       RXfailTO   
     HM:
       ChTblSize  220
       FUP        0
       HMactive   1
       hmCrdts    7
       hmSbusy    0
       ChTbl:
         6056653F   00
         C587193F   00
       msgCNT:
         0x01       82
         0x02       51
         0x03       45
       unknwn:
         222168:
           lstRecType 10
           nextSend   1516048266.80118
           nxtSndMcnt 7C
           tgtDly     88
           lRcTm:
             CUL_01     11064
             tnms       998553049
         413209:
           lstRecType 5E
           nextSend   1516050857.88511
           nxtSndMcnt 21
           tgtDly     88
           lRcTm:
             CUL_01     15772
             tnms       1001144133
         42EA6E:
           lstRecType 5A
           nextSend   1516050661.8874
           nxtSndMcnt 24
           tgtDly     88
           lRcTm:
             CUL_01     5336
             tnms       1000948135
         42EA70:
           lstRecType 41
           nextSend   1516050596.1117
           nxtSndMcnt 02
           tgtDly     88
           lRcTm:
             CUL_01     14020
             tnms       1000882360
         42EA9E:
           lstRecType 5A
           nextSend   1516050855.09439
           nxtSndMcnt DD
           tgtDly     88
           lRcTm:
             CUL_01     12984
             tnms       1001141342
         42EAB0:
           lstRecType 41
           nextSend   1516050898.40488
           nxtSndMcnt 02
           tgtDly     88
           lRcTm:
             CUL_01     9700
             tnms       1001184653
         42EABC:
           lstRecType 41
           nextSend   1516050897.58844
           nxtSndMcnt 02
           tgtDly     88
           lRcTm:
             CUL_01     8884
             tnms       1001183836
         43C4C8:
           lstRecType 03
           nextSend   1516050374.42649
           nxtSndMcnt 33
           tgtDly     88
           lRcTm:
             CUL_01     8368
             tnms       1000660674
         447937:
           lstRecType 02
           nextSend   1516050374.5453
           nxtSndMcnt 33
           tgtDly     88
           lRcTm:
             CUL_01     8488
             tnms       1000660793
     cnd:
       0          49
       250        2
       253        51
       255        50
     hmLogHist:
        478446 A F702 00006456 00 01 C3 _ping
        481539 A F701 00009548 00 0C EA 8470 42EAB0 000000 00EE35 -100dB
        008609 A F702 00006064 00 01 C3 _ping
        008936 A F701 00006388 00 0C 05 8470 42EABC 000000 00F435 -98.5dB
        012907 A F701 00010360 00 0D 02 8041 42EA9E 452560 07220080 -99dB
        016568 A F701 00014020 00 0D 02 8041 42EA70 452560 873A0080 -101.5dB
        082343 A F701 00005336 00 0C 24 865A 42EA6E 000000 88DE3B -85dB
        084656 A F702 00007652 00 01 C3 _ping
        146549 A F701 00006392 00 0C DC 8470 42EA9E 000000 00F235 -98.5dB
        147844 A F702 00007688 00 01 C3 _ping
        271100 A F702 00008
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 16 Januar 2018, 00:02:52
Hallo Heggeg,

wie es aussieht, startet Dein CUL oft neu, wie an der regelmäßig zurück gesetzten Timestamp zu erkennen. Mit get uptime müßtest Du das auch sehen.

Hast Du mal einen anderen USB Port verwendet? Und oder es mit einem extern versorgten USB Hub probiert?

Was sagt dmesg? Im Syslog irgendwelche Fehlerhinweise?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: Heggeg am 16 Januar 2018, 08:36:58
Zitat von: noansi am 16 Januar 2018, 00:02:52
Hallo Heggeg,

wie es aussieht, startet Dein CUL oft neu, wie an der regelmäßig zurück gesetzten Timestamp zu erkennen. Mit get uptime müßtest Du das auch sehen.

Hast Du mal einen anderen USB Port verwendet? Und oder es mit einem extern versorgten USB Hub probiert?

Was sagt dmesg? Im Syslog irgendwelche Fehlerhinweise?

Gruß, Ansgar.

Nein, ich habe noch keinen anderen USB Port verwendet. Der CUL lief auch ca 2 Monate am Host, zwar ohne verwendet zu werden, aber dort gab es keine Probleme im Log. Erst mit der ts_culfw. Ich werde aber heute noch mal einen anderen Port probieren und auch einen USB Hub daziwschen klemmen, wobei ich glaube das dies mit meinem Setup nicht funktioniert. Mein FHEM läuft nämlich als VM auf einem ESXi Hypervisor und der CUL wird mittels USB Passthrough vom Host direkt an die VM durchgereicht. Mit originaler FW kamen die Einträge im Log nicht, mit der FW war es mir aber eben auch nicht möglich mein Homematic Rolladenaktor zu pairen.

dmesg zeigt aber auch ziemlich viele Fehler an.. :(

dmesg:

[36249.934536] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[36324.804684] usb 1-2: USB disconnect, device number 34
[36324.804750] cdc_acm 1-2:1.0: failed to set dtr/rts
[36331.043807] usb 1-2: new full-speed USB device number 35 using xhci_hcd
[36331.522847] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[36331.522849] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[36331.522850] usb 1-2: Product: CUL868
[36331.522851] usb 1-2: Manufacturer: busware.de
[36331.522852] usb 1-2: SerialNumber: 868000
[36331.524552] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[36331.547968] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[36362.036105] usb 1-2: USB disconnect, device number 35
[36362.036191] cdc_acm 1-2:1.0: failed to set dtr/rts
[36368.268165] usb 1-2: new full-speed USB device number 36 using xhci_hcd
[36368.747107] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[36368.747109] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[36368.747110] usb 1-2: Product: CUL868
[36368.747111] usb 1-2: Manufacturer: busware.de
[36368.747112] usb 1-2: SerialNumber: 868000
[36368.748880] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[36368.772503] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[36448.318829] usb 1-2: USB disconnect, device number 36
[36448.318903] cdc_acm 1-2:1.0: failed to set dtr/rts
[36454.561280] usb 1-2: new full-speed USB device number 37 using xhci_hcd
[36455.040128] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[36455.040130] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[36455.040131] usb 1-2: Product: CUL868
[36455.040132] usb 1-2: Manufacturer: busware.de
[36455.040133] usb 1-2: SerialNumber: 868000
[36455.041814] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[36455.063634] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[36514.450723] usb 1-2: USB disconnect, device number 37
[36514.450811] cdc_acm 1-2:1.0: failed to set dtr/rts
[36520.686221] usb 1-2: new full-speed USB device number 38 using xhci_hcd
[36521.161101] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[36521.161103] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[36521.161104] usb 1-2: Product: CUL868
[36521.161105] usb 1-2: Manufacturer: busware.de
[36521.161105] usb 1-2: SerialNumber: 868000
[36521.162845] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[36521.186354] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[36605.989029] usb 1-2: USB disconnect, device number 38
[36605.989115] cdc_acm 1-2:1.0: failed to set dtr/rts
[36612.227367] usb 1-2: new full-speed USB device number 39 using xhci_hcd
[36612.710354] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[36612.710356] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[36612.710358] usb 1-2: Product: CUL868
[36612.710358] usb 1-2: Manufacturer: busware.de
[36612.710359] usb 1-2: SerialNumber: 868000
[36612.714396] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[36612.738540] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[36661.336819] usb 1-2: USB disconnect, device number 39
[36661.336919] cdc_acm 1-2:1.0: failed to set dtr/rts
[36667.580126] usb 1-2: new full-speed USB device number 40 using xhci_hcd
[36668.058915] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[36668.058917] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[36668.058918] usb 1-2: Product: CUL868
[36668.058919] usb 1-2: Manufacturer: busware.de
[36668.058919] usb 1-2: SerialNumber: 868000
[36668.060574] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[36668.084072] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[36762.934909] usb 1-2: USB disconnect, device number 40
[36762.935010] cdc_acm 1-2:1.0: failed to set dtr/rts
[36769.173397] usb 1-2: new full-speed USB device number 41 using xhci_hcd
[36769.652239] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[36769.652242] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[36769.652243] usb 1-2: Product: CUL868
[36769.652244] usb 1-2: Manufacturer: busware.de
[36769.652244] usb 1-2: SerialNumber: 868000
[36769.653942] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[36769.677166] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[36828.035783] usb 1-2: USB disconnect, device number 41
[36828.035874] cdc_acm 1-2:1.0: failed to set dtr/rts
[36834.278342] usb 1-2: new full-speed USB device number 42 using xhci_hcd
[36834.753128] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[36834.753130] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[36834.753131] usb 1-2: Product: CUL868
[36834.753132] usb 1-2: Manufacturer: busware.de
[36834.753133] usb 1-2: SerialNumber: 868000
[36834.754784] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[36834.778179] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[36912.483677] usb 1-2: USB disconnect, device number 42
[36912.483752] cdc_acm 1-2:1.0: failed to set dtr/rts
[36918.727484] usb 1-2: new full-speed USB device number 43 using xhci_hcd
[36919.202250] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[36919.202252] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[36919.202253] usb 1-2: Product: CUL868
[36919.202254] usb 1-2: Manufacturer: busware.de
[36919.202255] usb 1-2: SerialNumber: 868000
[36919.203929] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[36919.227433] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[36968.453068] usb 1-2: USB disconnect, device number 43
[36968.453180] cdc_acm 1-2:1.0: failed to set dtr/rts
[36974.692175] usb 1-2: new full-speed USB device number 44 using xhci_hcd
[36975.171018] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[36975.171030] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[36975.171032] usb 1-2: Product: CUL868
[36975.171033] usb 1-2: Manufacturer: busware.de
[36975.171034] usb 1-2: SerialNumber: 868000
[36975.172701] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[36975.196255] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[37063.392388] usb 1-2: USB disconnect, device number 44
[37063.392461] cdc_acm 1-2:1.0: failed to set dtr/rts
[37069.629418] usb 1-2: new full-speed USB device number 45 using xhci_hcd
[37070.108297] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[37070.108299] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[37070.108300] usb 1-2: Product: CUL868
[37070.108301] usb 1-2: Manufacturer: busware.de
[37070.108302] usb 1-2: SerialNumber: 868000
[37070.109943] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[37070.133204] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[37112.967032] usb 1-2: USB disconnect, device number 45
[37112.967116] cdc_acm 1-2:1.0: failed to set dtr/rts
[37119.206142] usb 1-2: new full-speed USB device number 46 using xhci_hcd
[37119.685095] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[37119.685097] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[37119.685098] usb 1-2: Product: CUL868
[37119.685099] usb 1-2: Manufacturer: busware.de
[37119.685100] usb 1-2: SerialNumber: 868000
[37119.686851] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[37119.709594] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[37181.293754] usb 1-2: USB disconnect, device number 46
[37181.293835] cdc_acm 1-2:1.0: failed to set dtr/rts
[37187.535079] usb 1-2: new full-speed USB device number 47 using xhci_hcd
[37188.014097] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[37188.014100] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[37188.014102] usb 1-2: Product: CUL868
[37188.014103] usb 1-2: Manufacturer: busware.de
[37188.014104] usb 1-2: SerialNumber: 868000
[37188.015932] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[37188.039382] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[37255.828327] usb 1-2: USB disconnect, device number 47
[37255.828460] cdc_acm 1-2:1.0: failed to set dtr/rts
[37262.072073] usb 1-2: new full-speed USB device number 48 using xhci_hcd
[37262.550872] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[37262.550874] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[37262.550875] usb 1-2: Product: CUL868
[37262.550876] usb 1-2: Manufacturer: busware.de
[37262.550876] usb 1-2: SerialNumber: 868000
[37262.552560] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[37262.576116] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[37318.974615] usb 1-2: USB disconnect, device number 48
[37318.974724] cdc_acm 1-2:1.0: failed to set dtr/rts
[37325.216884] usb 1-2: new full-speed USB device number 49 using xhci_hcd
[37325.695827] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[37325.695829] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[37325.695830] usb 1-2: Product: CUL868
[37325.695831] usb 1-2: Manufacturer: busware.de
[37325.695832] usb 1-2: SerialNumber: 868000
[37325.698506] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[37325.722022] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[37391.993985] usb 1-2: USB disconnect, device number 49
[37391.994065] cdc_acm 1-2:1.0: failed to set dtr/rts
[37398.233847] usb 1-2: new full-speed USB device number 50 using xhci_hcd
[37398.712816] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[37398.712818] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[37398.712819] usb 1-2: Product: CUL868
[37398.712820] usb 1-2: Manufacturer: busware.de
[37398.712820] usb 1-2: SerialNumber: 868000
[37398.714536] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[37398.737871] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[37435.616201] usb 1-2: USB disconnect, device number 50
[37435.616281] cdc_acm 1-2:1.0: failed to set dtr/rts
[37441.858429] usb 1-2: new full-speed USB device number 51 using xhci_hcd
[37442.337248] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[37442.337250] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[37442.337251] usb 1-2: Product: CUL868
[37442.337252] usb 1-2: Manufacturer: busware.de
[37442.337252] usb 1-2: SerialNumber: 868000
[37442.339005] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[37442.362335] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[37514.159063] usb 1-2: USB disconnect, device number 51
[37514.159160] cdc_acm 1-2:1.0: failed to set dtr/rts
[37520.399447] usb 1-2: new full-speed USB device number 52 using xhci_hcd
[37520.878309] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[37520.878311] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[37520.878312] usb 1-2: Product: CUL868
[37520.878313] usb 1-2: Manufacturer: busware.de
[37520.878314] usb 1-2: SerialNumber: 868000
[37520.879992] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[37520.903486] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[37563.467170] usb 1-2: USB disconnect, device number 52
[37563.467270] cdc_acm 1-2:1.0: failed to set dtr/rts
[37569.704239] usb 1-2: new full-speed USB device number 53 using xhci_hcd
[37570.179157] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[37570.179159] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[37570.179160] usb 1-2: Product: CUL868
[37570.179161] usb 1-2: Manufacturer: busware.de
[37570.179162] usb 1-2: SerialNumber: 868000
[37570.180866] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[37570.204219] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[37621.354789] usb 1-2: USB disconnect, device number 53
[37621.354884] cdc_acm 1-2:1.0: failed to set dtr/rts
[37627.592925] usb 1-2: new full-speed USB device number 54 using xhci_hcd
[37628.067899] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[37628.067901] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[37628.067902] usb 1-2: Product: CUL868
[37628.067903] usb 1-2: Manufacturer: busware.de
[37628.067908] usb 1-2: SerialNumber: 868000
[37628.070091] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[37628.093451] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[37701.993213] usb 1-2: USB disconnect, device number 54
[37701.993277] cdc_acm 1-2:1.0: failed to set dtr/rts
[37708.238008] usb 1-2: new full-speed USB device number 55 using xhci_hcd
[37708.716884] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[37708.716886] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[37708.716887] usb 1-2: Product: CUL868
[37708.716888] usb 1-2: Manufacturer: busware.de
[37708.716889] usb 1-2: SerialNumber: 868000
[37708.719294] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[37708.742751] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[37778.799189] usb 1-2: USB disconnect, device number 55
[37778.799288] cdc_acm 1-2:1.0: failed to set dtr/rts
[37785.038953] usb 1-2: new full-speed USB device number 56 using xhci_hcd
[37785.513846] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[37785.513848] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[37785.513850] usb 1-2: Product: CUL868
[37785.513850] usb 1-2: Manufacturer: busware.de
[37785.513851] usb 1-2: SerialNumber: 868000
[37785.515511] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[37785.537210] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[37818.352950] usb 1-2: USB disconnect, device number 56
[37818.353045] cdc_acm 1-2:1.0: failed to set dtr/rts
[37824.595556] usb 1-2: new full-speed USB device number 57 using xhci_hcd
[37825.074359] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[37825.074361] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[37825.074362] usb 1-2: Product: CUL868
[37825.074363] usb 1-2: Manufacturer: busware.de
[37825.074363] usb 1-2: SerialNumber: 868000
[37825.074437] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[37825.096731] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[37867.684211] usb 1-2: USB disconnect, device number 57
[37867.684298] cdc_acm 1-2:1.0: failed to set dtr/rts
[37873.924127] usb 1-2: new full-speed USB device number 58 using xhci_hcd
[37874.403007] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[37874.403009] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[37874.403010] usb 1-2: Product: CUL868
[37874.403011] usb 1-2: Manufacturer: busware.de
[37874.403011] usb 1-2: SerialNumber: 868000
[37874.404708] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[37874.428288] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[37920.051231] usb 1-2: USB disconnect, device number 58
[37920.051306] cdc_acm 1-2:1.0: failed to set dtr/rts
[37926.292821] usb 1-2: new full-speed USB device number 59 using xhci_hcd
[37926.771733] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[37926.771735] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[37926.771736] usb 1-2: Product: CUL868
[37926.771737] usb 1-2: Manufacturer: busware.de
[37926.771737] usb 1-2: SerialNumber: 868000
[37926.773401] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[37926.796751] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[38017.092618] usb 1-2: USB disconnect, device number 59
[38017.092707] cdc_acm 1-2:1.0: failed to set dtr/rts
[38023.330160] usb 1-2: new full-speed USB device number 60 using xhci_hcd
[38023.809010] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[38023.809012] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[38023.809013] usb 1-2: Product: CUL868
[38023.809014] usb 1-2: Manufacturer: busware.de
[38023.809014] usb 1-2: SerialNumber: 868000
[38023.810656] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[38023.833857] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[38071.873690] usb 1-2: USB disconnect, device number 60
[38071.873765] cdc_acm 1-2:1.0: failed to set dtr/rts
[38078.114838] usb 1-2: new full-speed USB device number 61 using xhci_hcd
[38078.593790] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[38078.593793] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[38078.593794] usb 1-2: Product: CUL868
[38078.593795] usb 1-2: Manufacturer: busware.de
[38078.593796] usb 1-2: SerialNumber: 868000
[38078.595646] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[38078.618937] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[38145.481486] usb 1-2: USB disconnect, device number 61
[38145.481563] cdc_acm 1-2:1.0: failed to set dtr/rts
[38151.723793] usb 1-2: new full-speed USB device number 62 using xhci_hcd
[38152.202773] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[38152.202775] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[38152.202776] usb 1-2: Product: CUL868
[38152.202777] usb 1-2: Manufacturer: busware.de
[38152.202777] usb 1-2: SerialNumber: 868000
[38152.204488] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[38152.226632] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[38192.033400] usb 1-2: USB disconnect, device number 62
[38192.033487] cdc_acm 1-2:1.0: failed to set dtr/rts
[38198.272448] usb 1-2: new full-speed USB device number 63 using xhci_hcd
[38198.751587] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[38198.751594] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[38198.751595] usb 1-2: Product: CUL868
[38198.751596] usb 1-2: Manufacturer: busware.de
[38198.751596] usb 1-2: SerialNumber: 868000
[38198.754049] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[38198.777367] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[38282.364372] usb 1-2: USB disconnect, device number 63
[38282.364463] cdc_acm 1-2:1.0: failed to set dtr/rts
[38288.601614] usb 1-2: new full-speed USB device number 64 using xhci_hcd
[38289.080518] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[38289.080520] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[38289.080521] usb 1-2: Product: CUL868
[38289.080521] usb 1-2: Manufacturer: busware.de
[38289.080522] usb 1-2: SerialNumber: 868000
[38289.082134] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[38289.105461] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[38345.498828] usb 1-2: USB disconnect, device number 64
[38345.498904] cdc_acm 1-2:1.0: failed to set dtr/rts
[38351.734442] usb 1-2: new full-speed USB device number 65 using xhci_hcd
[38352.213341] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[38352.213343] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[38352.213344] usb 1-2: Product: CUL868
[38352.213345] usb 1-2: Manufacturer: busware.de
[38352.213345] usb 1-2: SerialNumber: 868000
[38352.215022] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[38352.236858] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[38411.005115] usb 1-2: USB disconnect, device number 65
[38411.005200] cdc_acm 1-2:1.0: failed to set dtr/rts
[38417.247325] usb 1-2: new full-speed USB device number 66 using xhci_hcd
[38417.726187] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[38417.726189] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[38417.726190] usb 1-2: Product: CUL868
[38417.726191] usb 1-2: Manufacturer: busware.de
[38417.726191] usb 1-2: SerialNumber: 868000
[38417.727890] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[38417.751379] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[38466.753855] usb 1-2: USB disconnect, device number 66
[38466.753965] cdc_acm 1-2:1.0: failed to set dtr/rts
[38472.992116] usb 1-2: new full-speed USB device number 67 using xhci_hcd
[38473.471006] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[38473.471008] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[38473.471009] usb 1-2: Product: CUL868
[38473.471010] usb 1-2: Manufacturer: busware.de
[38473.471011] usb 1-2: SerialNumber: 868000
[38473.472738] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[38473.496046] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[38548.812906] usb 1-2: USB disconnect, device number 67
[38548.813033] cdc_acm 1-2:1.0: failed to set dtr/rts
[38555.053162] usb 1-2: new full-speed USB device number 68 using xhci_hcd
[38555.532070] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[38555.532072] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[38555.532073] usb 1-2: Product: CUL868
[38555.532074] usb 1-2: Manufacturer: busware.de
[38555.532075] usb 1-2: SerialNumber: 868000
[38555.533883] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[38555.557447] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[38617.508678] usb 1-2: USB disconnect, device number 68
[38617.508772] cdc_acm 1-2:1.0: failed to set dtr/rts
[38623.750221] usb 1-2: new full-speed USB device number 69 using xhci_hcd
[38624.224963] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[38624.224965] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[38624.224966] usb 1-2: Product: CUL868
[38624.224966] usb 1-2: Manufacturer: busware.de
[38624.224967] usb 1-2: SerialNumber: 868000
[38624.226707] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[38624.250225] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[38689.380328] usb 1-2: USB disconnect, device number 69
[38689.380436] cdc_acm 1-2:1.0: failed to set dtr/rts
[38695.619008] usb 1-2: new full-speed USB device number 70 using xhci_hcd
[38696.097979] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[38696.097981] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[38696.097982] usb 1-2: Product: CUL868
[38696.097983] usb 1-2: Manufacturer: busware.de
[38696.097984] usb 1-2: SerialNumber: 868000
[38696.099746] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[38696.123138] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[38753.915816] usb 1-2: USB disconnect, device number 70
[38753.915895] cdc_acm 1-2:1.0: failed to set dtr/rts
[38760.155866] usb 1-2: new full-speed USB device number 71 using xhci_hcd
[38760.634716] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[38760.634718] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[38760.634720] usb 1-2: Product: CUL868
[38760.634720] usb 1-2: Manufacturer: busware.de
[38760.634721] usb 1-2: SerialNumber: 868000
[38760.636441] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[38760.659598] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[38805.736934] usb 1-2: USB disconnect, device number 71
[38805.737001] cdc_acm 1-2:1.0: failed to set dtr/rts
[38811.976609] usb 1-2: new full-speed USB device number 72 using xhci_hcd
[38812.455340] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[38812.455342] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[38812.455344] usb 1-2: Product: CUL868
[38812.455344] usb 1-2: Manufacturer: busware.de
[38812.455345] usb 1-2: SerialNumber: 868000
[38812.457008] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[38812.480378] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[38879.880158] usb 1-2: USB disconnect, device number 72
[38879.880242] cdc_acm 1-2:1.0: failed to set dtr/rts
[38886.121470] usb 1-2: new full-speed USB device number 73 using xhci_hcd
[38886.600356] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[38886.600358] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[38886.600359] usb 1-2: Product: CUL868
[38886.600360] usb 1-2: Manufacturer: busware.de
[38886.600360] usb 1-2: SerialNumber: 868000
[38886.602031] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[38886.625422] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[38932.485881] usb 1-2: USB disconnect, device number 73
[38932.485960] cdc_acm 1-2:1.0: failed to set dtr/rts
[38938.730186] usb 1-2: new full-speed USB device number 74 using xhci_hcd
[38939.205220] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[38939.205222] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[38939.205223] usb 1-2: Product: CUL868
[38939.205224] usb 1-2: Manufacturer: busware.de
[38939.205225] usb 1-2: SerialNumber: 868000
[38939.207800] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[38939.231166] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[38997.634912] usb 1-2: USB disconnect, device number 74
[38997.635008] cdc_acm 1-2:1.0: failed to set dtr/rts
[39003.878984] usb 1-2: new full-speed USB device number 75 using xhci_hcd
[39004.358020] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[39004.358022] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[39004.358024] usb 1-2: Product: CUL868
[39004.358025] usb 1-2: Manufacturer: busware.de
[39004.358025] usb 1-2: SerialNumber: 868000
[39004.359815] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[39004.381617] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[39061.378893] usb 1-2: USB disconnect, device number 75
[39061.378976] cdc_acm 1-2:1.0: failed to set dtr/rts
[39067.615823] usb 1-2: new full-speed USB device number 76 using xhci_hcd
[39068.094671] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[39068.094677] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[39068.094679] usb 1-2: Product: CUL868
[39068.094680] usb 1-2: Manufacturer: busware.de
[39068.094680] usb 1-2: SerialNumber: 868000
[39068.096378] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[39068.119714] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[39119.489223] usb 1-2: USB disconnect, device number 76
[39119.489341] cdc_acm 1-2:1.0: failed to set dtr/rts
[39125.728617] usb 1-2: new full-speed USB device number 77 using xhci_hcd
[39126.203461] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[39126.203463] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[39126.203464] usb 1-2: Product: CUL868
[39126.203465] usb 1-2: Manufacturer: busware.de
[39126.203466] usb 1-2: SerialNumber: 868000
[39126.205192] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[39126.228780] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[39175.885831] usb 1-2: USB disconnect, device number 77
[39175.885919] cdc_acm 1-2:1.0: failed to set dtr/rts
[39182.125273] usb 1-2: new full-speed USB device number 78 using xhci_hcd
[39182.600377] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[39182.600379] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[39182.600380] usb 1-2: Product: CUL868
[39182.600381] usb 1-2: Manufacturer: busware.de
[39182.600381] usb 1-2: SerialNumber: 868000
[39182.602125] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[39182.625448] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[39240.272939] usb 1-2: USB disconnect, device number 78
[39240.273003] cdc_acm 1-2:1.0: failed to set dtr/rts
[39246.514133] usb 1-2: new full-speed USB device number 79 using xhci_hcd
[39246.988912] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[39246.988914] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[39246.988915] usb 1-2: Product: CUL868
[39246.988916] usb 1-2: Manufacturer: busware.de
[39246.988917] usb 1-2: SerialNumber: 868000
[39246.990626] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[39247.012901] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[39300.427940] usb 1-2: USB disconnect, device number 79
[39300.428033] cdc_acm 1-2:1.0: failed to set dtr/rts
[39306.666926] usb 1-2: new full-speed USB device number 80 using xhci_hcd
[39307.145648] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[39307.145650] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[39307.145652] usb 1-2: Product: CUL868
[39307.145652] usb 1-2: Manufacturer: busware.de
[39307.145653] usb 1-2: SerialNumber: 868000
[39307.150918] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[39307.173723] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[39352.317602] usb 1-2: USB disconnect, device number 80
[39352.317691] cdc_acm 1-2:1.0: failed to set dtr/rts
[39358.555574] usb 1-2: new full-speed USB device number 81 using xhci_hcd
[39359.030345] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[39359.030348] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[39359.030349] usb 1-2: Product: CUL868
[39359.030350] usb 1-2: Manufacturer: busware.de
[39359.030351] usb 1-2: SerialNumber: 868000
[39359.032775] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[39359.056229] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[39415.890071] usb 1-2: USB disconnect, device number 81
[39415.890210] cdc_acm 1-2:1.0: failed to set dtr/rts
[39422.132385] usb 1-2: new full-speed USB device number 82 using xhci_hcd
[39422.611338] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[39422.611340] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[39422.611341] usb 1-2: Product: CUL868
[39422.611342] usb 1-2: Manufacturer: busware.de
[39422.611343] usb 1-2: SerialNumber: 868000
[39422.613120] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[39422.636491] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[39456.426790] usb 1-2: USB disconnect, device number 82
[39456.426873] cdc_acm 1-2:1.0: failed to set dtr/rts
[39462.664980] usb 1-2: new full-speed USB device number 83 using xhci_hcd
[39463.143727] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[39463.143729] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[39463.143730] usb 1-2: Product: CUL868
[39463.143731] usb 1-2: Manufacturer: busware.de
[39463.143732] usb 1-2: SerialNumber: 868000
[39463.145517] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[39463.167491] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[39498.556919] usb 1-2: USB disconnect, device number 83
[39498.556996] cdc_acm 1-2:1.0: failed to set dtr/rts
[39504.797462] usb 1-2: new full-speed USB device number 84 using xhci_hcd
[39505.276359] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[39505.276362] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[39505.276363] usb 1-2: Product: CUL868
[39505.276364] usb 1-2: Manufacturer: busware.de
[39505.276364] usb 1-2: SerialNumber: 868000
[39505.276430] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[39505.299690] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[39541.382715] usb 1-2: USB disconnect, device number 84
[39541.382801] cdc_acm 1-2:1.0: failed to set dtr/rts
[39547.626030] usb 1-2: new full-speed USB device number 85 using xhci_hcd
[39548.104936] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[39548.104938] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[39548.104939] usb 1-2: Product: CUL868
[39548.104940] usb 1-2: Manufacturer: busware.de
[39548.104940] usb 1-2: SerialNumber: 868000
[39548.106559] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[39548.127940] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[39612.893617] usb 1-2: USB disconnect, device number 85
[39612.893725] cdc_acm 1-2:1.0: failed to set dtr/rts
[39619.130956] usb 1-2: new full-speed USB device number 86 using xhci_hcd
[39619.605882] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[39619.605884] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[39619.605885] usb 1-2: Product: CUL868
[39619.605886] usb 1-2: Manufacturer: busware.de
[39619.605887] usb 1-2: SerialNumber: 868000
[39619.607505] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[39619.630193] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[39665.035470] usb 1-2: USB disconnect, device number 86
[39665.035565] cdc_acm 1-2:1.0: failed to set dtr/rts
[39671.275663] usb 1-2: new full-speed USB device number 87 using xhci_hcd
[39671.750627] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[39671.750629] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[39671.750630] usb 1-2: Product: CUL868
[39671.750631] usb 1-2: Manufacturer: busware.de
[39671.750632] usb 1-2: SerialNumber: 868000
[39671.752315] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[39671.775679] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[39733.503208] usb 1-2: USB disconnect, device number 87
[39733.503291] cdc_acm 1-2:1.0: failed to set dtr/rts
[39739.736538] usb 1-2: new full-speed USB device number 88 using xhci_hcd
[39740.215461] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[39740.215464] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[39740.215466] usb 1-2: Product: CUL868
[39740.215467] usb 1-2: Manufacturer: busware.de
[39740.215468] usb 1-2: SerialNumber: 868000
[39740.217115] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[39740.240586] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[39764.475903] usb 1-2: USB disconnect, device number 88
[39764.475989] cdc_acm 1-2:1.0: failed to set dtr/rts
[39770.716932] usb 1-2: new full-speed USB device number 89 using xhci_hcd
[39771.199907] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[39771.200494] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[39771.200497] usb 1-2: Product: CUL868
[39771.200498] usb 1-2: Manufacturer: busware.de
[39771.200498] usb 1-2: SerialNumber: 868000
[39771.202156] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[39771.223604] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[39872.460834] usb 1-2: USB disconnect, device number 89
[39872.460921] cdc_acm 1-2:1.0: failed to set dtr/rts
[39878.698342] usb 1-2: new full-speed USB device number 90 using xhci_hcd
[39879.177281] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[39879.177283] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[39879.177284] usb 1-2: Product: CUL868
[39879.177285] usb 1-2: Manufacturer: busware.de
[39879.177285] usb 1-2: SerialNumber: 868000
[39879.178978] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[39879.201574] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[39939.278359] usb 1-2: USB disconnect, device number 90
[39939.278421] cdc_acm 1-2:1.0: failed to set dtr/rts
[39945.519208] usb 1-2: new full-speed USB device number 91 using xhci_hcd
[39945.994101] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[39945.994103] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[39945.994104] usb 1-2: Product: CUL868
[39945.994105] usb 1-2: Manufacturer: busware.de
[39945.994106] usb 1-2: SerialNumber: 868000
[39945.995726] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[39946.018881] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[40021.389255] usb 1-2: USB disconnect, device number 91
[40021.389366] cdc_acm 1-2:1.0: failed to set dtr/rts
[40027.632342] usb 1-2: new full-speed USB device number 92 using xhci_hcd
[40028.107105] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[40028.107106] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[40028.107108] usb 1-2: Product: CUL868
[40028.107109] usb 1-2: Manufacturer: busware.de
[40028.107109] usb 1-2: SerialNumber: 868000
[40028.108743] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[40028.131895] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[40071.574721] usb 1-2: USB disconnect, device number 92
[40071.574784] cdc_acm 1-2:1.0: failed to set dtr/rts
[40077.816987] usb 1-2: new full-speed USB device number 93 using xhci_hcd
[40078.295884] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[40078.295886] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[40078.295887] usb 1-2: Product: CUL868
[40078.295888] usb 1-2: Manufacturer: busware.de
[40078.295889] usb 1-2: SerialNumber: 868000
[40078.297689] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[40078.319670] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[40135.913031] usb 1-2: USB disconnect, device number 93
[40135.913107] cdc_acm 1-2:1.0: failed to set dtr/rts
[40142.153775] usb 1-2: new full-speed USB device number 94 using xhci_hcd
[40142.632731] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[40142.632733] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[40142.632734] usb 1-2: Product: CUL868
[40142.632735] usb 1-2: Manufacturer: busware.de
[40142.632735] usb 1-2: SerialNumber: 868000
[40142.634417] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[40142.656524] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[40194.759577] usb 1-2: USB disconnect, device number 94
[40194.759664] cdc_acm 1-2:1.0: failed to set dtr/rts
[40200.998580] usb 1-2: new full-speed USB device number 95 using xhci_hcd
[40201.473442] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[40201.473444] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[40201.473445] usb 1-2: Product: CUL868
[40201.473446] usb 1-2: Manufacturer: busware.de
[40201.473447] usb 1-2: SerialNumber: 868000
[40201.475092] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[40201.497432] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[40251.036953] usb 1-2: USB disconnect, device number 95
[40251.037044] cdc_acm 1-2:1.0: failed to set dtr/rts
[40257.275311] usb 1-2: new full-speed USB device number 96 using xhci_hcd
[40257.754240] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[40257.754242] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[40257.754243] usb 1-2: Product: CUL868
[40257.754243] usb 1-2: Manufacturer: busware.de
[40257.754244] usb 1-2: SerialNumber: 868000
[40257.755931] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[40257.779152] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[40294.718790] usb 1-2: USB disconnect, device number 96
[40294.718901] cdc_acm 1-2:1.0: failed to set dtr/rts
[40300.959858] usb 1-2: new full-speed USB device number 97 using xhci_hcd
[40301.438792] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[40301.438794] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[40301.438795] usb 1-2: Product: CUL868
[40301.438796] usb 1-2: Manufacturer: busware.de
[40301.438797] usb 1-2: SerialNumber: 868000
[40301.438863] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[40301.463399] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[40354.403655] usb 1-2: USB disconnect, device number 97
[40354.403717] cdc_acm 1-2:1.0: failed to set dtr/rts
[40360.636640] usb 1-2: new full-speed USB device number 98 using xhci_hcd
[40361.115550] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[40361.115552] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[40361.115553] usb 1-2: Product: CUL868
[40361.115554] usb 1-2: Manufacturer: busware.de
[40361.115555] usb 1-2: SerialNumber: 868000
[40361.117900] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[40361.141354] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[40437.563382] usb 1-2: USB disconnect, device number 98
[40437.563467] cdc_acm 1-2:1.0: failed to set dtr/rts
[40443.801760] usb 1-2: new full-speed USB device number 99 using xhci_hcd
[40444.280734] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[40444.280736] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[40444.280737] usb 1-2: Product: CUL868
[40444.280738] usb 1-2: Manufacturer: busware.de
[40444.280738] usb 1-2: SerialNumber: 868000
[40444.282417] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[40444.305700] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[40495.152843] usb 1-2: USB disconnect, device number 99
[40495.152935] cdc_acm 1-2:1.0: failed to set dtr/rts
[40501.386552] usb 1-2: new full-speed USB device number 100 using xhci_hcd
[40501.861379] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[40501.861381] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[40501.861382] usb 1-2: Product: CUL868
[40501.861383] usb 1-2: Manufacturer: busware.de
[40501.861384] usb 1-2: SerialNumber: 868000
[40501.863084] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[40501.884435] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[40581.531751] usb 1-2: USB disconnect, device number 100
[40581.531839] cdc_acm 1-2:1.0: failed to set dtr/rts
[40587.771744] usb 1-2: new full-speed USB device number 101 using xhci_hcd
[40588.246588] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[40588.246590] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[40588.246591] usb 1-2: Product: CUL868
[40588.246592] usb 1-2: Manufacturer: busware.de
[40588.246592] usb 1-2: SerialNumber: 868000
[40588.248382] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[40588.270494] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[40634.273865] usb 1-2: USB disconnect, device number 101
[40634.273944] cdc_acm 1-2:1.0: failed to set dtr/rts
[40640.508323] usb 1-2: new full-speed USB device number 102 using xhci_hcd
[40640.987281] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[40640.987288] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[40640.987289] usb 1-2: Product: CUL868
[40640.987290] usb 1-2: Manufacturer: busware.de
[40640.987291] usb 1-2: SerialNumber: 868000
[40640.989022] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[40641.011772] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[40680.830847] usb 1-2: USB disconnect, device number 102
[40680.830932] cdc_acm 1-2:1.0: failed to set dtr/rts
[40687.068976] usb 1-2: new full-speed USB device number 103 using xhci_hcd
[40687.543770] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[40687.543772] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[40687.543773] usb 1-2: Product: CUL868
[40687.543774] usb 1-2: Manufacturer: busware.de
[40687.543775] usb 1-2: SerialNumber: 868000
[40687.545485] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[40687.568700] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[40741.402744] usb 1-2: USB disconnect, device number 103
[40741.402826] cdc_acm 1-2:1.0: failed to set dtr/rts
[40747.637794] usb 1-2: new full-speed USB device number 104 using xhci_hcd
[40748.116739] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[40748.116741] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[40748.116742] usb 1-2: Product: CUL868
[40748.116743] usb 1-2: Manufacturer: busware.de
[40748.116743] usb 1-2: SerialNumber: 868000
[40748.118504] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[40748.141620] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[40800.028394] usb 1-2: USB disconnect, device number 104
[40800.028514] cdc_acm 1-2:1.0: failed to set dtr/rts
[40806.262478] usb 1-2: new full-speed USB device number 105 using xhci_hcd
[40806.741421] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[40806.741423] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[40806.741424] usb 1-2: Product: CUL868
[40806.741425] usb 1-2: Manufacturer: busware.de
[40806.741426] usb 1-2: SerialNumber: 868000
[40806.743509] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[40806.766822] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[40868.683161] usb 1-2: USB disconnect, device number 105
[40868.683253] cdc_acm 1-2:1.0: failed to set dtr/rts
[40874.919367] usb 1-2: new full-speed USB device number 106 using xhci_hcd
[40875.398274] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[40875.398276] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[40875.398277] usb 1-2: Product: CUL868
[40875.398278] usb 1-2: Manufacturer: busware.de
[40875.398279] usb 1-2: SerialNumber: 868000
[40875.399908] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[40875.423325] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[40920.074511] usb 1-2: USB disconnect, device number 106
[40920.074595] cdc_acm 1-2:1.0: failed to set dtr/rts
[40926.316082] usb 1-2: new full-speed USB device number 107 using xhci_hcd
[40926.794988] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[40926.794989] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[40926.794991] usb 1-2: Product: CUL868
[40926.794991] usb 1-2: Manufacturer: busware.de
[40926.794992] usb 1-2: SerialNumber: 868000
[40926.796707] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[40926.818222] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[40964.741916] usb 1-2: USB disconnect, device number 107
[40964.742001] cdc_acm 1-2:1.0: failed to set dtr/rts
[40970.980631] usb 1-2: new full-speed USB device number 108 using xhci_hcd
[40971.463543] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[40971.463545] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[40971.463546] usb 1-2: Product: CUL868
[40971.463547] usb 1-2: Manufacturer: busware.de
[40971.463548] usb 1-2: SerialNumber: 868000
[40971.463616] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[40971.487011] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[41018.194948] usb 1-2: USB disconnect, device number 108
[41018.195052] cdc_acm 1-2:1.0: failed to set dtr/rts
[41024.437316] usb 1-2: new full-speed USB device number 109 using xhci_hcd
[41024.916195] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[41024.916197] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[41024.916198] usb 1-2: Product: CUL868
[41024.916199] usb 1-2: Manufacturer: busware.de
[41024.916200] usb 1-2: SerialNumber: 868000
[41024.917866] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[41024.941208] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[41092.027277] usb 1-2: USB disconnect, device number 109
[41092.027359] cdc_acm 1-2:1.0: failed to set dtr/rts
[41098.274378] usb 1-2: new full-speed USB device number 110 using xhci_hcd
[41098.753236] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[41098.753239] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[41098.753240] usb 1-2: Product: CUL868
[41098.753241] usb 1-2: Manufacturer: busware.de
[41098.753241] usb 1-2: SerialNumber: 868000
[41098.754940] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[41098.777576] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[41139.406386] usb 1-2: USB disconnect, device number 110
[41139.406482] cdc_acm 1-2:1.0: failed to set dtr/rts
[41145.650870] usb 1-2: new full-speed USB device number 111 using xhci_hcd
[41146.129741] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[41146.129743] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[41146.129744] usb 1-2: Product: CUL868
[41146.129745] usb 1-2: Manufacturer: busware.de
[41146.129746] usb 1-2: SerialNumber: 868000
[41146.131440] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[41146.153722] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[41220.450760] usb 1-2: USB disconnect, device number 111
[41220.450865] cdc_acm 1-2:1.0: failed to set dtr/rts
[41226.688012] usb 1-2: new full-speed USB device number 112 using xhci_hcd
[41227.162947] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[41227.162949] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[41227.162950] usb 1-2: Product: CUL868
[41227.162951] usb 1-2: Manufacturer: busware.de
[41227.162951] usb 1-2: SerialNumber: 868000
[41227.164692] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[41227.186017] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[41256.710579] usb 1-2: USB disconnect, device number 112
[41256.710671] cdc_acm 1-2:1.0: failed to set dtr/rts
[41262.944405] usb 1-2: new full-speed USB device number 113 using xhci_hcd
[41263.423320] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[41263.423322] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[41263.423323] usb 1-2: Product: CUL868
[41263.423324] usb 1-2: Manufacturer: busware.de
[41263.423324] usb 1-2: SerialNumber: 868000
[41263.425027] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[41263.446874] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[41330.941295] usb 1-2: USB disconnect, device number 113
[41330.941370] cdc_acm 1-2:1.0: failed to set dtr/rts
[41337.177463] usb 1-2: new full-speed USB device number 114 using xhci_hcd
[41337.656947] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[41337.656949] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[41337.656951] usb 1-2: Product: CUL868
[41337.656951] usb 1-2: Manufacturer: busware.de
[41337.656952] usb 1-2: SerialNumber: 868000
[41337.658710] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[41337.682053] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[41399.022882] usb 1-2: USB disconnect, device number 114
[41399.022972] cdc_acm 1-2:1.0: failed to set dtr/rts
[41405.266227] usb 1-2: new full-speed USB device number 115 using xhci_hcd
[41405.745124] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[41405.745126] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[41405.745127] usb 1-2: Product: CUL868
[41405.745129] usb 1-2: Manufacturer: busware.de
[41405.745129] usb 1-2: SerialNumber: 868000
[41405.746725] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[41405.770026] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[41434.846227] usb 1-2: USB disconnect, device number 115
[41434.846320] cdc_acm 1-2:1.0: failed to set dtr/rts
[41441.086780] usb 1-2: new full-speed USB device number 116 using xhci_hcd
[41441.565795] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[41441.565797] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[41441.565798] usb 1-2: Product: CUL868
[41441.565799] usb 1-2: Manufacturer: busware.de
[41441.565799] usb 1-2: SerialNumber: 868000
[41441.567531] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[41441.590660] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[41477.444590] usb 1-2: USB disconnect, device number 116
[41477.444661] cdc_acm 1-2:1.0: failed to set dtr/rts
[41483.687320] usb 1-2: new full-speed USB device number 117 using xhci_hcd
[41484.166298] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[41484.166301] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[41484.166302] usb 1-2: Product: CUL868
[41484.166303] usb 1-2: Manufacturer: busware.de
[41484.166303] usb 1-2: SerialNumber: 868000
[41484.167956] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[41484.191248] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[41519.777930] usb 1-2: USB disconnect, device number 117
[41519.778028] cdc_acm 1-2:1.0: failed to set dtr/rts
[41526.019933] usb 1-2: new full-speed USB device number 118 using xhci_hcd
[41526.498516] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[41526.498518] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[41526.498519] usb 1-2: Product: CUL868
[41526.498520] usb 1-2: Manufacturer: busware.de
[41526.498521] usb 1-2: SerialNumber: 868000
[41526.500327] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[41526.523555] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[41567.787194] usb 1-2: USB disconnect, device number 118
[41567.787276] cdc_acm 1-2:1.0: failed to set dtr/rts
[41574.028408] usb 1-2: new full-speed USB device number 119 using xhci_hcd
[41574.503315] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[41574.503317] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[41574.503319] usb 1-2: Product: CUL868
[41574.503324] usb 1-2: Manufacturer: busware.de
[41574.503325] usb 1-2: SerialNumber: 868000
[41574.505113] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[41574.527706] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[41643.804899] usb 1-2: USB disconnect, device number 119
[41643.804979] cdc_acm 1-2:1.0: failed to set dtr/rts
[41650.045475] usb 1-2: new full-speed USB device number 120 using xhci_hcd
[41650.524415] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[41650.524417] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[41650.524418] usb 1-2: Product: CUL868
[41650.524419] usb 1-2: Manufacturer: busware.de
[41650.524420] usb 1-2: SerialNumber: 868000
[41650.526081] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[41650.549512] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[41691.849579] usb 1-2: USB disconnect, device number 120
[41691.849687] cdc_acm 1-2:1.0: failed to set dtr/rts
[41698.086009] usb 1-2: new full-speed USB device number 121 using xhci_hcd
[41698.564846] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[41698.564848] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[41698.564849] usb 1-2: Product: CUL868
[41698.564850] usb 1-2: Manufacturer: busware.de
[41698.564851] usb 1-2: SerialNumber: 868000
[41698.566542] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[41698.588566] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[41791.456960] usb 1-2: USB disconnect, device number 121
[41791.457049] cdc_acm 1-2:1.0: failed to set dtr/rts
[41797.691345] usb 1-2: new full-speed USB device number 122 using xhci_hcd
[41798.170147] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[41798.170149] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[41798.170150] usb 1-2: Product: CUL868
[41798.170151] usb 1-2: Manufacturer: busware.de
[41798.170151] usb 1-2: SerialNumber: 868000
[41798.172599] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[41798.194774] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[41850.845196] usb 1-2: USB disconnect, device number 122
[41850.845291] cdc_acm 1-2:1.0: failed to set dtr/rts
[41857.084080] usb 1-2: new full-speed USB device number 123 using xhci_hcd
[41857.563113] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[41857.563115] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[41857.563116] usb 1-2: Product: CUL868
[41857.563117] usb 1-2: Manufacturer: busware.de
[41857.563118] usb 1-2: SerialNumber: 868000
[41857.564768] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[41857.587331] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[41881.997779] usb 1-2: USB disconnect, device number 123
[41881.997858] cdc_acm 1-2:1.0: failed to set dtr/rts
[41888.232677] usb 1-2: new full-speed USB device number 124 using xhci_hcd
[41888.711367] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[41888.711369] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[41888.711370] usb 1-2: Product: CUL868
[41888.711371] usb 1-2: Manufacturer: busware.de
[41888.711371] usb 1-2: SerialNumber: 868000
[41888.713051] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[41888.736220] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[41941.419485] usb 1-2: USB disconnect, device number 124
[41941.419579] cdc_acm 1-2:1.0: failed to set dtr/rts
[41947.653265] usb 1-2: new full-speed USB device number 125 using xhci_hcd
[41948.128080] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[41948.128082] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[41948.128083] usb 1-2: Product: CUL868
[41948.128084] usb 1-2: Manufacturer: busware.de
[41948.128085] usb 1-2: SerialNumber: 868000
[41948.129729] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[41948.151620] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[42006.598282] usb 1-2: USB disconnect, device number 125
[42006.598365] cdc_acm 1-2:1.0: failed to set dtr/rts
[42012.838107] usb 1-2: new full-speed USB device number 126 using xhci_hcd
[42013.317003] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[42013.317005] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[42013.317006] usb 1-2: Product: CUL868
[42013.317007] usb 1-2: Manufacturer: busware.de
[42013.317008] usb 1-2: SerialNumber: 868000
[42013.318709] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[42013.340847] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[42111.712048] usb 1-2: USB disconnect, device number 126
[42111.712149] cdc_acm 1-2:1.0: failed to set dtr/rts
[42117.955481] usb 1-2: new full-speed USB device number 127 using xhci_hcd
[42118.434817] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[42118.434819] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[42118.434820] usb 1-2: Product: CUL868
[42118.434821] usb 1-2: Manufacturer: busware.de
[42118.434822] usb 1-2: SerialNumber: 868000
[42118.436643] usb 1-2: ep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
[42118.458408] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[42158.101990] usb 1-2: USB disconnect, device number 127
[42158.102082] cdc_acm 1-2:1.0: failed to set dtr/rts
[42164.340088] usb 1-2: new full-speed USB device number 3 using xhci_hcd
[42164.815002] usb 1-2: New USB device found, idVendor=03eb, idProduct=204b
[42164.815004] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: Bastel-Frank am 16 Januar 2018, 10:16:18
Hallo Ansgar,

ich komme leider jetzt erst dazu deine Fragen zu beantworten:

Zitat von: noansi am 09 Januar 2018, 21:32:03
Hallo Frank,
2018.01.08 20:56:07 1: TSCUL_Parse: CUL_KG received ASKSIN error message: A?AX31D0AD3F
Gab es dazu einen Zusammenhang? Z.B. Neustart? Wie regelmäßig?

Dies betraf den CUL, der direkt am fhem hängt. Seit einem Neustart am 10.01.18 sind die Fehler weg.

Fehlermeldung:
Zitat von: Bastel-FrankUnd dann hatte ich auf der fhem-Startseite eine Fehlermeldung ungefähr in der Art, dass die "ASKSIN-Bibliothek nicht installiert" sei. Die genaue Fehlermeldung habe ich leider nicht. Falls ich diese nochmal bekomme, dann melde ich dir die genaue Beschreibung.

Zitat von: noansi am 09 Januar 2018, 21:32:03
Auch mit der aktuellen Version noch?
War das nach dem Flashen vor Tausch der Module? Oder nach dem Anstecken des CUL?
Stehen die auf Initialized? List bitte.
Das sind die, die per ser2net angebunden sind, richtig?

Mit der aktuellen Version und nach dem Neustart ist der Fehler bisher nicht mehr aufgetreten. Die Fehlermeldung kam von den CULs, die per ser2net angebunden sind. Die Module waren aus der Version 27 oder 28.

Vielen Dank für deine kurze Einführung zu AES. Ich möchten den Thread ebenfalls nicht sprengen. Aber eine kurze Nachfrage: Läuft bei dir AES mit einem CUL? An anderer Stelle habe ich gelesen, dass AES nicht mit einem CUL läuft.

Viele Grüße
Frank
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 16 Januar 2018, 21:04:43
Hallo Frank,

danke für das Feedback.

ZitatVielen Dank für deine kurze Einführung zu AES. Ich möchten den Thread ebenfalls nicht sprengen. Aber eine kurze Nachfrage: Läuft bei dir AES mit einem CUL? An anderer Stelle habe ich gelesen, dass AES nicht mit einem CUL läuft.
Es läuft bei mir mit AES.

Aktuelle Version vorrausgesetzt. Mit alten Ständen würde man noch sehr unter den FHEM Latenzen leiden.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 16 Januar 2018, 21:47:01
Hallo Heggeg,

die dmesg Ausgabe sagt im Grunde das gleiche, wie schon Dein Logauszug. CUL disconnected und reconnected häufig.

Leider sagt es auch nichts zur Ursache.
Zitatep 0x82 - rounding interval to 1024 microframes, ep desc says 2040 microframes
Das habe ich bei meinem RasPi nicht. Sollte aber wohl nicht das Problem sein.

ZitatDer CUL lief auch ca 2 Monate am Host, zwar ohne verwendet zu werden, aber dort gab es keine Probleme im Log.
Lief der da auch schon auf Homematic?

Beim Flashen des CULs kam keine Fehlermeldung? Wäre es fehlgeschlagen, würde das sicherlich zu merkwürdigem Verhalten führen.

ZitatMein FHEM läuft nämlich als VM auf einem ESXi Hypervisor und der CUL wird mittels USB Passthrough vom Host direkt an die VM durchgereicht.
Die Konfiguration kann ich leider nicht testen.
Was Watchdog Resets auslösen könnte, wäre, wenn CUL seine Daten an den Host für etwa 8 Sekunden (eigentlich eine Ewigkeit) nicht loswerden könnte. Das ist ein Unterschied zur Standard und a-culfw Firmware, bei vollem Sendepuffer wird gewartet, bis wieder Platz im Puffer ist.
Hast Du einen anderen Host, auf dem Du testen könntest? Bist Du mit Deinem System bezüglich Updates auf dem neuesten Stand?

Was sendet bei Dir noch auf der Frequenz?
HomeMatic IP z.B. habe ich noch nicht testen können, ob es irgendwie stört, wie bei anderen HM IOs. Vom Code her sollte es aber nicht zu so einem Verhalten kommen.

Was auch noch schlecht wäre, wenn irgendwas ein "B00" oder "e" an den CUL senden würde.
Setz den CUL mal auf verbose 5, ob damit so was seltsames im Log zu sehen ist.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: Heggeg am 18 Januar 2018, 22:40:01
Hey Ansgar

ZitatLief der da auch schon auf Homematic?
Nein, der CUL ist einfach nur in FHEM angelegt gewesen und wurde aber nicht benutzt.

ZitatBeim Flashen des CULs kam keine Fehlermeldung? Wäre es fehlgeschlagen, würde das sicherlich zu merkwürdigem Verhalten führen.
Nein, ich glaube nicht.

Habs grade noch mal gemacht, vielleicht hab ich ja auch einen Fehler gemacht.

root@ubuntu:~/Downloads/TSCUL_fwcode_00_21_FHEM_Modules_00_32/Firmware$ lsusbBus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 005: ID 03eb:2ff4 Atmel Corp. atmega32u4 DFU bootloader
Bus 002 Device 004: ID 0e0f:0008 VMware, Inc.
Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
root@ubuntu:~/Downloads/TSCUL_fwcode_00_21_FHEM_Modules_00_32/Firmware$ sudo dfu-programmer atmega32u4 erase
root@ubuntu:~/Downloads/TSCUL_fwcode_00_21_FHEM_Modules_00_32/Firmware$ sudo dfu-programmer atmega32u4 flash TSCUL_V3.hex
Validating...
28632 bytes used (99.86%)
root@ubuntu:~/Downloads/TSCUL_fwcode_00_21_FHEM_Modules_00_32/Firmware$ sudo dfu-programmer atmega32u4 start
root@ubuntu:~/Downloads/TSCUL_fwcode_00_21_FHEM_Modules_00_32/Firmware$


Keine Chance, Problem ist immer noch da.

ZitatHast Du einen anderen Host, auf dem Du testen könntest? Bist Du mit Deinem System bezüglich Updates auf dem neuesten Stand?
ESXi Host ist auf dem neusten Stand und das Ubuntu 16.04 LTS auf dem FHEM läuft ebenfalls. FHEM selber ist ebenfalls auf dem neusten Stand.
Ein anderes System habe ich so aber nicht da.

ZitatWas sendet bei Dir noch auf der Frequenz?
So weit gar nichts auf 868Mhz. Habe nur etliche Zigbee und WIFI Geräte im Betrieb.

ZitatWas auch noch schlecht wäre, wenn irgendwas ein "B00" oder "e" an den CUL senden würde.
Setz den CUL mal auf verbose 5, ob damit so was seltsames im Log zu sehen ist.
Ich habe nichts deartiges konfiguriert - bin absolut CUL & Homematic Neuling. Habe den CUL nun auf Verbose 5 laufen.


2018.01.18 22:31:26 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.18 22:31:26 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:31:27 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:31:27 5: TSCUL/RAW CUL_01 ReadAnswer: /VTS 0.21 CUL868

2018.01.18 22:31:27 5: dummy V CUL_01 VTS 0.21 CUL868
2018.01.18 22:31:27 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:31:27 5: TSCUL/RAW CUL_01 ReadAnswer: /? (? is unknown) Use one of A B C F G J K R U V W X Y e i l m t x

2018.01.18 22:31:27 5: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.18 22:31:27 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:31:27 5: TSCUL/RAW CUL_01 ReadAnswer: /VTS 0.21 CUL868

2018.01.18 22:31:27 5: V CUL_01 VTS 0.21 CUL868
2018.01.18 22:31:27 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:31:27 5: TSCUL/RAW CUL_01 ReadAnswer: /CUL_V3.4

2018.01.18 22:31:27 5: TSCUL/RAW CUL_01 ReadAnswer: /? (? is unknown) Use one of A B C F G J K R U V W X Y e i l m t x

2018.01.18 22:31:27 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.18 22:31:27 5: TSCUL/RAW CUL_01 ReadAnswer: /A?At1

2018.01.18 22:31:27 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:31:28 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:31:28 5: TSCUL/RAW CUL_01 ReadAnswer: /AF7020000486E0004TiMeStAmP80

2018.01.18 22:31:28 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:31:28 5: TSCUL/RAW CUL_01 ReadAnswer: /AL 6056653F:00 C587193F:00

2018.01.18 22:31:28 5: TSCUL_DoInit CUL_01 605665 created in ids
2018.01.18 22:31:28 5: TSCUL_DoInit CUL_01 C58719 created in ids
2018.01.18 22:31:28 5: TSCUL_DoInit CUL_01 {ids} built
2018.01.18 22:31:28 5: TSCUL/RAW CUL_01 ReadAnswer: /AS02/DC

2018.01.18 22:31:28 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.18 22:31:28 5: TSCUL/RAW CUL_01 ReadAnswer: /A?At0

2018.01.18 22:31:28 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:31:28 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:31:28 5: TSCUL/RAW CUL_01 ReadAnswer: /AF702000049050004TiMeStAmP80

2018.01.18 22:31:28 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.18 22:31:28 5: TSCUL/RAW CUL_01 ReadAnswer: /AHC58719

2018.01.18 22:31:28 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:31:29 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:31:29 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.18 22:31:29 5: TSCUL_Read CUL_01: /AF70200004A490001C380

2018.01.18 22:31:29 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.18 22:31:29 4: TSCUL_Parse: CUL_01  463684 A F702 00076068 00 01 C3 _ping
2018.01.18 22:32:33 3: CUL_HM set HM_605665 pct 50
2018.01.18 22:32:33 5: TSCUL_Write: CUL_01 sending As0C5FA011C58719605665020164
2018.01.18 22:32:33 4: TSCUL_send:  CUL_01  002929                 As 0C 5F A011 C58719 605665 020164
2018.01.18 22:32:33 4: TSCUL_XmitDlyHM:  CUL_01  id:605665 rtoms:2328
2018.01.18 22:32:34 4: TSCUL_SendPingHM CUL_01 ApC0 send. Throttle start
2018.01.18 22:32:35 4: TSCUL_XmitAwaitHMTo CUL_01: timeout - 605665
2018.01.18 22:32:38 5: TSCUL_Write: CUL_01 sending As0C5FA011C58719605665020164
2018.01.18 22:32:38 4: TSCUL_send:  CUL_01  007641                 As 0C 5F A011 C58719 605665 020164
2018.01.18 22:32:38 4: TSCUL_XmitDlyHM:  CUL_01  id:605665 rtoms:2328
2018.01.18 22:32:40 4: TSCUL_XmitAwaitHMTo CUL_01: timeout - 605665
2018.01.18 22:32:43 5: TSCUL_Write: CUL_01 sending As0C5FA011C58719605665020164
2018.01.18 22:32:43 4: TSCUL_send:  CUL_01  013220                 As 0C 5F A011 C58719 605665 020164
2018.01.18 22:32:43 4: TSCUL_XmitDlyHM:  CUL_01  id:605665 rtoms:2328
2018.01.18 22:32:46 4: TSCUL_XmitAwaitHMTo CUL_01: timeout - 605665
2018.01.18 22:32:46 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.18 22:32:46 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.017
2018.01.18 22:32:46 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.18 22:32:46 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.18 22:32:46 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.18 22:32:46 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.18 22:32:53 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.18 22:32:53 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:32:54 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:32:54 5: TSCUL/RAW CUL_01 ReadAnswer: /VTS 0.21 CUL868

2018.01.18 22:32:54 5: dummy V CUL_01 VTS 0.21 CUL868
2018.01.18 22:32:54 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:32:54 5: TSCUL/RAW CUL_01 ReadAnswer: /? (? is unknown) Use one of A B C F G J K R U V W X Y e i l m t x

2018.01.18 22:32:54 5: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.18 22:32:54 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:32:54 5: TSCUL/RAW CUL_01 ReadAnswer: /VTS 0.21 CUL868

2018.01.18 22:32:54 5: V CUL_01 VTS 0.21 CUL868
2018.01.18 22:32:54 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:32:54 5: TSCUL/RAW CUL_01 ReadAnswer: /CUL_V3.4

2018.01.18 22:32:54 5: TSCUL/RAW CUL_01 ReadAnswer: /? (? is unknown) Use one of A B C F G J K R U V W X Y e i l m t x

2018.01.18 22:32:54 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.18 22:32:54 5: TSCUL/RAW CUL_01 ReadAnswer: /A?At1

2018.01.18 22:32:54 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:32:55 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:32:55 5: TSCUL/RAW CUL_01 ReadAnswer: /AF702000003240004TiMeStAmP80

2018.01.18 22:32:55 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:32:55 5: TSCUL/RAW CUL_01 ReadAnswer: /AL 6056653F:00 C587193F:00

2018.01.18 22:32:55 5: TSCUL_DoInit CUL_01 605665 created in ids
2018.01.18 22:32:55 5: TSCUL_DoInit CUL_01 C58719 created in ids
2018.01.18 22:32:55 5: TSCUL_DoInit CUL_01 {ids} built
2018.01.18 22:32:55 5: TSCUL/RAW CUL_01 ReadAnswer: /AS02/DC

2018.01.18 22:32:55 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.18 22:32:55 5: TSCUL/RAW CUL_01 ReadAnswer: /A?At0

2018.01.18 22:32:55 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:32:55 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:32:55 5: TSCUL/RAW CUL_01 ReadAnswer: /AF702000003BB0004TiMeStAmP80

2018.01.18 22:32:55 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.18 22:32:55 5: TSCUL/RAW CUL_01 ReadAnswer: /AHC58719

2018.01.18 22:32:55 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:32:56 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:32:56 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.18 22:32:57 5: TSCUL_Read CUL_01: /AF70100000509000D60A410605665C5871906016400E0

2018.01.18 22:32:57 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.18 22:32:57 4: TSCUL_Parse: CUL_01  026414 A F701 00005156 00 0D 60 A410 605665 C58719 06016400 -90dB -90
2018.01.18 22:32:57 5: CUL_01: dispatch A0D60A410605665C5871906016400::-90:CUL_01:
2018.01.18 22:32:57 5: TSCUL_Write: CUL_01 sending As0A608002C5871960566500
2018.01.18 22:32:57 5: TSCUL_Write: CUL_01 Skip ACK
2018.01.18 22:32:57 5: TSCUL_Read CUL_01: /AF70300000523010A608002C587196056650080

2018.01.18 22:32:57 4: TSCUL_Parse: CUL_01  026542 A F703 00005260 01 0A 60 8002 C58719 605665 00 _CCAdly:4 _dhmSt:104
2018.01.18 22:32:58 5: TSCUL_Read CUL_01: /AF702000006920001C380

2018.01.18 22:32:58 4: TSCUL_Parse: CUL_01  027985 A F702 00006728 00 01 C3 _ping
2018.01.18 22:32:58 3: CUL_HM set HM_605665 pct 50
2018.01.18 22:33:03 1: TSCUL_RecoverHMQlen: CUL_01 recovered from Qlen lock
2018.01.18 22:33:08 3: CUL_HM set HM_605665 pct 60
2018.01.18 22:33:34 1: TSCUL_SendPingHM CUL_01 fatal: ApC0 timed out! Failsafe release send.
2018.01.18 22:33:34 5: TSCUL_Write: CUL_01 sending As0C61A011C58719605665020164
2018.01.18 22:33:34 4: TSCUL_send:  CUL_01  063500                 As 0C 61 A011 C58719 605665 020164
2018.01.18 22:33:34 4: TSCUL_XmitDlyHM:  CUL_01  id:605665 rtoms:2328
2018.01.18 22:33:34 4: TSCUL_SendPingHM CUL_01 ApC0 send. Throttle start
2018.01.18 22:33:36 5: TSCUL_Write: CUL_01 sending As0C61A011C58719605665020164
2018.01.18 22:33:36 4: TSCUL_XmitAwaitHMTo CUL_01: timeout - 605665
2018.01.18 22:33:40 5: TSCUL_Write: CUL_01 sending As0C61A011C58719605665020164
2018.01.18 22:33:40 4: TSCUL_send:  CUL_01  070191                 As 0C 61 A011 C58719 605665 020164
2018.01.18 22:33:40 4: TSCUL_XmitDlyHM:  CUL_01  id:605665 rtoms:2328
2018.01.18 22:33:43 4: TSCUL_XmitAwaitHMTo CUL_01: timeout - 605665
2018.01.18 22:33:46 5: TSCUL_Write: CUL_01 sending As0C61A011C58719605665020164
2018.01.18 22:33:46 4: TSCUL_send:  CUL_01  075847                 As 0C 61 A011 C58719 605665 020164
2018.01.18 22:33:46 4: TSCUL_XmitDlyHM:  CUL_01  id:605665 rtoms:2328
2018.01.18 22:33:48 4: TSCUL_XmitAwaitHMTo CUL_01: timeout - 605665
2018.01.18 22:33:49 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.18 22:33:49 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.018
2018.01.18 22:33:49 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.18 22:33:49 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.18 22:33:49 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.18 22:33:49 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.18 22:33:56 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.18 22:33:56 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:33:56 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:33:56 5: TSCUL/RAW CUL_01 ReadAnswer: /VTS 0.21 CUL868

2018.01.18 22:33:56 5: dummy V CUL_01 VTS 0.21 CUL868
2018.01.18 22:33:56 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:33:56 5: TSCUL/RAW CUL_01 ReadAnswer: /? (? is unknown) Use one of A B C F G J K R U V W X Y e i l m t x

2018.01.18 22:33:56 5: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.18 22:33:57 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:33:57 5: TSCUL/RAW CUL_01 ReadAnswer: /VTS 0.21 CUL868

2018.01.18 22:33:57 5: V CUL_01 VTS 0.21 CUL868
2018.01.18 22:33:57 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:33:57 5: TSCUL/RAW CUL_01 ReadAnswer: /CUL_V3.4

2018.01.18 22:33:57 5: TSCUL/RAW CUL_01 ReadAnswer: /? (? is unknown) Use one of A B C F G J K R U V W X Y e i l m t x

2018.01.18 22:33:57 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.18 22:33:57 5: TSCUL/RAW CUL_01 ReadAnswer: /A?At1

2018.01.18 22:33:57 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:33:57 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:33:57 5: TSCUL/RAW CUL_01 ReadAnswer: /AF702000003220004TiMeStAmP80

2018.01.18 22:33:57 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:33:57 5: TSCUL/RAW CUL_01 ReadAnswer: /AL 6056653F:00 C587193F:00

2018.01.18 22:33:57 5: TSCUL_DoInit CUL_01 605665 created in ids
2018.01.18 22:33:57 5: TSCUL_DoInit CUL_01 C58719 created in ids
2018.01.18 22:33:57 5: TSCUL_DoInit CUL_01 {ids} built
2018.01.18 22:33:57 5: TSCUL/RAW CUL_01 ReadAnswer: /AS02/DC

2018.01.18 22:33:57 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.18 22:33:57 5: TSCUL/RAW CUL_01 ReadAnswer: /A?At0

2018.01.18 22:33:58 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:33:58 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:33:58 5: TSCUL/RAW CUL_01 ReadAnswer: /AF702000003B90004TiMeStAmP80

2018.01.18 22:33:58 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.18 22:33:58 5: TSCUL/RAW CUL_01 ReadAnswer: /AHC58719

2018.01.18 22:33:58 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:33:58 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:33:58 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.18 22:34:00 5: TSCUL_Read CUL_01: /AF702000005BC0001C380

2018.01.18 22:34:00 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.18 22:34:00 4: TSCUL_Parse: CUL_01  089680 A F702 00005872 00 01 C3 _ping
2018.01.18 22:34:04 1: TSCUL_RecoverHMQlen: CUL_01 recovered from Qlen lock
2018.01.18 22:34:34 1: TSCUL_SendPingHM CUL_01 fatal: ApC0 timed out! Failsafe release send.
2018.01.18 22:34:34 5: TSCUL_Write: CUL_01 sending As0C62A011C58719605665020164
2018.01.18 22:34:34 4: TSCUL_send:  CUL_01  124111                 As 0C 62 A011 C58719 605665 020164
2018.01.18 22:34:34 4: TSCUL_XmitDlyHM:  CUL_01  id:605665 rtoms:2328
2018.01.18 22:34:35 4: TSCUL_SendPingHM CUL_01 ApC0 send. Throttle start
2018.01.18 22:34:37 4: TSCUL_XmitAwaitHMTo CUL_01: timeout - 605665
2018.01.18 22:34:39 5: TSCUL_Write: CUL_01 sending As0C62A011C58719605665020164
2018.01.18 22:34:39 4: TSCUL_send:  CUL_01  128539                 As 0C 62 A011 C58719 605665 020164
2018.01.18 22:34:39 4: TSCUL_XmitDlyHM:  CUL_01  id:605665 rtoms:2328
2018.01.18 22:34:41 4: TSCUL_XmitAwaitHMTo CUL_01: timeout - 605665
2018.01.18 22:34:45 5: TSCUL_Write: CUL_01 sending As0C62A011C58719605665020164
2018.01.18 22:34:45 4: TSCUL_send:  CUL_01  134446                 As 0C 62 A011 C58719 605665 020164
2018.01.18 22:34:45 4: TSCUL_XmitDlyHM:  CUL_01  id:605665 rtoms:2328
2018.01.18 22:34:47 4: TSCUL_XmitAwaitHMTo CUL_01: timeout - 605665
2018.01.18 22:34:47 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.18 22:34:47 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.019
2018.01.18 22:34:47 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.18 22:34:47 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.18 22:34:47 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.18 22:34:47 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.18 22:34:54 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.18 22:34:54 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:34:54 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:34:54 5: TSCUL/RAW CUL_01 ReadAnswer: /VTS 0.21 CUL868

2018.01.18 22:34:54 5: dummy V CUL_01 VTS 0.21 CUL868
2018.01.18 22:34:55 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:34:55 5: TSCUL/RAW CUL_01 ReadAnswer: /? (? is unknown) Use one of A B C F G J K R U V W X Y e i l m t x

2018.01.18 22:34:55 5: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.18 22:34:55 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:34:55 5: TSCUL/RAW CUL_01 ReadAnswer: /VTS 0.21 CUL868

2018.01.18 22:34:55 5: V CUL_01 VTS 0.21 CUL868
2018.01.18 22:34:55 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:34:55 5: TSCUL/RAW CUL_01 ReadAnswer: /CUL_V3.4

2018.01.18 22:34:55 5: TSCUL/RAW CUL_01 ReadAnswer: /? (? is unknown) Use one of A B C F G J K R U V W X Y e i l m t x

2018.01.18 22:34:55 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.18 22:34:55 5: TSCUL/RAW CUL_01 ReadAnswer: /A?At1

2018.01.18 22:34:55 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:34:55 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:34:55 5: TSCUL/RAW CUL_01 ReadAnswer: /AF702000003210004TiMeStAmP80

2018.01.18 22:34:56 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:34:56 5: TSCUL/RAW CUL_01 ReadAnswer: /AL 6056653F:00 C587193F:00

2018.01.18 22:34:56 5: TSCUL_DoInit CUL_01 605665 created in ids
2018.01.18 22:34:56 5: TSCUL_DoInit CUL_01 C58719 created in ids
2018.01.18 22:34:56 5: TSCUL_DoInit CUL_01 {ids} built
2018.01.18 22:34:56 5: TSCUL/RAW CUL_01 ReadAnswer: /AS02/DC

2018.01.18 22:34:56 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.18 22:34:56 5: TSCUL/RAW CUL_01 ReadAnswer: /A?At0

2018.01.18 22:34:56 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:34:56 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:34:56 5: TSCUL/RAW CUL_01 ReadAnswer: /AF702000003B80004TiMeStAmP80

2018.01.18 22:34:56 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.18 22:34:56 5: TSCUL/RAW CUL_01 ReadAnswer: /AHC58719

2018.01.18 22:34:56 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:34:56 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:34:56 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.18 22:34:59 5: TSCUL_Read CUL_01: /AF7020000067B0001C380

2018.01.18 22:34:59 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.18 22:34:59 4: TSCUL_Parse: CUL_01  148793 A F702 00006636 00 01 C3 _ping
2018.01.18 22:35:03 3: SONOS1: Event: Received Alarm-Event for Zone "Sonos_Badezimmer".
2018.01.18 22:35:04 1: TSCUL_RecoverHMQlen: CUL_01 recovered from Qlen lock
2018.01.18 22:35:09 3: SONOS1: Event: Received Alarm-Event for Zone "Sonos_Wohnzimmer".
2018.01.18 22:35:35 1: TSCUL_SendPingHM CUL_01 fatal: ApC0 timed out! Failsafe release send.
2018.01.18 22:35:35 5: TSCUL_Write: CUL_01 sending As0C63A011C58719605665020164
2018.01.18 22:35:35 4: TSCUL_send:  CUL_01  184665                 As 0C 63 A011 C58719 605665 020164
2018.01.18 22:35:35 4: TSCUL_XmitDlyHM:  CUL_01  id:605665 rtoms:2328
2018.01.18 22:35:35 4: TSCUL_SendPingHM CUL_01 ApC0 send. Throttle start
2018.01.18 22:35:37 4: TSCUL_XmitAwaitHMTo CUL_01: timeout - 605665
2018.01.18 22:35:38 5: TSCUL_Write: CUL_01 sending As0C63A011C58719605665020164
2018.01.18 22:35:38 4: TSCUL_send:  CUL_01  187553                 As 0C 63 A011 C58719 605665 020164
2018.01.18 22:35:38 4: TSCUL_XmitDlyHM:  CUL_01  id:605665 rtoms:2328
2018.01.18 22:35:40 4: TSCUL_XmitAwaitHMTo CUL_01: timeout - 605665
2018.01.18 22:35:43 5: TSCUL_Write: CUL_01 sending As0C63A011C58719605665020164
2018.01.18 22:35:43 4: TSCUL_send:  CUL_01  192853                 As 0C 63 A011 C58719 605665 020164
2018.01.18 22:35:43 4: TSCUL_XmitDlyHM:  CUL_01  id:605665 rtoms:2328
2018.01.18 22:35:45 4: TSCUL_XmitAwaitHMTo CUL_01: timeout - 605665
2018.01.18 22:35:46 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.18 22:35:46 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.02
2018.01.18 22:35:46 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.18 22:35:46 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.18 22:35:46 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.18 22:35:46 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.18 22:35:53 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.18 22:35:53 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:35:53 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:35:53 5: TSCUL/RAW CUL_01 ReadAnswer: /VTS 0.21 CUL868

2018.01.18 22:35:53 5: dummy V CUL_01 VTS 0.21 CUL868
2018.01.18 22:35:54 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:35:54 5: TSCUL/RAW CUL_01 ReadAnswer: /? (? is unknown) Use one of A B C F G J K R U V W X Y e i l m t x

2018.01.18 22:35:54 5: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.18 22:35:54 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:35:54 5: TSCUL/RAW CUL_01 ReadAnswer: /VTS 0.21 CUL868

2018.01.18 22:35:54 5: V CUL_01 VTS 0.21 CUL868
2018.01.18 22:35:54 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:35:54 5: TSCUL/RAW CUL_01 ReadAnswer: /CUL_V3.4

2018.01.18 22:35:54 5: TSCUL/RAW CUL_01 ReadAnswer: /? (? is unknown) Use one of A B C F G J K R U V W X Y e i l m t x

2018.01.18 22:35:54 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.18 22:35:54 5: TSCUL/RAW CUL_01 ReadAnswer: /A?At1

2018.01.18 22:35:54 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:35:54 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:35:54 5: TSCUL/RAW CUL_01 ReadAnswer: /AF702000003210004TiMeStAmP80

2018.01.18 22:35:55 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:35:55 5: TSCUL/RAW CUL_01 ReadAnswer: /AL 6056653F:00 C587193F:00

2018.01.18 22:35:55 5: TSCUL_DoInit CUL_01 605665 created in ids
2018.01.18 22:35:55 5: TSCUL_DoInit CUL_01 C58719 created in ids
2018.01.18 22:35:55 5: TSCUL_DoInit CUL_01 {ids} built
2018.01.18 22:35:55 5: TSCUL/RAW CUL_01 ReadAnswer: /AS02/DC

2018.01.18 22:35:55 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.18 22:35:55 5: TSCUL/RAW CUL_01 ReadAnswer: /A?At0

2018.01.18 22:35:55 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:35:55 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:35:55 5: TSCUL/RAW CUL_01 ReadAnswer: /AF702000003B80004TiMeStAmP80

2018.01.18 22:35:55 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.18 22:35:55 5: TSCUL/RAW CUL_01 ReadAnswer: /AHC58719

2018.01.18 22:35:55 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:35:55 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:35:55 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.18 22:35:57 5: TSCUL_Read CUL_01: /AF702000005D90001C380

2018.01.18 22:35:57 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.18 22:35:57 4: TSCUL_Parse: CUL_01  207157 A F702 00005988 00 01 C3 _ping
2018.01.18 22:36:00 5: TSCUL_Read CUL_01: /AF7020000083B0001CC80

2018.01.18 22:36:00 4: TSCUL_Parse: CUL_01  209597 A F702 00008428 00 01 CC _ping
2018.01.18 22:36:05 1: TSCUL_RecoverHMQlen: CUL_01 recovered from Qlen lock
2018.01.18 22:36:35 1: TSCUL_SendPingHM CUL_01 fatal: ApC0 timed out! Failsafe release send.
2018.01.18 22:36:35 5: TSCUL_Write: CUL_01 sending As0C64A011C58719605665020164
2018.01.18 22:36:35 4: TSCUL_send:  CUL_01  245275                 As 0C 64 A011 C58719 605665 020164
2018.01.18 22:36:35 4: TSCUL_XmitDlyHM:  CUL_01  id:605665 rtoms:2328
2018.01.18 22:36:36 4: TSCUL_SendPingHM CUL_01 ApC0 send. Throttle start
2018.01.18 22:36:38 4: TSCUL_XmitAwaitHMTo CUL_01: timeout - 605665
2018.01.18 22:36:39 5: TSCUL_Write: CUL_01 sending As0C64A011C58719605665020164
2018.01.18 22:36:39 4: TSCUL_send:  CUL_01  249101                 As 0C 64 A011 C58719 605665 020164
2018.01.18 22:36:39 4: TSCUL_XmitDlyHM:  CUL_01  id:605665 rtoms:2328
2018.01.18 22:36:42 4: TSCUL_XmitAwaitHMTo CUL_01: timeout - 605665
2018.01.18 22:36:45 5: TSCUL_Write: CUL_01 sending As0C64A011C58719605665020164
2018.01.18 22:36:45 4: TSCUL_send:  CUL_01  254648                 As 0C 64 A011 C58719 605665 020164
2018.01.18 22:36:45 4: TSCUL_XmitDlyHM:  CUL_01  id:605665 rtoms:2328
2018.01.18 22:36:47 4: TSCUL_XmitAwaitHMTo CUL_01: timeout - 605665
2018.01.18 22:36:48 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.18 22:36:48 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.021
2018.01.18 22:36:48 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.18 22:36:48 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.18 22:36:48 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.18 22:36:48 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.18 22:36:55 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.18 22:36:55 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:36:55 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:36:55 5: TSCUL/RAW CUL_01 ReadAnswer: /VTS 0.21 CUL868

2018.01.18 22:36:55 5: dummy V CUL_01 VTS 0.21 CUL868
2018.01.18 22:36:55 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:36:55 5: TSCUL/RAW CUL_01 ReadAnswer: /? (? is unknown) Use one of A B C F G J K R U V W X Y e i l m t x

2018.01.18 22:36:55 5: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.18 22:36:55 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:36:55 5: TSCUL/RAW CUL_01 ReadAnswer: /VTS 0.21 CUL868

2018.01.18 22:36:55 5: V CUL_01 VTS 0.21 CUL868
2018.01.18 22:36:56 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:36:56 5: TSCUL/RAW CUL_01 ReadAnswer: /CUL_V3.4

2018.01.18 22:36:56 5: TSCUL/RAW CUL_01 ReadAnswer: /? (? is unknown) Use one of A B C F G J K R U V W X Y e i l m t x

2018.01.18 22:36:56 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.18 22:36:56 5: TSCUL/RAW CUL_01 ReadAnswer: /A?At1

2018.01.18 22:36:56 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:36:56 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:36:56 5: TSCUL/RAW CUL_01 ReadAnswer: /AF702000003220004TiMeStAmP80

2018.01.18 22:36:56 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:36:56 5: TSCUL/RAW CUL_01 ReadAnswer: /AL 6056653F:00 C587193F:00

2018.01.18 22:36:56 5: TSCUL_DoInit CUL_01 605665 created in ids
2018.01.18 22:36:56 5: TSCUL_DoInit CUL_01 C58719 created in ids
2018.01.18 22:36:56 5: TSCUL_DoInit CUL_01 {ids} built
2018.01.18 22:36:56 5: TSCUL/RAW CUL_01 ReadAnswer: /AS02/DC

2018.01.18 22:36:56 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.18 22:36:56 5: TSCUL/RAW CUL_01 ReadAnswer: /A?At0

2018.01.18 22:36:56 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:36:57 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:36:57 5: TSCUL/RAW CUL_01 ReadAnswer: /AF702000003B90004TiMeStAmP80

2018.01.18 22:36:57 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.18 22:36:57 5: TSCUL/RAW CUL_01 ReadAnswer: /AHC58719

2018.01.18 22:36:57 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:36:57 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:36:57 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.18 22:36:59 5: TSCUL_Read CUL_01: /AF702000005E00001C380

2018.01.18 22:36:59 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.18 22:36:59 4: TSCUL_Parse: CUL_01  268735 A F702 00006016 00 01 C3 _ping
2018.01.18 22:37:05 1: TSCUL_RecoverHMQlen: CUL_01 recovered from Qlen lock
2018.01.18 22:37:36 1: TSCUL_SendPingHM CUL_01 fatal: ApC0 timed out! Failsafe release send.
2018.01.18 22:37:36 5: TSCUL_Write: CUL_01 sending As0C65A011C58719605665020164
2018.01.18 22:37:36 4: TSCUL_send:  CUL_01  305803                 As 0C 65 A011 C58719 605665 020164
2018.01.18 22:37:36 4: TSCUL_XmitDlyHM:  CUL_01  id:605665 rtoms:2328
2018.01.18 22:37:36 4: TSCUL_SendPingHM CUL_01 ApC0 send. Throttle start
2018.01.18 22:37:38 5: TSCUL_Write: CUL_01 sending As0C65A011C58719605665020164
2018.01.18 22:37:38 4: TSCUL_XmitAwaitHMTo CUL_01: timeout - 605665
2018.01.18 22:37:43 5: TSCUL_Write: CUL_01 sending As0C65A011C58719605665020164
2018.01.18 22:37:43 4: TSCUL_send:  CUL_01  312593                 As 0C 65 A011 C58719 605665 020164
2018.01.18 22:37:43 4: TSCUL_XmitDlyHM:  CUL_01  id:605665 rtoms:2328
2018.01.18 22:37:45 4: TSCUL_XmitAwaitHMTo CUL_01: timeout - 605665
2018.01.18 22:37:48 5: TSCUL_Write: CUL_01 sending As0C65A011C58719605665020164
2018.01.18 22:37:48 4: TSCUL_send:  CUL_01  318032                 As 0C 65 A011 C58719 605665 020164
2018.01.18 22:37:48 4: TSCUL_XmitDlyHM:  CUL_01  id:605665 rtoms:2328
2018.01.18 22:37:50 4: TSCUL_XmitAwaitHMTo CUL_01: timeout - 605665
2018.01.18 22:37:51 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.18 22:37:51 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.022
2018.01.18 22:37:51 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.18 22:37:51 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.18 22:37:51 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.18 22:37:51 1: TSCUL_Read CUL_01: no data read or disconnected
2018.01.18 22:37:58 3: Setting CUL_01 serial parameters to 12000000,8,N,1
2018.01.18 22:37:58 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:37:59 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:37:59 5: TSCUL/RAW CUL_01 ReadAnswer: /VTS 0.21 CUL868

2018.01.18 22:37:59 5: dummy V CUL_01 VTS 0.21 CUL868
2018.01.18 22:37:59 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:37:59 5: TSCUL/RAW CUL_01 ReadAnswer: /? (? is unknown) Use one of A B C F G J K R U V W X Y e i l m t x

2018.01.18 22:37:59 5: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.18 22:37:59 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:37:59 5: TSCUL/RAW CUL_01 ReadAnswer: /VTS 0.21 CUL868

2018.01.18 22:37:59 5: V CUL_01 VTS 0.21 CUL868
2018.01.18 22:37:59 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:37:59 5: TSCUL/RAW CUL_01 ReadAnswer: /CUL_V3.4

2018.01.18 22:37:59 5: TSCUL/RAW CUL_01 ReadAnswer: /? (? is unknown) Use one of A B C F G J K R U V W X Y e i l m t x

2018.01.18 22:37:59 3: CUL_01: Possible commands: ABCFGJKRUVWXYeilmtx
2018.01.18 22:37:59 5: TSCUL/RAW CUL_01 ReadAnswer: /A?At1

2018.01.18 22:37:59 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:38:00 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:38:00 5: TSCUL/RAW CUL_01 ReadAnswer: /AF702000003220004TiMeStAmP80

2018.01.18 22:38:00 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:38:00 5: TSCUL/RAW CUL_01 ReadAnswer: /AL 6056653F:00 C587193F:00

2018.01.18 22:38:00 5: TSCUL_DoInit CUL_01 605665 created in ids
2018.01.18 22:38:00 5: TSCUL_DoInit CUL_01 C58719 created in ids
2018.01.18 22:38:00 5: TSCUL_DoInit CUL_01 {ids} built
2018.01.18 22:38:00 5: TSCUL/RAW CUL_01 ReadAnswer: /AS02/DC

2018.01.18 22:38:00 1: CUL_01 is VERSION_TS, VTS 0.21 CUL868, CUL_V3.4
2018.01.18 22:38:00 5: TSCUL/RAW CUL_01 ReadAnswer: /A?At0

2018.01.18 22:38:00 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:38:00 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:38:00 5: TSCUL/RAW CUL_01 ReadAnswer: /AF702000003B90004TiMeStAmP80

2018.01.18 22:38:00 2: TSCUL_condUpdateHM: CUL_01 new condition init
2018.01.18 22:38:00 5: TSCUL/RAW CUL_01 ReadAnswer: /AHC58719

2018.01.18 22:38:00 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:38:01 5: TSCUL/RAW CUL_01 select timeout ReadAnswer: Clear
2018.01.18 22:38:01 1: /dev/ttyACM0 reappeared (CUL_01)
2018.01.18 22:38:02 5: TSCUL_Read CUL_01: /AF702000005810001C380

2018.01.18 22:38:02 2: TSCUL_condUpdateHM: CUL_01 new condition ok
2018.01.18 22:38:02 4: TSCUL_Parse: CUL_01  331846 A F702 00005636 00 01 C3 _ping
2018.01.18 22:38:06 1: TSCUL_RecoverHMQlen: CUL_01 recovered from Qlen lock
2018.01.18 22:38:36 1: TSCUL_SendPingHM CUL_01 fatal: ApC0 timed out! Failsafe release send.
2018.01.18 22:38:37 5: TSCUL_Write: CUL_01 sending As0C66A011C58719605665020164
2018.01.18 22:38:37 4: TSCUL_send:  CUL_01  366485                 As 0C 66 A011 C58719 605665 020164
2018.01.18 22:38:37 4: TSCUL_XmitDlyHM:  CUL_01  id:605665 rtoms:2328
2018.01.18 22:38:37 4: TSCUL_SendPingHM CUL_01 ApC0 send. Throttle start
2018.01.18 22:38:39 4: TSCUL_XmitAwaitHMTo CUL_01: timeout - 605665
2018.01.18 22:38:42 5: TSCUL_Write: CUL_01 sending As0C66A011C58719605665020164
2018.01.18 22:38:42 4: TSCUL_send:  CUL_01  372293                 As 0C 66 A011 C58719 605665 020164
2018.01.18 22:38:42 4: TSCUL_XmitDlyHM:  CUL_01  id:605665 rtoms:2328
2018.01.18 22:38:45 4: TSCUL_XmitAwaitHMTo CUL_01: timeout - 605665
2018.01.18 22:38:47 5: TSCUL_Write: CUL_01 sending As0C66A011C58719605665020164
2018.01.18 22:38:47 4: TSCUL_send:  CUL_01  377239                 As 0C 66 A011 C58719 605665 020164
2018.01.18 22:38:47 4: TSCUL_XmitDlyHM:  CUL_01  id:605665 rtoms:2328
2018.01.18 22:38:50 4: TSCUL_XmitAwaitHMTo CUL_01: timeout - 605665
2018.01.18 22:38:51 1:  DevIoTS_SimpleReadWithTimeout CUL_01
2018.01.18 22:38:51 1: DevIoTS_SimpleRead CUL_01: USB/DIO Device second read, ReReadTO:0.023
2018.01.18 22:38:51 1: /dev/ttyACM0 disconnected, waiting to reappear CUL_01
2018.01.18 22:38:51 1: DevIoTS_SimpleRead CUL_01: Device Error encountered, disconnected
2018.01.18 22:38:51 2: TSCUL_condUpdateHM: CUL_01 new condition disconnected
2018.01.18 22:38:51 1: TSCUL_Read CUL_01: no data read or disconnected


Ich werde nun noch mal ein Testsystem aufsetzen und den CUL dort testen und den CUL am Hauptsystem mit einem aktiven USB Hub anschließen.

Gruß,
Heggeg
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: essera am 19 Januar 2018, 16:33:29
Ich arbeite nun schon seit einiger Zeit mit Homematic Komponenten und musste leider feststellen, dass sich einige beim besten willen nicht mit Fhem (USB CUL-Busware mit 1.66) komplett pairen lassen. (z.B. HM-Sen-MDIR-WM55 - Motion Sensor, HM-PB-6-WM55 - 6fach Schalter, HM-Sen-DB-PCB - Klingel Sensor)
es kommen halt die Fehlermeldungen von wegen Request Problemen.

Wäre die alternative Software für den Cul für dieser Fälle genau das Richtige ?

Der Aufwand ist ja nicht so gering, wie ich den Einträgen so entnehmen konnte, und ich möchte schon sicher sein, dass die Firmware für mich passt bzw. die Richtige für mein PRoblem ist.





Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: MadMax-FHEM am 19 Januar 2018, 17:20:23
Kann man nur vermuten, da du ja nicht schreibst welche Probleme (genau)...
...aber z.B. den Klingelsensor kenne ich auch.
War für mich der Grund es mit dieser FW zu versuchen (alles andere hat nicht geklappt) und was soll ich sagen: hat funktioniert!

Und das zu einer Zeit wo es sicher noch "aufwändiger" war... ;)

Und so groß ist der Aufwand ja nicht: https://forum.fhem.de/index.php/topic,82909.msg750829.html#msg750829

Backup vorher nicht vergessen!

@Ansgar: sorry das mit dem Wiki dauert wohl noch etwas... Hab grad wenig Zeit... :-|

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 19 Januar 2018, 21:22:02
Hallo Heggeg,

ZitatHabe nur etliche Zigbee
Und auf welcher Frequenz sendet Deine Zigbee Landschaft?

In Deinem Raw Log sehe ich nur, dass nicht gesendet wird bevor es "knallt", da die Sendequittungen nicht von CUL kommen, die kommen müßten. Empfangen wird dagegen etwas, wie ich schon gesehen habe. Nur ein einziges mal hat CUL nach Log auch ein ACK gesendet.

Merkwürdigerweise kommt aber auch keine CCA Fehlerquittung. (CCA steht für Clear Channel Assessment, sprich Prüfung ob der Kanal frei ist).
Auch auf "ApC0 send. Throttle start" fehlt eine Ping Antwort von CUL. Da schient schon was nicht mehr ok zu sein.

Falls Deine USB Stromversorgung sehr schwach ist, könnte auch das Senden an sich wegen des dann höchsten Stroms zu einem "Absturzt" des CUL führen. Das würde auch die fehlende Ping Antwort erklären.
Dagegen würden ein extra stromversorgter USB Hub helfen können.

Falls doch CCA das Problem darstellt, würde es eventuell helfen den CUL nicht direkt an Deinen Rechner anzuschließen, sondern mit einem USB Verlängerungskabel entfernt von Störquellen, insbesondere Deinem Rechner, Monitor, sonstiger Sender etc., zu positionieren.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: Heggeg am 20 Januar 2018, 21:44:33
Und auf welcher Frequenz sendet Deine Zigbee Landschaft?

Ich glaube 2400 bis 2483,5 MHz, sind Hue Leuchten und Strips.

Ich habe nun den CUL an meinen ESXi mit einem aktiven HUB angeschlossen und der CUL reconnected immer noch wie verrückt. Du hattest mir ja gesagt ich solle das ganze auf einem anderen System testen, ich habe mir zum Test eben FHEM auf einem PI installiert und dort den CUL eingerichtet. Siehe da, es funkt alles so wie es soll. Danach habe ich noch mal eine neue Ubuntu VM erstellt und FHEM installiert und den CUL eingerichtet. Dort habe ich dann leider wieder den Fehler das der CUL die ganze Zeit reconnected. Nun würde ich das ganze trotzdem an meinem Hauptsystem zum laufen bekommen.

dmesg gibt immer folgende Fehler aus:

cdc_acm 1-2.1:1.0: failed to set dtr/rts

Hast du noch eine Idee?

Gruß,
Heggeg
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 21 Januar 2018, 00:14:45
Hallo Heggeg,

Zitatich habe mir zum Test eben FHEM auf einem PI installiert und dort den CUL eingerichtet. Siehe da, es funkt alles so wie es soll.
Ok, dann hat der CUL keine Macke und die Firmware arbeitet, wie erwartet.

ZitatNun würde ich das ganze trotzdem an meinem Hauptsystem zum laufen bekommen.
Den Wunsch kann ich verstehen, nur fehlt mir jegliche Info, woran es krankt.

Zitatdmesg gibt immer folgende Fehler aus:
cdc_acm 1-2.1:1.0: failed to set dtr/rts
Das ist normal und habe ich auch, wenn ich CUL einen Soft Reboot sende.

Da der CUL jedesmal seine timestamp zurück setzt, wird er neu gestartet. Das kann durch einen Watchdog Reset passieren, aber auch dadurch, dass das System den Strom vom Port weg nimmt.
Ich denke, das irgendwas auf USB Ebene schief läuft.

Du musst mehr log Ausgabe zu USB aus Deinem ESXi raus holen. So kommen wir nicht weiter.
Hat Dein ESXi noch ein Log, was irgendwas zu USB sagt.
Es sollte noch möglich sein, die USB Debug Ausgaben im Linux Kernel Deiner VM zu aktivieren.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: HeGa59 am 22 Januar 2018, 12:48:13
Hallo liebe Experten,
besteht die Möglichkeit auch den CUBE mit TSCUL zu flashen analog zu aCULFW?
Herzliche Grüße!
Heinz
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: Heggeg am 22 Januar 2018, 13:23:10
Zitat von: noansi am 21 Januar 2018, 00:14:45
Hallo Heggeg,
Ok, dann hat der CUL keine Macke und die Firmware arbeitet, wie erwartet.
Den Wunsch kann ich verstehen, nur fehlt mir jegliche Info, woran es krankt.
cdc_acm 1-2.1:1.0: failed to set dtr/rts
Das ist normal und habe ich auch, wenn ich CUL einen Soft Reboot sende.

Da der CUL jedesmal seine timestamp zurück setzt, wird er neu gestartet. Das kann durch einen Watchdog Reset passieren, aber auch dadurch, dass das System den Strom vom Port weg nimmt.
Ich denke, das irgendwas auf USB Ebene schief läuft.

Du musst mehr log Ausgabe zu USB aus Deinem ESXi raus holen. So kommen wir nicht weiter.
Hat Dein ESXi noch ein Log, was irgendwas zu USB sagt.
Es sollte noch möglich sein, die USB Debug Ausgaben im Linux Kernel Deiner VM zu aktivieren.

Gruß, Ansgar.

Ich schau mal ob ich bzgl USB etwas finde. Ich habe nun paralel eine PCIe USB Karte bestellt und werde die mittels PCIe Passthrough direkt an meine VM weiterreichen. Ich denke damit werde ich allen Problemen aus dem Weg gehen. Ich vermute das es an dem durchreichen von USB an die VM Probleme gibt. Mein ESX läuft zudem auch auf nicht von VMware supportetem Blech, somit kan nich auch nicht den VMware Support um Rat fragen.

Ich melde mich falls ich was finde. Ist ja vielleicht auch für den ein oder anderen intressant der alles virtualisiert laufen lässt.

Gruß,
Heggeg
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: presskopf am 22 Januar 2018, 19:36:01
Da ich diese Woche nicht auf Dienstreise sein werde (nur ein Tagestrip), bin ich mal volles Risiko gegangen und habe auf TSCUL umgestellt, gemäß:
https://forum.fhem.de/index.php?action=post;quote=732585;topic=24436.600;last_msg=753715

Also:
- 2 x Backup gemacht  8)
- fhem abgeschaltet
- alle relevanten Dateien in /FHEM und /FHEM/Firmware reinkopiert
- in der fhem.cfg die CULs durch TSCUL ersetzt; mehr war da nicht zu tun
- Der lokale CUL1 wurde dann mit "falscher Firmware" gefunden. Das Flashen mittels TSCULflash ging problemlos.
- Anschließend noch ein attr CUL1 rfmode Homematic und die Rolladen ließen sich steuern, die Thermostate einstellen.

Meine beiden entfernten CULlies ließen sich natürlich nicht über ser2net flashen.
Das habe ich dann lokal mittels
avrdude -c arduino -b 57600 -P /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A104RK6C-if00-port0  -p atmega328p -vv -U flash:w:TSnanoCUL.hex
erledigen.
Die Verbindung baute sich dann ruckzuck auf. rfmode einstellen und einsatzbereit. Toll!

Ich bin gespannt.
Zunächst ist mir aufgefallen, dass einige Missing Register bei den Wandthermostaten auf einmal da waren! :)
Bei den Bewegungsmeldern fehlen noch welche (RegL_00.,RegL_01.). Mit der alten aculfw habe ich mich doof-ge-getConfig-t - ohne Erfolg. Insbesondere die Wandthermostate_Climate waren hartnäckig.

Im log sind ein paar neue Meldungen bzgl. TSCUL, die ich erst mal zuordnen muss. Schauen aber nicht schlimm aus.

Ich werde vom Produktiv-Betrieb berichten, wenn es etwas zu berichten gibt. Einfrieren kann man aktuell ja kaum und mein Weibchen ist geimpft.
(HM-Geräte, die ich verwende: Wandthermostat, Heizkörperthermostat, 4-Fach-Relais, Tür-/Fensterkontakt-Schalter (opt/reed), Bewegungsmelder, Rauchmelder) 4-Knöppchen-Fernbedienung).

Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 22 Januar 2018, 22:10:19
Hallo Heggeg,

vielleicht noch eine Idee, kannst Du in Deinem virtuellen Ubuntu USB2.0 Unterstützung abschalten?
Möglicherweise hilft das?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 22 Januar 2018, 22:13:14
Hallo presskopf,

ZitatBei den Bewegungsmeldern fehlen noch welche (RegL_00.,RegL_01.).
Vermutlich wirst Du, je nach Typ, um getConfig mit Knöpfchen drücken nicht herum kommen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 22 Januar 2018, 23:06:09
Hallo Heinz,

Zitatbesteht die Möglichkeit auch den CUBE mit TSCUL zu flashen analog zu aCULFW?

Die Möglichkeit würde eine intensive Anpassung des Codes an die Hardware erfordern. Derzeit daher nicht.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: presskopf am 23 Januar 2018, 10:58:34
Zitat von: noansi am 22 Januar 2018, 22:13:14
Hallo presskopf,
Vermutlich wirst Du, je nach Typ, um getConfig mit Knöpfchen drücken nicht herum kommen.

Gruß, Ansgar.

Top, ging hier auch wie Schmitz Katze!


Nachtrag: Auch die Templisten flutschen jetzt ohne Murren rüber!
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: Heggeg am 24 Januar 2018, 19:18:21
Zitat von: noansi am 22 Januar 2018, 22:10:19
Hallo Heggeg,

vielleicht noch eine Idee, kannst Du in Deinem virtuellen Ubuntu USB2.0 Unterstützung abschalten?
Möglicherweise hilft das?

Gruß, Ansgar.

Wen ich das abschalte funktioniert das USB Passthrough des CULs nicht mehr.
Nun habe ich in meinen ESX folgende PCI-E USB Karte eingebaut und meiner VM via PCI-Passthrough präsentiert und siehe da - CUL in einen der Ports von der Karte gesteckt und es gibt keine Fehlermeldungen mehr im dmesg Log. Ich bedanke mich für deine tolle Firmware und die Unterstützung. Endlich kann ich anfangen meine Homematic Landschaft aufzubauen.

Gruß,
Heggeg
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 24 Januar 2018, 22:13:10
Hallo Heggeg,

ZitatNun habe ich in meinen ESX folgende PCI-E USB Karte eingebaut und meiner VM via PCI-Passthrough präsentiert und siehe da - CUL in einen der Ports von der Karte gesteckt und es gibt keine Fehlermeldungen mehr im dmesg Log.
Danke für das Feedback und schön, dass es so funktioniert. Demnach müßte es wohl ein USB-Virtualisierungs- oder Treiberproblem auf Deiner Plattform gewesen sein.

Hätte mich schon interessiert was da wie schief läuft. Sähe aber andererseits gefühlt dann nach Würgarrounds inklusive Übertragungsdelays aus, die dann zu weiteren unerwünschten Nebenwirkungen geführt hätten.

@Joachim: Der Hinweis mit der USB Karte und PCI-Passthrough bei FHEM in VM wäre wohl auch was für den Wiki Artikel.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: davedeluxe am 25 Januar 2018, 09:25:25
Hi,

ich nutze seit einiger Zeit diese Firmware da ich mit der "Standardfirmware" immer Probleme mit meinen HM-Rolladenaktoren hatte.
Ich nutze/nutzte zusätzlich noch einen weiteren nanoCUL im SlowRF Mode für meine ESA 2000 Energiemessung.

Beide CULs basieren auf Arduino Nano V3 FTDI´s.

Leider bekomme ich immer wieder Probleme wenn ich beide CUL´s angeschlossen habe. Meistens tritt der Fehler auf das keine Daten mehr von den Homematic-Senoren/Aktoren ankommen bzw. gesendet werden. In der Log finde ich keine Einträge.

Gibt es irgendwas zu beachten wenn ich zwei CUL´s nutze? Kann/muss der CUL für SlowRF auch diese ASKSIN Firmware nutzen oder kann er auch mit der "Standard-Firmware" laufen?

Grüße Dave
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: Omega-5 am 25 Januar 2018, 09:46:22
Zitat von: davedeluxe am 25 Januar 2018, 09:25:25
Beide CULs basieren auf Arduino Nano V3 FTDI´s.

Du kennst das Problem mit den FAKE-FTDI? Gleiche Seriennummer -> nur einer wird erkannt. Vieleicht hast du ja Nanos aus diesen Produktionen.
Mache mal ein

ls -l /dev/serial/by-id
oder
ls -l /dev/serial/by-path

Gruß Friedrich
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: MadMax-FHEM am 25 Januar 2018, 09:47:19
Hi Dave,

ich hatte damals ebenfalls 2 nano-CULs laufen.

Gut nicht wirklich 2 CULs einer war ein mySensorsGateway...

Wie hast du die eingebunden?

/dev/serial/by-id?
/dev/serial/by-path?
/dev/ttyUSB?

Kommen "einfach so" im Betrieb keine Daten mehr oder z.B. nach einem Neustart etc.?

Das wären mal die einfachsten Dinge die zu prüfen sind...

Wenn da alles passt und eigentlich nichts "durcheinander" kommen kann, muss man weiter analysieren (wenn der Fall wieder auftritt)...

Leider habe ich inzwischen mein Testsystem mit CULs "abgebaut"...

EDIT: und wieder zu langsam ;)

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: MadMax-FHEM am 25 Januar 2018, 09:50:36
Zitat von: noansi am 24 Januar 2018, 22:13:10
@Joachim: Der Hinweis mit der USB Karte und PCI-Passthrough bei FHEM in VM wäre wohl auch was für den Wiki Artikel.

Gruß, Ansgar.

Hallo Ansgar,

ich muss mich entschuldigen.

Die Idee mit dem Wiki hatte ich in der "Weihnachts-Frei-Euphorie" ;)

Leider bin ich aktuell etwas eingebunden aber ich hab's nicht vergessen und noch vor...

Ich sammle schon fleißig, muss nur noch Zeit finden das dann zu sortieren und mal zusammenzuschreiben.
Nehme ich mit auf (falls ich's vergessen sollte: einfach erinnern ;)  ).

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: davedeluxe am 25 Januar 2018, 09:51:40
nein das passt alles, sind 2 unterschiedliche Seriennummern.
ich habe auch schon mehrere Arduinos durchprobiert, kein Unterschied.

Eingebunden habe ich sie per ID, getestet habe ich per path und per  tty - alles ohne Erfolg.
Wobei das Fehlerbild das du da beschreibst auf meine Probleme zutrifft.
Ich habe noch nen SuperJee laufen, der macht keine Probleme.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 25 Januar 2018, 21:40:16
Hallo Dave,

ZitatGibt es irgendwas zu beachten wenn ich zwei CUL´s nutze? Kann/muss der CUL für SlowRF auch diese ASKSIN Firmware nutzen oder kann er auch mit der "Standard-Firmware" laufen?
theoretisch bietet auch die tsculfw ESA Empfang. Allerdings mangels Hardware ungetestet und daher in TS_CUL.pm bisher auch auskommentiert.

CUL und TS_CUL sollten sich eigentlich nicht ins Gehege kommen. D.h. den nano mit tsculfw definierst Du mit TS_CUL und den nano mit Standardfirmware oder a-culfw mit CUL.

Wenn Du das so gemacht hast denke ich auch eher, dass Du schon mal USB Verbindungsverlust hast oder eher das USB Vertauschungsproblem je nach Systemneustartart, wenn Du nicht eindeutig die USB-Seriennummern den seriellen devices in der 99-usb-serial.rules zugeordnet hast oder mit /dev/serial/by-id arbeitest. Die Schnittstellenzuordnung muss eindeutig passen. Nur weil die nanos eindeutige Seriennummern haben bedeutet es nicht, dass sie auch immer den gleichen Schnittstellen zugeordnet werden.

Schau Dir ggf. mit dmesg an, welcher Schnittstelle der jeweilige nano zugeordnet wird. Bei mir war es so, dass beim RasPi Warmstart mit "sudo shutdown -r now" eine andere Zuordnung meiner USB CULs stattgefunden hat, als beim Hochfahren nach stromlos machen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: en-trust am 01 Februar 2018, 17:01:36
Ich wollte nun den CUL neu definieren...

define myCUL_868 TSCUL /dev/serial/by-path/platform-3f980000.usb-usb-0:1.5.4:1.0@38400 F088

erhalte aber...

FHTID must be H1H2, with H1 and H2 hex and both smaller than 64

Ich habe aber gar kein FHT.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 02 Februar 2018, 20:17:48
Hallo Sven,

ZitatIch habe aber gar kein FHT.

Aber mit F088 eine FHT Id einstellen wollen, die den korrekten Kriterien nicht entsprechen.
Da Du kein FHT hast, ist 0000 statt dessen richtig.

Die übrigen Fragen hast Du Dir wohl inzwischen durch Lesen und Probieren selber beantworten können.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: en-trust am 02 Februar 2018, 20:33:57
Aber ich brauche doch eine hmId analog zur vccu für die Homematic's und da wurde hier immer gesagt nimm einen hexacode. Jetzt heißt es nimm 0000.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 02 Februar 2018, 20:53:46
Hallo Sven,

ZitatAber ich brauche doch eine hmId analog zur vccu für die Homematic's und da wurde hier immer gesagt nimm einen hexacode. Jetzt heißt es nimm 0000.
z.B.:
attr myCUL_868 hmId F1F088

Wenn Du das Attribut nicht setzt, aber eine FHTID (die nicht 0000 ist), dann wird die mit vorangestelltem "F1" als hmID per default benutzt. Aber die FHTID muss immer noch im gültigen Bereich liegen. Dieses (wenig übersichtliche) Verhalten habe ich nur so vom CUL Modul übernommen.


Oder gehes direkt mit einer VCCU an (der Du auch eine hmId zuweisen musst) und weise der Deinen CUL als IO zu.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: stanford am 04 Februar 2018, 01:56:58
Hey,

ich hab heute Deine TSCUL FW auf meinem 868 CUL installiert, damit funktionieren endlich einige HM Sachen bei mir, wie sie sollen. Danke!

Jetzt habe ich auch meine 433 CUL auf die TSCUL v0.21 geflashed, damit lassen sich allerdings meine IT V1 Dosen nicht mehr schalten. Mit der aktuellen a-culfw ging es einwandfrei.

define CUL_1 TSCUL /dev/serial/by-id/usb-busware.de_CUL433_433000-if00@12000000 0135
attr CUL_1 hmId AFAF01
attr CUL_1 hmLanQlen 1_min
attr CUL_1 rfmode SlowRF


define Draussen.Steckdose IT FF00F0FFFF FF F0
attr Draussen.Steckdose IODev CUL_1
attr Draussen.Steckdose icon garden_socket
attr Draussen.Steckdose model itswitch
attr Draussen.Steckdose protocol V1


Das Ergebnis:

2018.02.04 01:24:05 1: TSCUL_Parse: CUL_1 channel busy detected: NOCCA

... und kein Licht ;)

Ich hab in diesem Thread jetzt auf Anhieb nichts gefunden, was mich wirklich weiter bringt. Hat jemand eine Idee?

Vielen Dank!
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 04 Februar 2018, 08:00:46
Hallo Stanford,

ZitatTSCUL_Parse: CUL_1 channel busy detected: NOCCA

Dein CUL sendet in diesem Fall nicht, weil er etwas Sendendes auf dem Kanal gesehen hat.
Wenn Das immer bei jedem Schaltvorgang kommt, empfängt der CUL entweder einen Dauerstörsender auf der Frequenz oder empfängt Störungen von Deinem Host Rechner.

Im letzteren Fall sollte Absetzen mit einem USB Verlängerungskabel helfen.

Dauerstörsender könnte z.B. Funkkopfhörer sein. Ich hatte auch schon mal den Fall eines Temperatursensors, bei dem die Batterien leer wurden und er dabei meinte auf Dauersenden gehen zu müssen, bis die Batterie ganz leer war.

Du kannst auch noch mit csRelThr (6,10,14dB) und csAbsThr (-7 bis 7dB) versuchen die CCA Empfindlichkeit herab zu setzen (größere Werte) oder CCAmode von 1 auf 0 setzen, um die CCA Erkennung ganz abzuschalten.
Anpassung geht nicht, da feste Konfiguration genutzt wird.

a-culfw und Standard Firmware verwenden CCA nicht für IT.
Es macht aber Sinn es zu verwenden, da es nicht erfolgversprechend ist, zu senden, wenn bereits gesendet wird.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 04 Februar 2018, 11:26:16
Hallo Testwillige,

ich habe hier https://forum.fhem.de/index.php/topic,24436.msg732585.html#msg732585 (https://forum.fhem.de/index.php/topic,24436.msg732585.html#msg732585) nochmal die Module aktualisiert.
Ich habe Martins letzte Änderungen nach gezogen.

Außerdem mit 97_timerTS.pm die Timerroutinen von fhme.pl ersetzt (ergibt 3 Warnungen beim FHEM Start wegen des Austauschs der Timerroutinen), siehe auch https://forum.fhem.de/index.php/topic,81365.msg734513.html#msg734513 (https://forum.fhem.de/index.php/topic,81365.msg734513.html#msg734513). Das wird nur nicht mit 30_MilightBridge.pm funktionieren, wenn Matthew es nicht auch auf RemoveInternalTimer anpasst. Möchte man es nicht nutzen kann man 97_timerTS.pm auch einfach umbenennen oder löschen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: stanford am 04 Februar 2018, 13:43:16
Hallo noansi,

(vorab: habe die Module bereits geupdated auf v33.)

Habe jetzt mal testweise CCAmode auf 0 gesetzt:

CUL_1 ccconf => freq:433.920MHz freqOffs:0.000kHz bWidth:325kHz freqIF:177.73kHz rAmpl:42dB sens:12dB dRate:2.461kBit/s
agcPrio:1 agcWait:32 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:0 AGC_FREEZE:0
CCAmode:0 csRelThr:10dB csAbsThr:4dB


Leider kann ich meine IT V1 Steckdosen weiterhin nicht schalten, es bleibt bei:

2018.02.04 13:38:45 1: TSCUL_Parse: CUL_1 channel busy detected: NOCCA

USB Verlängerung ist zwischen CUL und RasPi eh dran, hab die auch noch mal getauscht und den anderen CUL weiter weggehangen mit einer Verlängerungen. Einen JeeLink hab ich auch noch dran.
Wie könnten ich denn anderen Störsendern auf die Schliche gekommen? a-culfw hat extrem zuverlässig geschaltet.

LG
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 04 Februar 2018, 15:11:17
Hallo stanford,

dann setze CCAmode auf 0 und sende anschließend ein raw B00 an den CUL oder ziehe ihn mal kurz ab und stecke ihn wieder auf.

Eigentlich sollte es mit CCAmode 0 schon aus sein, wenn die Doku zum cc1101 nicht unscharf ist, aber zusätzlich kannst Du noch
set CUL_1 csRelThr dis
und
set CUL_1 csAbsThr dis
setzen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: stanford am 04 Februar 2018, 15:48:42
Hey noansi,

keinerlei Änderung leider (den CUL hatte ich natürlich schon ein paar Mal stromlos gemacht ;))

Schade, aber kein Problem. Kommt auf den 868er Deine FW und auf den 433 die a-culfw. Dann funktioniert der "billige" IT V3 PIR 1000 Bewegungsmelder zwar nicht, aber das ist kein Beinbruch. Wenn ich Dich irgendwie beim Debugging unterstützten kann, sag Bescheid!

LG
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 04 Februar 2018, 16:09:30
Hallo stanford,

hast Du das mit csRelThr und csAbsThr auch ausprobiert?

Kam dann immer noch die "TSCUL_Parse: CUL_1 channel busy detected: NOCCA" Meldung im Log?

Wie sieht ccconf aus?
List vom CUL?

Bei mir schalten die IT Dosen einwandfrei mit den Defaults und auch wenn ich die Einstellungen ändere, wie beschrieben.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 05 Februar 2018, 23:03:36
Hallo stanford,

anbei mal eine neue Firmware für CUL V3 zum Testen.

Darin habe ich das CCA Handling etwas geändert, so dass bei CCAmode = 0 vor dem Umschalten auf Senden auf IDLE geschaltet wird, und somit mit CCA nix mehr sein sollte. Teste bitte mal mit Deinen IT Dosen, ob damit die Meldung aus dem Log verschwindet und Du damit schalten kannst.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: stanford am 07 Februar 2018, 20:35:04
Hey Ansgar,

leider immer noch kein Erfolg. Hab die neue Firmware direkt geflashed. Hab folgende Settings getestet: CCAmode = 1, CCAmode = 0, sowie CCAmode 0 mit csRelThr und csAbsThr = dis. Die IT V1 Dosen lassen sich weiterhin nicht schalten.

Das Log zeigt weiterhin:
TSCUL_Parse: CUL_1 channel busy detected: NOCCA

get CUL_1 ccconf:
CUL_1 ccconf => freq:433.920MHz freqOffs:0.000kHz bWidth:325kHz freqIF:177.73kHz rAmpl:42dB sens:12dB dRate:2.461kBit/s
agcPrio:1 agcWait:32 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:0 AGC_FREEZE:0
CCAmode:0 csRelThr:dis csAbsThr:dis


list CUL_1:
Internals:
   CMDS       ABCFGJKRUVWXYeilmtx
   CUL_1_MSGCNT 19
   CUL_1_TIME 2018-02-07 20:29:43
   Clients    STACKABLETS:STACKABLE:TSCUL_WS:IT:CUL_FHTTK:CUL_HOERMANN:TSCUL_TX:CUL_IR:SOMFY:Revolt:ESA2000:TSCUL_EM:BS:USF1000:FS20:FHT.*:TSKS300:HMS:CUL_TCM97001:CUL_REDIRECT
   DEF        /dev/serial/by-id/usb-busware.de_CUL433_433000-if00@12000000 1134
   DeviceName /dev/serial/by-id/usb-busware.de_CUL433_433000-if00@12000000
   FD         11
   FHTID      1134
   NAME       CUL_1
   NR         40
   PARTIAL   
   RAWMSG     A0A898002DE10BE4B309700::-72:CUL_1:
   RSSI       -72
   STATE      Initialized
   SlowRF_BitBufferOvrfl 0
   SlowRF_BucketOvrfl 0
   SlowRF_IntCalcStat Last: 38.6  Min: 14.6  Mean: 38.6  Max: 51.6
   TYPE       TSCUL
   VERSION    VTS 0.22 CUL433
   VERSION_HW CUL_V3.4
   VERSION_TS yes AES ChTblSize:220
   XmitOpen   0
   initString X21
AM5
AHDE11BE
   MatchList:
     1:STACKABLETS ^\*
     2:STACKABLE ^\*
     A:TSCUL_WS ^K.....
     B:IT       ^i.(:.|.....)
     C:CUL_FHTTK ^T[\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F]
     D:CUL_HOERMANN ^R..........
     E:TSCUL_TX ^TXA.........
     F:CUL_IR   ^I............
     G:SOMFY    ^Y[r|t|s]:?[\dA-F]+
     H:Revolt   ^r......................$
     I:ESA2000  ^S................................$
     K:TSCUL_EM ^E0.0[\dA-F]..............
     L:BS       ^81..(04|0c)..0101a001a5cf
     M:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     N:FS20     ^81..(04|0c)..0101a001
     O:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     P:TSKS300  ^810d04..4027a001
     Q:HMS      ^810e04......a001
     R:CUL_TCM97001 ^s[\dA-F]+
     S:CUL_REDIRECT ^o
   READINGS:
     2018-02-04 01:40:29   ITSndFreq       433.920MHz
     2018-02-07 20:30:16   Ints_per_sec    SI: 4.93276  TI: 1.39984  S: 0.53327  L: 0.00000  U: 0.06666  M: 0.00000
     2018-02-04 01:40:32   SlowRFSndFreq   433.920MHz
     2018-02-07 20:30:01   Xmit-Events     init:1 disconnected:1 ok:1 non-HM:6
     2018-02-07 20:32:31   ccconf          freq:433.920MHz freqOffs:0.000kHz bWidth:325kHz freqIF:177.73kHz rAmpl:42dB sens:12dB dRate:2.461kBit/s
agcPrio:1 agcWait:32 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:0 AGC_FREEZE:0
CCAmode:0 csRelThr:dis csAbsThr:dis
     2018-02-07 20:26:21   cmds             A B C F G J K R U V W X Y e i l m t x
     2018-02-07 20:30:01   cond            non-HM
     2018-01-21 18:27:02   credit10ms      563
     2018-01-21 18:27:06   fhtbuf          AE
     2018-02-07 20:26:20   prot_disconnected last
     2018-02-07 20:28:15   prot_init       last
     2018-02-07 20:30:01   prot_non-HM     last
     2018-02-07 20:28:15   prot_ok         last
     2018-02-04 01:37:24   raw             NOCCA
     2018-02-07 20:32:33   scF             0.999980469665484
     2018-02-07 20:26:23   state           Initialized
     2018-02-04 01:00:41   unusedstack     401
     2018-02-04 00:39:55   uptime          0 00:03:38
     2018-02-04 01:40:43   version         VTS 0.21 CUL433
   helper:
     CUrun      1
     ChkPart    0
     RA_Timeout 0
     VTS        1
     VTS_ACK    1
     VTS_AES    1
     hmTSAt1Add
     lastIntC   1537
     lastIntCTime 1518031816.68612
     lastIntTOC 319
     lastSyncC  287
     lastloFltC 0
     lastmtchErrC 0
     lastupFltC 22
     recd       1
     tbuf       
     DEVIO:
       RXfailTO   
     HM:
       ChTblSize  220
       FUP        0
       HMactive   0
       hmCrdts    6
       hmSbusy    0
       ChTbl:
       msgCNT:
         0x01       19
         0x02       17
       unknwn:
         DE10BE:
           lstRecType 02
           nextSend   1518031783.23813
           nxtSndMcnt 89
           tgtDly     88
           lRcTm:
             CUL_1      211932
             tnms       834585838
     cnd:
       0          1
       250        6
       253        1
       255        1
     ids:
     q:
       HMcndN     250
       XRpCnt     0
       XRpTm      1518031695.16934
       answerPend 0
       hmLanQlen  1
       cap:
         sum        13500
     ref:
       Sdly       1
       doNbyterate 41
       ioByteRate 1200000
       ioByteRateMeas 58507.6959303814
       lHMt       370612
       lSys       834744468
       pTTu       512
       pndAs      0
       pndCUAp    0
       pngFrc     1
       pngLm      9
       pngMax     -300000
       pngMaxTot  3
       pngMin     1
       pngRef     2
       pngtm      834756379
       pngtmBRs   1518031976.85725
       scErr      0
       scF        0.999980469665484
       scFN       0
       scHT       126512
       scST       834500374
Attributes:
   hmId       AF91FC
   hmLanQlen  1_min
   icon       cul_cul
   rfmode     SlowRF
   room       System


Lieben Dank für's Kümmern!
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: stanford am 07 Februar 2018, 21:13:43
Gerade poppten noch folgende Nachrichten in meinem Log auf:

2018.02.07 20:56:23 2: TSCUL_ReceiveDelayed: CUL_1  C 00=0D 01=2E 02=2D 03=47 04=D3 05=91 06=3D 07=00 08=32 09=00 0A=00 0B=07 0C=00 0D=10 0E=B0 0F=71 10=56 11=8D 12=30 13=23 14=B9 15=00 16=07 17=00 18=18 19=14 1A=6C 1B=07 1C=48 1D=B2 1E=87 1F=6B 20=F8 21=B6 22=11 23=EF 24=2A 25=14 26=1F 27=41 28=00 29=59 2A=7F 2B=B7 2C=81 2D=35 2E=0B 2F=00 30=00 31=14 32=00 33=80 34=F6 35=0D 36=00 37=00 38=B4 39=FD 3A=00 3B=00 3C=00 3D=00
2018.02.07 21:01:08 1: TSCUL_Parse: CUL_1 SlowRF receive timeout detected: C_TOR00 01 00 00
2018.02.07 21:11:23 2: TSCUL_ReceiveDelayed: CUL_1  C 00=0D 01=2E 02=2D 03=47 04=D3 05=91 06=3D 07=00 08=32 09=00 0A=00 0B=07 0C=00 0D=10 0E=B0 0F=71 10=56 11=8D 12=30 13=23 14=B9 15=00 16=07 17=00 18=18 19=14 1A=6C 1B=07 1C=48 1D=B2 1E=87 1F=6B 20=F8 21=B6 22=11 23=EF 24=2A 25=14 26=1F 27=41 28=00 29=59 2A=7F 2B=BF 2C=81 2D=35 2E=0B 2F=00 30=00 31=14 32=00 33=80 34=F2 35=0D 36=00 37=00 38=B4 39=FD 3A=00 3B=00 3C=00 3D=00
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 07 Februar 2018, 21:14:54
Hallo stanford,

schon seltsam.
Und das
TSCUL_Parse: CUL_1 channel busy detected: NOCCA
kommt wirklich bei jedem IT Schaltversuch neu im Log?

Was hat
hmId       AF91FC
bei dem CUL_1 zu suchen?
Schmeiß das da mal raus (auch wenn es eigentlich nicht stören sollte) und falls Du es als IO bei HM mit angegeben hast, dann auch da.

Außerdem definiere ihn als
define CUL_1 TSCUL /dev/serial/by-id/usb-busware.de_CUL433_433000-if00@12000000 0000
womit Du FHT abschaltest, das Du eh nicht benötigst.

Poste bitte auch mal das Ergebnis eines get raw C99

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: stanford am 07 Februar 2018, 21:33:23
Hallo Ansgar,

das NOCCA kommt bei jedem einzelnen Schaltversuch im Log, jeweils mit einer gefühlten Sekunde Latenz oder teilweise etwas mehr.

hmId rausgeworfen, TSCUL mit 0000 definiert - Macht keinen Unterschied.

get CUL_1 raw C99:
CUL_1 raw => C 00=0D 01=2E 02=2D 03=47 04=D3 05=91 06=3D 07=00 08=32 09=00 0A=00 0B=07 0C=00 0D=10 0E=B0 0F=71 10=56 11=8D 12=30 13=23 14=B9 15=00 16=07 17=00 18=18 19=14 1A=6C 1B=07 1C=48 1D=B2 1E=87 1F=6B 20=F8 21=B6 22=11 23=EF 24=2A 25=14 26=1F 27=41 28=00 29=59 2A=7F 2B=BF 2C=81 2D=35 2E=0B 2F=00 30=00 31=14 32=00 33=80 34=F4 35=0D 36=00 37=00 38=B4 39=FD 3A=00 3B=00 3C=00 3D=00

Danke!
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 07 Februar 2018, 21:37:32
Hallo stanford,

ZitatGerade poppten noch folgende Nachrichten in meinem Log auf:
Die sind normal, wenn Du lange keine sinnvollen Datenpakete empfängst. Dann schickt die Firmware automatisch den C99, den ich haben wollte.  :)

Auffällig ist nur der vergleichsweise hohe Ruhe RSSI von -79dB bzw. -81dB

Ich habe da -90dB und weniger.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: stanford am 07 Februar 2018, 21:50:29
Volltreffer!

Oh Mann.. Ich hab gerade meine Antenne gerade die kleine kurze mitgelieferte Antenne ausgetauscht.... Jetzt funktioniert's! Auch mit CCAmode 1 und den originalen Einstellungen für die Thresholds.

Dank Dir!
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.21
Beitrag von: noansi am 07 Februar 2018, 22:38:22
Hallo stanford,

ZitatJetzt funktioniert's!

Schön, nur versteh ich jetzt nicht, warum die letzte Firmware mit CCAmode=0 nicht den erhofften Erfolg gebracht hat.  :(
Jetzt schon. Mehr Wunsch als Wirklichkeit.

Was ist das für eine Antenne gewesen? Irgendeine oder hatte die doch was mit 433.92MHz zu tun?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.25
Beitrag von: noansi am 17 Februar 2018, 11:53:34
Hallo Testwillige,

hier eine neue Version 0.25 der Timestamp Firmware und der dazu benötigten FHEM Module.

Diese Version bereinigt einige Bugs und verkürzt das Timing etwas.
Für CUL-IOs mit großem SRAM Speicher (SCC,COC,CUNO2,PIGATOR,...) ist die Device Tabelle vom EEPROM ins SRAM verlagert und somit der EEPROM Verschleiss bei HM für diese entfallen.

Es ist eine Prüfung auf Stacküberlauf eingebaut. Am Anfang des heap werden zwei Byte mit einem Bitmuster beschrieben. Wird das verändert, dann ist der Speicher wahrscheinlich korrumpiert, was durch einen Stacküberlauf ausgelöst sein sollte. Sofern der CUL dann noch kann sendet er ein "C_M" an TSCUL, was zu einem entsprechenden Log Eintrag führt.
Damit kann man vorsichtig die Speichergrenzen ausloten. Ein langer Testzeitraum ist aber erforderlich, um einigermaßen sicher zu sein, dass der worst case auch mal durchlaufen worden ist.
Außerdem ist ein Kommando mU (je nach Firmware) eingebaut, mit dem man den vom Stack ungenutzen heap in etwa auslesen kann (auch als get unusedstack in TSCUL verfügbar). Auch hier gilt, nur nach langer Laufzeit einigermaßen sinnvoll. Es macht sicher keinen Sinn auf Grund des Wertes den Speicher bis auf das letzte Byte auszuquetschen, denn weiterhin hängt die Stacknutzung vom gewählten Protokoll und Einstellungen ab.

In TSCULflash ist der Versuch des Flashens auch von NanoCULs und MiniCULs ergänzt. Da ich es aber mangels Hardware nicht testen kann, bitte ich um Feedback, ob es funktioniert. Vor dem Flashen wird ein "B00" also Reset für die TSCUL Firmware an den nano/Mini geschickt, 1 Sekunde gewartet und dann versucht mit avrdude zu flashen. Wäre nett, wenn das mal jemand testen und Feedback geben könnte.
Also erst die Firmware in den FHEM/Firmware Ordner kopieren und dann in FHEM mit
TSCULflash <nanodevicename> TSnanoCUL
bzw.
TSCULflash <minidevicename> TSminiCUL
versuchen zu Flashen. Im Log sollte danach (dauert etwas) die avrdude Ausgabe zu finden sein.

AESCommReq wird unterstützt. Die Nutzung ist unverändert zu Standard CUL, sprich, beim gewünschten Gerät/Kanal aesCommReq auf 1 setzen und ggf. noch aesKey passend zum verteilten Key setzen.
Es werden von tsculfw nur die Keys 0 (Default Key) bis 3 unterstützt.

Diese Erweiterung erfordert jedoch auch zusätzliche Empfangspuffer im knappen Speicher des CULs. Ein CUL V3 nutzt bis zu 6 Empfangspuffer. Auch der FlashSpeicherbdarf ist angestiegen, so dass einige Protokolle nicht mehr gleichzeitig in ein Kompilat passen. Das sollte aber weniger tragisch sein, da im ASKSIN Modus ohnehin nur HM empfangen werden kann.

Bei der nanoCUL und miniCUL Version habe ich nur 3 Empfangspuffer vorgesehen, um den Restpeicher für den Stack zu erhalten. Vielleicht hat jemand die Möglichkeit, die max. Stacknutzung mal ausgiebig zu testen, damit der verbleibende Speicher optimal "ausgequetscht" werden kann???

Bei CUL V2 reicht der verfügbare Speicher leider hinten und vorne nicht aus, um diese Version nutzen zu können.

Im Anhang ist in TSCUL_fwcode_00_25_FHEM_Modules_00_37.zip wieder die Timestamp Firmware zu finden. Getestet habe ich TSCUL_V3, TSCOC und TSSCC.

Die tsculfw Firmware kann für TSCUL_V3 und TSPIGATOR (an CUNX) mit FHEM mit dem TSCULflash geflashed werden. Die anderen müssen mit dem jeweiligen Flash Programmer geflashed werden.
So z.B. https://forum.fhem.de/index.php/topic,24436.msg631743.html#msg631743 kann es mit einem USB CUL Stick gehen, wenn man nicht TSCULflash verwendet.
TSCULflash ist erweitert auf COC, SCC, CCD, rpiaddon, CUNO2 und CUNO. Jedoch ist es nicht ganz so einfach zu handhaben, da zum einen teilweise die Taste zu drücken ist und bei Raspberry PI Modulen die Rechteproblematik für den Zugriff auf die IO-Pins überwunden werden muss. Tips dazu in der Command-Ref auch bei RPI_GPIO.
Bei einem Stapel aus SCC mit aufgesetztem COC, CCD oder (rpiaddon?) ist unbedingt beim SCC Flash darauf zu achten, die Taste am gewünschten Modul zu drücken. Sonst wird das oberste Nicht-SCC Modul mit der SCC Firmware geflashed.
Mit CUNO2 ist das flashen noch nicht getestet (nur über USB!). Wichtig, aber auch hier, die Taste zu drücken.

Es gibt nicht den Luxus des Downloads beim TSCULflash, sondern die Firmware muss händisch in den FHEM/firmware Ordner kopiert werden. Der Typ ist dann TSCUL_V3.
Beispiel:
TSCULflash MeinCulDevice TSCUL_V3

Wichtig für SCC Nutzer. TSSTACKED ist entfallen und wird nicht mehr unterstützt.
Statt dessen gibt es das neue Modul STACKABLETS (als Abwandlung von Rudolfs STACKABLE).
Dieses wird sozusagen zwischen die Stackteilnehmer eingebaut.

Beispiel für fhem.cfg:
#erstes SCC Modul als Basis
define SCC_WS868 TSCUL /dev/ttyAMA0@38400 0000
attr SCC_WS868 event-on-change-reading Ints_per_sec,IntCalcStat,MatchStat
attr SCC_WS868 rfmode SlowRF
attr SCC_WS868 room Receiver
attr SCC_WS868 sendpool CUL_HM868,SCC_WS868
attr SCC_WS868 verbose 1

#neues STACKABLETS virtuelles IO device
define STACK_1 STACKABLETS SCC_WS868
attr STACK_1 verbose 1

#zweites SCC Modul
define SCC_HM868 TSCUL FHEM:DEVIO:STACK_1:38400 1034
attr SCC_HM868 event-on-change-reading cond
attr SCC_HM868 hmId F11034


Ergänzender Hinweis zu USB CULs: 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_08\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 1234
bzw.
define CUL_433 TSCUL /dev/CUL433_0@12000000 0000
definiert 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 Zip Datei sind ebenfalls die ergänzten Module zu finden, die zur Nutzung der Firmware erforderlich sind.

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
16_STACKABLETS.pm -> statt der 16_STACKABLE.pm, aus STACKABLE werden damit STACKABLETS devices in der fhem.cfg (händisch anzupassen)

10_UNIRoll_TS.pm  -> statt der 10_UNIRoll.pm, mit TSCUL 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 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 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 IO-devices zu verwenden, aus CUL_WS wird dann TSCUL_WS  in der fhem.cfg (händisch anzupassen)
15_TSCUL_EM.pm   -> statt der 15_CUL_EM.pm, mit TSCUL IO-devices zu verwenden, aus CUL_EM wird dann TSCUL_EM  in der fhem.cfg (händisch anzupassen)
CalcUtil.pm               -> Hilfsrechenroutinen für Taupunkt und Windstärkeindex

97_timerTS.pm        -> Austausch Timerroutinen (inkompatibel zu 30_MilightBridge.pm vgl. https://forum.fhem.de/index.php/topic,81365.msg734828.html#msg734828 (https://forum.fhem.de/index.php/topic,81365.msg734828.html#msg734828)). Wenn es nicht genutzt werden soll, dann löschen oder umbennen. Nicht mit aktueller fhem.pl verwenden!

Da diese Module ergänzt werden (müssen!), überleben sie auch ein Update von FHEM.

Außerdem:

10_CUL_HM.pm         -> angepasste Version zur Nutzung mit TSCUL/tsculfw. Die Nutzung dieses Moduls ist optional. Für CUL_V3, nanoCUL, miniCUL im Multio-HM-IO Betrieb jedoch empfohlen, da sie den EEPROM Verschleiss über das Attribut "rssiSwitchHyst" verringert.
HMConfig.pm             -> optional, Einstelllimits für HM-CC-RT-DN Regler P und I Anteil erweitert. Damit kann man mit R-regAdaptive offDeter deutlich mehr an den Regelparametern spielen.
98_TSCULflash.pm     -> Zum Flash von TSCUL_V3, TSPIGATOR (an CUNX) mit Datei in FHEM/firmware

98_apptime.pm          -> apptime zur Nutzung mit 97_timerTS.pm. Nicht mit aktueller fhem.pl verwenden!

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 10_CUL_HM.pm HMConfig.pm 98_apptime.pm 00_TSCUL.pm 16_STACKABLETS.pm DevIoTS.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.pm CalcUtil.pm 97_timerTS.pm 98_TSCULflash.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` }

Noch ein Hinweis: TSCUL fragt auch die Firmwareversion der tsculfw auf 0.16 ab. Eine ältere Version wird also nicht unterstützt, da sich diesmal auch wieder das Timestamp Protokoll (inkompatibel zum vorherigen Stand) geändert hat, so dass mit dem Austausch der FHEM Module auch ein Firmwareupdate des CUL devices erforderlich ist!

Noch ein Tip zur Haltbarkeit der CULs mit wenig SRAM (CUL V3, nanoCUL, miniCUL ...). Jedesmal, wenn einem HM-Device das IODev durch Roaming neu zugeordnet wird, führt das zu EEPROM Schreibvorgängen in den beteiligten CULs. Die Lebensdauer des EEPROMs ist begrenzt (100000 Schreibzyklen laut Datenblatt). Daher rate ich zur Nutzung des VorzugsIOs beim Device Attribut IOgrp. Also nicht einfach stumpf
attr HMdeviceName IOgrp VCCU
setzen, sondern
attr HMdeviceName IOgrp VCCU:CUL_mit_gutem_Empfang_fuer_Device
sofern die Roaming Funktionalität entsprechend RSSI für das jeweilige device nicht zwingend benötigt wird. Ein Fallback auf einen anderen CUL bleibt dennoch möglich.
Mit dem Attribut "rssiSwitchHyst", das in der beigefügten 10_CUL_HM.pm verfügbar ist, kann bei den HM-devices die Umschalthysterese für das Roaming von 10 bis auf 2 bei Bedarf für mobile devices verringert werden.

Ergänzt ist auch noch ein set TX3Send.
Damit lassen sich TX3 Sensordatentelegramme auf 433er CULs versenden.
Beispiel:

define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 TX3Send T:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." SID:23 U")}

define NF_HumOut notify Sen_Aussen:humidity.* {fhem("set TSCUL_WS433 TX3Send H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." SID:23 U")}


Ergänzt ist auch noch ein set KSSend.
Damit lassen sich WS Sensordatentelegramme versenden.
Beispiel:

define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 KSSend T:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." Code:2")}


Gruß, Ansgar.

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

Edit1: 10_CUL_HM.pm doch wieder zwingend wegen Rollback in SVN! RollRollback hat's wieder geändert.

Edit2: Enthaltene 97_timerTS.pm und 98_apptime.pm nicht mit aktueller fhem.pl verwenden!
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.25
Beitrag von: Space_Teddy am 23 Februar 2018, 21:20:23
hi noansi,

update von einem NanoCul von 0.21 auf 0.25 ging mit TSCUL_flash ohne Schwierigkeiten, hat es aber wohl 2x gemacht.

gruß,
Chris


2018.02.23 21:11:14 2: TSCUL_Parse: TSCUL_868 unknown message ? (fx is unknown) Use one of A B C E F G J K M N R U V W X Y Z e i l m t x
2018.02.23 21:11:15 1: /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0 disconnected, waiting to reappear TSCUL_868
2018.02.23 21:11:16 0: Flash-Data: type=TSnanoCUL device=TSCUL_868 basedevice=TSCUL_868 devport=/dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0 filepath=./FHEM/firmware/TSnanoCUL.hex -> avrdude -p atmega328p -P /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0 -c arduino -b 57600 -U flash:w:./FHEM/firmware/TSnanoCUL.hex;
2018.02.23 21:11:16 1: TSCULflash avrdude -p atmega328p -P /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0 -c arduino -b 57600 -U flash:w:./FHEM/firmware/TSnanoCUL.hex;
2018.02.23 21:11:44 1: TSCULflash
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e950f
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "./FHEM/firmware/TSnanoCUL.hex"
avrdude: input file ./FHEM/firmware/TSnanoCUL.hex auto detected as Intel Hex
avrdude: writing flash (28434 bytes):

Writing | ################################################## | 100% 14.59s

avrdude: 28434 bytes of flash written
avrdude: verifying flash memory against ./FHEM/firmware/TSnanoCUL.hex:
avrdude: load data flash data from input file ./FHEM/firmware/TSnanoCUL.hex:
avrdude: input file ./FHEM/firmware/TSnanoCUL.hex auto detected as Intel Hex
avrdude: input file ./FHEM/firmware/TSnanoCUL.hex contains 28434 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 12.38s

avrdude: verifying ...
avrdude: 28434 bytes of flash verified

avrdude done.  Thank you.


2018.02.23 21:11:46 2: TSCUL_condUpdateHM: TSCUL_868 new condition disconnected
2018.02.23 21:11:47 0: Flash-Data: type=TSnanoCUL device=TSCUL_868 basedevice=TSCUL_868 devport=/dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0 filepath=./FHEM/firmware/TSnanoCUL.hex -> avrdude -p atmega328p -P /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0 -c arduino -b 57600 -U flash:w:./FHEM/firmware/TSnanoCUL.hex;
2018.02.23 21:11:47 1: TSCULflash avrdude -p atmega328p -P /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0 -c arduino -b 57600 -U flash:w:./FHEM/firmware/TSnanoCUL.hex;
2018.02.23 21:12:16 1: TSCULflash
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e950f
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "./FHEM/firmware/TSnanoCUL.hex"
avrdude: input file ./FHEM/firmware/TSnanoCUL.hex auto detected as Intel Hex
avrdude: writing flash (28434 bytes):

Writing | ################################################## | 100% 14.59s

avrdude: 28434 bytes of flash written
avrdude: verifying flash memory against ./FHEM/firmware/TSnanoCUL.hex:
avrdude: load data flash data from input file ./FHEM/firmware/TSnanoCUL.hex:
avrdude: input file ./FHEM/firmware/TSnanoCUL.hex auto detected as Intel Hex
avrdude: input file ./FHEM/firmware/TSnanoCUL.hex contains 28434 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 12.38s

avrdude: verifying ...
avrdude: 28434 bytes of flash verified

avrdude done.  Thank you.


2018.02.23 21:12:18 1: FHEMWEB SSL/HTTPS error:  SSL connect accept failed because of handshake problems (peer: 192.168.178.38)
2018.02.23 21:12:18 3: Setting TSCUL_868 serial parameters to 38400,8,N,1
2018.02.23 21:12:20 0: TSCUL_Parse: TSCUL_868 External Reset Restart detected: C_RE
2018.02.23 21:12:20 1: TSCUL_Parse: TSCUL_868 Restart detected: C_ReadyCSM868
2018.02.23 21:12:24 0: TSCUL_868 version 0.25 is not version VTS 0.16 to 0.21, please update firmware
2018.02.23 21:12:25 3: TSCUL_868: Possible commands: ABCEFGJKMNRUVWXYZeilmtx
2018.02.23 21:12:25 1: TSCUL_868 is VERSION_TS, VTS 0.25 CSM868, nanoCUL_V1.x
2018.02.23 21:12:26 2: TSCUL_condUpdateHM: TSCUL_868 new condition init
2018.02.23 21:12:26 1: /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0 reappeared (TSCUL_868)
2018.02.23 21:12:26 1: FHEMWEB SSL/HTTPS error:  SSL connect accept failed because of handshake problems (peer: 192.168.178.38)
2018.02.23 21:12:26 1: FHEMWEB SSL/HTTPS error:  SSL connect accept failed because of handshake problems (peer: 192.168.178.38)
2018.02.23 21:12:27 2: TSCUL_condUpdateHM: TSCUL_868 new condition ok
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.25
Beitrag von: noansi am 25 Februar 2018, 14:00:05
Hallo Chris,

danke für's Feedback.

Zweimal kommt nicht von alleine nach dem Code.

Warst Du eventuell ungeduldig und hast den Befehl zweimal eingegeben? Der Flashvorgang dauert einige Sekunden bevor eine Rückmeldung kommt.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.26
Beitrag von: noansi am 26 Februar 2018, 20:41:04
Hallo Testwillige,

hier eine neue Version 0.26 der Timestamp Firmware und der dazu benötigten FHEM Module.

Diese Version verlängert das Timing wieder leicht.

Für CUL-IOs mit großem SRAM Speicher (SCC,COC,CUNO2,PIGATOR,...) ist die Device Tabelle vom EEPROM ins SRAM verlagert und somit der EEPROM Verschleiss bei HM für diese entfallen.

Es ist eine Prüfung auf Stacküberlauf eingebaut. Am Anfang des heap werden zwei Byte mit einem Bitmuster beschrieben. Wird das verändert, dann ist der Speicher wahrscheinlich korrumpiert, was durch einen Stacküberlauf ausgelöst sein sollte. Sofern der CUL dann noch kann sendet er ein "C_M" an TSCUL, was zu einem entsprechenden Log Eintrag führt.
Damit kann man vorsichtig die Speichergrenzen ausloten. Ein langer Testzeitraum ist aber erforderlich, um einigermaßen sicher zu sein, dass der worst case auch mal durchlaufen worden ist.
Außerdem ist ein Kommando mU (je nach Firmware) eingebaut, mit dem man den vom Stack ungenutzen heap in etwa auslesen kann (auch als get unusedstack in TSCUL verfügbar). Auch hier gilt, nur nach langer Laufzeit einigermaßen sinnvoll. Es macht sicher keinen Sinn auf Grund des Wertes den Speicher bis auf das letzte Byte auszuquetschen, denn weiterhin hängt die Stacknutzung vom gewählten Protokoll und Einstellungen ab.

In TSCULflash ist Flashen auch von NanoCULs und MiniCULs ergänzt. Vor dem Flashen wird ein "B00" also Reset für die TSCUL Firmware an den nano/Mini geschickt, 1 Sekunde gewartet und dann versucht mit avrdude zu flashen.
Also erst die Firmware in den FHEM/Firmware Ordner kopieren und dann in FHEM mit
TSCULflash <nanodevicename> TSnanoCUL
bzw.
TSCULflash <minidevicename> TSminiCUL
versuchen zu Flashen. Im Log sollte danach (dauert etwas) die avrdude Ausgabe zu finden sein.

AESCommReq wird unterstützt. Die Nutzung ist unverändert zu Standard CUL, sprich, beim gewünschten Gerät/Kanal aesCommReq auf 1 setzen und ggf. noch aesKey passend zum verteilten Key setzen.
Es werden von tsculfw nur die Keys 0 (Default Key) bis 3 unterstützt.

Diese Erweiterung erfordert jedoch auch zusätzliche Empfangspuffer im knappen Speicher des CULs. Ein CUL V3 nutzt bis zu 6 Empfangspuffer. Auch der FlashSpeicherbdarf ist angestiegen, so dass einige Protokolle nicht mehr gleichzeitig in ein Kompilat passen. Das sollte aber weniger tragisch sein, da im ASKSIN Modus ohnehin nur HM empfangen werden kann.

Bei der nanoCUL und miniCUL Version habe ich nur 3 Empfangspuffer vorgesehen, um den Restpeicher für den Stack zu erhalten. Vielleicht hat jemand die Möglichkeit, die max. Stacknutzung mal ausgiebig zu testen, damit der verbleibende Speicher optimal "ausgequetscht" werden kann???

Bei CUL V2 reicht der verfügbare Speicher leider hinten und vorne nicht aus, um diese Version nutzen zu können.

Im Anhang ist in TSCUL_fwcode_00_26_FHEM_Modules_00_38.zip wieder die Timestamp Firmware zu finden. Getestet habe ich TSCUL_V3, TSCOC und TSSCC.

Die tsculfw Firmware kann für TSCUL_V3 und TSPIGATOR (an CUNX) mit FHEM mit dem TSCULflash geflashed werden. Die anderen müssen mit dem jeweiligen Flash Programmer geflashed werden.
So z.B. https://forum.fhem.de/index.php/topic,24436.msg631743.html#msg631743 kann es mit einem USB CUL Stick gehen, wenn man nicht TSCULflash verwendet.
TSCULflash ist erweitert auf COC, SCC, CCD, rpiaddon, CUNO2 und CUNO. Jedoch ist es nicht ganz so einfach zu handhaben, da zum einen teilweise die Taste zu drücken ist und bei Raspberry PI Modulen die Rechteproblematik für den Zugriff auf die IO-Pins überwunden werden muss. Tips dazu in der Command-Ref auch bei RPI_GPIO.
Bei einem Stapel aus SCC mit aufgesetztem COC, CCD oder (rpiaddon?) ist unbedingt beim SCC Flash darauf zu achten, die Taste am gewünschten Modul zu drücken. Sonst wird das oberste Nicht-SCC Modul mit der SCC Firmware geflashed.
Mit CUNO2 ist das flashen noch nicht getestet (nur über USB!). Wichtig, aber auch hier, die Taste zu drücken.

Es gibt nicht den Luxus des Downloads beim TSCULflash, sondern die Firmware muss händisch in den FHEM/firmware Ordner kopiert werden. Der Typ ist dann TSCUL_V3.
Beispiel:
TSCULflash MeinCulDevice TSCUL_V3

Wichtig für SCC Nutzer. TSSTACKED ist entfallen und wird nicht mehr unterstützt.
Statt dessen gibt es das neue Modul STACKABLETS (als Abwandlung von Rudolfs STACKABLE).
Dieses wird sozusagen zwischen die Stackteilnehmer eingebaut.

Beispiel für fhem.cfg:
#erstes SCC Modul als Basis
define SCC_WS868 TSCUL /dev/ttyAMA0@38400 0000
attr SCC_WS868 event-on-change-reading Ints_per_sec,IntCalcStat,MatchStat
attr SCC_WS868 rfmode SlowRF
attr SCC_WS868 room Receiver
attr SCC_WS868 sendpool CUL_HM868,SCC_WS868
attr SCC_WS868 verbose 1

#neues STACKABLETS virtuelles IO device
define STACK_1 STACKABLETS SCC_WS868
attr STACK_1 verbose 1

#zweites SCC Modul
define SCC_HM868 TSCUL FHEM:DEVIO:STACK_1:38400 1034
attr SCC_HM868 event-on-change-reading cond
attr SCC_HM868 hmId F11034


Ergänzender Hinweis zu USB CULs: 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_08\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 1234
bzw.
define CUL_433 TSCUL /dev/CUL433_0@12000000 0000
definiert 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 Zip Datei sind ebenfalls die ergänzten Module zu finden, die zur Nutzung der Firmware erforderlich sind.

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
16_STACKABLETS.pm -> statt der 16_STACKABLE.pm, aus STACKABLE werden damit STACKABLETS devices in der fhem.cfg (händisch anzupassen)

10_UNIRoll_TS.pm  -> statt der 10_UNIRoll.pm, mit TSCUL 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 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 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 IO-devices zu verwenden, aus CUL_WS wird dann TSCUL_WS  in der fhem.cfg (händisch anzupassen)
15_TSCUL_EM.pm   -> statt der 15_CUL_EM.pm, mit TSCUL IO-devices zu verwenden, aus CUL_EM wird dann TSCUL_EM  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.

Außerdem:

98_TSCULflash.pm     -> Zum Flash von TSCUL_V3, TSPIGATOR (an CUNX) mit Datei in FHEM/firmware

10_CUL_HM.pm         -> angepasste Version zur Nutzung mit TSCUL/tsculfw. Die Nutzung dieses Moduls ist optional. Für CUL_V3, nanoCUL, miniCUL im Multio-HM-IO Betrieb jedoch empfohlen, da sie den EEPROM Verschleiss über das Attribut "rssiSwitchHyst" verringert.
HMConfig.pm             -> optional, Einstelllimits für HM-CC-RT-DN Regler P und I Anteil erweitert. Damit kann man mit R-regAdaptive offDeter deutlich mehr an den Regelparametern spielen.

10_IT.pm                   -> optional, vermeidet unnötiges busy waiting beim Senden
10_CULG.pm              -> optional, enthalten, da die Firmware es unterstützt

97_timerTS.pm           -> optional, Austausch-Timerroutinen. Wenn es nicht genutzt werden soll, dann löschen oder umbennen.
98_apptime.pm          -> apptime zur zwingenden Nutzung mit 97_timerTS.pm.

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_STACKABLETS.pm DevIoTS.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.pm CalcUtil.pm 97_timerTS.pm 98_TSCULflash.pm 97_timerTS.pm 98_apptime.pm 10_IT.pm 10_CULG.pm 10_CUL_HM.pm HMConfig.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` }

Noch ein Hinweis: TSCUL fragt auch die Firmwareversion der tsculfw auf 0.16 ab. Eine ältere Version wird also nicht unterstützt, da das Timestamp Protokoll (inkompatibel zu vorherigen Ständen) geändert hat, so dass mit dem Austausch der FHEM Module auch ein Firmwareupdate des CUL devices erforderlich ist!

Noch ein Tip zur Haltbarkeit der CULs mit wenig SRAM (CUL V3, nanoCUL, miniCUL ...). Jedesmal, wenn einem HM-Device das IODev durch Roaming neu zugeordnet wird, führt das zu EEPROM Schreibvorgängen in den beteiligten CULs. Die Lebensdauer des EEPROMs ist begrenzt (100000 Schreibzyklen laut Datenblatt). Daher rate ich zur Nutzung des VorzugsIOs beim Device Attribut IOgrp. Also nicht einfach stumpf
attr HMdeviceName IOgrp VCCU
setzen, sondern
attr HMdeviceName IOgrp VCCU:CUL_mit_gutem_Empfang_fuer_Device
sofern die Roaming Funktionalität entsprechend RSSI für das jeweilige device nicht zwingend benötigt wird. Ein Fallback auf einen anderen CUL bleibt dennoch möglich.
Mit dem Attribut "rssiSwitchHyst", das in der beigefügten 10_CUL_HM.pm verfügbar ist, kann bei den HM-devices die Umschalthysterese für das Roaming von 10 bis auf 2 bei Bedarf für mobile devices verringert werden.

Ergänzt ist auch noch ein set TX3Send.
Damit lassen sich TX3 Sensordatentelegramme auf 433er CULs versenden.
Beispiel:

define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 TX3Send T:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." SID:23 U")}

define NF_HumOut notify Sen_Aussen:humidity.* {fhem("set TSCUL_WS433 TX3Send H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." SID:23 U")}


Ergänzt ist auch noch ein set KSSend.
Damit lassen sich WS Sensordatentelegramme versenden.
Beispiel:

define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 KSSend T:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." Code:2")}


Gruß, Ansgar.

Vorherige Version: https://forum.fhem.de/index.php/topic,24436.msg767959.html#msg767959 (https://forum.fhem.de/index.php/topic,24436.msg767959.html#msg767959)
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.26
Beitrag von: hackepeter am 03 März 2018, 20:00:24
Hallo,

zuerst einmal vielen Dank an noansi für diese excellente Arbeit!

Ich habe allerdings ein Problem mit meinem Selbstbau NanoCul und zwei HM Wandthermostaten (HM-TC-IT-WM-W-EU)

Es ist mir noch nie gelungen die desired-temp der Thermostate zu setzen. Aktuell hatte ich den Cul auf die 0.26er firmware geflasht und gehofft, dass es damit funktioniert. Leider tut es das auch nach erneutem pairing nicht. Hat noch jemand eine Idee woran es liegen könnte?


2018.03.03 19:35:10 0: Flash-Data: type=TSnanoCUL device=cul868 basedevice=cul868 devport=/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AH06NII9-if00-port0 filepath=./FHEM/firmware/TSnanoCUL.hex -> avrdude -p atmega328p -P /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AH06NII9-if00-port0 -c arduino -b 57600 -U flash:w:./FHEM/firmware/TSnanoCUL.hex;
2018.03.03 19:35:10 1: TSCULflash avrdude -p atmega328p -P /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AH06NII9-if00-port0 -c arduino -b 57600 -U flash:w:./FHEM/firmware/TSnanoCUL.hex;
2018.03.03 19:35:35 1: TSCULflash
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "./FHEM/firmware/TSnanoCUL.hex"
avrdude: input file ./FHEM/firmware/TSnanoCUL.hex auto detected as Intel Hex
avrdude: writing flash (28434 bytes):

Writing | ################################################## | 100% 11.35s

avrdude: 28434 bytes of flash written
avrdude: verifying flash memory against ./FHEM/firmware/TSnanoCUL.hex:
avrdude: load data flash data from input file ./FHEM/firmware/TSnanoCUL.hex:
avrdude: input file ./FHEM/firmware/TSnanoCUL.hex auto detected as Intel Hex
avrdude: input file ./FHEM/firmware/TSnanoCUL.hex contains 28434 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 12.14s

avrdude: verifying ...
avrdude: 28434 bytes of flash verified

avrdude done.  Thank you.


2018.03.03 19:35:37 3: Setting cul868 serial parameters to 38400,8,N,1
2018.03.03 19:35:38 0: TSCUL_Parse: cul868 External Reset Restart detected: C_RE
2018.03.03 19:35:38 1: TSCUL_Parse: cul868 Restart detected: C_ReadyCSM868
2018.03.03 19:35:43 0: cul868 version 0.26 is not version VTS 0.16 to 0.21, please update firmware
2018.03.03 19:35:43 3: cul868: Possible commands: ABCEFGJKMNRUVWXYZeilmtx
2018.03.03 19:35:44 1: cul868 is VERSION_TS, VTS 0.26 CSM868, nanoCUL_V1.x
2018.03.03 19:35:44 2: TSCUL_condUpdateHM: cul868 new condition init
2018.03.03 19:35:45 1: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AH06NII9-if00-port0 reappeared (cul868)
2018.03.03 19:35:45 2: TSCUL_condUpdateHM: cul868 new condition ok
2018.03.03 19:36:11 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-03_00:00:00  to:2018-03-03_23:59:59
2018.03.03 19:36:11 4: FileLog_HM_618148 get: line 1, regexp:HM_618148_Weather.humidity\x3a, col:3, output lines:464
2018.03.03 19:36:11 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-03_00:00:00  to:2018-03-03_23:59:59
2018.03.03 19:36:11 4: FileLog_HM_618148 get: line 1, regexp:HM_618148.measured-temp\x3a, col:3, output lines:76
2018.03.03 19:36:11 4: FileLog_HM_618148 get: line 2, regexp:HM_618148.desired-temp\x3a, col:3, output lines:76
2018.03.03 19:37:58 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-03_00:00:00  to:2018-03-03_23:59:59
2018.03.03 19:37:58 4: FileLog_HM_618148 get: line 1, regexp:HM_618148_Weather.humidity\x3a, col:3, output lines:464
2018.03.03 19:37:59 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-03_00:00:00  to:2018-03-03_23:59:59
2018.03.03 19:37:59 4: FileLog_HM_618148 get: line 1, regexp:HM_618148.measured-temp\x3a, col:3, output lines:76
2018.03.03 19:37:59 4: FileLog_HM_618148 get: line 2, regexp:HM_618148.desired-temp\x3a, col:3, output lines:76
2018.03.03 19:38:53 3: CUL_HM set HM_618148_Climate desired-temp 22.0
2018.03.03 19:38:55 3: LogHist cul868:  005911 A F702 00144248 00 15 AA001122AA001122AA001122AA001122AA001122AA _ping
2018.03.03 19:38:55 3: LogHist cul868:  009575 A F701 00147912 00 0C 53 865A 618148 000000 A8EC25 -53.5dB
2018.03.03 19:38:55 3: LogHist cul868:  012453 A F701 00150784 00 09 F2 A03F 618148 0FA1FF  -54dB
2018.03.03 19:38:55 3: LogHist cul868:  018620 A F701 00156948 00 09 5B A03F 618153 0FA1FF  -77.5dB
2018.03.03 19:38:55 3: LogHist cul868:  027455 A F701 00165784 00 09 F3 A03F 618148 0FA1FF  -53.5dB
2018.03.03 19:38:55 3: LogHist cul868:  029579 A F701 00167912 00 0C 53 8470 618148 000000 00EC25 -54dB
2018.03.03 19:38:55 3: LogHist cul868:  033622 A F701 00171944 00 09 5C A03F 618153 0FA1FF  -76.5dB
2018.03.03 19:38:55 3: LogHist cul868:  036220 A F702 00174556 00 15 AA001122AA001122AA001122AA001122AA001122AA _ping
2018.03.03 19:38:55 3: LogHist cul868:  042457 A F601 00180780 00 09 F4 A03F 618148 0FA1FF  -53.5dB
2018.03.03 19:38:55 3: LogHist cul868:  048624 A F601 00186944 00 09 5D A03F 618153 0FA1FF  -76.5dB
2018.03.03 19:38:55 3: LogHist cul868:  056442                 As 09 F5 B112 F63018 618148
2018.03.03 19:38:55 3: LogHist cul868:  056821 A F703 00194788 01 09 F5 B112 F63018 618148  _bst _CCAdly:4
2018.03.03 19:38:55 3: LogHist cul868:  057428 A F703 00195396 01 09 F5 B112 F63018 618148  _bst _CCAdly:4
2018.03.03 19:38:55 3: LogHist cul868:  057573 A F701 00195892 00 09 F5 A03F 618148 0FA1FF  -54.5dB
2018.03.03 19:38:55 3: LogHist cul868:  057588                 As 10 F6 A001 F63018 618148 00040000000000
2018.03.03 19:38:55 3: LogHist cul868:  058037 A F703 00196004 01 09 F5 B112 F63018 618148  _bst _CCAdly:4 _dhmSt:112
2018.03.03 19:38:55 3: TSCUL_ParseTsHM: cul868 HM repeat failed to 618148/HM_618148:  058276 A F709 00196608 00 09 F5 B112 F63018 618148  _bst _sfail _noAnsw
2018.03.03 19:38:56 3: LogHist cul868:  027455 A F701 00165784 00 09 F3 A03F 618148 0FA1FF  -53.5dB
2018.03.03 19:38:56 3: LogHist cul868:  029579 A F701 00167912 00 0C 53 8470 618148 000000 00EC25 -54dB
2018.03.03 19:38:56 3: LogHist cul868:  033622 A F701 00171944 00 09 5C A03F 618153 0FA1FF  -76.5dB
2018.03.03 19:38:56 3: LogHist cul868:  036220 A F702 00174556 00 15 AA001122AA001122AA001122AA001122AA001122AA _ping
2018.03.03 19:38:56 3: LogHist cul868:  042457 A F601 00180780 00 09 F4 A03F 618148 0FA1FF  -53.5dB
2018.03.03 19:38:56 3: LogHist cul868:  048624 A F601 00186944 00 09 5D A03F 618153 0FA1FF  -76.5dB
2018.03.03 19:38:56 3: LogHist cul868:  056442                 As 09 F5 B112 F63018 618148
2018.03.03 19:38:56 3: LogHist cul868:  056821 A F703 00194788 01 09 F5 B112 F63018 618148  _bst _CCAdly:4
2018.03.03 19:38:56 3: LogHist cul868:  057428 A F703 00195396 01 09 F5 B112 F63018 618148  _bst _CCAdly:4
2018.03.03 19:38:56 3: LogHist cul868:  057573 A F701 00195892 00 09 F5 A03F 618148 0FA1FF  -54.5dB
2018.03.03 19:38:56 3: LogHist cul868:  057588                 As 10 F6 A001 F63018 618148 00040000000000
2018.03.03 19:38:56 3: LogHist cul868:  058037 A F703 00196004 01 09 F5 B112 F63018 618148  _bst _CCAdly:4 _dhmSt:112
2018.03.03 19:38:56 3: LogHist cul868:  058276 A F709 00196608 00 09 F5 B112 F63018 618148  _bst _sfail _noAnsw
2018.03.03 19:38:56 3: LogHist cul868:  058320 A F703 00196616 01 10 F6 A001 F63018 618148 00040000000000 _CCAdly:4 _dhmSt:724
2018.03.03 19:38:56 3: LogHist cul868:  058592 A F703 00196888 01 10 F6 A001 F63018 618148 00040000000000 _CCAdly:4 _dhmSt:996
2018.03.03 19:38:56 3: LogHist cul868:  058863 A F703 00197160 01 10 F6 A001 F63018 618148 00040000000000 _CCAdly:4 _dhmSt:1268
2018.03.03 19:38:56 3: TSCUL_ParseTsHM: cul868 HM repeat failed to 618148/HM_618148:  059104 A F709 00197428 00 10 F6 A001 F63018 618148 00040000000000 _sfail _noAnsw
2018.03.03 19:39:02 3: LogHist cul868:  056442                 As 09 F5 B112 F63018 618148
2018.03.03 19:39:02 3: LogHist cul868:  056821 A F703 00194788 01 09 F5 B112 F63018 618148  _bst _CCAdly:4
2018.03.03 19:39:02 3: LogHist cul868:  057428 A F703 00195396 01 09 F5 B112 F63018 618148  _bst _CCAdly:4
2018.03.03 19:39:02 3: LogHist cul868:  057573 A F701 00195892 00 09 F5 A03F 618148 0FA1FF  -54.5dB
2018.03.03 19:39:02 3: LogHist cul868:  057588                 As 10 F6 A001 F63018 618148 00040000000000
2018.03.03 19:39:02 3: LogHist cul868:  058037 A F703 00196004 01 09 F5 B112 F63018 618148  _bst _CCAdly:4 _dhmSt:112
2018.03.03 19:39:02 3: LogHist cul868:  058276 A F709 00196608 00 09 F5 B112 F63018 618148  _bst _sfail _noAnsw
2018.03.03 19:39:02 3: LogHist cul868:  058320 A F703 00196616 01 10 F6 A001 F63018 618148 00040000000000 _CCAdly:4 _dhmSt:724
2018.03.03 19:39:02 3: LogHist cul868:  058592 A F703 00196888 01 10 F6 A001 F63018 618148 00040000000000 _CCAdly:4 _dhmSt:996
2018.03.03 19:39:02 3: LogHist cul868:  058863 A F703 00197160 01 10 F6 A001 F63018 618148 00040000000000 _CCAdly:4 _dhmSt:1268
2018.03.03 19:39:02 3: LogHist cul868:  059104 A F709 00197428 00 10 F6 A001 F63018 618148 00040000000000 _sfail _noAnsw
2018.03.03 19:39:02 3: LogHist cul868:  063075                 As 10 F6 B001 F63018 618148 00040000000000
2018.03.03 19:39:02 3: LogHist cul868:  063465 A F703 00201424 01 10 F6 B001 F63018 618148 00040000000000 _bst _CCAdly:4
2018.03.03 19:39:02 3: LogHist cul868:  063613 A F701 00201944 00 09 5E A03F 618153 0FA1FF  -92.5dB
2018.03.03 19:39:02 3: LogHist cul868:  064089 A F703 00202040 01 10 F6 B001 F63018 618148 00040000000000 _bst _CCAdly:4
2018.03.03 19:39:02 3: LogHist cul868:  064696 A F703 00202652 01 10 F6 B001 F63018 618148 00040000000000 _bst _CCAdly:4
2018.03.03 19:39:02 3: TSCUL_ParseTsHM: cul868 HM repeat failed to 618148/HM_618148:  064935 A F709 00203260 00 10 F6 B001 F63018 618148 00040000000000 _bst _sfail _noAnsw
2018.03.03 19:40:42 3: Device HM_618148 added to ActionDetector with 000:10 time
2018.03.03 19:40:42 3: CUL_HM pair: HM_618148 thermostat, model HM-TC-IT-WM-W-EU serialNr OEQ1665558
2018.03.03 19:40:46 3: CUL_HM set HM_618148 getConfig
2018.03.03 19:40:48 3: LogHist cul868:  138613 A F701 00276932 00 09 63 A03F 618153 0FA1FF  -95.5dB
2018.03.03 19:40:48 3: LogHist cul868:  147448 A F701 00285772 00 09 FB A03F 618148 0FA1FF  -53dB
2018.03.03 19:40:48 3: LogHist cul868:  147479 A F701 00285796 00 0C 54 865A 618148 000000 A8EC26 -53.5dB
2018.03.03 19:40:48 3: LogHist cul868:  153615 A F701 00291932 00 09 64 A03F 618153 0FA1FF  -71.5dB
2018.03.03 19:40:48 3: LogHist cul868:  159856 A F702 00298164 00 15 AA001122AA001122AA001122AA001122AA001122AA _ping
2018.03.03 19:40:48 3: LogHist cul868:  162450 A F701 00300768 00 09 FC A03F 618148 0FA1FF  -48dB
2018.03.03 19:40:48 3: LogHist cul868:  165142 A F701 00303456 00 1A FD 8400 618148 0FA1FF 1300AD4F4551313636353535385803FFFF -48dB
2018.03.03 19:40:48 3: LogHist cul868:  165176                 As 10 25 A001 F63018 618148 00050000000000
2018.03.03 19:40:48 3: LogHist cul868:  165291 A F703 00303572 06 10 25 A001 F63018 618148 00050000000000 _CCAdly:24 _dhmSt:116
2018.03.03 19:40:48 3: LogHist cul868:  165406 A F701 00303724 00 0A 25 8002 618148 F63018 80 -48dB
2018.03.03 19:40:48 3: LogHist cul868:  167338 A F701 00305644 00 0C 54 8470 618148 000000 00EC26 -48.5dB
2018.03.03 19:40:48 3: LogHist cul868:  168617 A F701 00306932 00 09 65 A03F 618153 0FA1FF  -77dB
2018.03.03 19:40:48 3: LogHist cul868:  169223                 As 09 55 B112 F63018 618148
2018.03.03 19:40:48 3: LogHist cul868:  169656 A F703 00307612 0F 09 55 B112 F63018 618148  _bst _CCAdly:60 _dhmSt:1968
2018.03.03 19:40:48 3: LogHist cul868:  170264 A F703 00308220 01 09 55 B112 F63018 618148  _bst _CCAdly:4 _dhmSt:2576
2018.03.03 19:40:48 3: LogHist cul868:  170886 A F703 00308828 01 09 55 B112 F63018 618148  _bst _CCAdly:4
2018.03.03 19:40:48 3: TSCUL_ParseTsHM: cul868 HM repeat failed to 618148/HM_618148:  171110 A F709 00309432 00 09 55 B112 F63018 618148  _bst _sfail _noAnsw
2018.03.03 19:41:31 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-03_00:00:00  to:2018-03-03_23:59:59
2018.03.03 19:41:31 4: FileLog_HM_618148 get: line 1, regexp:HM_618148_Weather.humidity\x3a, col:3, output lines:466
2018.03.03 19:41:31 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-03_00:00:00  to:2018-03-03_23:59:59
2018.03.03 19:41:31 4: FileLog_HM_618148 get: line 1, regexp:HM_618148.measured-temp\x3a, col:3, output lines:77
2018.03.03 19:41:31 4: FileLog_HM_618148 get: line 2, regexp:HM_618148.desired-temp\x3a, col:3, output lines:77
2018.03.03 19:41:43 3: CUL_HM set HM_618148_Climate desired-temp 22.0
2018.03.03 19:41:45 3: LogHist cul868:  170886 A F703 00308828 01 09 55 B112 F63018 618148  _bst _CCAdly:4
2018.03.03 19:41:45 3: LogHist cul868:  171110 A F709 00309432 00 09 55 B112 F63018 618148  _bst _sfail _noAnsw
2018.03.03 19:41:45 3: LogHist cul868:  178130 A F701 00315768 00 09 FD A03F 618148 0FA1FF  -52.5dB
2018.03.03 19:41:45 3: LogHist cul868:  183621 A F701 00321928 00 09 66 A03F 618153 0FA1FF  -73dB
2018.03.03 19:41:45 3: LogHist cul868:  192456 A F701 00330764 00 09 FE A03F 618148 0FA1FF  -59.5dB
2018.03.03 19:41:45 3: LogHist cul868:  196348 A F702 00334656 00 15 AA001122AA001122AA001122AA001122AA001122AA _ping
2018.03.03 19:41:45 3: LogHist cul868:  198622 A F701 00336928 00 09 67 A03F 618153 0FA1FF  -70dB
2018.03.03 19:41:45 3: LogHist cul868:  207327 A F701 00345644 00 0E 5A 8410 618148 0FA1FF 0BA8EF4C00 -50.5dB
2018.03.03 19:41:45 3: LogHist cul868:  207473 A F701 00345788 00 09 FF A03F 618148 0FA1FF  -50.5dB
2018.03.03 19:41:45 3: LogHist cul868:  213624 A F701 00351924 00 09 68 A03F 618153 0FA1FF  -73.5dB
2018.03.03 19:41:45 3: LogHist cul868:  222458 A F701 00360760 00 09 00 A03F 618148 0FA1FF  -51dB
2018.03.03 19:41:45 3: LogHist cul868:  224960 A F702 00363264 00 15 AA001122AA001122AA001122AA001122AA001122AA _ping
2018.03.03 19:41:45 3: LogHist cul868:  226249                 As 09 01 B112 F63018 618148
2018.03.03 19:41:45 3: LogHist cul868:  226628 A F703 00364576 01 09 01 B112 F63018 618148  _bst _CCAdly:4
2018.03.03 19:41:45 3: LogHist cul868:  227236 A F703 00365184 01 09 01 B112 F63018 618148  _bst _CCAdly:4
2018.03.03 19:41:45 3: LogHist cul868:  228163 A F703 00366108 50 09 01 B112 F63018 618148  _bst _CCAdly:320
2018.03.03 19:41:45 3: TSCUL_ParseTsHM: cul868 HM repeat failed to 618148/HM_618148:  228402 A F709 00366712 00 09 01 B112 F63018 618148  _bst _sfail _noAnsw
2018.03.03 19:42:44 3: Device HM_618153 added to ActionDetector with 000:10 time
2018.03.03 19:42:44 3: CUL_HM pair: HM_618153 thermostat, model HM-TC-IT-WM-W-EU serialNr OEQ1665577
2018.03.03 19:42:48 3: CUL_HM set HM_618153 getConfig
2018.03.03 19:42:50 3: LogHist cul868:  267339 A F701 00405636 00 0E 5E 8410 618148 0FA1FF 0BA8F04C00 -49.5dB
2018.03.03 19:42:50 3: LogHist cul868:  267486 A F701 00405780 00 09 03 A03F 618148 0FA1FF  -49.5dB
2018.03.03 19:42:50 3: LogHist cul868:  268246 A F702 00406544 00 15 AA001122AA001122AA001122AA001122AA001122AA _ping
2018.03.03 19:42:50 3: LogHist cul868:  270615 A F701 00408884 00 0C 55 865A 618148 000000 A8F022 -50dB
2018.03.03 19:42:50 3: LogHist cul868:  273622 A F701 00411920 00 09 6C A03F 618153 0FA1FF  -58.5dB
2018.03.03 19:42:50 3: LogHist cul868:  282506 A F701 00420756 00 09 04 A03F 618148 0FA1FF  -49dB
2018.03.03 19:42:50 3: LogHist cul868:  287323 A F701 00425612 00 1A 6D 8400 618153 0FA1FF 1300AD4F4551313636353537375803FFFF -51dB
2018.03.03 19:42:50 3: LogHist cul868:  287355                 As 10 95 A001 F63018 618153 00050000000000
2018.03.03 19:42:50 3: LogHist cul868:  287455 A F703 00425720 04 10 95 A001 F63018 618153 00050000000000 _CCAdly:16 _dhmSt:108
2018.03.03 19:42:50 3: LogHist cul868:  287570 A F701 00425876 00 0A 95 8002 618153 F63018 80 -51dB
2018.03.03 19:42:50 3: LogHist cul868:  288625 A F701 00426916 00 09 6D A03F 618153 0FA1FF  -48dB
2018.03.03 19:42:50 3: LogHist cul868:  290589 A F701 00428884 00 0C 55 8470 618148 000000 00F022 -50dB
2018.03.03 19:42:50 3: LogHist cul868:  291402                 As 09 6E B112 F63018 618153
2018.03.03 19:42:50 3: LogHist cul868:  291901 A F703 00429844 20 09 6E B112 F63018 618153  _bst _CCAdly:128 _dhmSt:2928
2018.03.03 19:42:50 3: LogHist cul868:  292524 A F803 00430452 01 09 6E B112 F63018 618153  _bst _CCAdly:4
2018.03.03 19:42:50 3: LogHist cul868:  293148 A F803 00431080 06 09 6E B112 F63018 618153  _bst _CCAdly:24
2018.03.03 19:42:50 3: TSCUL_ParseTsHM: cul868 HM repeat failed to 618153/HM_618153:  293387 A F809 00431684 00 09 6E B112 F63018 618153  _bst _sfail _noAnsw
2018.03.03 19:43:24 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-03_00:00:00  to:2018-03-03_23:59:59
2018.03.03 19:43:24 4: FileLog_HM_618148 get: line 1, regexp:HM_618148.measured-temp\x3a, col:3, output lines:79
2018.03.03 19:43:24 4: FileLog_HM_618148 get: line 2, regexp:HM_618148.desired-temp\x3a, col:3, output lines:79
2018.03.03 19:43:24 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-03_00:00:00  to:2018-03-03_23:59:59
2018.03.03 19:43:24 4: FileLog_HM_618148 get: line 1, regexp:HM_618148_Weather.humidity\x3a, col:3, output lines:467
2018.03.03 19:43:38 3: CUL_HM set HM_618148_Climate desired-temp 22.0
2018.03.03 19:43:40 3: LogHist cul868:  293148 A F803 00431080 06 09 6E B112 F63018 618153  _bst _CCAdly:24
2018.03.03 19:43:40 3: LogHist cul868:  293387 A F809 00431684 00 09 6E B112 F63018 618153  _bst _sfail _noAnsw
2018.03.03 19:43:40 3: LogHist cul868:  294101 A F802 00432396 00 15 AA001122AA001122AA001122AA001122AA001122AA _ping
2018.03.03 19:43:40 3: LogHist cul868:  297462 A F801 00435752 00 09 05 A03F 618148 0FA1FF  -49.5dB
2018.03.03 19:43:40 3: LogHist cul868:  303498 A F801 00441796 00 0E 90 8410 618153 0FA1FF 0BBCEE4C40 -75dB
2018.03.03 19:43:40 3: LogHist cul868:  303644 A F801 00441940 00 09 6E A03F 618153 0FA1FF  -70.5dB
2018.03.03 19:43:40 3: LogHist cul868:  312449 A F801 00450752 00 09 06 A03F 618148 0FA1FF  -49.5dB
2018.03.03 19:43:40 3: LogHist cul868:  318616 A F801 00456912 00 09 6F A03F 618153 0FA1FF  -78.5dB
2018.03.03 19:43:40 3: LogHist cul868:  327458 A F801 00465628 00 0E 63 8410 618148 0FA1FF 0BA8ED4C00 -54.5dB
2018.03.03 19:43:40 3: LogHist cul868:  327798 A F801 00465772 00 09 07 A03F 618148 0FA1FF  -54dB
2018.03.03 19:43:40 3: LogHist cul868:  330930 A F802 00469216 00 15 AA001122AA001122AA001122AA001122AA001122AA _ping
2018.03.03 19:43:40 3: LogHist cul868:  333620 A F801 00471912 00 09 70 A03F 618153 0FA1FF  -69dB
2018.03.03 19:43:40 3: LogHist cul868:  341147                 As 09 08 B112 F63018 618148
2018.03.03 19:43:40 3: LogHist cul868:  341529 A F803 00479460 01 09 08 B112 F63018 618148  _bst _CCAdly:4
2018.03.03 19:43:40 3: LogHist cul868:  342136 A F803 00480068 01 09 08 B112 F63018 618148  _bst _CCAdly:4
2018.03.03 19:43:40 3: LogHist cul868:  342743 A F803 00480676 01 09 08 B112 F63018 618148  _bst _CCAdly:4
2018.03.03 19:43:40 3: TSCUL_ParseTsHM: cul868 HM repeat failed to 618148/HM_618148:  342983 A F809 00481280 00 09 08 B112 F63018 618148  _bst _sfail _noAnsw
2018.03.03 19:48:48 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-03_00:00:00  to:2018-03-03_23:59:59
2018.03.03 19:48:48 4: FileLog_HM_618148 get: line 1, regexp:HM_618148_Weather.humidity\x3a, col:3, output lines:469
2018.03.03 19:48:49 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-03_00:00:00  to:2018-03-03_23:59:59
2018.03.03 19:48:49 4: FileLog_HM_618148 get: line 1, regexp:HM_618148.measured-temp\x3a, col:3, output lines:83
2018.03.03 19:48:49 4: FileLog_HM_618148 get: line 2, regexp:HM_618148.desired-temp\x3a, col:3, output lines:83
2018.03.03 19:49:03 3: CUL_HM set HM_618153 clear msgEvents
2018.03.03 19:49:05 3: CUL_HM set HM_618148 clear msgEvents
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.26
Beitrag von: noansi am 04 März 2018, 06:09:29
Hallo hackepeter,

zunächst hast Du nur die Firmware geflashed, aber nicht die aktualisierten Module genutzt (nach Backup der alten in den FHEM Ordner kopieren und fhem neu starten).
Deswegen kommt
2018.03.03 19:35:43 0: cul868 version 0.26 is not version VTS 0.16 to 0.21, please update firmware

Dann fehlt ein List vom nanoCUL und vom Problemdevice, um der Glaskugel mehr Input zu liefern.

Das log sagt, dass Du für Deinen cul868 die HM Id F63018 zum Senden verwendest und damit versuchst die Id 618148 mit Burst aufzuwecken. Das 618148 device
schickt dann was an die Id 0FA1FF, vermutlich ein Antwortversuch, da gleicher MsgCounter (ohne es im Detail weiter angeschaut zu haben).

Daher die Annahme, dass Dein Thermostat nicht mit F63018 (Deinem nanoCUL) gepaired ist, sondern mit 0FA1FF ?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.26
Beitrag von: hackepeter am 04 März 2018, 11:47:38
Hallo noansi,

vielen Dank für die Antwort!

eigentlich hatte ich die Module wie folgt kopiert:

cp TSCUL/FHEM/* /opt/fhem/FHEM/

Ich habe die Module nun noch einmal kopiert, erhalte aber dennoch nach dem Start

2018.03.04 11:45:24 0: cul868 version 0.26 is not version VTS 0.16 to 0.21, please update firmware

Vermutlich funktioniert es deswegen nicht, weil ich die FHEM.cfg nicht angepasst habe.
Kannst du mir bitte einen TIP geben, was ich in der fhem.cfg noch anpassen muss?

CUL:
define cul868 TSCUL /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AH06NII9-if00-port0@38400 0000
attr cul868 hmId F63018
attr cul868 hmLanQlen 1_min
attr cul868 rfmode HomeMatic


Thermostat Wohnzimmer:
define HM_618148 CUL_HM 618148
attr HM_618148 IODev cul868
attr HM_618148 actCycle 000:10
attr HM_618148 actStatus alive
attr HM_618148 alias thermostat_Wohnzimmer_HM_618148
attr HM_618148 autoReadReg 4_reqStatus
attr HM_618148 expert 2_raw
attr HM_618148 firmware 1.3
attr HM_618148 model HM-TC-IT-WM-W-EU
attr HM_618148 msgRepeat 1
attr HM_618148 room Heizung
attr HM_618148 serialNr OEQ1665558
attr HM_618148 subType thermostat
attr HM_618148 webCmd getConfig:clear msgEvents
define HM_618148_Weather CUL_HM 61814801
attr HM_618148_Weather model HM-TC-IT-WM-W-EU
attr HM_618148_Weather peerIDs
attr HM_618148_Weather room Heizung
define HM_618148_Climate CUL_HM 61814802
attr HM_618148_Climate model HM-TC-IT-WM-W-EU
attr HM_618148_Climate room Heizung
define HM_618148_WindowRec CUL_HM 61814803
attr HM_618148_WindowRec model HM-TC-IT-WM-W-EU
attr HM_618148_WindowRec stateFormat last:trigLast
define HM_618148_remote CUL_HM 61814806
attr HM_618148_remote model HM-TC-IT-WM-W-EU
define HM_618148_SwitchTr CUL_HM 61814807
attr HM_618148_SwitchTr model HM-TC-IT-WM-W-EU


Thermostat Bad:
define HM_618153 CUL_HM 618153
attr HM_618153 IODev cul868
attr HM_618153 actCycle 000:10
attr HM_618153 actStatus alive
attr HM_618153 alias thermostat_Bad_HM_618153
attr HM_618153 autoReadReg 4_reqStatus
attr HM_618153 expert 2_raw
attr HM_618153 firmware 1.3
attr HM_618153 model HM-TC-IT-WM-W-EU
attr HM_618153 msgRepeat 1
attr HM_618153 room Heizung
attr HM_618153 serialNr OEQ1665577
attr HM_618153 subType thermostat
attr HM_618153 webCmd getConfig:clear msgEvents
define FileLog_HM_618153 FileLog ./log/HM_618153-%Y.log HM_618153|HM_618153_Weather:.*
attr FileLog_HM_618153 alias Bad_FileLog_HM_618153
attr FileLog_HM_618153 logtype text
define HM_618153_Weather CUL_HM 61815301
attr HM_618153_Weather model HM-TC-IT-WM-W-EU
attr HM_618153_Weather peerIDs
attr HM_618153_Weather room Heizung
define HM_618153_Climate CUL_HM 61815302
attr HM_618153_Climate model HM-TC-IT-WM-W-EU
attr HM_618153_Climate room Heizung
define HM_618153_WindowRec CUL_HM 61815303
attr HM_618153_WindowRec model HM-TC-IT-WM-W-EU
attr HM_618153_WindowRec stateFormat last:trigLast
define HM_618153_remote CUL_HM 61815306
attr HM_618153_remote model HM-TC-IT-WM-W-EU
define HM_618153_SwitchTr CUL_HM 61815307
attr HM_618153_SwitchTr model HM-TC-IT-WM-W-EU
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.26
Beitrag von: noansi am 04 März 2018, 12:05:16
Hallo hackepeter,

ZitatIch habe die Module nun noch einmal kopiert, erhalte aber dennoch nach dem Start

Dann geht beim Kopieren was schief oder Deine Quelle ist veraltet.

ZitatKannst du mir bitte einen TIP geben, was ich in der fhem.cfg noch anpassen muss?

autoReadReg 4_reqStatus
würde ich in
autoReadReg 5_readMissing

und

expert 2_raw
würde ich in
expert 3_allReg+raw

ändern.

Und Du hast kein list von den devices beigepackt und somit keine Infos zum Status für die Glaskugel.

list cul868
list HM_618148

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.26
Beitrag von: hackepeter am 04 März 2018, 13:11:43
Hallo noansi,

tatsächlich waren die Module noch veraltet. Nachdem ich diese nun noch einmal neu heruntergeladen und übertragen hatte, kommt die Meldung nicht mehr.

Anschließend habe ich das Thermostat im Wohnzimmer nochmals neu gepait, was zur konsequenz hatte, dass das FHEM Frontend nicht mehr erreichbar war.

Anschließend habe ich den Raspi neu gestartet und das Pairing nochmals mit erfolg durchgeführt.
Und danach die desired temp geändert - was leider noch immer schief geht. Readings kommen aber wie gewohnt an.

Hier mal das Log von diesem Ablauf:

2018.03.04 12:50:54 0: Server shutdown
2018.03.04 12:50:57 1: Including fhem.cfg
2018.03.04 12:50:57 3: telnetPort: port 7072 opened
2018.03.04 12:50:57 3: WEB: port 8083 opened
2018.03.04 12:50:57 3: WEBphone: port 8084 opened
2018.03.04 12:50:57 3: WEBtablet: port 8085 opened
2018.03.04 12:50:57 2: eventTypes: loaded 373 events from ./log/eventTypes.txt
2018.03.04 12:50:58 3: FHEM2FHEM opening RPI1 at 192.168.178.4:7072
2018.03.04 12:50:58 1: PERL WARNING: Subroutine HandleTimeout redefined at ./FHEM/97_timerTS.pm line 32, <$fh> line 112.
2018.03.04 12:50:58 1: PERL WARNING: Subroutine InternalTimer redefined at ./FHEM/97_timerTS.pm line 103, <$fh> line 112.
2018.03.04 12:50:58 1: PERL WARNING: Subroutine RemoveInternalTimer redefined at ./FHEM/97_timerTS.pm line 182, <$fh> line 112.
2018.03.04 12:50:58 2: TSCUL_condUpdateHM: cul868 new condition disconnected
2018.03.04 12:50:58 3: Opening cul868 device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AH06NII9-if00-port0
2018.03.04 12:50:58 3: Setting cul868 serial parameters to 38400,8,N,1
2018.03.04 12:51:04 3: cul868: Possible commands: ABCEFGJKMNRUVWXYZeilmtx
2018.03.04 12:51:04 1: cul868 is VERSION_TS, VTS 0.26 CSM868, nanoCUL_V1.x
2018.03.04 12:51:05 2: TSCUL_condUpdateHM: cul868 new condition non-HM
2018.03.04 12:51:05 3: cul868 device opened
2018.03.04 12:51:05 2: TSCUL_condUpdateHM: cul868 new condition init
2018.03.04 12:51:05 2: Switched cul868 rfmode to HomeMatic
2018.03.04 12:51:06 1: Including ./log/fhem.save
2018.03.04 12:51:06 3: Device HM_618148 added to ActionDetector with 000:10 time
2018.03.04 12:51:06 3: Device HM_618153 added to ActionDetector with 000:10 time
2018.03.04 12:51:07 1: usb create starting
2018.03.04 12:51:07 3: Probing CUL device /dev/ttyAMA0
2018.03.04 12:51:07 3: Probing TCM_ESP3 device /dev/ttyAMA0
2018.03.04 12:51:07 3: Probing ZWDongle device /dev/ttyAMA0
2018.03.04 12:51:07 3: Probing FRM device /dev/ttyAMA0
2018.03.04 12:51:13 1: usb create end
2018.03.04 12:51:13 0: Featurelevel: 5.8
2018.03.04 12:51:13 0: Server started with 62 defined entities (fhem.pl:16312/2018-03-02 perl:5.024001 os:linux user:fhem pid:11455)
2018.03.04 12:51:13 3: CUL_HM set HM_618148 getConfig
2018.03.04 12:51:13 3: FHEM2FHEM device opened (RPI1)
2018.03.04 12:51:13 2: TSCUL_condUpdateHM: cul868 new condition ok
2018.03.04 12:51:14 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  131682 A F704 00012952 00 09 17 B112 F63018 618148  _bst _sfail
2018.03.04 12:51:15 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  132659 A F704 00014212 00 09 17 B112 F63018 618148  _bst _sfail
2018.03.04 12:51:17 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  133922 A F704 00015472 00 09 17 B112 F63018 618148  _bst _sfail
2018.03.04 12:51:17 3: LogHist cul868:  130164 A F701 00009520 00 09 16 A03F 618148 0FA1FF  -63dB
2018.03.04 12:51:17 3: LogHist cul868:  130169 A F702 00012688 00 01 C0 _ping
2018.03.04 12:51:17 3: LogHist cul868:  130169 A F702 00012704 00 01 C3 _ping
2018.03.04 12:51:17 3: LogHist cul868:  130363                 As 09 17 B112 F63018 618148
2018.03.04 12:51:17 3: LogHist cul868:  131682 A F704 00012952 00 09 17 B112 F63018 618148  _bst _sfail
2018.03.04 12:51:17 3: LogHist cul868:  132659 A F704 00014212 00 09 17 B112 F63018 618148  _bst _sfail
2018.03.04 12:51:17 3: LogHist cul868:  133086 A F701 00015616 00 09 7F A03F 618153 0FA1FF  -72dB
2018.03.04 12:51:17 3: LogHist cul868:  133922 A F704 00015472 00 09 17 B112 F63018 618148  _bst _sfail
2018.03.04 12:51:17 3: TSCUL_ParseTsHM: cul868 HM repeat failed to 618148/HM_618148:  134161 A F709 00016732 00 09 17 B112 F63018 618148  _bst _sfail _noAnsw
2018.03.04 12:51:17 3: CUL_HM set HM_618153 getConfig
2018.03.04 12:51:18 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618153/HM_618153:  135263 A F704 00016812 00 09 80 B112 F63018 618153  _bst _sfail
2018.03.04 12:51:19 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618153/HM_618153:  136511 A F704 00018072 00 09 80 B112 F63018 618153  _bst _sfail
2018.03.04 12:51:20 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618153/HM_618153:  137772 A F704 00019332 00 09 80 B112 F63018 618153  _bst _sfail
2018.03.04 12:51:21 3: LogHist cul868:  130164 A F701 00009520 00 09 16 A03F 618148 0FA1FF  -63dB
2018.03.04 12:51:21 3: LogHist cul868:  130169 A F702 00012688 00 01 C0 _ping
2018.03.04 12:51:21 3: LogHist cul868:  130169 A F702 00012704 00 01 C3 _ping
2018.03.04 12:51:21 3: LogHist cul868:  130363                 As 09 17 B112 F63018 618148
2018.03.04 12:51:21 3: LogHist cul868:  131682 A F704 00012952 00 09 17 B112 F63018 618148  _bst _sfail
2018.03.04 12:51:21 3: LogHist cul868:  132659 A F704 00014212 00 09 17 B112 F63018 618148  _bst _sfail
2018.03.04 12:51:21 3: LogHist cul868:  133086 A F701 00015616 00 09 7F A03F 618153 0FA1FF  -72dB
2018.03.04 12:51:21 3: LogHist cul868:  133922 A F704 00015472 00 09 17 B112 F63018 618148  _bst _sfail
2018.03.04 12:51:21 3: LogHist cul868:  134161 A F709 00016732 00 09 17 B112 F63018 618148  _bst _sfail _noAnsw
2018.03.04 12:51:21 3: LogHist cul868:  134223                 As 09 80 B112 F63018 618153
2018.03.04 12:51:21 3: LogHist cul868:  135263 A F704 00016812 00 09 80 B112 F63018 618153  _bst _sfail
2018.03.04 12:51:21 3: LogHist cul868:  136511 A F704 00018072 00 09 80 B112 F63018 618153  _bst _sfail
2018.03.04 12:51:21 3: LogHist cul868:  137772 A F704 00019332 00 09 80 B112 F63018 618153  _bst _sfail
2018.03.04 12:51:21 3: TSCUL_ParseTsHM: cul868 HM repeat failed to 618153/HM_618153:  138012 A F709 00020592 00 09 80 B112 F63018 618153  _bst _sfail _noAnsw
2018.03.04 12:51:35 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-04_00:00:00  to:2018-03-04_23:59:59
2018.03.04 12:51:35 4: FileLog_HM_618148 get: line 1, regexp:HM_618148_Weather.humidity\x3a, col:3, output lines:292
2018.03.04 12:51:35 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-04_00:00:00  to:2018-03-04_23:59:59
2018.03.04 12:51:35 4: FileLog_HM_618148 get: line 1, regexp:HM_618148.measured-temp\x3a, col:3, output lines:56
2018.03.04 12:51:35 4: FileLog_HM_618148 get: line 2, regexp:HM_618148.desired-temp\x3a, col:3, output lines:56
2018.03.04 12:51:57 3: Device HM_618148 added to ActionDetector with 000:10 time
2018.03.04 12:51:57 3: CUL_HM pair: HM_618148 thermostat, model HM-TC-IT-WM-W-EU serialNr OEQ1665558
2018.03.04 12:51:58 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  175124 A F704 00056676 00 10 42 A001 F63018 618148 00050000000000 _sfail
2018.03.04 12:51:59 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  176386 A F704 00057936 00 10 42 A001 F63018 618148 00050000000000 _sfail
2018.03.04 12:52:00 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  177649 A F704 00059196 00 10 42 A001 F63018 618148 00050000000000 _sfail
2018.03.04 12:52:01 3: LogHist cul868:  136511 A F704 00018072 00 09 80 B112 F63018 618153  _bst _sfail
2018.03.04 12:52:01 3: LogHist cul868:  137772 A F704 00019332 00 09 80 B112 F63018 618153  _bst _sfail
2018.03.04 12:52:01 3: LogHist cul868:  138012 A F709 00020592 00 09 80 B112 F63018 618153  _bst _sfail _noAnsw
2018.03.04 12:52:01 3: LogHist cul868:  139631 A F702 00022204 00 01 C3 _ping
2018.03.04 12:52:01 3: LogHist cul868:  141828 A F701 00024396 00 0E 08 8410 618148 0FA1FF 0BBCE34C00 -65dB
2018.03.04 12:52:01 3: LogHist cul868:  141975 A F701 00024540 00 09 17 A03F 618148 0FA1FF  -64dB
2018.03.04 12:52:01 3: LogHist cul868:  156945 A F701 00039512 00 09 18 A03F 618148 0FA1FF  -63.5dB
2018.03.04 12:52:01 3: LogHist cul868:  163049 A F701 00045612 00 09 81 A03F 618153 0FA1FF  -74dB
2018.03.04 12:52:01 3: LogHist cul868:  171949 A F701 00054512 00 09 19 A03F 618148 0FA1FF  -47dB
2018.03.04 12:52:01 3: LogHist cul868:  174016 A F701 00056584 00 1A 1A 8400 618148 0FA1FF 1300AD4F4551313636353535385803FFFF -44.5dB
2018.03.04 12:52:01 3: LogHist cul868:  174049                 As 10 42 A001 F63018 618148 00050000000000
2018.03.04 12:52:01 3: LogHist cul868:  175124 A F704 00056676 00 10 42 A001 F63018 618148 00050000000000 _sfail
2018.03.04 12:52:01 3: LogHist cul868:  176386 A F704 00057936 00 10 42 A001 F63018 618148 00050000000000 _sfail
2018.03.04 12:52:01 3: LogHist cul868:  177649 A F704 00059196 00 10 42 A001 F63018 618148 00050000000000 _sfail
2018.03.04 12:52:01 3: TSCUL_ParseTsHM: cul868 HM repeat failed to 618148/HM_618148:  177888 A F709 00060456 00 10 42 A001 F63018 618148 00050000000000 _sfail _noAnsw
2018.03.04 12:52:03 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  180462 A F704 00062016 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:04 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  181723 A F704 00063276 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:06 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  182985 A F704 00064536 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:06 3: LogHist cul868:  156945 A F701 00039512 00 09 18 A03F 618148 0FA1FF  -63.5dB
2018.03.04 12:52:06 3: LogHist cul868:  163049 A F701 00045612 00 09 81 A03F 618153 0FA1FF  -74dB
2018.03.04 12:52:06 3: LogHist cul868:  171949 A F701 00054512 00 09 19 A03F 618148 0FA1FF  -47dB
2018.03.04 12:52:06 3: LogHist cul868:  174016 A F701 00056584 00 1A 1A 8400 618148 0FA1FF 1300AD4F4551313636353535385803FFFF -44.5dB
2018.03.04 12:52:06 3: LogHist cul868:  174049                 As 10 42 A001 F63018 618148 00050000000000
2018.03.04 12:52:06 3: LogHist cul868:  175124 A F704 00056676 00 10 42 A001 F63018 618148 00050000000000 _sfail
2018.03.04 12:52:06 3: LogHist cul868:  176386 A F704 00057936 00 10 42 A001 F63018 618148 00050000000000 _sfail
2018.03.04 12:52:06 3: LogHist cul868:  177649 A F704 00059196 00 10 42 A001 F63018 618148 00050000000000 _sfail
2018.03.04 12:52:06 3: LogHist cul868:  177888 A F709 00060456 00 10 42 A001 F63018 618148 00050000000000 _sfail _noAnsw
2018.03.04 12:52:06 3: LogHist cul868:  178037 A F701 00060608 00 09 82 A03F 618153 0FA1FF  -74dB
2018.03.04 12:52:06 3: LogHist cul868:  179431                 As 10 01 B001 F63018 618148 00050000000000
2018.03.04 12:52:06 3: LogHist cul868:  180462 A F704 00062016 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:06 3: LogHist cul868:  181723 A F704 00063276 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:06 3: LogHist cul868:  182985 A F704 00064536 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:06 3: TSCUL_ParseTsHM: cul868 HM repeat failed to 618148/HM_618148:  183225 A F709 00065796 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail _noAnsw
2018.03.04 12:52:08 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  185685 A F704 00067232 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:10 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  186949 A F704 00068492 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:11 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  188210 A F704 00069752 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:11 3: LogHist cul868:  175124 A F704 00056676 00 10 42 A001 F63018 618148 00050000000000 _sfail
2018.03.04 12:52:11 3: LogHist cul868:  176386 A F704 00057936 00 10 42 A001 F63018 618148 00050000000000 _sfail
2018.03.04 12:52:11 3: LogHist cul868:  177649 A F704 00059196 00 10 42 A001 F63018 618148 00050000000000 _sfail
2018.03.04 12:52:11 3: LogHist cul868:  177888 A F709 00060456 00 10 42 A001 F63018 618148 00050000000000 _sfail _noAnsw
2018.03.04 12:52:11 3: LogHist cul868:  178037 A F701 00060608 00 09 82 A03F 618153 0FA1FF  -74dB
2018.03.04 12:52:11 3: LogHist cul868:  179431                 As 10 01 B001 F63018 618148 00050000000000
2018.03.04 12:52:11 3: LogHist cul868:  180462 A F704 00062016 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:11 3: LogHist cul868:  181723 A F704 00063276 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:11 3: LogHist cul868:  182985 A F704 00064536 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:11 3: LogHist cul868:  183225 A F709 00065796 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail _noAnsw
2018.03.04 12:52:11 3: LogHist cul868:  184649                 As 10 01 B001 F63018 618148 00050000000000
2018.03.04 12:52:11 3: LogHist cul868:  185685 A F704 00067232 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:11 3: LogHist cul868:  186949 A F704 00068492 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:11 3: LogHist cul868:  188210 A F704 00069752 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:11 3: TSCUL_ParseTsHM: cul868 HM repeat failed to 618148/HM_618148:  188451 A F709 00071012 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail _noAnsw
2018.03.04 12:52:13 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  189921 A F704 00071464 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:14 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  191183 A F704 00072724 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:15 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  192446 A F704 00073984 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:15 3: LogHist cul868:  179431                 As 10 01 B001 F63018 618148 00050000000000
2018.03.04 12:52:15 3: LogHist cul868:  180462 A F704 00062016 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:15 3: LogHist cul868:  181723 A F704 00063276 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:15 3: LogHist cul868:  182985 A F704 00064536 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:15 3: LogHist cul868:  183225 A F709 00065796 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail _noAnsw
2018.03.04 12:52:15 3: LogHist cul868:  184649                 As 10 01 B001 F63018 618148 00050000000000
2018.03.04 12:52:15 3: LogHist cul868:  185685 A F704 00067232 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:15 3: LogHist cul868:  186949 A F704 00068492 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:15 3: LogHist cul868:  188210 A F704 00069752 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:15 3: LogHist cul868:  188451 A F709 00071012 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail _noAnsw
2018.03.04 12:52:15 3: LogHist cul868:  188879                 As 10 01 B001 F63018 618148 00050000000000
2018.03.04 12:52:15 3: LogHist cul868:  189921 A F704 00071464 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:15 3: LogHist cul868:  191183 A F704 00072724 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:15 3: LogHist cul868:  192446 A F704 00073984 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:15 3: TSCUL_ParseTsHM: cul868 HM repeat failed to 618148/HM_618148:  192685 A F709 00075244 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail _noAnsw
2018.03.04 12:52:16 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  193787 A F704 00075332 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:18 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  195050 A F704 00076592 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:19 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  196312 A F704 00077852 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:20 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  197542 A F704 00079080 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:21 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  198789 A F704 00080340 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:23 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  200050 A F704 00081600 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:24 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  201154 A F704 00082696 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:25 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  202416 A F704 00083956 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:26 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  203677 A F704 00085216 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:27 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  204764 A F704 00086312 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:29 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  206027 A F704 00087572 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:30 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  207289 A F704 00088832 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:31 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  208423 A F704 00089960 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:32 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  209813 A F704 00091220 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:34 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  210931 A F704 00092480 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:35 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  212034 A F704 00093576 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:36 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  213296 A F704 00094836 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:37 3: Device HM_618148 added to ActionDetector with 000:10 time
2018.03.04 12:52:37 3: CUL_HM pair: HM_618148 thermostat, model HM-TC-IT-WM-W-EU serialNr OEQ1665558
2018.03.04 12:52:37 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  214558 A F704 00096096 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:37 3: LogHist cul868:  203677 A F704 00085216 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:37 3: LogHist cul868:  204764 A F704 00086312 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:37 3: LogHist cul868:  206027 A F704 00087572 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:37 3: LogHist cul868:  207289 A F704 00088832 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:37 3: LogHist cul868:  207378                 As 10 01 B001 F63018 618148 00050000000000
2018.03.04 12:52:37 3: LogHist cul868:  208423 A F704 00089960 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:37 3: LogHist cul868:  209813 A F704 00091220 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:37 3: LogHist cul868:  210931 A F704 00092480 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:37 3: LogHist cul868:  210977                 As 10 01 B001 F63018 618148 00050000000000
2018.03.04 12:52:37 3: LogHist cul868:  212034 A F704 00093576 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:37 3: LogHist cul868:  213296 A F704 00094836 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:37 3: LogHist cul868:  213962 A F701 00096520 00 1A 1C 8400 618148 0FA1FF 1300AD4F4551313636353535385803FFFF -52.5dB
2018.03.04 12:52:37 3: LogHist cul868:  214547                 As 10 44 A001 F63018 618148 00050000000000
2018.03.04 12:52:37 3: LogHist cul868:  214558 A F704 00096096 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:37 3: TSCUL_ParseTsHM: cul868 HM repeat failed to 618148/HM_618148:  214798 A F709 00097356 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail _noAnsw
2018.03.04 12:52:38 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  215821 A F704 00097360 00 10 44 A001 F63018 618148 00050000000000 _sfail
2018.03.04 12:52:40 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  217083 A F704 00098620 00 10 44 A001 F63018 618148 00050000000000 _sfail
2018.03.04 12:52:41 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  218344 A F704 00099880 00 10 44 A001 F63018 618148 00050000000000 _sfail
2018.03.04 12:52:41 3: LogHist cul868:  209813 A F704 00091220 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:41 3: LogHist cul868:  210931 A F704 00092480 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:41 3: LogHist cul868:  210977                 As 10 01 B001 F63018 618148 00050000000000
2018.03.04 12:52:41 3: LogHist cul868:  212034 A F704 00093576 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:41 3: LogHist cul868:  213296 A F704 00094836 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:41 3: LogHist cul868:  213962 A F701 00096520 00 1A 1C 8400 618148 0FA1FF 1300AD4F4551313636353535385803FFFF -52.5dB
2018.03.04 12:52:41 3: LogHist cul868:  214547                 As 10 44 A001 F63018 618148 00050000000000
2018.03.04 12:52:41 3: LogHist cul868:  214558 A F704 00096096 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:41 3: LogHist cul868:  214798 A F709 00097356 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail _noAnsw
2018.03.04 12:52:41 3: LogHist cul868:  215821 A F704 00097360 00 10 44 A001 F63018 618148 00050000000000 _sfail
2018.03.04 12:52:41 3: LogHist cul868:  216942 A F701 00099508 00 09 1C A03F 618148 0FA1FF  -47.5dB
2018.03.04 12:52:41 3: LogHist cul868:  217083 A F704 00098620 00 10 44 A001 F63018 618148 00050000000000 _sfail
2018.03.04 12:52:41 3: LogHist cul868:  218344 A F704 00099880 00 10 44 A001 F63018 618148 00050000000000 _sfail
2018.03.04 12:52:41 3: LogHist cul868:  218358 A F702 00100908 00 15 AA001122AA001122AA001122AA001122AA001122AA _ping
2018.03.04 12:52:41 3: TSCUL_ParseTsHM: cul868 HM repeat failed to 618148/HM_618148:  218585 A F709 00101140 00 10 44 A001 F63018 618148 00050000000000 _sfail _noAnsw
2018.03.04 12:52:43 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  220007 A F704 00101540 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:44 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  221253 A F704 00102800 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:45 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  222516 A F704 00104060 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:45 3: LogHist cul868:  213962 A F701 00096520 00 1A 1C 8400 618148 0FA1FF 1300AD4F4551313636353535385803FFFF -52.5dB
2018.03.04 12:52:45 3: LogHist cul868:  214547                 As 10 44 A001 F63018 618148 00050000000000
2018.03.04 12:52:45 3: LogHist cul868:  214558 A F704 00096096 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:45 3: LogHist cul868:  214798 A F709 00097356 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail _noAnsw
2018.03.04 12:52:45 3: LogHist cul868:  215821 A F704 00097360 00 10 44 A001 F63018 618148 00050000000000 _sfail
2018.03.04 12:52:45 3: LogHist cul868:  216942 A F701 00099508 00 09 1C A03F 618148 0FA1FF  -47.5dB
2018.03.04 12:52:45 3: LogHist cul868:  217083 A F704 00098620 00 10 44 A001 F63018 618148 00050000000000 _sfail
2018.03.04 12:52:45 3: LogHist cul868:  218344 A F704 00099880 00 10 44 A001 F63018 618148 00050000000000 _sfail
2018.03.04 12:52:45 3: LogHist cul868:  218358 A F702 00100908 00 15 AA001122AA001122AA001122AA001122AA001122AA _ping
2018.03.04 12:52:45 3: LogHist cul868:  218585 A F709 00101140 00 10 44 A001 F63018 618148 00050000000000 _sfail _noAnsw
2018.03.04 12:52:45 3: LogHist cul868:  218960                 As 10 01 B001 F63018 618148 00050000000000
2018.03.04 12:52:45 3: LogHist cul868:  220007 A F704 00101540 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:45 3: LogHist cul868:  221253 A F704 00102800 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:45 3: LogHist cul868:  222516 A F704 00104060 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:45 3: TSCUL_ParseTsHM: cul868 HM repeat failed to 618148/HM_618148:  222755 A F709 00105320 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail _noAnsw
2018.03.04 12:52:48 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  225455 A F704 00107000 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:49 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  226717 A F704 00108260 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:51 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  227980 A F704 00109520 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:51 3: LogHist cul868:  217083 A F704 00098620 00 10 44 A001 F63018 618148 00050000000000 _sfail
2018.03.04 12:52:51 3: LogHist cul868:  218344 A F704 00099880 00 10 44 A001 F63018 618148 00050000000000 _sfail
2018.03.04 12:52:51 3: LogHist cul868:  218358 A F702 00100908 00 15 AA001122AA001122AA001122AA001122AA001122AA _ping
2018.03.04 12:52:51 3: LogHist cul868:  218585 A F709 00101140 00 10 44 A001 F63018 618148 00050000000000 _sfail _noAnsw
2018.03.04 12:52:51 3: LogHist cul868:  218960                 As 10 01 B001 F63018 618148 00050000000000
2018.03.04 12:52:51 3: LogHist cul868:  220007 A F704 00101540 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:51 3: LogHist cul868:  221253 A F704 00102800 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:51 3: LogHist cul868:  222516 A F704 00104060 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:51 3: LogHist cul868:  222755 A F709 00105320 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail _noAnsw
2018.03.04 12:52:51 3: LogHist cul868:  223046 A F701 00105604 00 09 85 A03F 618153 0FA1FF  -70dB
2018.03.04 12:52:51 3: LogHist cul868:  224423                 As 10 01 B001 F63018 618148 00050000000000
2018.03.04 12:52:51 3: LogHist cul868:  225455 A F704 00107000 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:51 3: LogHist cul868:  226717 A F704 00108260 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:51 3: LogHist cul868:  227980 A F704 00109520 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:51 3: TSCUL_ParseTsHM: cul868 HM repeat failed to 618148/HM_618148:  228219 A F709 00110780 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail _noAnsw
2018.03.04 12:52:54 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  231031 A F704 00112568 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:55 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  232292 A F704 00113828 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:56 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  233554 A F704 00115088 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:56 3: LogHist cul868:  222516 A F704 00104060 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:56 3: LogHist cul868:  222755 A F709 00105320 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail _noAnsw
2018.03.04 12:52:56 3: LogHist cul868:  223046 A F701 00105604 00 09 85 A03F 618153 0FA1FF  -70dB
2018.03.04 12:52:56 3: LogHist cul868:  224423                 As 10 01 B001 F63018 618148 00050000000000
2018.03.04 12:52:56 3: LogHist cul868:  225455 A F704 00107000 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:56 3: LogHist cul868:  226717 A F704 00108260 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:56 3: LogHist cul868:  227980 A F704 00109520 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:56 3: LogHist cul868:  228219 A F709 00110780 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail _noAnsw
2018.03.04 12:52:56 3: LogHist cul868:  229991                 As 10 01 B001 F63018 618148 00050000000000
2018.03.04 12:52:56 3: LogHist cul868:  231031 A F704 00112568 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:56 3: LogHist cul868:  232104 A F701 00114648 00 09 1D A03F 618148 0FA1FF  -40.5dB
2018.03.04 12:52:56 3: LogHist cul868:  232103 A F701 00114648 00 0C EB 865A 618148 000000 BCEA2E -39.5dB
2018.03.04 12:52:56 3: LogHist cul868:  232292 A F704 00113828 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:56 3: LogHist cul868:  233554 A F704 00115088 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:56 3: TSCUL_ParseTsHM: cul868 HM repeat failed to 618148/HM_618148:  233794 A F709 00116348 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail _noAnsw
2018.03.04 12:52:58 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  234913 A F704 00116452 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:52:59 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  236175 A F704 00117712 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:00 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  237436 A F704 00118972 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:00 3: LogHist cul868:  226717 A F704 00108260 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:00 3: LogHist cul868:  227980 A F704 00109520 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:00 3: LogHist cul868:  228219 A F709 00110780 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail _noAnsw
2018.03.04 12:53:00 3: LogHist cul868:  229991                 As 10 01 B001 F63018 618148 00050000000000
2018.03.04 12:53:00 3: LogHist cul868:  231031 A F704 00112568 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:00 3: LogHist cul868:  232104 A F701 00114648 00 09 1D A03F 618148 0FA1FF  -40.5dB
2018.03.04 12:53:00 3: LogHist cul868:  232103 A F701 00114648 00 0C EB 865A 618148 000000 BCEA2E -39.5dB
2018.03.04 12:53:00 3: LogHist cul868:  232292 A F704 00113828 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:00 3: LogHist cul868:  233554 A F704 00115088 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:00 3: LogHist cul868:  233794 A F709 00116348 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail _noAnsw
2018.03.04 12:53:00 3: LogHist cul868:  233876                 As 10 01 B001 F63018 618148 00050000000000
2018.03.04 12:53:00 3: LogHist cul868:  234913 A F704 00116452 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:00 3: LogHist cul868:  236175 A F704 00117712 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:00 3: LogHist cul868:  237436 A F704 00118972 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:00 3: TSCUL_ParseTsHM: cul868 HM repeat failed to 618148/HM_618148:  237677 A F709 00120232 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail _noAnsw
2018.03.04 12:53:02 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  239210 A F704 00120752 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:03 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  240472 A F704 00122012 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:04 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  241733 A F704 00123272 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:05 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  242869 A F704 00124404 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:07 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  244131 A F704 00125664 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:08 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  245503 A F704 00126924 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:08 3: LogHist cul868:  234913 A F704 00116452 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:08 3: LogHist cul868:  236175 A F704 00117712 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:08 3: LogHist cul868:  237436 A F704 00118972 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:08 3: LogHist cul868:  237677 A F709 00120232 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail _noAnsw
2018.03.04 12:53:08 3: LogHist cul868:  237917 A F701 00120480 00 0E 3F 8410 618153 0FA1FF 0BBCE84C40 -69dB
2018.03.04 12:53:08 3: LogHist cul868:  238063 A F701 00120624 00 09 86 A03F 618153 0FA1FF  -71dB
2018.03.04 12:53:08 3: LogHist cul868:  238177                 As 10 01 B001 F63018 618148 00050000000000
2018.03.04 12:53:08 3: LogHist cul868:  239210 A F704 00120752 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:08 3: LogHist cul868:  240472 A F704 00122012 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:08 3: LogHist cul868:  241733 A F704 00123272 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:08 3: LogHist cul868:  241828                 As 10 01 B001 F63018 618148 00050000000000
2018.03.04 12:53:08 3: LogHist cul868:  242869 A F704 00124404 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:08 3: LogHist cul868:  244131 A F704 00125664 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:08 3: LogHist cul868:  245503 A F704 00126924 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:08 3: TSCUL_ParseTsHM: cul868 HM repeat failed to 618148/HM_618148:  245633 A F709 00128184 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail _noAnsw
2018.03.04 12:53:09 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  246783 A F704 00128312 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:11 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  248061 A F704 00129592 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:12 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  249323 A F704 00130852 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:13 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  250409 A F704 00131948 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:14 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  251671 A F704 00133208 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:16 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  252934 A F704 00134468 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:17 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  254021 A F704 00135564 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:18 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  255285 A F704 00136824 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:19 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  256548 A F704 00138084 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:20 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  257648 A F704 00139180 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:22 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  258910 A F704 00140440 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:23 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  260175 A F704 00141700 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:24 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  261261 A F704 00142796 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:26 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  263448 A F704 00144976 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:27 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  264679 A F704 00146208 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:29 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  265941 A F704 00147468 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:30 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  267189 A F704 00148728 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:31 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  268293 A F704 00149824 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:32 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  269551 A F704 00151084 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:33 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  270814 A F704 00152344 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:35 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  271901 A F704 00153440 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:36 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  273165 A F704 00154700 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:37 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  274491 A F704 00155960 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:38 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  275871 A F704 00157100 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:40 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  277124 A F704 00158360 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:41 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  278413 A F704 00159620 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:41 3: LogHist cul868:  267214                 As 10 01 B001 F63018 618148 00050000000000
2018.03.04 12:53:41 3: LogHist cul868:  268293 A F704 00149824 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:41 3: LogHist cul868:  269551 A F704 00151084 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:41 3: LogHist cul868:  270794                 As 10 01 B001 F63018 618148 00050000000000
2018.03.04 12:53:41 3: LogHist cul868:  270814 A F704 00152344 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:41 3: LogHist cul868:  271901 A F704 00153440 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:41 3: LogHist cul868:  273165 A F704 00154700 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:41 3: LogHist cul868:  274491 A F704 00155960 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:41 3: LogHist cul868:  274531                 As 10 01 B001 F63018 618148 00050000000000
2018.03.04 12:53:41 3: LogHist cul868:  275871 A F704 00157100 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:41 3: LogHist cul868:  277124 A F704 00158360 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:41 3: LogHist cul868:  277128 A F701 00159496 00 09 20 A03F 618148 0FA1FF  -67.5dB
2018.03.04 12:53:41 3: LogHist cul868:  278413 A F704 00159620 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:41 3: LogHist cul868:  278415 A F701 00160720 00 0C B8 8470 618153 000000 00E82C -65dB
2018.03.04 12:53:41 3: TSCUL_ParseTsHM: cul868 HM repeat failed to 618148/HM_618148:  278413 A F709 00160880 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail _noAnsw
2018.03.04 12:53:48 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  285404 A F704 00166416 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:57 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  293956 A F704 00167676 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:57 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  293956 A F704 00168936 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:57 3: LogHist cul868:  273165 A F704 00154700 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:57 3: LogHist cul868:  274491 A F704 00155960 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:57 3: LogHist cul868:  274531                 As 10 01 B001 F63018 618148 00050000000000
2018.03.04 12:53:57 3: LogHist cul868:  275871 A F704 00157100 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:57 3: LogHist cul868:  277124 A F704 00158360 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:57 3: LogHist cul868:  277128 A F701 00159496 00 09 20 A03F 618148 0FA1FF  -67.5dB
2018.03.04 12:53:57 3: LogHist cul868:  278413 A F704 00159620 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:57 3: LogHist cul868:  278415 A F701 00160720 00 0C B8 8470 618153 000000 00E82C -65dB
2018.03.04 12:53:57 3: LogHist cul868:  278413 A F709 00160880 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail _noAnsw
2018.03.04 12:53:57 3: LogHist cul868:  283847                 As 10 01 B001 F63018 618148 00050000000000
2018.03.04 12:53:57 3: LogHist cul868:  285408 A F701 00165592 00 09 89 A03F 618153 0FA1FF  -80dB
2018.03.04 12:53:57 3: LogHist cul868:  285404 A F704 00166416 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:57 3: LogHist cul868:  293956 A F704 00167676 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:57 3: LogHist cul868:  293956 A F704 00168936 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:53:57 3: TSCUL_ParseTsHM: cul868 HM repeat failed to 618148/HM_618148:  293956 A F709 00170196 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail _noAnsw
2018.03.04 12:54:49 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  346622 A F704 00201616 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:54:49 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  346622 A F704 00202876 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:55:59 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  416615 A F704 00204136 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:55:59 3: LogHist cul868:  293956 A F704 00167676 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:55:59 3: LogHist cul868:  293956 A F704 00168936 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:55:59 3: LogHist cul868:  293956 A F709 00170196 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail _noAnsw
2018.03.04 12:55:59 3: LogHist cul868:  293954 A F702 00173504 00 15 AA001122AA001122AA001122AA001122AA001122AA _ping
2018.03.04 12:55:59 3: LogHist cul868:  310988 A F701 00174492 00 09 21 A03F 618148 0FA1FF  -68.5dB
2018.03.04 12:55:59 3: LogHist cul868:  310988 A F701 00180592 00 09 8A A03F 618153 0FA1FF  -79dB
2018.03.04 12:55:59 3: LogHist cul868:  310988 A F701 00189488 00 09 22 A03F 618148 0FA1FF  -68dB
2018.03.04 12:55:59 3: LogHist cul868:  319053                 As 10 01 B001 F63018 618148 00050000000000
2018.03.04 12:55:59 3: LogHist cul868:  346625 A F701 00195588 00 09 8B A03F 618153 0FA1FF  -78.5dB
2018.03.04 12:55:59 3: LogHist cul868:  346622 A F704 00201616 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:55:59 3: LogHist cul868:  346622 A F704 00202876 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:55:59 3: LogHist cul868:  346623 A F701 00204372 00 0E 15 8410 618148 0FA1FF 0BBCEF4C00 -68.5dB
2018.03.04 12:55:59 3: LogHist cul868:  346625 A F701 00204512 00 09 23 A03F 618148 0FA1FF  -69.5dB
2018.03.04 12:55:59 3: LogHist cul868:  416615 A F704 00204136 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail
2018.03.04 12:55:59 3: TSCUL_ParseTsHM: cul868 HM repeat failed to 618148/HM_618148:  416615 A F709 00205396 00 10 01 B001 F63018 618148 00050000000000 _bst _sfail _noAnsw
2018.03.04 12:58:25 0: Server shutdown
2018.03.04 12:57:55 1: Including fhem.cfg
2018.03.04 12:57:56 3: telnetPort: port 7072 opened
2018.03.04 12:57:58 3: WEB: port 8083 opened
2018.03.04 12:57:58 3: WEBphone: port 8084 opened
2018.03.04 12:57:58 3: WEBtablet: port 8085 opened
2018.03.04 12:57:58 2: eventTypes: loaded 373 events from ./log/eventTypes.txt
2018.03.04 12:58:01 3: FHEM2FHEM opening RPI1 at 192.168.178.4:7072
2018.03.04 12:58:03 1: PERL WARNING: Subroutine HandleTimeout redefined at ./FHEM/97_timerTS.pm line 32, <$fh> line 112.
2018.03.04 12:58:03 1: PERL WARNING: Subroutine InternalTimer redefined at ./FHEM/97_timerTS.pm line 103, <$fh> line 112.
2018.03.04 12:58:03 1: PERL WARNING: Subroutine RemoveInternalTimer redefined at ./FHEM/97_timerTS.pm line 182, <$fh> line 112.
2018.03.04 12:58:03 2: TSCUL_condUpdateHM: cul868 new condition disconnected
2018.03.04 12:58:03 3: Opening cul868 device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AH06NII9-if00-port0
2018.03.04 12:58:03 3: Setting cul868 serial parameters to 38400,8,N,1
2018.03.04 12:58:08 3: cul868: Possible commands: ABCEFGJKMNRUVWXYZeilmtx
2018.03.04 12:58:09 1: cul868 is VERSION_TS, VTS 0.26 CSM868, nanoCUL_V1.x
2018.03.04 12:58:09 2: TSCUL_condUpdateHM: cul868 new condition non-HM
2018.03.04 12:58:10 3: cul868 device opened
2018.03.04 12:58:10 2: TSCUL_condUpdateHM: cul868 new condition init
2018.03.04 12:58:10 2: Switched cul868 rfmode to HomeMatic
2018.03.04 12:58:11 1: Including ./log/fhem.save
2018.03.04 12:58:11 3: Device HM_618148 added to ActionDetector with 000:10 time
2018.03.04 12:58:11 3: Device HM_618153 added to ActionDetector with 000:10 time
2018.03.04 12:58:11 1: usb create starting
2018.03.04 12:58:12 3: Probing CUL device /dev/ttyAMA0
2018.03.04 12:58:12 3: Probing TCM_ESP3 device /dev/ttyAMA0
2018.03.04 12:58:12 3: Probing ZWDongle device /dev/ttyAMA0
2018.03.04 12:58:12 3: Probing FRM device /dev/ttyAMA0
2018.03.04 12:59:05 1: usb create end
2018.03.04 12:59:05 0: Featurelevel: 5.8
2018.03.04 12:59:05 0: Server started with 62 defined entities (fhem.pl:16312/2018-03-02 perl:5.024001 os:linux user:fhem pid:823)
2018.03.04 12:59:05 3: CUL_HM set HM_618148 getConfig
2018.03.04 12:59:05 3: FHEM2FHEM device opened (RPI1)
2018.03.04 12:59:05 2: TSCUL_condUpdateHM: cul868 new condition ok
2018.03.04 12:59:06 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  079094 A F704 00013424 00 09 A2 B112 F63018 618148  _bst _sfail
2018.03.04 12:59:07 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  080356 A F704 00014684 00 09 A2 B112 F63018 618148  _bst _sfail
2018.03.04 12:59:09 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  081618 A F704 00015944 00 09 A2 B112 F63018 618148  _bst _sfail
2018.03.04 12:59:09 3: LogHist cul868:  077994 A F701 00009052 00 09 9E A03F 618153 0FA1FF  -78.5dB
2018.03.04 12:59:09 3: LogHist cul868:  077998 A F702 00013312 00 01 C0 _ping
2018.03.04 12:59:09 3: LogHist cul868:  077998 A F702 00013328 00 01 C3 _ping
2018.03.04 12:59:09 3: LogHist cul868:  078069                 As 09 A2 B112 F63018 618148
2018.03.04 12:59:09 3: LogHist cul868:  079094 A F704 00013424 00 09 A2 B112 F63018 618148  _bst _sfail
2018.03.04 12:59:09 3: LogHist cul868:  080356 A F704 00014684 00 09 A2 B112 F63018 618148  _bst _sfail
2018.03.04 12:59:09 3: LogHist cul868:  081618 A F704 00015944 00 09 A2 B112 F63018 618148  _bst _sfail
2018.03.04 12:59:09 3: TSCUL_ParseTsHM: cul868 HM repeat failed to 618148/HM_618148:  081858 A F709 00017204 00 09 A2 B112 F63018 618148  _bst _sfail _noAnsw
2018.03.04 12:59:09 3: CUL_HM set HM_618153 getConfig
2018.03.04 12:59:10 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618153/HM_618153:  083057 A F704 00017380 00 09 9F B112 F63018 618153  _bst _sfail
2018.03.04 12:59:12 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618153/HM_618153:  084702 A F704 00018640 00 09 9F B112 F63018 618153  _bst _sfail
2018.03.04 12:59:12 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618153/HM_618153:  085582 A F704 00019900 00 09 9F B112 F63018 618153  _bst _sfail
2018.03.04 12:59:13 3: LogHist cul868:  077994 A F701 00009052 00 09 9E A03F 618153 0FA1FF  -78.5dB
2018.03.04 12:59:13 3: LogHist cul868:  077998 A F702 00013312 00 01 C0 _ping
2018.03.04 12:59:13 3: LogHist cul868:  077998 A F702 00013328 00 01 C3 _ping
2018.03.04 12:59:13 3: LogHist cul868:  078069                 As 09 A2 B112 F63018 618148
2018.03.04 12:59:13 3: LogHist cul868:  079094 A F704 00013424 00 09 A2 B112 F63018 618148  _bst _sfail
2018.03.04 12:59:13 3: LogHist cul868:  080356 A F704 00014684 00 09 A2 B112 F63018 618148  _bst _sfail
2018.03.04 12:59:13 3: LogHist cul868:  081618 A F704 00015944 00 09 A2 B112 F63018 618148  _bst _sfail
2018.03.04 12:59:13 3: LogHist cul868:  081858 A F709 00017204 00 09 A2 B112 F63018 618148  _bst _sfail _noAnsw
2018.03.04 12:59:13 3: LogHist cul868:  082025                 As 09 9F B112 F63018 618153
2018.03.04 12:59:13 3: LogHist cul868:  082609 A F701 00017956 00 09 36 A03F 618148 0FA1FF  -69dB
2018.03.04 12:59:13 3: LogHist cul868:  083057 A F704 00017380 00 09 9F B112 F63018 618153  _bst _sfail
2018.03.04 12:59:13 3: LogHist cul868:  084702 A F704 00018640 00 09 9F B112 F63018 618153  _bst _sfail
2018.03.04 12:59:13 3: LogHist cul868:  085582 A F704 00019900 00 09 9F B112 F63018 618153  _bst _sfail
2018.03.04 12:59:13 3: TSCUL_ParseTsHM: cul868 HM repeat failed to 618153/HM_618153:  085821 A F709 00021160 00 09 9F B112 F63018 618153  _bst _sfail _noAnsw
2018.03.04 12:59:14 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-04_00:00:00  to:2018-03-04_23:59:59
2018.03.04 12:59:14 4: FileLog_HM_618148 get: line 1, regexp:HM_618148.measured-temp\x3a, col:3, output lines:58
2018.03.04 12:59:14 4: FileLog_HM_618148 get: line 2, regexp:HM_618148.desired-temp\x3a, col:3, output lines:58
2018.03.04 12:59:15 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-04_00:00:00  to:2018-03-04_23:59:59
2018.03.04 12:59:15 4: FileLog_HM_618148 get: line 1, regexp:HM_618148_Weather.humidity\x3a, col:3, output lines:293
2018.03.04 12:59:56 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-04_00:00:00  to:2018-03-04_23:59:59
2018.03.04 12:59:56 4: FileLog_HM_618148 get: line 1, regexp:HM_618148_Weather.humidity\x3a, col:3, output lines:293
2018.03.04 12:59:56 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-04_00:00:00  to:2018-03-04_23:59:59
2018.03.04 12:59:57 4: FileLog_HM_618148 get: line 1, regexp:HM_618148.measured-temp\x3a, col:3, output lines:58
2018.03.04 12:59:57 4: FileLog_HM_618148 get: line 2, regexp:HM_618148.desired-temp\x3a, col:3, output lines:58
2018.03.04 13:00:29 3: Device HM_618148 added to ActionDetector with 000:10 time
2018.03.04 13:00:29 3: CUL_HM pair: HM_618148 thermostat, model HM-TC-IT-WM-W-EU serialNr OEQ1665558
2018.03.04 13:00:31 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  163611 A F704 00097920 00 10 64 A001 F63018 618148 00050000000000 _sfail
2018.03.04 13:00:32 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  164872 A F704 00099180 00 10 64 A001 F63018 618148 00050000000000 _sfail
2018.03.04 13:00:33 3: CUL_HM set HM_618148 getConfig
2018.03.04 13:00:36 3: LogHist cul868:  148708 A F701 00084044 00 09 A3 A03F 618153 0FA1FF  -77.5dB
2018.03.04 13:00:36 3: LogHist cul868:  156486 A F701 00091820 00 0C EE 865A 618148 000000 BCED25 -42dB
2018.03.04 13:00:36 3: LogHist cul868:  157491 A F701 00092820 00 0E 2F 8410 618148 0FA1FF 0BA8ED0C00 -58.5dB
2018.03.04 13:00:36 3: LogHist cul868:  157639 A F701 00092964 00 09 3B A03F 618148 0FA1FF  -59.5dB
2018.03.04 13:00:36 3: LogHist cul868:  162502 A F701 00097828 00 1A 3C 8400 618148 0FA1FF 1300AD4F4551313636353535385803FFFF -40dB
2018.03.04 13:00:36 3: LogHist cul868:  162538                 As 10 64 A001 F63018 618148 00050000000000
2018.03.04 13:00:36 3: LogHist cul868:  163611 A F704 00097920 00 10 64 A001 F63018 618148 00050000000000 _sfail
2018.03.04 13:00:36 3: LogHist cul868:  164872 A F704 00099180 00 10 64 A001 F63018 618148 00050000000000 _sfail
2018.03.04 13:00:36 3: LogHist cul868:  165959 A F703 00101252 CB 10 64 A001 F63018 618148 00050000000000 _CCAdly:812
2018.03.04 13:00:36 3: LogHist cul868:  166074 A F701 00101404 00 0A 64 8002 618148 F63018 80 -47.5dB
2018.03.04 13:00:36 3: LogHist cul868:  166582                 As 09 65 B112 F63018 618148
2018.03.04 13:00:36 3: LogHist cul868:  167225 A F703 00102188 42 09 65 B112 F63018 618148  _bst _CCAdly:264 _dhmSt:784
2018.03.04 13:00:36 3: LogHist cul868:  167847 A F703 00102808 04 09 65 B112 F63018 618148  _bst _CCAdly:16 _dhmSt:1404
2018.03.04 13:00:36 3: LogHist cul868:  168486 A F703 00103452 0A 09 65 B112 F63018 618148  _bst _CCAdly:40 _dhmSt:2048
2018.03.04 13:00:36 3: TSCUL_ParseTsHM: cul868 HM repeat failed to 618148/HM_618148:  168727 A F709 00104060 00 09 65 B112 F63018 618148  _bst _sfail _noAnsw
2018.03.04 13:00:57 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-04_00:00:00  to:2018-03-04_23:59:59
2018.03.04 13:00:57 4: FileLog_HM_618148 get: line 1, regexp:HM_618148_Weather.humidity\x3a, col:3, output lines:294
2018.03.04 13:00:57 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-04_00:00:00  to:2018-03-04_23:59:59
2018.03.04 13:00:57 4: FileLog_HM_618148 get: line 1, regexp:HM_618148.measured-temp\x3a, col:3, output lines:59
2018.03.04 13:00:57 4: FileLog_HM_618148 get: line 2, regexp:HM_618148.desired-temp\x3a, col:3, output lines:59
2018.03.04 13:01:02 3: CUL_HM set HM_618148_Climate desired-temp 22.5
2018.03.04 13:01:03 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  196370 A F704 00130668 00 09 3E B112 F63018 618148  _bst _sfail
2018.03.04 13:01:05 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  197632 A F704 00131928 00 09 3E B112 F63018 618148  _bst _sfail
2018.03.04 13:01:06 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  198895 A F704 00133188 00 09 3E B112 F63018 618148  _bst _sfail
2018.03.04 13:01:06 3: LogHist cul868:  167225 A F703 00102188 42 09 65 B112 F63018 618148  _bst _CCAdly:264 _dhmSt:784
2018.03.04 13:01:06 3: LogHist cul868:  167847 A F703 00102808 04 09 65 B112 F63018 618148  _bst _CCAdly:16 _dhmSt:1404
2018.03.04 13:01:06 3: LogHist cul868:  168486 A F703 00103452 0A 09 65 B112 F63018 618148  _bst _CCAdly:40 _dhmSt:2048
2018.03.04 13:01:06 3: LogHist cul868:  168727 A F709 00104060 00 09 65 B112 F63018 618148  _bst _sfail _noAnsw
2018.03.04 13:01:06 3: LogHist cul868:  170237 A F702 00105568 00 15 AA001122AA001122AA001122AA001122AA001122AA _ping
2018.03.04 13:01:06 3: LogHist cul868:  172608 A F701 00107940 00 09 3C A03F 618148 0FA1FF  -48dB
2018.03.04 13:01:06 3: LogHist cul868:  176490 A F701 00111816 00 0C EE 8470 618148 000000 00ED25 -54dB
2018.03.04 13:01:06 3: LogHist cul868:  178712 A F701 00114036 00 09 A5 A03F 618153 0FA1FF  -78.5dB
2018.03.04 13:01:06 3: LogHist cul868:  187612 A F701 00122936 00 09 3D A03F 618148 0FA1FF  -79dB
2018.03.04 13:01:06 3: LogHist cul868:  195335                 As 09 3E B112 F63018 618148
2018.03.04 13:01:06 3: LogHist cul868:  196370 A F704 00130668 00 09 3E B112 F63018 618148  _bst _sfail
2018.03.04 13:01:06 3: LogHist cul868:  197632 A F704 00131928 00 09 3E B112 F63018 618148  _bst _sfail
2018.03.04 13:01:06 3: LogHist cul868:  198895 A F704 00133188 00 09 3E B112 F63018 618148  _bst _sfail
2018.03.04 13:01:06 3: LogHist cul868:  198905 A F702 00134208 00 15 AA001122AA001122AA001122AA001122AA001122AA _ping
2018.03.04 13:01:06 3: TSCUL_ParseTsHM: cul868 HM repeat failed to 618148/HM_618148:  199135 A F709 00134448 00 09 3E B112 F63018 618148  _bst _sfail _noAnsw


Anmerkung: Die Warnungen mit der FHEM/97_timerTS.pm sind neu hinzugekommen.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.26
Beitrag von: hackepeter am 04 März 2018, 13:14:09
Hat nicht alles in einen Post gepasst.

list HM_cul868
Internals:
   CMDS       ABCEFGJKMNRUVWXYZeilmtx
   Clients    STACKABLETS:STACKABLE:CUL_HM:CUL_IR:HMS
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AH06NII9-if00-port0@38400 0000
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AH06NII9-if00-port0@38400
   FD         12
   FHTID      0000
   NAME       cul868
   NR         47
   PARTIAL   
   RAWMSG     A09D9A03F6181530FA1FF::-77:cul868:
   RSSI       -77
   STATE      Initialized
   TYPE       TSCUL
   VERSION    VTS 0.26 CSM868
   VERSION_HW nanoCUL_V1.x
   VERSION_TS yes AES ChTblSize:220
   XmitOpen   1
   assignUpdCntI 4
   assignedIDsCnt 2
   cul868_MSGCNT 149
   cul868_TIME 2018-03-04 13:13:46
   initString X21
Ar
AM5
AHF63018
   MatchList:
     1:STACKABLETS ^\*
     2:STACKABLE ^\*
     A:CUL_HM   ^A....................
     B:CUL_IR   ^I............
     C:HMS      ^810e04......a001
   READINGS:
     2018-03-04 11:19:05   ITSndFreq       433.920MHz
     2018-01-06 19:52:37   SlowRFSndFreq   868.300MHz
     2018-03-04 12:59:05   Xmit-Events     ok:1 init:1 disconnected:1 non-HM:1
     2018-03-04 12:58:08   cmds             A B C E F G J K M N R U V W X Y Z e i l m t x
     2018-03-04 12:59:05   cond            ok
     2018-01-06 19:52:46   credit10ms      1634
     2018-03-04 12:58:03   prot_disconnected last
     2018-03-04 12:58:10   prot_init       last
     2018-03-04 12:58:09   prot_non-HM     last
     2018-03-04 12:59:05   prot_ok         last
     2018-03-04 12:36:55   scF             1.00016674835006
     2018-03-04 12:58:10   state           Initialized
   helper:
     CUrun      1
     ChkPart    0
     RA_Timeout 0
     VTS        1
     VTS_ACK    1
     VTS_AES    1
     assIdCnt   2
     assIdRep   2
     hmTSAt1Add
     recd       1
     tbuf       
     DEVIO:
       RXfailTO   
     HM:
       ChTblSize  220
       FUP        0
       HMactive   1
       hmCrdts    4
       hmSbusy    0
       ChTbl:
         6181483F   00
         6181533F   00
       msgCNT:
         0x01       149
         0x02       35
         0x03       4
         0x04       11
         0x09       4
       unknwn:
     cnd:
       0          1
       250        1
       253        1
       255        1
     hmLogHist:
        368331 A F501 00827824 00 09 6C A03F 618148 0FA1FF  -52dB
        374434 A F401 00833920 00 09 D5 A03F 618153 0FA1FF  -78dB
        383334 A F401 00842820 00 09 6D A03F 618148 0FA1FF  -52dB
        383695 A F402 00843188 00 15 AA001122AA001122AA001122AA001122AA001122AA _ping
        389437 A F401 00848920 00 09 D6 A03F 618153 0FA1FF  -78dB
        390203 A F401 00849696 00 0C F3 865A 618148 000000 A8EA25 -52.5dB
        398337 A F401 00857820 00 09 6E A03F 618148 0FA1FF  -52dB
        404425 A F401 00863916 00 09 D7 A03F 618153 0FA1FF  -79.5dB
        410207 A F401 00869696 00 0C F3 8470 618148 000000 00EA25 -52.5dB
        413341 A F401 00872816 00 09 6F A03F 618148 0FA1FF  -52dB
        416658 A F402 00876140 00 15 AA001122AA001122AA001122AA001122AA001122AA _ping
        419427 A F401 00878912 00 09 D8 A03F 618153 0FA1FF  -77.5dB
        428327 A F401 00887812 00 09 70 A03F 618148 0FA1FF  -52dB
        434431 A F401 00893912 00 09 D9 A03F 618153 0FA1FF  -77dB
     hmQ:
       618148:
       618153:
     ids:
       618148:
         cfg        +618148,00,00,00
         name       HM_618148
       618153:
         cfg        +618153,00,00,00
         name       HM_618153
     q:
       ATrNo      0
       HMcndN     0
       InQueues   0
       XRpCnt     0
       XRpTm      1520164745.35262
       answerPend 0
       hmLanQlen  1
       apIDs:
         618148     0
         618153     0
       cap:
         sum        20250
     ref:
       Sdly       5
       doNbyterate 21
       ioByteRate 3840
       ioByteRateMeas 3715.81598881628
       lHMt       863916
       lSys       820915145
       pTTu       1024
       pndAs      0
       pndCUAp    0
       pngLm      20
       pngMax     23
       pngMaxTot  23
       pngMin     12
       pngRef     12
       pngtm      820075138
       pngtmBRs   1520165608.31863
       scF        1.00016674835006
       scFN       0
       scHT       24056
       scST       820075150
Attributes:
   hmId       F63018
   hmLanQlen  1_min
   rfmode     HomeMatic


list HM_618148
Internals:
   DEF        618148
   IODev      cul868
   LASTInputDev cul868
   MSGCNT     70
   NAME       HM_618148
   NOTIFYDEV  global
   NR         48
   NTFY_ORDER 50-HM_618148
   STATE      CMDs_pending
   TYPE       CUL_HM
   channel_01 HM_618148_Weather
   channel_02 HM_618148_Climate
   channel_03 HM_618148_WindowRec
   channel_06 HM_618148_remote
   channel_07 HM_618148_SwitchTr
   cul868_MSGCNT 70
   cul868_RAWMSG A0965A03F6181480FA1FF::-52.5:cul868:
   cul868_RSSI -52.5
   cul868_TIME 2018-03-04 13:10:55
   lastMsg    No:65 - t:3F s:618148 d:0FA1FF
   protCmdDel 3
   protCmdPend 16 CMDs pending
   protCondBurst off
   protLastRcv 2018-03-04 13:10:55
   protNack   1 last_at:2018-03-04 13:00:33
   protSnd    4 last_at:2018-03-04 13:01:02
   protState  CMDs_pending
   rssi_at_cul868 lst:-52.5 cnt:70 avg:-53.66 min:-79 max:-40
   READINGS:
     2018-03-04 13:00:29   Activity        alive
     2018-03-04 13:00:33   CommandAccepted no
     2018-03-04 13:00:29   D-firmware      1.3
     2018-03-04 13:00:29   D-serialNr      OEQ1665558
     2018-03-03 19:40:42   R-pairCentral   set_0xF63018
     2018-03-04 13:09:24   battery         ok
     2018-03-04 13:09:24   batteryLevel    2.7
     2018-03-04 13:09:24   desired-temp    21.0
     2018-03-04 13:09:24   measured-temp   23.6
     2018-03-04 13:01:05   state           CMDs_pending
   cmdStack:
     ++A001F6301861814800040000000000
     ++A001F630186181480103
     ++A001F6301861814801040000000001
     ++A001F630186181480203
     ++A001F6301861814802040000000001
     ++A001F6301861814800040000000007
     ++A001F6301861814802040000000008
     ++A001F6301861814802040000000009
     ++A001F630186181480303
     ++A001F6301861814803040000000001
     ++A001F630186181480603
     ++A001F6301861814806040000000001
     ++A001F630186181480703
     ++A001F6301861814807040000000001
     ++A011F6301861814886042D
     ++A011F6301861814886022D
   helper:
     HM_CMDNR   101
     cSnd       ,01F6301861814800050000000000
     mId        00AD
     regLst     ,0
     rxType     6
     supp_Pair_Rep 0
     expert:
       def        1
       det        1
       raw        1
       tpl        0
     io:
       lstRecType 3F
       newChn     +618148,00,00,00
       nextSend   1520165455.09168
       nxtSndMcnt 65
       prefIO     
       restoredIO cul868
       rxt        0
       tgtDly     88
       vccu       
       lRcTm:
         cul868     722840
         tnms       820774049
       p:
         618148
         00
         00
         00
     mRssi:
       mNo        65
       io:
         cul868:
           -42.5
           -42.5
     prt:
       awake      0
       bErr       0
       brstWu     0
       sProc      2
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       prs        1
     rssi:
       at_cul868:
         avg        -53.6642857142857
         cnt        70
         lst        -52.5
         max        -40
         min        -79
     shRegW:
       07         02
     shadowReg:
       RegL_00.    02:01 0A:F6 0B:30 0C:18
Attributes:
   IODev      cul868
   actCycle   000:10
   actStatus  alive
   alias      thermostat_Wohnzimmer_HM_618148
   autoReadReg 5_readMissing
   expert     3_allReg+raw
   firmware   1.3
   model      HM-TC-IT-WM-W-EU
   msgRepeat  1
   room       Heizung
   serialNr   OEQ1665558
   subType    thermostat
   webCmd     getConfig:clear msgEvents
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.26
Beitrag von: noansi am 04 März 2018, 13:36:51
Hallo hackepeter,

ZitatAnschließend habe ich den Raspi neu gestartet und das Pairing nochmals mit erfolg durchgeführt.
Zitat2018-03-03 19:40:42   R-pairCentral   set_0xF63018
sagt, dass das Pairing nicht voll durchgelaufen ist.
Eventuell machst Du beim Pairing was falsch. z.B. fehlendes wiederholtes Knöpfchen drücken. Hängt vom device ab und ich kenne Deine Thermostaten nicht.

Außerdem hast Du nun häufig CCA Fehler, also nanoCUL meint, dass der Kanal belegt ist. Hast Du den nun ungünstig an einer Störquelle positioniert?

Zitatich das Thermostat im Wohnzimmer nochmals neu gepait, was zur konsequenz hatte, dass das FHEM Frontend nicht mehr erreichbar war.
Wie alt ist Deine FHEM Installation, bzw. wann zum letzten mal mit update aktualisiert? Eventuell hast Du noch veraltete Module, die zu merkwürdigem Verhalten führen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.26
Beitrag von: hackepeter am 04 März 2018, 18:53:25
Hallo noansi,

vielen Dank für die Antwort!

Sowohl das Betriebssystem als auch das FHEM ist auf dem neusten Stand.

Ich habe jetzt beide Thermostate richtig resettet (alle 3 Tasten drücken, danach Batterie´n einlegen und Tasten ca. 5sek gedrückt halten) und auch aus FHEM entfernt. Anschließend habe ich das HM_618148 neu gepairt. Zumindest das pairing scheint nun geklappt zuhaben:

Internals:
   CFGFN     
   DEF        618148
   IODev      cul868
   LASTInputDev cul868
   MSGCNT     265
   NAME       HM_618148
   NOTIFYDEV  global
   NR         118
   STATE      CMDs_pending
   TYPE       CUL_HM
   channel_01 HM_618148_Weather
   channel_02 HM_618148_Climate
   channel_03 HM_618148_WindowRec
   channel_06 HM_618148_remote
   channel_07 HM_618148_SwitchTr
   cul868_MSGCNT 265
   cul868_RAWMSG A0C2E847061814800000000F42B::-73:cul868:
   cul868_RSSI -73
   cul868_TIME 2018-03-04 18:40:04
   lastMsg    No:2E - t:70 s:618148 d:000000 00F42B
   protCmdDel 2
   protCmdPend 2 CMDs pending
   protCondBurst off
   protLastRcv 2018-03-04 18:40:04
   protResnd  3 last_at:2018-03-04 18:09:17
   protResndFail 1 last_at:2018-03-04 18:09:23
   protSnd    157 last_at:2018-03-04 18:10:21
   protState  CMDs_pending
   rssi_at_cul868 cnt:265 avg:-57.55 min:-76 lst:-73 max:-50
   READINGS:
     2018-03-04 16:49:10   Activity        alive
     2018-03-04 16:49:35   CommandAccepted yes
     2018-03-04 16:49:05   D-firmware      1.3
     2018-03-04 16:49:05   D-serialNr      OEQ1665558
     2018-03-04 16:49:36   PairedTo        0xF63018
     2018-03-04 16:49:10   R-burstRx       on
     2018-03-04 16:49:10   R-cyclicInfoMsg on
     2018-03-04 16:49:10   R-cyclicInfoMsgDis 0
     2018-03-04 16:49:10   R-pairCentral   0xF63018
     2018-03-04 16:49:36   RegL_00.          01:01 02:01 09:01 0A:F6 0B:30 0C:18 0F:00 11:00  12:16 16:01 18:00 19:00 1A:00 00:00
     2018-03-04 18:05:45   RegL_07.       
     2018-03-04 18:39:54   battery         ok
     2018-03-04 18:39:54   batteryLevel    2.7
     2018-03-04 18:39:54   desired-temp    20.0
     2018-03-04 18:39:54   measured-temp   24.4
     2018-03-04 18:10:25   state           CMDs_pending
     2018-03-04 16:50:06   time-request    -
   cmdStack:
     ++A011F6301861814886042C
     ++A011F6301861814886022C
   helper:
     HM_CMDNR   46
     PONtest    1
     cSnd       01F6301861814807040000000001,11F6301861814886042A
     mId        00AD
     regLst     ,0,1
     rxType     6
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       lstRecType 70
       newChn     +618148,00,00,00
       nextSend   1520185204.11522
       nxtSndMcnt 2E
       prefIO     
       restoredIO cul868
       rxt        0
       tgtDly     88
       vccu       
       lRcTm:
         cul868     17955308
         tnms       840523072
       p:
         618148
         00
         00
         00
     mRssi:
       mNo        2E
       io:
         cul868:
           -71
           -71
     prt:
       awake      0
       bErr       0
       brstWu     0
       sProc      2
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
     rssi:
       at_cul868:
         avg        -57.554716981132
         cnt        265
         lst        -73
         max        -50
         min        -76
     shRegW:
       07         02
     shadowReg:
Attributes:
   IODev      cul868
   actCycle   000:10
   actStatus  alive
   alias      Thermostat_Wohnz_HM_618148
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.3
   model      HM-TC-IT-WM-W-EU
   msgRepeat  1
   room       CUL_HM
   serialNr   OEQ1665558
   subType    thermostat
   webCmd     getConfig:clear msgEvents


Aber die eingestellte Temperatur wird leider noch immer nicht übernommen. Das Thermostat liegt auch seit 15min genau neben dem Cul.

Im Log sind jetzt auch andere Meldungen zu sehen. Könnten die von dem zweiten, nicht gepairten Thermostat kommen?
2018.03.04 16:49:05 2: CUL_HM Unknown device HM_618148 is now defined
2018.03.04 16:49:05 2: autocreate: define HM_618148 CUL_HM 618148
2018.03.04 16:49:05 2: autocreate: define FileLog_HM_618148 FileLog ./log/HM_618148-%Y.log HM_618148
2018.03.04 16:49:05 3: Device HM_618148 added to ActionDetector with 000:10 time
2018.03.04 16:49:05 3: CUL_HM pair: HM_618148 thermostat, model HM-TC-IT-WM-W-EU serialNr
2018.03.04 16:49:09 3: CUL_HM set HM_618148 getConfig
2018.03.04 16:49:10 3: Device HM_618148 added to ActionDetector with 000:10 time
2018.03.04 16:49:12 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 486) line 1.
2018.03.04 16:49:12 3: eval: setHzgVentilWohnz: warning in condition c01
2018.03.04 16:49:17 1: PERL WARNING: Argument "" isn't numeric in numeric gt (>) at (eval 499) line 1.
2018.03.04 16:49:17 3: eval: setHzgVentilWohnz: warning in condition c01
2018.03.04 16:49:17 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-04_00:00:00  to:2018-03-04_23:59:59
2018.03.04 16:49:17 4: FileLog_HM_618148 get: line 1, regexp:HM_618148_Weather.humidity\x3a, col:3, output lines:384
2018.03.04 16:49:17 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-04_00:00:00  to:2018-03-04_23:59:59
2018.03.04 16:49:18 4: FileLog_HM_618148 get: line 1, regexp:HM_618148.measured-temp\x3a, col:3, output lines:90
2018.03.04 16:49:18 4: FileLog_HM_618148 get: line 2, regexp:HM_618148.desired-temp\x3a, col:3, output lines:90
2018.03.04 16:49:34 3: CUL_HM set HM_618148 getConfig
2018.03.04 16:49:37 3: LogHist cul868:  276812 A F201 11328036 00 0A 66 8002 618148 F63018 00 -56dB
2018.03.04 16:49:37 3: LogHist cul868:  276833                 As 10 67 A001 F63018 618148 00040000000000
2018.03.04 16:49:37 3: LogHist cul868:  276897 A F203 11328216 02 10 67 A001 F63018 618148 00040000000000 _CCAdly:8 _dhmSt:180
2018.03.04 16:49:37 3: LogHist cul868:  276905 A F202 11328244 00 01 C0 _ping
2018.03.04 16:49:37 3: LogHist cul868:  277020 A F201 11328380 00 1A 67 A010 618148 F63018 020101020109010AF60B300C180F001100 -56dB
2018.03.04 16:49:37 3: LogHist cul868:  277141 A F203 11328476 01 0A 67 8002 F63018 618148 00 _CCAdly:4 _dhmSt:96
2018.03.04 16:49:37 3: LogHist cul868:  277278 A F201 11328636 00 16 68 8010 618148 F63018 0212161601180019001A000000 -56dB
2018.03.04 16:49:37 3: LogHist cul868:  277305                 As 0B 69 A001 F63018 618148 0103
2018.03.04 16:49:37 3: LogHist cul868:  277299 A F201 11328660 00 0E 04 8410 618148 F63018 0BA9050C00 -55.5dB
2018.03.04 16:49:37 3: LogHist cul868:  277428 A F203 11328756 01 0B 69 A001 F63018 618148 0103 _CCAdly:4 _dhmSt:96
2018.03.04 16:49:37 3: LogHist cul868:  277445 A F201 11328804 00 09 02 A03F 618148 F63018  -56dB
2018.03.04 16:49:37 3: LogHist cul868:  278100 A F203 11329440 01 0A 02 8002 F63018 618148 00 _CCAdly:4 _dhmSt:636
2018.03.04 16:49:37 3: LogHist cul868:  278210 A F203 11329544 01 0B 69 A001 F63018 618148 0103 _CCAdly:4 _dhmSt:740
2018.03.04 16:49:37 3: LogHist cul868:  278482 A F203 11329812 01 0B 69 A001 F63018 618148 0103 _CCAdly:4 _dhmSt:1008
2018.03.04 16:49:37 3: TSCUL_ParseTsHM: cul868 HM repeat failed to 618148/HM_618148:  278721 A F209 11330076 00 0B 69 A001 F63018 618148 0103 _sfail _noAnsw
2018.03.04 17:19:56 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-01_23:59:59  to:2018-03-04_23:59:59
2018.03.04 17:19:56 4: FileLog_HM_618148 get: line 1, regexp:HM_618148_Weather.humidity\x3a, col:3, output lines:1518
2018.03.04 17:19:56 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-01_23:59:59  to:2018-03-04_23:59:59
2018.03.04 17:19:56 4: FileLog_HM_618148 get: line 1, regexp:HM_618148.measured-temp\x3a, col:3, output lines:279
2018.03.04 17:19:57 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-01_23:59:59  to:2018-03-04_23:59:59
2018.03.04 17:19:57 4: FileLog_HM_618148 get: line 1, regexp:HM_618148.desired-temp\x3a, col:3, output lines:279
2018.03.04 18:04:41 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-04_00:00:00  to:2018-03-04_23:59:59
2018.03.04 18:04:41 4: FileLog_HM_618148 get: line 1, regexp:HM_618148_Weather.humidity\x3a, col:3, output lines:384
2018.03.04 18:04:41 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-04_00:00:00  to:2018-03-04_23:59:59
2018.03.04 18:04:41 4: FileLog_HM_618148 get: line 1, regexp:HM_618148.measured-temp\x3a, col:3, output lines:106
2018.03.04 18:04:41 4: FileLog_HM_618148 get: line 2, regexp:HM_618148.desired-temp\x3a, col:3, output lines:106
2018.03.04 18:07:16 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  218772 A F004 15986864 00 0A 28 8002 F63018 618148 00 _sfail
2018.03.04 18:07:17 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  219875 A F004 15987960 00 0A 28 8002 F63018 618148 00 _sfail
2018.03.04 18:07:18 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  220962 A F004 15989056 00 0A 5E 8002 F63018 618148 00 _sfail
2018.03.04 18:07:26 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  229160 A F004 15997252 00 0A 5E 8002 F63018 618148 00 _sfail
2018.03.04 18:07:27 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  230262 A F004 15998348 00 0A 28 8002 F63018 618148 00 _sfail
2018.03.04 18:07:28 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  231364 A F004 15999444 00 0A 5E 8002 F63018 618148 00 _sfail
2018.03.04 18:07:37 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  239673 A F004 16007752 00 0A 28 8002 F63018 618148 00 _sfail
2018.03.04 18:07:37 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-04_00:00:00  to:2018-03-04_23:59:59
2018.03.04 18:07:37 4: FileLog_HM_618148 get: line 1, regexp:HM_618148_Weather.humidity\x3a, col:3, output lines:384
2018.03.04 18:07:38 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-04_00:00:00  to:2018-03-04_23:59:59
2018.03.04 18:07:38 4: FileLog_HM_618148 get: line 1, regexp:HM_618148.measured-temp\x3a, col:3, output lines:107
2018.03.04 18:07:38 4: FileLog_HM_618148 get: line 2, regexp:HM_618148.desired-temp\x3a, col:3, output lines:107
2018.03.04 18:07:38 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  241018 A F004 16008848 00 0A 28 8002 F63018 618148 00 _sfail
2018.03.04 18:07:39 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  241863 A F004 16009944 00 0A 5E 8002 F63018 618148 00 _sfail
2018.03.04 18:07:43 3: CUL_HM set HM_618148_Climate desired-temp 21.0
2018.03.04 18:07:44 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  247438 A F004 16015524 00 09 29 B112 F63018 618148  _bst _sfail
2018.03.04 18:07:46 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  248701 A F004 16016784 00 09 29 B112 F63018 618148  _bst _sfail
2018.03.04 18:07:47 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  249963 A F004 16018044 00 09 29 B112 F63018 618148  _bst _sfail
2018.03.04 18:07:47 3: LogHist cul868:  231364 A F004 15999444 00 0A 5E 8002 F63018 618148 00 _sfail
2018.03.04 18:07:47 3: LogHist cul868:  233746 A F001 16002844 00 09 70 A03F 618153 0FA1FF  -75dB
2018.03.04 18:07:47 3: LogHist cul868:  237867 A F001 16006972 00 0C 34 865A 618153 000000 BCDF23 -75dB
2018.03.04 18:07:47 3: LogHist cul868:  238566 A F001 16007660 00 14 28 A010 618148 F63018 0400000000000709A70000 -58.5dB
2018.03.04 18:07:47 3: LogHist cul868:  238838 A F001 16007940 00 14 5E A010 618148 F63018 0400000000000709A70000 -58.5dB
2018.03.04 18:07:47 3: LogHist cul868:  239094 A F001 16008188 00 14 28 A010 618148 F63018 0400000000000709A70000 -58.5dB
2018.03.04 18:07:47 3: LogHist cul868:  239673 A F004 16007752 00 0A 28 8002 F63018 618148 00 _sfail
2018.03.04 18:07:47 3: LogHist cul868:  241018 A F004 16008848 00 0A 28 8002 F63018 618148 00 _sfail
2018.03.04 18:07:47 3: LogHist cul868:  241863 A F004 16009944 00 0A 5E 8002 F63018 618148 00 _sfail
2018.03.04 18:07:47 3: LogHist cul868:  246407                 As 09 29 B112 F63018 618148
2018.03.04 18:07:47 3: LogHist cul868:  247438 A F004 16015524 00 09 29 B112 F63018 618148  _bst _sfail
2018.03.04 18:07:47 3: LogHist cul868:  248701 A F004 16016784 00 09 29 B112 F63018 618148  _bst _sfail
2018.03.04 18:07:47 3: LogHist cul868:  248732 A F001 16017840 00 09 71 A03F 618153 0FA1FF  -76dB
2018.03.04 18:07:47 3: LogHist cul868:  249963 A F004 16018044 00 09 29 B112 F63018 618148  _bst _sfail
2018.03.04 18:07:47 3: TSCUL_ParseTsHM: cul868 HM repeat failed to 618148/HM_618148:  250202 A F009 16019304 00 09 29 B112 F63018 618148  _bst _sfail _noAnsw
2018.03.04 18:08:46 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-04_00:00:00  to:2018-03-04_23:59:59
2018.03.04 18:08:46 4: FileLog_HM_618148 get: line 1, regexp:HM_618148_Weather.humidity\x3a, col:3, output lines:384
2018.03.04 18:08:46 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-04_00:00:00  to:2018-03-04_23:59:59
2018.03.04 18:08:47 4: FileLog_HM_618148 get: line 1, regexp:HM_618148.measured-temp\x3a, col:3, output lines:107
2018.03.04 18:08:47 4: FileLog_HM_618148 get: line 2, regexp:HM_618148.desired-temp\x3a, col:3, output lines:107
2018.03.04 18:09:12 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  335167 A F004 16103236 00 0A 5E 8002 F63018 618148 00 _sfail
2018.03.04 18:09:13 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  336271 A F004 16104332 00 0A 28 8002 F63018 618148 00 _sfail
2018.03.04 18:09:14 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  337357 A F004 16105428 00 0A 5E 8002 F63018 618148 00 _sfail
2018.03.04 18:09:15 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  338458 A F004 16106524 00 0C 5F A011 F63018 618148 86042A _sfail
2018.03.04 18:09:17 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  339721 A F004 16107784 00 0C 5F A011 F63018 618148 86042A _sfail
2018.03.04 18:09:18 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  340983 A F004 16109044 00 0C 5F A011 F63018 618148 86042A _sfail
2018.03.04 18:09:18 3: LogHist cul868:  334060 A F001 16103144 00 14 5E A010 618148 F63018 0400000000000709A70000 -56.5dB
2018.03.04 18:09:18 3: LogHist cul868:  334194                 As 0C 5F A011 F63018 618148 86042A
2018.03.04 18:09:18 3: LogHist cul868:  334347 A F001 16103428 00 14 28 A010 618148 F63018 0400000000000709A70000 -56dB
2018.03.04 18:09:18 3: LogHist cul868:  334588 A F001 16103672 00 14 5E A010 618148 F63018 0400000000000709A70000 -56.5dB
2018.03.04 18:09:18 3: LogHist cul868:  335167 A F004 16103236 00 0A 5E 8002 F63018 618148 00 _sfail
2018.03.04 18:09:18 3: LogHist cul868:  335189 A F002 16104256 00 01 C0 _ping
2018.03.04 18:09:18 3: LogHist cul868:  336271 A F004 16104332 00 0A 28 8002 F63018 618148 00 _sfail
2018.03.04 18:09:18 3: LogHist cul868:  336276 A F002 16105352 00 01 C0 _ping
2018.03.04 18:09:18 3: LogHist cul868:  337357 A F004 16105428 00 0A 5E 8002 F63018 618148 00 _sfail
2018.03.04 18:09:18 3: LogHist cul868:  337378 A F002 16106448 00 01 C0 _ping
2018.03.04 18:09:18 3: LogHist cul868:  338458 A F004 16106524 00 0C 5F A011 F63018 618148 86042A _sfail
2018.03.04 18:09:18 3: LogHist cul868:  339659                 As 0C 5F B011 F63018 618148 86042A
2018.03.04 18:09:18 3: LogHist cul868:  339721 A F004 16107784 00 0C 5F A011 F63018 618148 86042A _sfail
2018.03.04 18:09:18 3: LogHist cul868:  340983 A F004 16109044 00 0C 5F A011 F63018 618148 86042A _sfail
2018.03.04 18:09:18 3: TSCUL_ParseTsHM: cul868 HM repeat failed to 618148/HM_618148:  341223 A F009 16110304 00 0C 5F A011 F63018 618148 86042A _sfail _noAnsw
2018.03.04 18:09:19 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  342245 A F004 16110308 00 0C 5F B011 F63018 618148 86042A _bst _sfail
2018.03.04 18:09:20 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  343508 A F004 16111568 00 0C 5F B011 F63018 618148 86042A _bst _sfail
2018.03.04 18:09:22 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  344972 A F004 16112828 00 0C 5F B011 F63018 618148 86042A _bst _sfail
2018.03.04 18:09:22 3: LogHist cul868:  335167 A F004 16103236 00 0A 5E 8002 F63018 618148 00 _sfail
2018.03.04 18:09:22 3: LogHist cul868:  335189 A F002 16104256 00 01 C0 _ping
2018.03.04 18:09:22 3: LogHist cul868:  336271 A F004 16104332 00 0A 28 8002 F63018 618148 00 _sfail
2018.03.04 18:09:22 3: LogHist cul868:  336276 A F002 16105352 00 01 C0 _ping
2018.03.04 18:09:22 3: LogHist cul868:  337357 A F004 16105428 00 0A 5E 8002 F63018 618148 00 _sfail
2018.03.04 18:09:22 3: LogHist cul868:  337378 A F002 16106448 00 01 C0 _ping
2018.03.04 18:09:22 3: LogHist cul868:  338458 A F004 16106524 00 0C 5F A011 F63018 618148 86042A _sfail
2018.03.04 18:09:22 3: LogHist cul868:  339659                 As 0C 5F B011 F63018 618148 86042A
2018.03.04 18:09:22 3: LogHist cul868:  339721 A F004 16107784 00 0C 5F A011 F63018 618148 86042A _sfail
2018.03.04 18:09:22 3: LogHist cul868:  340983 A F004 16109044 00 0C 5F A011 F63018 618148 86042A _sfail
2018.03.04 18:09:22 3: LogHist cul868:  341223 A F009 16110304 00 0C 5F A011 F63018 618148 86042A _sfail _noAnsw
2018.03.04 18:09:22 3: LogHist cul868:  342245 A F004 16110308 00 0C 5F B011 F63018 618148 86042A _bst _sfail
2018.03.04 18:09:22 3: LogHist cul868:  343508 A F004 16111568 00 0C 5F B011 F63018 618148 86042A _bst _sfail
2018.03.04 18:09:22 3: LogHist cul868:  344972 A F004 16112828 00 0C 5F B011 F63018 618148 86042A _bst _sfail
2018.03.04 18:09:22 3: TSCUL_ParseTsHM: cul868 HM repeat failed to 618148/HM_618148:  345010 A F009 16114088 00 0C 5F B011 F63018 618148 86042A _bst _sfail _noAnsw
2018.03.04 18:10:21 3: CUL_HM set HM_618148_Climate desired-temp 22.0
2018.03.04 18:10:22 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  404945 A F004 16173000 00 09 23 B112 F63018 618148  _bst _sfail
2018.03.04 18:10:23 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  406207 A F004 16174260 00 09 23 B112 F63018 618148  _bst _sfail
2018.03.04 18:10:24 3: TSCUL_ParseTsHM: cul868 HM CCA channel busy error to 618148/HM_618148:  407470 A F004 16175520 00 09 23 B112 F63018 618148  _bst _sfail
2018.03.04 18:10:25 3: LogHist cul868:  344972 A F004 16112828 00 0C 5F B011 F63018 618148 86042A _bst _sfail
2018.03.04 18:10:25 3: LogHist cul868:  345010 A F009 16114088 00 0C 5F B011 F63018 618148 86042A _bst _sfail _noAnsw
2018.03.04 18:10:25 3: LogHist cul868:  345058 A F001 16114132 00 0C 22 865A 618148 000000 A10933 -55.5dB
2018.03.04 18:10:25 3: LogHist cul868:  353735 A F001 16122820 00 09 78 A03F 618153 0FA1FF  -75.5dB
2018.03.04 18:10:25 3: LogHist cul868:  355058 A F001 16124132 00 0E 29 8410 618148 000000 0BA1094C40 -56dB
2018.03.04 18:10:25 3: LogHist cul868:  365045 A F001 16134128 00 0C 22 8470 618148 000000 010B2A -56dB
2018.03.04 18:10:25 3: LogHist cul868:  368738 A F001 16137820 00 09 79 A03F 618153 0FA1FF  -76dB
2018.03.04 18:10:25 3: LogHist cul868:  383742 A F001 16152816 00 09 7A A03F 618153 0FA1FF  -75.5dB
2018.03.04 18:10:25 3: LogHist cul868:  398377 A F001 16167440 00 0C 35 865A 618153 000000 BCDF23 -75.5dB
2018.03.04 18:10:25 3: LogHist cul868:  398745 A F001 16167812 00 09 7B A03F 618153 0FA1FF  -76.5dB
2018.03.04 18:10:25 3: LogHist cul868:  403916                 As 09 23 B112 F63018 618148
2018.03.04 18:10:25 3: LogHist cul868:  404945 A F004 16173000 00 09 23 B112 F63018 618148  _bst _sfail
2018.03.04 18:10:25 3: LogHist cul868:  406207 A F004 16174260 00 09 23 B112 F63018 618148  _bst _sfail
2018.03.04 18:10:25 3: LogHist cul868:  407470 A F004 16175520 00 09 23 B112 F63018 618148  _bst _sfail
2018.03.04 18:10:25 3: TSCUL_ParseTsHM: cul868 HM repeat failed to 618148/HM_618148:  407709 A F009 16176780 00 09 23 B112 F63018 618148  _bst _sfail _noAnsw
2018.03.04 18:16:30 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-04_00:00:00  to:2018-03-04_23:59:59
2018.03.04 18:16:30 4: FileLog_HM_618148 get: line 1, regexp:HM_618148_Weather.humidity\x3a, col:3, output lines:384
2018.03.04 18:16:30 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-04_00:00:00  to:2018-03-04_23:59:59
2018.03.04 18:16:31 4: FileLog_HM_618148 get: line 1, regexp:HM_618148.measured-temp\x3a, col:3, output lines:110
2018.03.04 18:16:31 4: FileLog_HM_618148 get: line 2, regexp:HM_618148.desired-temp\x3a, col:3, output lines:110
2018.03.04 18:17:01 3: cul868: Unknown code A0996A03F6181530FA1FF::-75.5:cul868:, help me!
2018.03.04 18:17:03 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-04_00:00:00  to:2018-03-04_23:59:59
2018.03.04 18:17:03 4: FileLog_HM_618148 get: line 1, regexp:HM_618148_Weather.humidity\x3a, col:3, output lines:384
2018.03.04 18:17:03 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-04_00:00:00  to:2018-03-04_23:59:59
2018.03.04 18:17:03 4: FileLog_HM_618148 get: line 1, regexp:HM_618148.measured-temp\x3a, col:3, output lines:111
2018.03.04 18:17:03 4: FileLog_HM_618148 get: line 2, regexp:HM_618148.desired-temp\x3a, col:3, output lines:111
2018.03.04 18:17:16 3: cul868: Unknown code A0997A03F6181530FA1FF::-72:cul868:, help me!
2018.03.04 18:17:31 3: cul868: Unknown code A0998A03F6181530FA1FF::-64:cul868:, help me!
2018.03.04 18:17:46 3: cul868: Unknown code A0999A03F6181530FA1FF::-61:cul868:, help me!
2018.03.04 18:18:08 3: cul868: Unknown code A0D00841061815300000006000000::-63:cul868:, help me!
2018.03.04 18:18:23 3: cul868: Unknown code A0C02865A618153000000A8E433::-60:cul868:, help me!
2018.03.04 18:18:43 3: cul868: Unknown code A0C02847061815300000000E433::-71:cul868:, help me!
2018.03.04 18:18:49 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-04_00:00:00  to:2018-03-04_23:59:59
2018.03.04 18:18:49 4: FileLog_HM_618148 get: line 1, regexp:HM_618148_Weather.humidity\x3a, col:3, output lines:384
2018.03.04 18:18:49 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-04_00:00:00  to:2018-03-04_23:59:59
2018.03.04 18:18:49 4: FileLog_HM_618148 get: line 1, regexp:HM_618148.measured-temp\x3a, col:3, output lines:111
2018.03.04 18:18:49 4: FileLog_HM_618148 get: line 2, regexp:HM_618148.desired-temp\x3a, col:3, output lines:111
2018.03.04 18:18:55 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-04_00:00:00  to:2018-03-04_23:59:59
2018.03.04 18:18:55 4: FileLog_HM_618148 get: line 1, regexp:HM_618148_Weather.humidity\x3a, col:3, output lines:384
2018.03.04 18:18:55 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-04_00:00:00  to:2018-03-04_23:59:59
2018.03.04 18:18:56 4: FileLog_HM_618148 get: line 1, regexp:HM_618148.measured-temp\x3a, col:3, output lines:111
2018.03.04 18:18:56 4: FileLog_HM_618148 get: line 2, regexp:HM_618148.desired-temp\x3a, col:3, output lines:111
2018.03.04 18:18:57 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-04_00:00:00  to:2018-03-04_23:59:59
2018.03.04 18:18:57 4: FileLog_HM_618148 get: line 1, regexp:HM_618148_Weather.humidity\x3a, col:3, output lines:384
2018.03.04 18:18:57 4: FileLog_HM_618148 get: Input file ./log/HM_618148-2018.log, from:2018-03-04_00:00:00  to:2018-03-04_23:59:59
2018.03.04 18:18:58 4: FileLog_HM_618148 get: line 1, regexp:HM_618148.measured-temp\x3a, col:3, output lines:111
2018.03.04 18:18:58 4: FileLog_HM_618148 get: line 2, regexp:HM_618148.desired-temp\x3a, col:3, output lines:111
2018.03.04 18:19:10 3: Device 618153 removed from ActionDetector
2018.03.04 18:21:20 3: cul868: Unknown code A0C03865A618153000000BCF02B::-75.5:cul868:, help me!
2018.03.04 18:21:40 3: cul868: Unknown code A0C03847061815300000000F02B::-79.5:cul868:, help me!
2018.03.04 18:24:04 3: cul868: Unknown code A0C04865A618153000000BCF02B::-81.5:cul868:, help me!
2018.03.04 18:24:24 3: cul868: Unknown code A0C04847061815300000000F02B::-71.5:cul868:, help me!
2018.03.04 18:26:32 3: cul868: Unknown code A0C05865A618153000000BCF12B::-67.5:cul868:, help me!
2018.03.04 18:26:52 3: cul868: Unknown code A0C05847061815300000000F12B::-68:cul868:, help me!
2018.03.04 18:28:47 3: cul868: Unknown code A0C06865A618153000000BCF12C::-68:cul868:, help me!
2018.03.04 18:29:07 3: cul868: Unknown code A0C06847061815300000000F12A::-68.5:cul868:, help me!
2018.03.04 18:30:47 3: cul868: Unknown code A0C07865A618153000000BCF02A::-69.5:cul868:, help me!
2018.03.04 18:31:07 3: cul868: Unknown code A0C07847061815300000000EF2A::-69.5:cul868:, help me!
2018.03.04 18:33:36 3: cul868: Unknown code A0C08865A618153000000BCEE2A::-67:cul868:, help me!
2018.03.04 18:33:56 3: cul868: Unknown code A0C08847061815300000000EE2A::-69.5:cul868:, help me!
2018.03.04 18:36:11 3: cul868: Unknown code A0C09865A618153000000BCEC2B::-69:cul868:, help me!
2018.03.04 18:36:31 3: cul868: Unknown code A0C09847061815300000000EC2B::-68.5:cul868:, help me!
2018.03.04 18:38:32 3: cul868: Unknown code A0C0A865A618153000000BCEC2B::-69:cul868:, help me!
2018.03.04 18:38:52 3: cul868: Unknown code A0C0A847061815300000000EC2B::-72:cul868:, help me!
2018.03.04 18:40:38 3: cul868: Unknown code A0C0B865A618153000000BCEB2A::-74.5:cul868:, help me!
2018.03.04 18:40:58 3: cul868: Unknown code A0C0B847061815300000000EB2A::-74.5:cul868:, help me!
2018.03.04 18:43:34 3: cul868: Unknown code A0C0C865A618153000000BCEB2B::-73.5:cul868:, help me!
2018.03.04 18:43:54 3: cul868: Unknown code A0C0C847061815300000000EB2B::-74.5:cul868:, help me!
2018.03.04 18:46:16 3: cul868: Unknown code A0C0D865A618153000000BCEB2B::-73.5:cul868:, help me!
2018.03.04 18:46:36 3: cul868: Unknown code A0C0D847061815300000000EB2B::-72.5:cul868:, help me!
2018.03.04 18:48:43 3: cul868: Unknown code A0C0E865A618153000000BCEB2B::-73:cul868:, help me!
2018.03.04 18:49:03 3: cul868: Unknown code A0C0E847061815300000000EB2B::-74:cul868:, help me!


Kann es sein, dass es an dem selbstbauCul liegt? Falls ja, gibt es eine Bauteilempfehlung? Dann würde ich mal einen neuen bauen.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.26
Beitrag von: noansi am 04 März 2018, 19:44:37
Hallo hackepeter,

Zitat2018-03-04 16:49:36   PairedTo        0xF63018
ja, das sieht schon besser aus.

ZitatDas Thermostat liegt auch seit 15min genau neben dem Cul.
Dann nimm mal 1m Abstand.

ZitatTSCUL_ParseTsHM: cul868 HM CCA channel busy error to
Das ist derzeit Dein Hauptproblem. Der nanoCUL sendet meistens nicht wegen detektierter Kanalbelegung.
Entweder sendet oder rauscht etwas in der Nähe des nanoCULs (Rechner, Monitore, Netzteile ...) oder Du hast vielleicht ein Antennenproblem, wie hier https://forum.fhem.de/index.php/topic,24436.msg762593.html#msg762593 (https://forum.fhem.de/index.php/topic,24436.msg762593.html#msg762593). Oder es ist schlicht der Thermostat, der zu dicht daneben liegt.

Und das ist noch seltsam, Wechsel des MsgCounters einfach so. Aber vielleicht verschwindet das mit größerem Abstand.
2018.03.04 18:07:47 3: LogHist cul868:  238566 A F001 16007660 00 14 28 A010 618148 F63018 0400000000000709A70000 -58.5dB
2018.03.04 18:07:47 3: LogHist cul868:  238838 A F001 16007940 00 14 5E A010 618148 F63018 0400000000000709A70000 -58.5dB



cul868: Unknown code A0C03865A618153000000BCF02B::-75.5:cul868:, help me!
Die kommen von Deinem anderen Thermostaten.

Gruß, Ansgar.

Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN V0.26
Beitrag von: hackepeter am 04 März 2018, 21:16:02
Hallo noansi,

jetzt schulde ich Dir einen Kasten Bier.

Der Tipp mit der Antenne war Gold wert!

http://rother-it.de/files/ArtikelBilder/Selbstbau_Cul/cul_antenne.JPG (http://rother-it.de/files/ArtikelBilder/Selbstbau_Cul/cul_antenne.JPG)

Ich hatte das Funkmudul zur Stabilisation vorne mit zwei "Beinchen" festgelötet. Anscheinend hat das gestört.

Nun funktioniert alles bestens! Vielen Dank!
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.26
Beitrag von: Gast45 am 11 März 2018, 14:20:01
Wenn ich das hier richtig verstehe, dann wird die TS-CUL-FW parallel zu der regulären CUL-FWgepflegt? Zudem mit erheblichen manuellen Pflegeaufwand in der FHEM-Installation?!

Ist es geplant die Timestamp-Version fest in die "reguläre" CUL-FW einfließen zu lassen?

Aktuell betreibe ich einen nanoCUL mit der normalen CUL-FW V1.67  für Homematic. Bisher kann ich aber noch keine gravierenden Probleme erkenne, so dass ich noch nicht erkennen kann, ob es sinnvoll ist auf TS umzusteigen. Vielleicht ist meine Installation mit insgesamt 6 Devices auch noch klein genug?
Hoffentlich auch noch, wenn ich bal AES einschalte?

Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.26
Beitrag von: noansi am 11 März 2018, 14:58:47
ZitatWenn ich das hier richtig verstehe, dann wird die TS-CUL-FW parallel zu der regulären CUL-FWgepflegt?/quote]
So ist es.

ZitatIst es geplant die Timestamp-Version fest in die reguläre CUL-FW einfließen zu lassen?
Nein, zu viel Aufwand für Rudolf.

ZitatVielleicht ist meine Installation mit insgesamt 6 Devices auch noch klein genug?
Das hängt auch von der Art der devices ab und auch welche sonstigen FHEM-Module eingesetzt werden, sowie an der Systemauslastung.

ZitatHoffentlich auch noch, wenn ich bal AES einschalte?
Versuch macht klug...
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.26
Beitrag von: Gast45 am 11 März 2018, 20:15:49
Danke für die Rückmeldung.

Integration in "reguläre" CUL-FW:
ZitatNein, zu viel Aufwand für Rudolf.

Schade, weil es ja doch scheinbar erheblichen manuellen Aufwand bedeutet. fhem.cfg manuell editieren?! Zudem man muss bei Updates immer darauf achten, dass die TS-Module noch vorhanden sind. Oder man setzt einen Schreibschutz drauf.

ZitatDas hängt auch von der Art der devices ab und auch welche sonstigen FHEM-Module eingesetzt werden, sowie an der Systemauslastung.

Fensterkontakte und Sirene. Ob später auch noch Rollladen- und/oder Lichtschalter dazu kommen steht noch nicht fest.

"reguläre" CUL-FW mit AES:
ZitatVersuch macht klug...

sehe ich auch so..... werde ich bald mal angehen
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.26
Beitrag von: MadMax-FHEM am 11 März 2018, 21:06:43
Zitat von: Gast45 am 11 März 2018, 20:15:49
Integration in "reguläre" CUL-FW:
Schade, weil es ja doch scheinbar erheblichen manuellen Aufwand bedeutet. fhem.cfg manuell editieren?! Zudem man muss bei Updates immer darauf achten, dass die TS-Module noch vorhanden sind. Oder man setzt einen Schreibschutz drauf.

fhem.cfg editieren nur einmalig (ginge auch ohne direktes editieren) und excludeFromUpdate setzen ginge auch...

Und ja ab und an schauen, ob es neue TS-Module gibt und manuell einspielen...
...ja nicht so schön...
...und viel Mühe für Ansgar hier am Ball zu bleiben...

Kurz, da Handy...

Gruß, Joachim
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.26
Beitrag von: noansi am 11 März 2018, 21:21:35
Zitatscheinbar erheblichen manuellen Aufwand bedeutet. fhem.cfg manuell editieren?!
Hmm, erheblich definiere ich massiv anders.  ;)
Die, die es gemacht haben, sehen das wohl inzwischen ähnlich.

ZitatZudem man muss bei Updates immer darauf achten, dass die TS-Module noch vorhanden sind.
Die speziellen werden normalerweise nicht von Update gelöscht. Nur die optionalen.

Außerdem gibt es noch den Hinweis auf "attr global exclude_from_update", wenn schon die fhem.cfg angepackt wird.

ZitatFensterkontakte und Sirene
Mit AES und Standard Firmware und AES viel Glück!!!
Nicht umsonst verweist auch Martin im HM Forum auf die tsculfw Firmware, wenn CUL genutzt werden soll.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.26
Beitrag von: hjgode am 12 April 2018, 22:46:51
Hallo noansi

hast Du schon mal über die Verwendung eines Repository (zB GitHub oder SourceForge) zur Bereitstellung der hex Daten, Informationen und Hinweise nachgedacht? In diesem Thread sucht man sich ja tot wenn man die aktuelle Version sucht.

Wenn Du dann noch den Quellcode über das Repo bereitstellst, musst Du auch nicht alleine weiterentwickeln.

Gruss

Josef
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.26
Beitrag von: noansi am 13 April 2018, 06:32:19
Hallo Josef,

ZitatIn diesem Thread sucht man sich ja tot wenn man die aktuelle Version sucht.
Im ersten Beitrag steht direkt der link zum Ziel.

ZitatWenn Du dann noch den Quellcode über das Repo bereitstellst, musst Du auch nicht alleine weiterentwickeln.
Was möchtest Du denn am Code ändern?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.26
Beitrag von: LT@Home am 14 April 2018, 07:57:42
Ich hab nen CUL mit einer alten 1.66 am laufen und will auf diese hier umflashen.

per dfu-programmer bekomme ich:

root@amenophis:/home/lutz/Downloads# dfu-programmer atmega32u4 erase
dfu-programmer: no device present.


wobei ich mir nicht (mehr) sicher bin, ob der typ stimmt - mein l. flash liegt ewig zurück...

lsusb liefert:



root@amenophis:/home/lutz/Downloads# lsusb -vv | more

Bus 002 Device 004: ID 03eb:204b Atmel Corp. LUFA USB to Serial Adapter Project
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            2 Communications
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x03eb Atmel Corp.
  idProduct          0x204b LUFA USB to Serial Adapter Project
  bcdDevice            0.00
  iManufacturer           1 busware.de
  iProduct                2 CUL868
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           67
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      1 AT-commands (v.25ter)
      iInterface              0
      CDC Header:
        bcdCDC               10.01
      CDC Call Management:
        bmCapabilities       0x03
          call management
          use DataInterface
        bDataInterface          1
      CDC ACM:
        bmCapabilities       0x06
          sends break
          line coding and serial state
      CDC Union:
        bMasterInterface        0
        bSlaveInterface         1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval             255
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
Device Status:     0x0000
  (Bus Powered)


den reset-button an der Unterseite habe ich schon mal gedrückt...
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.26
Beitrag von: noansi am 14 April 2018, 09:03:53
Hallo LT@Home,

der CUL ist nicht im Bootloader.
Du musst den Bootloadertaster gedrückt halten und dabei CUL in den USB Port einstecken.

Da Du den CUL in FHEM vermutlich schon nutzt, kannst aber auch TSCULflash nutzen.
- TSCUL_V3.hex in den FHEM/firmware Ordner kopieren
- 98_TSCULflash.pm, sowie00_TSCUL.pm und DevIoTS.pm in den FHEM Ordner kopieren
- in FHEM dann
TSCULflash <CULName> TSCUL_V3

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.26
Beitrag von: Bytechanger am 14 April 2018, 11:21:23
Wer keine Lust zu drücken hat, nicht dran kommt, oder der Knopf defekt ist, der kann -sofern der Stick in FHEM erkannt und eingerichtet ist- mit

set CUL0 raw B01

den Stick ebenfalls in den Flash-Modus versetzen!
So mache ich es immer.

Greets

Byte
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.26
Beitrag von: LT@Home am 15 April 2018, 11:47:22
Zitat von: noansi am 14 April 2018, 09:03:53
Hallo LT@Home,

der CUL ist nicht im Bootloader.
Du musst den Bootloadertaster gedrückt halten und dabei CUL in den USB Port einstecken.

Da Du den CUL in FHEM vermutlich schon nutzt, kannst aber auch TSCULflash nutzen.
- TSCUL_V3.hex in den FHEM/firmware Ordner kopieren
- 98_TSCULflash.pm in den FHEM Ordner kopieren
- in FHEM dann
TSCULflash <CULName> TSCUL_V3

Gruß, Ansgar.

hmm - fhem verabschiedet sich - seine letzten Worte im Log sind:


2018.04.15 11:44:03 5: CUL 585D68 dly:70ms
2018.04.15 11:44:03 5: SW: As0928A112070567585D68
2018.04.15 11:44:36 0: TSCULflash: CUL1 is not of TSCUL type
Undefined subroutine &main::TSCUL_SimpleWrite called at ./FHEM/98_TSCULflash.pm line 524.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.26
Beitrag von: noansi am 15 April 2018, 13:16:12
Hallo LT@Home,

ZitatUndefined subroutine &main::TSCUL_SimpleWrite called at ./FHEM/98_TSCULflash.pm line 524.
Ja, sorry, ich vergaß die Abhängigkeiten.
00_TSCUL.pm und DevIoTS.pm müssen auch noch in den FHEM Ordner kopiert werden.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.26
Beitrag von: hjgode am 18 April 2018, 07:03:38
Hallo Ansgar

Als ich das letzte Mal die aktuelle FW gesucht habe war das nicht so. Über ein Repository wäre das einfacher aktuell zu halten.

Man könnte über ein Repo auch das Update für alle vereinfachen.

War nur so ein Gedanke...

~Josef

Zitat von: noansi am 13 April 2018, 06:32:19
Hallo Josef,
Im ersten Beitrag steht direkt der link zum Ziel.
Was möchtest Du denn am Code ändern?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.26
Beitrag von: LT@Home am 22 April 2018, 11:06:02
Ich habe inzwischen per dfu-programmer geupdated. Jetzt bekomme ich im Log:


2018.04.22 11:01:52 3: Opening CUL1 device /dev/serial/by-id/usb-busware.de_CUL868_868000-if00
2018.04.22 11:01:52 3: Setting CUL1 serial parameters to 9600,8,N,1
2018.04.22 11:01:52 3: CUL1: Possible commands: ABCFGJKRUVWXYeilmtx
2018.04.22 11:01:52 2: Setting CUL1 fhtid from ? (T01 is unknown) Use one of A B C F G J K R U V W X Y e i l m t x to 0000
2018.04.22 11:01:52 3: CUL1 device opened
2018.04.22 11:01:52 2: Switched CUL1 rfmode to HomeMatic


und bei nem Statusrequest z.B.:

2018.04.22 11:03:19 3: CUL_HM set AU.GA.SC.4fach_01 statusRequest
2018.04.22 11:03:19 5: CUL1 sending As0B09A00107056757E0D9010E
2018.04.22 11:03:19 5: SW: As0B09A00107056757E0D9010E
2018.04.22 11:03:19 5: CUL/RAW: /A

2018.04.22 11:03:19 4: CUL_Parse: CUL1 A     
2018.04.22 11:03:19 5: CUL1: dispatch A
2018.04.22 11:03:20 3: CUL1: Unknown code A, help me!


Irgendwas ist schief...
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.26
Beitrag von: noansi am 22 April 2018, 13:35:53
Hallo LT@Home,

ja, in Deiner fhem.cfg muss es für Deinen HM CUL lauten

define CUL1 TSCUL /dev/serial/by-id/usb-busware.de_CUL868_868000-if00@12000000 0000

statt

define CUL1 CUL ...

damit Du auch das 00_TSCUL.pm Modul verwendest, wie es sein soll.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.26
Beitrag von: LT@Home am 24 April 2018, 06:23:54
Macht Sinn - und geht. Danke.

Sehr gesprächig das log jetzt - pairing mit einem Bewegungsmelder hat 1a funktioniert
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.26
Beitrag von: Jasimo am 23 Juli 2018, 15:27:48
Hallo,

hatte gerade die folgende Meldung im Log:
2018.07.23 14:44:52 2: TSCUL_ReceiveDelayed: CUL1  C 00=07 01=2E 02=01 03=42 04=E9 05=CA 06=31 07=0C 08=45 09=00 0A=00 0B=06 0C=F3 0D=21 0E=65 0F=6A 10=C8 11=93 12=03 13=22 14=F8 15=34 16=07 17=3C 18=18 19=16 1A=6C 1B=43 1C=67 1D=91 1E=87 1F=6B 20=F8 21=56 22=10 23=AC 24=2B 25=17 26=11 27=41 28=00 29=59 2A=7F 2B=3E 2C=81 2D=35 2E=0B 2F=00 30=00 31=14 32=F2 33=1A 34=C4 35=0D 36=00 37=00 38=2B 39=CC 3A=00 3B=41 3C=00 3D=00
2018.07.23 14:53:48 3: CUL_HM set TE_Licht on
2018.07.23 14:53:49 3: TSCUL_ParseTsHM: CUL1 HM CCA channel busy error to 5F6A36/TE_Licht:  260854 A F004 06277748 00 0E 22 A011 471147 5F6A36 0201C80000 _sfail
2018.07.23 14:53:58 3: CUL_HM set TE_Licht off

Nutze die tsculfw 0.26, hat da jemand eine Idee.
Gruß
Jan
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.26
Beitrag von: davedeluxe am 26 Juli 2018, 13:08:51
Hallo Zusammen,
da ich grade auf ne Intel NUC mit Proxmox und darauf FHEM in einem LXC - Container umgestellt habe, habe ich aktuell ein paar Probleme da ich meinen nanoCUL nicht zum Container durchschleifen kann.
Nun zur Frage, gibt es eine Möglichkeit diese Firmware auf einem WLAN- oder LAN-fähigen Gerät laufen zu lassen anstatt auf einem Arduino Nano?
Alternativ dachte ich an den originalen HM LAN-Adapter aber den gibt es leider nicht mehr.

Grüße Dave
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.26
Beitrag von: noansi am 26 Juli 2018, 21:32:22
Hallo Jan,

um 14:44:52 war wohl wenig los mit Empfang und daher wurden mal die Transceiver Register ausgelesen.

Um 14:53:49 war wohl auf 868MHz bereits ein anderes Gerät sendend bzw. der Kanal belegt und dann sendet die Firmware nicht. Kann passieren.
Wenn es mal zum Dauerzustand wird, dann hilft nur den Störer ausfindig zu machen, siehe auch dieser Thread: https://forum.fhem.de/index.php/topic,89162.0.html (https://forum.fhem.de/index.php/topic,89162.0.html)

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.26
Beitrag von: noansi am 26 Juli 2018, 21:48:03
Hallo Dave,

auf einem CUNO2 würde sie laufen.
Auf CUNO oder CUN vermutlich auch, aber ich habe es mit denen mangels Hardware nie testen können.
Die drei gibt es nur nicht mehr neu bei Busware.

Auf einem CC1101 868MHz PIGATOR Modul z.B. an einem CUNX würde sie laufen, jedoch nicht auf CUNX selbst.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.26
Beitrag von: davedeluxe am 27 Juli 2018, 08:09:09
Hi Ansgar,
danke für die Antwort, das klingt doch vielversprechend.

Ich habe mir das ganze mal angesehen, meinst du es läuft auch auf einem Network PIM Connector mit:
Pigator Modul: CC1101 868MHz RP-SMA-Anschluss ?
Oder sogar dem Busser? mit dem o.g. Pigator Modul ?


Ansonsten wäre das der von dir beschriebene CUNX? :
http://shop.busware.de/product_info.php/products_id/47
Brauch ich da noch etwas oder ist das alles an HArdware?

Grüße Dave
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.26
Beitrag von: Horti am 27 Juli 2018, 15:48:51
Hi,

bevor Du Geld und Zeit investierst, um die TSCUL-Firmware übers Netz laufen zu lassen, wäre nicht ein MOD-RPI-PCB über LAN/WLAN nicht eine Alternative?

Entweder fertig gelötet hier im Forum (suche nach WLAN der LAN Homematic Gateway) oder ansonsten aber relativ einfach selber zusammenzustricken. Kostet natürlich auch Zeit und Geld, aber deutlich weniger und hat sich schon bei vielen bewährt ;)

Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.26
Beitrag von: noansi am 27 Juli 2018, 20:01:08
Hallo Dave,

ZitatIch habe mir das ganze mal angesehen, meinst du es läuft auch auf einem Network PIM Connector mit:
Pigator Modul: CC1101 868MHz RP-SMA-Anschluss ?
Oder sogar dem Busser? mit dem o.g. Pigator Modul ?

Also auf dem von Dir richtig gewählten Pigator Modul läuft die tscul Firmware.
Ich habe ein 433MHz Modul damit geflashed und die Firmware läuft darauf stabil. Auf dem 868MHz Modul wird sie auch stabil laufen.

Die CUNX Firmware von Busware hat noch Schwächen. Insbesondere klappt DHCP nicht richtig und man muss die Netzwerkadresse/Netzmaske etc. händisch eintragen. Dazu gibt es einen Thread.

Das Pigatormodul zu flashen war in sofern problematisch, dass der vorinstallierte Bootloader auf dem Mpdul nicht wollte und ich erst mal den auf Stand bringen musste, was einen entsprechenden Programmer nötig machte.

Zum Network PIM Connector habe ich keine Erfahrungen. Ebenso nicht zum Busser.

Zum MOD-RPI-PCB über LAN/WLAN habe ich ebenfalls keine persönlichen Erfahrungswerte.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.26
Beitrag von: davedeluxe am 28 Juli 2018, 14:22:14
Ich denke ich werde es mal mit dem HM-MOD-RPI-PCB und nem USR-TCP232-T2 probieren,
Das ist günstig und schnell zusammengebastelt so wie es aussieht...

Danke für eure Hilfe, dann kann mein Intel NUC/Proxmox-Vorhaben jetzt weiter gehen :)

Grüße Dave
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.26
Beitrag von: Bastel-Frank am 03 August 2018, 17:47:30
Hallo Ansgar,

ich bin heute von der Version 21 auf die 26 gegangen. Bis auf ein Device läuft alles unauffällig.

Beim Device "HM-RC-Dis-H-x-EU" (Fernbedienung mit Display) bleiben nun CMDs hängen und werden auch nach mehrfachen Versuchen nicht übertragen. Ein Resetten auf die Werkseinstellungen hat dazu geführt, dass das Pairing nicht mehr vollständig durchgeführt wird. Dies bedeutet wohl, dass es mit diesem Device ein Timing-Problem gibt.

Ich bin versuchsweise auf die Version 25 und 21 zurückgegangen. Dies hat leider keine Besserung gebracht. Bei früheren Versionen habe ich dieses Problem nicht gehabt.

Hast Du eine Idee?

PS: Ich habe insgesamt 4 CUL's und einen NanoCUL im Einsatz, welche mit ser2net angebunden sind

Viele Grüße
Frank
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.26
Beitrag von: Bastel-Frank am 03 August 2018, 19:25:13
PS:

Ich habe nun festgestellt, dass es die o.g. Probleme gibt, wenn ich mich näher als 5m zu meinen "Haupt-CUL" (CUL mit langer Antenne) aufhalte. Entferne ich mich weiter, dann werden die CMDs ausgetauscht und die Fernbedienung wird konfiguriert und funktioniert anschließend.

Gibt es hierzu eine Erklärung?

Viele Grüße
Frank
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.26
Beitrag von: RaspiLED am 03 August 2018, 19:46:21
Ja steht auch im Wiki Stichwort Übersprechen.
Ich höre meine Tochter auch nicht, wenn Sie in mein Ohr brüllt und mein Gehirn sagt nur Aua und nicht ACK ;-)

Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.26
Beitrag von: noansi am 03 August 2018, 20:35:14
Hallo Frank,

es dürfte vermutlich eher was mit der Multi-IO Umgebung zu tun haben, wenn < als 5m nicht < als 1m bedeutet.

Ohne Log mit verbose 4 für alle CULs läßt sich dazu gar nichts sagen.

Wenn die IO-Device Zuordnung beim Anlernen wechselt, weil ein schlechter empfangender CUL zuerst empfängt, könnte das zu Problemen führen.

Außerdem natürlich Firmware aller CULs und Module auf den gleichen Stand nach jeweilgem ZIP-File bringen. Mischen bringt in der Regel nichts sinnvolles.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.26
Beitrag von: Bastel-Frank am 04 August 2018, 13:24:56
Hallo Ansgar,

ich halte alle CULs auf dem gleichen Versionsstand. Ich könne die anderen CULs mal fürs anlernen mit Dummy=1 stilllegen und mit verbose 4 mitschneiden. Würde das für die Analyse helfen?

Viele Grüße
Frank
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.26
Beitrag von: noansi am 04 August 2018, 23:40:57
Hallo Frank,

ZitatIch könne die anderen CULs mal fürs anlernen mit Dummy=1 stilllegen und mit verbose 4 mitschneiden. Würde das für die Analyse helfen?
Nur, wenn Du vermutest, dass der eine CUL "kaputt" ist.
Außerdem müsstest Du die anderen CULs dabei auch ausschalten, da Du nicht weisst, welcher CUL die Fernbedienung noch als sein device"kennt" und damit mit automatischen Acks dazwischen funken würde. Nur dummy=1 löscht nicht die Zuordnungstabelle in den CULs und schaltet die CULs auch nicht in SlowRF. Nur dummy=1 würde mehr Probleme schaffen.

Log mit verbose 4 für alle CULs.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: noansi am 08 August 2018, 21:08:12
Hallo Testwillige,

hier eine neue Version 0.29 der Timestamp Firmware und der dazu benötigten FHEM Module.

Diese Version enthält Korrekturen für HM und Ergänzungen für SlowRf. Außerdem wird das Attribut "dummy" nun sinnvoll unterstützt.

Für CUL-IOs mit großem SRAM Speicher (SCC,COC,CUNO2,PIGATOR,...) ist die HM-Device Tabelle vom EEPROM ins SRAM verlagert und somit der EEPROM Verschleiss bei HM für diese entfallen. In dieser Version ist de SRAM Tabelle vergrößert (je nach verfügbarem SRAM).

Kurzer Auszug für SlowRf Änderungen aus der Readme:
- SlowRF Send Frequeny to set with Xs
- Xs delivers SlowRF Send Frequeny Offset and Send Frequeny (answer Xf:ooffffff)
- Xo added to set SlowRF (default is the offset for reception)
- if delivers Send Frequeny Offset and Send Frequeny (answer if:ooffffff)
- io added to set InterTechno Send Frequeny Offset (default is 0)
- it removed, ic remains to set it_interval
- isr just sets InterTechno Repetition-count but does no more respond with ir:
- ir and ix removed
- Yx removed

Es ist eine Prüfung auf Stacküberlauf eingebaut. Am Anfang des heap werden zwei Byte mit einem Bitmuster beschrieben. Wird das verändert, dann ist der Speicher wahrscheinlich korrumpiert, was durch einen Stacküberlauf ausgelöst sein sollte. Sofern der CUL dann noch kann sendet er ein "C_M" an TSCUL, was zu einem entsprechenden Log Eintrag führt.
Damit kann man vorsichtig die Speichergrenzen ausloten. Ein langer Testzeitraum ist aber erforderlich, um einigermaßen sicher zu sein, dass der worst case auch mal durchlaufen worden ist.
Außerdem ist ein Kommando mU (je nach Firmware) eingebaut, mit dem man den vom Stack ungenutzen heap in etwa auslesen kann (auch als get unusedstack in TSCUL verfügbar). Auch hier gilt, nur nach langer Laufzeit einigermaßen sinnvoll. Es macht sicher keinen Sinn auf Grund des Wertes den Speicher bis auf das letzte Byte auszuquetschen, denn weiterhin hängt die Stacknutzung vom gewählten Protokoll und Einstellungen ab.

In TSCULflash ist Flashen auch von NanoCULs und MiniCULs ergänzt. Vor dem Flashen wird ein "B00" also Reset für die TSCUL Firmware an den nano/Mini geschickt, 1 Sekunde gewartet und dann versucht mit avrdude zu flashen.
Also erst die Firmware in den FHEM/Firmware Ordner kopieren und dann in FHEM mit
TSCULflash <nanodevicename> TSnanoCUL
bzw.
TSCULflash <minidevicename> TSminiCUL
versuchen zu Flashen. Im Log sollte danach (dauert etwas) die avrdude Ausgabe zu finden sein.

Ebenfalls möglich ist das Flashen eines PIGATOR Moduls an einem CUNX
TSCULflash <pigatordevicename>|<cunxdevicename> TSPIGATOR

AESCommReq wird unterstützt. Die Nutzung ist unverändert zu Standard CUL, sprich, beim gewünschten Gerät/Kanal aesCommReq auf 1 setzen und ggf. noch aesKey passend zum verteilten Key setzen.
Es werden von tsculfw nur die Keys 0 (Default Key) bis 3 unterstützt.

Diese Erweiterung erfordert jedoch auch zusätzliche Empfangspuffer im knappen Speicher des CULs. Ein CUL V3 nutzt bis zu 6 Empfangspuffer. Auch der FlashSpeicherbdarf ist angestiegen, so dass einige Protokolle nicht mehr gleichzeitig in ein Kompilat passen. Das sollte aber weniger tragisch sein, da im ASKSIN Modus ohnehin nur HM empfangen werden kann.

Bei CUL V2 reicht der verfügbare Speicher leider hinten und vorne nicht aus, um diese Version nutzen zu können.

Im Anhang ist in TSCUL_fwcode_00_29_FHEM_Modules_00_40_1.zip wieder die Timestamp Firmware zu finden. Getestet habe ich TSCUL_V3, TSCOC und TSSCC.

Die tsculfw Firmware kann für TSCUL_V3 und TSPIGATOR (an CUNX) mit FHEM mit dem TSCULflash geflashed werden. Die anderen müssen mit dem jeweiligen Flash Programmer geflashed werden.
So z.B. https://forum.fhem.de/index.php/topic,24436.msg631743.html#msg631743 kann es mit einem USB CUL Stick gehen, wenn man nicht TSCULflash verwendet.
TSCULflash ist erweitert auf COC, SCC, CCD, rpiaddon, CUNO2 und CUNO. Jedoch ist es nicht ganz so einfach zu handhaben, da zum einen teilweise die Taste zu drücken ist und bei Raspberry PI Modulen die Rechteproblematik für den Zugriff auf die IO-Pins überwunden werden muss. Tips dazu in der Command-Ref auch bei RPI_GPIO.
Bei einem Stapel aus SCC mit aufgesetztem COC, CCD oder (rpiaddon?) ist unbedingt beim SCC Flash darauf zu achten, die Taste am gewünschten Modul zu drücken. Sonst wird das oberste Nicht-SCC Modul mit der SCC Firmware geflashed.
Mit CUNO2 ist das flashen noch nicht getestet (generell nur über USB!). Wichtig, aber auch hier, die Taste zu drücken.

Es gibt nicht den Luxus des Downloads beim TSCULflash, sondern die Firmware muss händisch in den FHEM/firmware Ordner kopiert werden. Der Typ ist dann TSCUL_V3.
Beispiel:
TSCULflash MeinCulDevice TSCUL_V3

Wichtig für SCC Nutzer. TSSTACKED ist entfallen und wird nicht mehr unterstützt.
Statt dessen gibt es das neue Modul STACKABLETS (als Abwandlung von Rudolfs STACKABLE).
Dieses wird sozusagen zwischen die Stackteilnehmer eingebaut.

Beispiel für fhem.cfg:
#erstes SCC Modul als Basis
define SCC_WS868 TSCUL /dev/ttyAMA0@38400 0000
attr SCC_WS868 event-on-change-reading Ints_per_sec,IntCalcStat,MatchStat
attr SCC_WS868 rfmode SlowRF
attr SCC_WS868 room Receiver
attr SCC_WS868 sendpool CUL_HM868,SCC_WS868
attr SCC_WS868 verbose 1

#neues STACKABLETS virtuelles IO device
define STACK_1 STACKABLETS SCC_WS868
attr STACK_1 verbose 1

#zweites SCC Modul
define SCC_HM868 TSCUL FHEM:DEVIO:STACK_1:38400 1034
attr SCC_HM868 event-on-change-reading cond
attr SCC_HM868 hmId F11034


Ergänzender Hinweis zu USB CULs: 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_08\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 1234
bzw.
define CUL_433 TSCUL /dev/CUL433_0@12000000 0000
definiert werden und es gibt keine Probleme mit wechselnder Schnittstelle mehr.
Die Seriennummer kann beim Compilieren der Firmware in der board.h 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.

Bei nicht nativen USB CULs wie z.B. nanoCUL, miniCUL oder CUNO2, beträgt die Baudrate 38400, dementsprechend muss die Definition beispielsweise so aussehen:
define CUL_868 TSCUL /dev/CUL868@38400 1234
bzw.
define CUL_433 TSCUL /dev/CUL433@38400 0000

In der Zip Datei sind ebenfalls die ergänzten Module zu finden, die zur Nutzung der Firmware erforderlich sind.

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
16_STACKABLETS.pm -> statt der 16_STACKABLE.pm, aus STACKABLE werden damit STACKABLETS devices in der fhem.cfg (händisch anzupassen)

10_UNIRoll_TS.pm  -> statt der 10_UNIRoll.pm, mit TSCUL 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 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 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 IO-devices zu verwenden, aus CUL_WS wird dann TSCUL_WS  in der fhem.cfg (händisch anzupassen)
15_TSCUL_EM.pm   -> statt der 15_CUL_EM.pm, mit TSCUL IO-devices zu verwenden, aus CUL_EM wird dann TSCUL_EM  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_IT.pm                   -> vermeidet unnötiges busy waiting beim Senden. Wird ohne Schutz von FHEM update überschrieben

Außerdem:

98_TSCULflash.pm     -> Zum Flash von TSCUL_V3, TSPIGATOR (an CUNX) mit Datei in FHEM/firmware

10_CUL_HM.pm         -> angepasste Version zur Nutzung mit TSCUL/tsculfw. Die Nutzung dieses Moduls ist optional. Für CUL_V3, nanoCUL, miniCUL im Multio-HM-IO Betrieb jedoch empfohlen, da sie den EEPROM Verschleiss über das Attribut "rssiSwitchHyst" verringert.
HMConfig.pm             -> optional, Einstelllimits für HM-CC-RT-DN Regler P und I Anteil erweitert. Damit kann man mit R-regAdaptive offDeter deutlich mehr an den Regelparametern spielen.
98_HMinfo.pm           -> optional, Spaltenbreiten in Tabelle von protoEvents variabel zu verbesserten Übersicht in der Darstellung.

10_CULG.pm              -> optional, enthalten, da die Firmware es unterstützt

97_timerTS.pm           -> optional, Austausch-Timerroutinen. Wenn es nicht genutzt werden soll, dann löschen oder umbennen.
98_apptime.pm          -> apptime zur zwingenden Nutzung mit 97_timerTS.pm.

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_STACKABLETS.pm DevIoTS.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.pm CalcUtil.pm 97_timerTS.pm 98_TSCULflash.pm 97_timerTS.pm 98_apptime.pm 10_IT.pm 10_CULG.pm 10_CUL_HM.pm HMConfig.pm 98_HMinfo.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` }

Noch ein Hinweis: TSCUL fragt auch die Firmwareversion der tsculfw auf 0.28 ab. Eine ältere Version wird also nicht unterstützt, da das Timestamp Protokoll (inkompatibel zu vorherigen Ständen) geändert hat, so dass mit dem Austausch der FHEM Module auch ein Firmwareupdate des CUL devices erforderlich ist!

Noch ein Tip zur Haltbarkeit der CULs mit wenig SRAM (CUL V3, nanoCUL, miniCUL ...). Jedesmal, wenn einem HM-Device das IODev durch Roaming neu zugeordnet wird, führt das zu EEPROM Schreibvorgängen in den beteiligten CULs. Die Lebensdauer des EEPROMs ist begrenzt (100000 Schreibzyklen laut Datenblatt). Daher rate ich zur Nutzung des VorzugsIOs beim Device Attribut IOgrp. Also nicht einfach stumpf
attr HMdeviceName IOgrp VCCU
setzen, sondern
attr HMdeviceName IOgrp VCCU:CUL_mit_gutem_Empfang_fuer_Device
sofern die Roaming Funktionalität entsprechend RSSI für das jeweilige device nicht zwingend benötigt wird. Ein Fallback auf einen anderen CUL bleibt dennoch möglich.
Mit dem Attribut "rssiSwitchHyst", das in der beigefügten 10_CUL_HM.pm verfügbar ist, kann bei den HM-devices die Umschalthysterese für das Roaming von 10 bis auf 2 bei Bedarf für mobile devices verringert werden.

Ergänzt ist auch noch ein set TX3Send.
Damit lassen sich TX3 Sensordatentelegramme auf 433er CULs versenden.
Beispiel:

define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 TX3Send T:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." SID:23 U")}

define NF_HumOut notify Sen_Aussen:humidity.* {fhem("set TSCUL_WS433 TX3Send H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." SID:23 U")}


Ergänzt ist auch noch ein set KSSend.
Damit lassen sich WS Sensordatentelegramme versenden.
Beispiel:

define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 KSSend T:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." Code:2")}


Gruß, Ansgar.

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

EDIT: Firmware .hex Dateien in zip aktualisiert
EDIT2: 00_TSCUL.pm angepasst um CC0 = xx / xxx Meldungen im SlowRf Betrieb zu filtern.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: Bastel-Frank am 08 August 2018, 21:20:35
Hallo Ansgar,

wieder Mal vielen herzlichen Dank für deine tolle unermüdliche Arbeit  :)!

Soll ich in meinem Szenario nun die Dummy-Funktion nutzen, um dem Problem(-chen) mit der Fernbedienung auf die Spur zu kommen?

Viele Grüße
Frank
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: noansi am 08 August 2018, 21:34:24
Hallo Frank,

Zitatich halte alle CULs auf dem gleichen Versionsstand. Ich könne die anderen CULs mal fürs anlernen mit Dummy=1 stilllegen und mit verbose 4 mitschneiden. Würde das für die Analyse helfen?
mit der Version 0.29 und den zugehörigen Modulen kannst Du nun auch mal den Test mit dummy=1 für andere CULs machen.

Wenn Du mit dummy fertig bist, dann mußt Du das Attribut dummy mit delete entfernen! dummy=0 hebt den dummy Zustand nicht auf!

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: MartiAn am 12 August 2018, 11:03:08
Hallo,

ich habe gerade erst begonnen mich mit TSCUL zu beschäftigen.

Hierzu habe ich die Version V0.29 heruntergeladen und TSnanoCUL.hex auf meinen Selbstbau nanoCUL geflasht, kurz im Terminal mit einer Homematic-Fernbedienung getestet und gesehen, dass der nanoCUL die Meldungen ausgibt.

Die zusätzlichen Module wurden ins FHEM-Verzeichnis kopiert, jedoch scheitert das Einbinden des nanoCULs:
2018.08.11 20:23:32 0: CUL868HM version 0.27 is not version VTS 0.28 to 0.30, please update

Eine Überprüfung im Terminal hat gezeit, dass der nanoCUL tatsächlich unter V0.27 läuft. Dann ist mir aufgefallen, dass die TSnanoCUL.hex aus dem März ist.

Im nächsten Schritt, wollte ich TSCUL für meinen nanoCUL selbst kompilieren, so wie ich es von der normalen culfw kenne. Hier scheitert es beim Linken:
/usr/bin/avr-ld: --relax and -r may not be used together

Kurze Überprüfung mit: make SHELL="/bin/bash -x"
+ echo Linking: TSnanoCUL.elf
Linking: TSnanoCUL.elf
+ avr-gcc -mmcu=atmega328p -I. -DnanoCUL -gdwarf-2 -DF_CPU=8000000UL -Os -flto -Wall -Wundef -Wmain -Wstrict-prototypes -funsigned-char -funsigned-bitfields -ffunction-sections -fdata-sections -fpack-struct -fshort-enums -finline-limit=20 -fomit-frame-pointer -fauto-inc-dec -fcompare-elim -frename-registers -fconserve-stack -fshrink-wrap -ftree-dce -ftree-dse -ftree-ter -mcall-prologues -maccumulate-args -mstrict-X -mrelax -Wa,-adhlns=../../clib/ir.o -I../.. -I../../clib -std=gnu99 -MMD -MP -MF .dep/TSnanoCUL.elf.d ../../clib/ir.o ../../clib/irmp.o ../../clib/irsnd.o ../../clib/serial.o ../../clib/tsculfw_ARCH_AVR8.o ../../clib/memory.o ../../clib/display.o ../../clib/ringbuffer.o ../../clib/ttydata.o ../../clib/fht.o ../../clib/rf_receive.o ../../clib/rf_router.o ../../clib/rf_send.o ../../clib/rf_credits.o ../../clib/clock.o ../../clib/delay.o ../../clib/aes_ecb.o ../../clib/rf_asksin.o ../../clib/cc1101_pllcheck.o ../../clib/spi.o ../../clib/cc1101.o ../../clib/fncollection.o ../../clib/stringfunc.o ../../clib/rf_moritz.o ../../clib/rf_rwe.o ../../clib/fastrf.o ../../clib/intertechno.o ../../clib/somfy_rts.o ../../clib/rf_mbus.o ../../clib/mbus/manchester.o ../../clib/mbus/3outof6.o ../../clib/mbus/mbus_packet.o ../../clib/mbus/crc.o ../../clib/rf_native.o ../../clib/lacrosse.o ../../clib/registry.o --output TSnanoCUL.elf -Wl,-Map=TSnanoCUL.map,--cref -Wl,--relax -Wl,--gc-sections -Os -flto -lm
/usr/bin/avr-ld: --relax and -r may not be used together

Zum einen wundert mich die Definition -DF_CPU=8000000UL, weiterhin sehe ich kein -r.

Weiß jemand Rat.

Vielen Dank und Gruß,

Martin

Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: noansi am 12 August 2018, 12:59:13
Hallo MartiAn,

ZitatCUL868HM version 0.27
ups, sorry, da hab ich noch die älteren .hex Dateien im zip gehabt. Danke für den Hinweis!

Bitte lad das aktualiserte zip aus https://forum.fhem.de/index.php/topic,24436.msg825473.html#msg825473 (https://forum.fhem.de/index.php/topic,24436.msg825473.html#msg825473) nochmal runter und flashe nochmal.

ZitatHier scheitert es beim Linken
Mag an der Version liegen. Ich nutze avr-gcc 4.9.2

Zitatwundert mich die Definition -DF_CPU=8000000UL
Im Code wird ein 16MHz nano per Prescaler auf 8MHz runter geteilt, damit es mit dem Timing problemlos klappt. Das ist also richtig. Siehe auch board.h, da wird es definiert.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: MartiAn am 12 August 2018, 15:58:19
Hallo Ansgar,

ZitatBitte lad das aktualiserte zip aus https://forum.fhem.de/index.php/topic,24436.msg825473.html#msg825473 (https://forum.fhem.de/index.php/topic,24436.msg825473.html#msg825473) nochmal runter und flashe nochmal.
Jetzt hat es funktioniert, vielen Dank für die schnelle Reaktion.

ZitatMag an der Version liegen. Ich nutze avr-gcc 4.9.2
Ups, da liegen wohl Generation dazwischen. Mein Compiler sagt: 8.2.0.

Zitat
Im Code wird ein 16MHz nano per Prescaler auf 8MHz runter geteilt, damit es mit dem Timing problemlos klappt. Das ist also richtig. Siehe auch board.h, da wird es definiert.
Alles klar.

Gruß,

Martin
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: noansi am 18 August 2018, 11:36:55
Hallo Frank,

ZitatSoll ich in meinem Szenario nun die Dummy-Funktion nutzen, um dem Problem(-chen) mit der Fernbedienung auf die Spur zu kommen?

Hast Du mal einen Test gemacht?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: Bastel-Frank am 18 August 2018, 18:55:18
Zitat von: noansi am 18 August 2018, 11:36:55
Hallo Frank,

Hast Du mal einen Test gemacht?

Gruß, Ansgar.

Hallo Ansgar,

ich habe leider noch keine Zeit gehabt. Bin im Moment beruflich viel unterwegs. Ich habe das Thema aber im Auge ...

Viele Grüße
Frank
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: Bastel-Frank am 24 September 2018, 11:40:25
Hallo Ansgar,

ich habe jetzt endlich Zeit gefunden ...  ;D

Ich habe meine CULs auf die aktuelle Version gehoben und habe sie alle aktive gelassen (kein Dummy). Dann habe ich meine "Problem"-Fernbedienung zurückgesetzt und neu gepaired.

Ergebnis: Das Pairing lief jetzt durch. Aber ich muss mit der Fernbedienung einen Abstand von jetzt mind. 2 Metern (vorher waren es 5m) einhalten, damit der Austausch der CMD's funktioniert. Bei den anderen HM-Device ist der Abstand egal.

Läuft soweit ... und was bleibt mir jetzt nur noch bleibt, ist Dir für deine Super Arbeit und deine tolle Firmware zu danken!

Viele Grüße
Frank

Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: noansi am 24 September 2018, 22:26:17
Hallo Frank,

ZitatErgebnis: Das Pairing lief jetzt durch. Aber ich muss mit der Fernbedienung einen Abstand von jetzt mind. 2 Metern (vorher waren es 5m) einhalten, damit der Austausch der CMD's funktioniert. Bei den anderen HM-Device ist der Abstand egal.
Interessant, ich bin mir keiner Änderung bewusst, die dazu hätte beitragen können oder sollen?!
Der dummy ist dazu gekommen und Änderungen an SlowRf. Bei HM eher "Kosmetik".
Und der dummy, damit Du mal testen kannst, ob nur ein aktiver CUL in Funkreichweite zu einer Besserung bei Deinem Pairing Problem führt.
Aber vielleicht ist es jetzt auch der Batteriestand der Fernbedienung, der zu einer Verbesserung durch geringere Reichweite führt?

Hast Du alle Module genutzt oder HMInfo, CUL_HM und HMConfig nach aktuellem Stand von Martin?
Seine letzte große Änderungswelle habe ich noch nicht nachgepflegt. Der Wechsel des IOs nach RSSI ist und war unterschiedlich. Daher ist das relevant.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: Bastel-Frank am 25 September 2018, 07:44:31
Hallo Ansgar,

Ich habe seit ca. einem Monat kein Update mehr gemacht.

Die Fernbedienung hat noch die gleiche Batterie wie vorher. Den Unterschied meine ich schon auszumachen :D. Als ich den vorherigen Firmwarestand drauf hatte, hat die FB keine CMD's ausgetauscht, wenn ich in der Nähe zu meinem Haupt-CUL (mit langer Antenne) war. Mit der aktuellen Firmware klappt der Austausch der CMD's sporadisch, wenn ich in der Nähe bin. Gehe ich 2m weg (mehrfach getestet), dann kommt die Verbindung zuverlässig zustande.

Was hat sich bei Martin geändert? Was ist der Hintergrund?

Viele Grüße
Frank
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: noansi am 25 September 2018, 22:53:11
Hallo Frank,

ZitatMit der aktuellen Firmware klappt der Austausch der CMD's sporadisch, wenn ich in der Nähe bin. Gehe ich 2m weg (mehrfach getestet), dann kommt die Verbindung zuverlässig zustande.
Hmm, wie schon geschrieben, derzeit unverständlich, was die Firmware oder Module damit zu tun haben sollen.
Hast Du eventuell noch das EEPROM nach dem Update zurück gesetzt? Damit hättest Du dann den Frequenzoffset zurück gesetzt, was eine Änderung hätte bewirken können, wenn der vorher nicht auf default war.

ZitatWas hat sich bei Martin geändert? Was ist der Hintergrund?
SVN sagt:
Zitatchanges for WD100 - with respect to peer handling
Und das war umfangreich. Details must Du im Forum suchen. Danach kamen noch Fixes dazu und noch ein paar Änderungen.
ZitatHMConfig:add clear msgError
Zitat98_HMInfo:improve update function - update actiondetector and vccu ...

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: Bastel-Frank am 03 November 2018, 18:43:03
Hallo Ansgar,

ein Frage: Wie kann man mit deiner Firmware Firmware-Updated auf HM-Devices OTA übertragen?

Mit dem OTA-flasher kommt die Fehlermeldung "This version does _not_ support firmware upgrade mode, you need at least 1.58!"

Viele Grüße
Frank
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: noansi am 03 November 2018, 20:10:37
Hallo Frank,

das sollte direkt aus FHEM raus gehen.
Beim entsprechenden HM-device set fwUpdate mit dem Namen der Firmwaredatei, die sich im FHEM\firmware Verzeichnis befinden sollte (also vorher hineinkopieren).

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: Bastel-Frank am 04 November 2018, 10:47:38
Hallo Ansgar,

vielen Dank für den Tipp :-). In diesem Fall geht es darum, dass das FW-Update über fhem schiefgegangen ist und das Device keine Befehle mehr annimmt (die LED blinkt dabei sehr schnell). Dann kann man mit dem OTA-Tool eine neue Firmware mit der Angabe der Seriennummer direkt auf's Device pushen. Das Tool fragt aber fhem nach dem Versionsstand ab und erwartet eine Version >= 1.58. Da jetzt 0.29 zurückgemeldet wird, beendet sich das Tool.
Was kann man jetzt machen?

Viele Grüße
Frank
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: noansi am 04 November 2018, 11:21:52
Hallo Frank,

Variante 2: Du flashst Dein CUL temporär mit der Standard Firmware und versuchst es damit.

Du hast in jedem Fall ein altes hmcfgusb Paket als Basis im Einsatz. Der letzte Stand sollte die Meldung nicht bringen.
Aber auch das aktuelle hmcfgusb ist nicht auf dem Stand für die aktuelle tsculfw. Da sind noch einige Anpassungen nötig, damit es damit klappen kann, da sich das Protokoll firmwareseits seit den letzten Anpassungen geändert/erweitert hat.
Wie lange kannst Du mit dem Zustand des ungeflashten devices leben?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: Bastel-Frank am 04 November 2018, 12:23:25
Nicht sehr lange ... sie sind im Produktiven Einsatz ... und der WAF ist in Gefahr :-)

aber keinen Stress, ich habe eine fhem-Umgebung mit Standard-FW aufgesetzt. Es wäre aber zukünftig schön, wenn man solche Fälle auch mit deiner FW lösen könnte.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: noansi am 04 November 2018, 13:41:21
Hallo Frank,

ZitatEs wäre aber zukünftig schön, wenn man solche Fälle auch mit deiner FW lösen könnte.
Die Zukunft ist jetzt.
Im Anhang der Quellcode zur adaptierten Version des hmcfgusb Pakets 1.03-git von Michael Gernoth.
Es wird dafür die tsculfw VTS 0.28 oder höher benötigt.

Erfolgreich getestet habe ich ein OTA-Firmwareupdate mit CULs mit tsculfw VTS 0.29 tsculfw VTS 0.38.

@Michael: flash-ota.c, culfw.c und culfw.h sind geändert (und version.h, sowie LICENSE), wäre schön, wenn Du es einarbeiten könntest.

Gruß, Ansgar.

EDIT: noch ein Update, da bei Flashen mit Seriennummer die HMID des devices nicht im CUL registriert wurde.
EDIT2: und noch ein kleines Update, damit bei mangelnden credits die ungefähre Wartezeit bis zur Vollaufladung angezeigt wird.
EDIT3: Update für VTS 0.34 und höher
EDIT4: Update für gestackte CULs
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: Bastel-Frank am 04 November 2018, 14:16:47
Hallo Ansgar,

vielen lieben Dank ... mal wieder ... bei Dir. Was für ein Top-Service!

Wenn ich könnte, würde ich Dir ein paar Bierchen rüberschieben. Das welcher Region DE kommst Du?

LG
Frank
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: noansi am 04 November 2018, 14:37:40
Hallo Frank,

der Quellcode oben ist aktualisiert, weil mir noch was im Bezug auf OTA-Firmwareupdate mit Seriennummer aufgefallen ist.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: noansi am 04 November 2018, 16:12:40
Hallo Frank,

zum Thema Bier ist habe ich noch eine kleine Ergänzung eingebaut, die die ungefähre Wartezeit bis zur Vollaufladung der credits angibt. Damit kann man die Zeit sinnvoller nutzen.
Allerdings sollte man sich beim Warten eine gewisse Restzuzurechnungsfähigkeit erhalten, da die für korrekte Befehlseingabe und device-Bedienung erforderlich ist.  ;)

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: frank am 05 November 2018, 08:26:44
ota fwupdate sollte trotzdem normal über cul_hm funktionieren. einfach eine optionale waittime angeben.

ZitatfwUpdate [onlyEnterBootLoader] <filename> [<waitTime>]
update Fw of the device. User must provide the appropriate file. waitTime can be given optionally. In case the device needs to be set to FW update mode manually this is the time the system will wait.
"onlyEnterBootLoader" tells the device to enter the boot loader so it can be flashed using the eq3 firmware update tool. Mainly useful for flush-mounted devices in FHEM environments solely using HM-LAN adapters.

nach dem senden des befehls muss innerhalb der waittime, das device manuell gebootet werden. das sollte im changelog der fw datei beschrieben sein.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: jw1hal am 16 November 2018, 20:05:28
Hallo,

ich bin noch relativ neu und fuchse mich so nach und nach in dieses sehr komplexe Thema. So habe ich noch große Probleme mich richtig exakt auszudrücken oder eben gleich die wichtigen Informationen zu liefern, weil ich nicht immer genau weiß, wie man da genau ran kommt. Das kommt eben mit der Zeit, jeder hat mal angefangen.

Ich fange mal an zu berichten. Nachdem meine 8 Fenstersensoren mit der vorherigen CUL-Firmware sich nicht pairen ließen, bin ich auf TSCUL aufmerksam geworden und habe zunächst erst einmal den 868iger Nano-CUL über Fhem geflasht. Das ging auch nicht sofort, erst Taste drücken, gedrückt halten und CUL einstecken hat es gebracht.
Ein Fenstersensor ließ sich auch nicht richtig pairen und peeren, so dass ich ihn zwar im Peer vom Thermostat sah, aber nicht andersherum. Auch die Meldungen "R-05_BW_Heizung_WindowRec-expectAES off" und "R-05_BW_Heizung_WindowRec-peerNeedsBurst on" blieben auf "set" stehen. Das habe ich 2 Tage probiert und es hat alles nix geholfen. Einen nachbestellt, mit dem ging es sofort. Der eventuell Defekte geht eben zurück.

Ich habe noch einen Fernseher über eine Funksteckdose (433 Mhz) laufen, die ich nicht in Fhem integriert bekomme. Als ich früh nach Hause kam, wollte ich diese Funksteckdose schalten und sie zuckte  auch am darauf folgenden Tag gar nicht. Erst Neustart vom PI oder Entfernung der  CUL´s lies diese Steckdose wieder schalten, so dass ich vermutete, der CUL sendet dauerhaft und stört den Funkverkehr. Da ich nur den 868iger geflasht hatte, dachte ich mir, dass es sich nicht verträgt, wenn der 433iger über die alte Firmware und der 868iger über die TS-Firmware läuft. Also flashte ich den 433iger auch. Mit dem lief auch erst einmal alles, muss ich aber noch beobachten, weil ich die letzten Tage mehrere Dinge getan habe.
So habe ich mich heute auch mit dem "99-usb-serial.rules-Thema" beschäftigt und bin letztendlich leider daran gescheitert. Bei den CUL´s stand zwar "Initialized", aber s in der VCCU stand "CUL_868:disconnected" und beide CUL´s funktionierten nicht. Also habe ich bei CUL´s wieder direkt mit dem USB-Port zugewiesen und nun funktionieren sie wieder.

Inhalt der Datei in: \etc\udev\rules.d\SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A9G7BTLL", SYMLINK+="CUL868"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="433", SYMLINK+="CUL433"


Das ergab dmesg:[    2.630149] usb 1-1.2: New USB device found, idVendor=0403, idProduct=6001
[    2.630158] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    2.630165] usb 1-1.2: Product: FT232R USB UART
[    2.630171] usb 1-1.2: Manufacturer: FTDI
[    2.630177] usb 1-1.2: SerialNumber: A9G7BTLL

[    3.184894] usb 1-1.3: New USB device found, idVendor=0403, idProduct=6001
[    3.184910] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    3.184919] usb 1-1.3: Product: NANO CUL
[    3.184927] usb 1-1.3: Manufacturer: SHK
[    3.184934] usb 1-1.3: SerialNumber: 433


Damit hatte ich es eingebunden:/dev/CUL433@12000000 0000
/dev/CUL868@12000000 4321


Und damit war es vorher und ist es auch jetzt wieder eingebunden:/dev/serial/by-id/usb-SHK_NANO_CUL_433-if00-port0@38400 4321
/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9G7BTLL-if00-port0@38400 4321



Mein eigentliche Frage ist die folgende Meldung, über die ich im Netz auch nix weiter finde:2018.11.16 19:12:33 2: TSCUL_Parse: CUL_433 unknown message CC0 = 0D / 13
Diese taucht immer wieder im Log auf.

Dann hatte ich auch mal diese Meldung gesehen:2018.11.15 04:00:13 3: CUL_433: Unknown code NOCCA, help me!
Diese soll wohl besagen, so hatte ich es gelesen, dass die Frequenz belegt war und er deswegen nicht sendete. Dieses konnte ich die letzten Stunden nicht mehr sehen. Mal schauen, ob es morgen früh wieder da ist und mit dem weiter oben beschriebenen Problem zusammenhängen könnte.

Dann verstehe ich auch ein paar Meldungen nicht, die mich etwas verwirren und denken lassen, dass die beiden CUL´s auf den jeweils anderen Frequenzen senden.
So steht bei dem 433iger CUL:Internals:
   VERSION    VTS 0.29 CSM868
   READINGS:
     2018-11-15 06:21:40   ITSndFreq       433.920MHz +0.000kHz
     2018-11-15 06:25:17   ccconf          freq:868.300MHz freqOffs:0.000kHz bWidth:325kHz freqIF:177.73kHz rAmpl:42dB sens:12dB dRate:2.461kBit/s
     2018-11-15 06:22:18   version         VTS 0.29 CSM868


Und bei dem 868iger CUL steht:Internals:
   VERSION    VTS 0.29 CSM868
   READINGS:
     2018-11-15 04:21:55   ITSndFreq       433.920MHz +0.000kHz
     2018-11-15 06:23:33   ccconf          freq:868.300MHz freqOffs:-20.630kHz bWidth:101kHz freqIF:152.34kHz rAmpl:33dB sens:8dB dRate:9.993kBit/s
     2018-11-16 18:45:56   version         VTS 0.29 CSM868


Wieso steht bei dem 868iger etwas von 433 und bei den 433iger etwas von 868?


Das sind Fragen über Fragen und ganz sicher nicht ganz so fachmännisch, wie ihr es gern erwartet. Aber es ist ja noch kein Meister vom Himmel gefallen. Und selbst das Lesen, Lesen und nochmals Lesen von diversen Wiki´s und dieser Commandref ist auch sehr mühsam und unverständlich, wenn einem einfach die Erfahrung und das dafür nötige Grundwissen fehlt, was man sich nach und nach aneignen muss. Nur wenn ich nun trotz stundenlangen Suchen, Lesen und Probieren doch nicht weiter komme, muss ich irgendwo fragen, was mir unklar ist und wofür ich nirgends eine Erklärung finde, auch wenn es für manch einen von euch vielleicht ziemlich lächerlich ist.


Gruß jw1hal
Titel: Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: RaspiLED am 17 November 2018, 08:00:50
Hi,

Edit: Ich lerne jeden Tag dazu und TSCUL kann also auch 433 ;-)

Rest daher ignorieren und weiter unten lesen! Danke für die Nachhilfe!

[ignorieren]
Offtopic hier ist Dein 433 nanoCUL. Flashe dort bitte die a-culfw und dann ist der fine und wird voraussichtlich auch Deinen Fernseher anschalten können. Falls nicht mach einen eigenen Thread unter Anfängerfragen auf. Da helfen Wir weiter für 433!

Dein 868 mit TS CUL sieht doch gut aus! Die 433.920 MHz würden verwendet, falls Du darüber Intertechno (z.B. Deinen Fernseher) schalten würdest. Aber eben nur ganz kurz und dann wieder zurück zu 868.300 MHz.

[/ignorieren]

Kurzum alles okay bei 868!

Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: noansi am 17 November 2018, 09:16:17
Hallo jw1hal,

Zitatgroße Probleme mich richtig exakt auszudrücken oder eben gleich die wichtigen Informationen zu liefern
Das erste wäre, in der zeitlichen Reihenfolge zu berichten, damit Ursache und Wirkung auch in Zusammenhang zu bringen sind.
Dann ist ein list von den fraglichen Komponenten auch immer hilfreich.

ZitatFunksteckdose (433 Mhz) laufen, die ich nicht in Fhem integriert bekomme.
Welches Protokoll verwendet die Funksteckdose? IT?

Zitatder CUL sendet dauerhaft und stört den Funkverkehr
ZitatSo habe ich mich heute auch mit dem "99-usb-serial.rules-Thema" beschäftigt
Das war der richtige Ansatz, um eine feste Schnittstellenzuordnung auch im Falle von Disconnect/Reconnect zu erhalten, woran es zuvor wohl gekrankt hat. Deine 99-usb-serial.rules sieht gut aus.

Zitat/dev/CUL433@12000000 0000
/dev/CUL868@12000000 4321
ist falsch, da Du nanoCULs zu verwenden scheinst.
/dev/CUL433@38400 0000
/dev/CUL868@38400 4321

Die 38400 ist für nanoCULs richtig, damit der USB-Seriel Interface Chip auf der nanoCUL Platine mit der richtigen Baudrate eingestellt wird.

Die 4 Ziffern danach sind die FHT ID. FHT setzt Du aber nach Deinem Bericht nicht ein. Wenn Du bei dem 868MHz CUL nicht das Attribut "hmId" setzt, dann wird mit den 4 Ziffern 4321 die hmId F14321 ersatzweise festgelegt.

Zitat2018.11.16 19:12:33 2: TSCUL_Parse: CUL_433 unknown message CC0 = 0D / 13
Beim nanoCUL ist der Speicherplatz knapp, daher ist das Feature des InterruptCounters für SlowRf nicht in die Frimware reincompiliert, weshalb der nano auf die CC0 Anfrage mit CC0 = 0D / 13 antwortet und nicht mit einer Ci Antwort, wie es das 00_TSCUL.pm Modul erwartet. Das muss ich wohl mal ausfiltern, danke für den Hinweis. Ist aber erst mal nicht tragisch, außer dass es Dein Log füllt.

ZitatWieso steht bei dem 868iger etwas von 433 und bei den 433iger etwas von 868?
ITSndFreq ist die Sendefrequenz für IT Befehle. Wenn Deine Dose also auf 433.92MHz auf IT Schaltbefehle lauscht, ist das richtig so.
Andere SlowRF Befehle werden von dem 433er auf 868.3MHz gesendet und generell auf 868.3MHz in der gewählte Einstellung empfangen. Die Frequenz solltest Du beim 433er auf 433.92MHz umstellen. Das geht mit set freq 433.92 in fhem.
Wenn Du den Anschluss A0 (entsprechend PortC Bit0 am Prozessor) am nanoCUL mit 150Ohm nach GND verbindest, dann sollte sich der nanoCUL mit tsculfw in der Version auch als CSM433 melden und die Frequenz auch auf 433.92Mhz als Firmwaredefault (Rücksetzen mit e) einstellen. Alternativ kann man das mit Anpasung der board.h auch fest in die Firmware reincompilieren, statt A0 mit 150Ohm nach GND zu verbinden.

Den 868er betreibst Du mittels des Attributs rfmode auf HomeMatic. Damit wird der nanoCUL auf 868MHz Sende- und Empfangsfrequenz im passenden Modus eingestellt. Gleichwohl könnte er IT Befehle auf 433.92Mhz senden, aber mit sehr schlechter Reichweite, weil die Anpassung der Elektronik nicht passt.

Mittels IODev bestimmst Du beim Schaltmodul (IT?) für Deine 433MHz Dose, welcher nanoCUL tatsächlich für das Senden verwendet wird.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: noansi am 17 November 2018, 09:36:54
Hallo Arnd,

ZitatOfftopic hier ist Dein 433 nanoCUL.
Nicht ganz.
Die a-cuffw bietet sicherlich mehr Protkollunterstützung für unterschiedliche SlowRF Protokolle.

Die tsculfw macht das was sie an SlowRF kann aber etwas stabiler im Sendetiming.
CCA wird auch bei SlowRF verwendet. Das verringert Störungen anderer laufender Funktelegramme und erhöht in der Regel etwas die Schalterfolgschancen.

Außerdem sollte er bei Verwendung der a-culfw für den 433er auch das Standard CUL Modul und das Standard IT Modul für den 433er verwenden und nicht das TSCUL Modul und das IT Modul meiner Variante.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: noansi am 17 November 2018, 10:28:53
Hallo Zusammen,

hier https://forum.fhem.de/index.php/topic,24436.msg825473.html#msg825473 (https://forum.fhem.de/index.php/topic,24436.msg825473.html#msg825473) habe ich die 00_TSCUL.pm in der zip zum Code angepasst, um die oben angesprochenen CC0 = 0D / 13 log Einträge raus zu filtern.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: jw1hal am 17 November 2018, 17:57:28
Vorab danke für die Antworten.

Zitat von: RaspiLED am 17 November 2018, 08:00:50Offtopic hier ist Dein 433 nanoCUL. Flashe dort bitte die a-culfw und dann ist der fine und wird voraussichtlich auch Deinen Fernseher anschalten können. Falls nicht mach einen eigenen Thread unter Anfängerfragen auf. Da helfen Wir weiter für 433!
Zitat von: noansi am 17 November 2018, 09:16:17Welches Protokoll verwendet die Funksteckdose? IT?
Da schrieb ich ja bereits:
Zitat von: jw1hal am 16 November 2018, 20:05:28Ich habe noch einen Fernseher über eine Funksteckdose (433 Mhz) laufen, die ich nicht in Fhem integriert bekomme.
Gut, ich hatte nicht erwähnt, dass ich mich bereits damit abgefunden habe, weil ich vermute, dass diese ein Protokoll verwenden, was gar nicht in Fhem geht.
Das waren meine erste Funksteckdosen, bevor ich Fhem und den ganzen Kram hatte. Da hatte ich eine davon fest in einem Fernseher im Kinderzimmer verbaut, damit ich mit einer Fernbedienung bei Schlafenszeit und Verbot dem Fernseher den Strom entziehen konnte. Hat immer gut funktioniert. Kind ist nicht mehr da und ich bin zu faul, das Ding wieder auszubauen. Also liegen hier 2 Fernbedienungen für den Fernseher.

Ich habe mal ein paar Bilder davon hochgeladen, weiß aber nicht, wie ich die zwischen den Text bekomme. Dann beschreibe ich es mal so. Die ZAP-Steckdosen (2 Bilder) mit der Anlerntaste hatte ich später gekauft und funktionieren (bis jetzt) auch noch nicht in Fhem.

Die anderen 5 Bilder sind von den besagten Steckdosen, wovon ich eine in dem Fernseher verbaut habe. Ich hatte da schon mehrfach sehr ausgiebig gesucht und nichts gefunden. Vermutlich funktionieren sie mit einem Protokoll, was entweder gar nicht in Fhem geht oder ich einfach nicht heraus bekommen kann, weil ich nicht die Möglichkeit dazu habe.

Aber das wollte ich hier eigentlich nicht thematisieren, hatte es nur am Rande erwähnt, mich vielleicht etwas falsch ausgedrückt und gehört ja hier nicht her.

Zitat von: noansi am 17 November 2018, 09:16:17Die 38400 ist für nanoCULs richtig, damit der USB-Seriel Interface Chip auf der nanoCUL Platine mit der richtigen Baudrate eingestellt wird.
Das werde ich die Tage nochmal probieren. So richtig habe ich über die Baudraten nichts gefunden oder an falschen Stellen gesucht. Denn gesucht hatte ich definitiv danach, eine meiner ganz vielen Fragen ...

Zitat von: noansi am 17 November 2018, 09:16:17ITSndFreq ist die Sendefrequenz für IT Befehle. Wenn Deine Dose also auf 433.92MHz auf IT Schaltbefehle lauscht, ist das richtig so.
Andere SlowRF Befehle werden von dem 433er auf 868.3MHz gesendet und generell auf 868.3MHz in der gewählte Einstellung empfangen.
Also senden die CUL´s generell da, wie es in den einzelnen Geräten angegeben ist? Ich hatte schon die Befürchtung, dass durch eine falsche Einstellung in den CUL´s sie dann generell auf der falschen, also nicht dafür vorgesehenen Frequenz senden. Denn genau dafür habe ich mir ja 2 zugelegt, damit der eine brav auf 344 und der andere brav auf 868 sendet.

Zitat von: noansi am 17 November 2018, 09:16:17Die Frequenz solltest Du beim 433er auf 433.92MHz umstellen. Das geht mit set freq 433.92 in fhem.
Das habe ich gleich mal gemacht und schon steht bei den 433er auch:ccconf
freq:433.920MHz freqOffs:0.000kHz bWidth:325kHz freqIF:330.08kHz rAmpl:42dB sens:12dB dRate:2.461kBit/s
agcPrio:1 agcWait:32 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:0 AGC_FREEZE:0
CCAmode:0 csRelThr:14dB csAbsThr:5dB


Zitat von: noansi am 17 November 2018, 09:16:17Wenn Du den Anschluss A0 (entsprechend PortC Bit0 am Prozessor) am nanoCUL mit 150Ohm nach GND verbindest, dann sollte sich der nanoCUL mit tsculfw in der Version auch als CSM433 melden und die Frequenz auch auf 433.92Mhz als Firmwaredefault (Rücksetzen mit e) einstellen. Alternativ kann man das mit Anpasung der board.h auch fest in die Firmware reincompilieren, statt A0 mit 150Ohm nach GND zu verbinden.
Das muss ich mir mal etwas genauer anschauen, mal sehen, ob ich dazu etwas (Anleitung) finde. Ich weiß nicht, ob es auch generell sinnvoll wäre, wenn ich den 433er zum Beispiel mal wieder zurück flashen möchte. Wofür ist das eigentlich? Um die Einstellung "set freq 433.92" nicht machen zu müssen? Das macht man dann doch nur einmal, muss man eben nur wissen ... Oder hat dies jetzt einen anderen Grund? Ich gehe jetzt mal davon aus, dass wenn man den 433er mit dem TS flasht, er für 868 geflasht ist und man ihm mit "set freq 433.92" oder "150Ohm" oder "board.h" dann nach jedem Flashen die richtige Frequenz geben muss. Dann muss ich mir das einfach mal merken, macht man ja dann nur nach dem Flashen. Oder hab ich das falsch verstanden?

Zitat von: noansi am 17 November 2018, 09:16:17Außerdem sollte er bei Verwendung der a-culfw für den 433er auch das Standard CUL Modul und das Standard IT Modul für den 433er verwenden und nicht das TSCUL Modul und das IT Modul meiner Variante.
Was sind die "Standard-Module"?

Laut diesen Beitrag (https://forum.fhem.de/index.php/topic,24436.msg825473.html#msg825473) vielleicht 00_CUL.pm und 10_IT.pm? Die 00_CUL.pm wird mit der 00_TSCUL.pm egänzt,so dass, wenn man den 868er mit TS und den 433er mit a-culfw geflasht hat, beide CUL´s laufen können. Da aber die 10_IT.pm ausgetauscht wird, ist dies wohl nicht möglich, oder verstehe ich das falsch? Wenn dies möglich ist, bräuchte ich ja den 433er gar nicht mit Ts zu flashen, könnte ihn zurück flashen, damit er mit den IT-Dingern vielleicht mehr und bessere Möglichkeiten hat. Da weiß ich nun nicht, was das Richtige wäre.

Mit TS hatte ich es ja ursprünglich geflasht, weil die Fenstersensoren sich nicht pairen ließen. Da las ich das mit dem AES oder wie das jetzt hieß, also die Verschlüsselung, die standardmäßig aktiviert ist, was mich eben zu diesen Schritt zwang. Und als es dann Probleme gab, flashte ich auch den 433er.

Zitat von: noansi am 17 November 2018, 10:28:53hier https://forum.fhem.de/index.php/topic,24436.msg825473.html#msg825473 (https://forum.fhem.de/index.php/topic,24436.msg825473.html#msg825473) habe ich die 00_TSCUL.pm in der zip zum Code angepasst, um die oben angesprochenen CC0 = 0D / 13 log Einträge raus zu filtern.
Das habe ich dann auch gleich mal aktualisiert.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: noansi am 17 November 2018, 21:32:13
Hallo jw1hal,

ZitatUm die Einstellung "set freq 433.92" nicht machen zu müssen?
Ja. Und niemand zwingt Dich die Marker Option zu löten und somit zu nutzen.
Und lass, es, wenn Dir mein Satz Anleitung zu unklar ist.
A0 entspricht der Platinenpinbezeichung eines Nano V3.0, wie via Suche über Goggle nachzulesen.

ZitatAlso senden die CUL´s generell da, wie es in den einzelnen Geräten angegeben ist?
So ist es, bzw. genau genommen solltest Du die Frequenzen mit get (ITSendFreq, get SlowRfSendFreq) erst mal beim nanoCUL auslesen, um garantiert aktuelle Werte zu sehen. Im SlowRf Modus kannst Du auch beide Frequenzen verstellen, um sie feiner an Deine Geräte anpassen zu können.
Im Homematic Modus kannst Du nur die IT-Sendefrequenz verstellen, da die für Homematic ist fest programmiert ist (nur der Frequenzoffset ist für Finetuning noch anpassbar).
Auf 344Mhz sollst Du sicher nicht senden (Schreibfehler). ;)

ZitatWas sind die "Standard-Module"? ... vielleicht 00_CUL.pm und 10_IT.pm?
Ja, die, die Du in FHEM direkt dabei hast bzw. per Update bekommen kannst, bezeichne ich mal als "Standard".


Zu den Bildern:
Das 5. Bild mit dem HS2272C-L2 deutet auf IT hin. Vermutlich ähnlich dem PT2272, zu dem man ein Datenblatt finden kann. Dann wären der Basistakt zu ermitteln, um ITClock richtig wählen zu können und die Schaltcodes nach Beschaltung.
Ich tippe mal auf F000FFFF10 F0 F1 für die IT Schaltcodes. ITClock 224.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: jw1hal am 18 November 2018, 07:38:32
Zitat von: noansi am 17 November 2018, 21:32:13Ja. Und niemand zwingt Dich die Marker Option zu löten und somit zu nutzen.
Und lass, es, wenn Dir mein Satz Anleitung zu unklar ist.
A0 entspricht der Platinenpinbezeichung eines Nano V3.0, wie via Suche über Goggle nachzulesen.
Das ist das, was ich meine. Die Profi´s unter euch haben so ein Ding schön öfter gesehen, sich näher damit beschäftigt oder auch selbst gebaut. Vielleicht auch so etwas beruflich gelernt. Ich nicht, bin nur ein blöder Holzwurm, der jetzt was anderes macht. Ich hab das zum ersten Mal gesehen und vorher noch nicht gewusst, dass es das so gibt. Ich kann bissel mit nen Lötkolben umgehen, ich weiß was ein Widerstand ist, kann nach bebilderten oder auch Videoanleitungen etwas nachmachen und eventuell auch, wenn es mir logisch erscheint, nach einen Satz Anleitung etwas nachvollziehen. Dazu muss ich das aber auch alles kennen, damit ich dem allen folgen kann. Ich müsste mir den CUL nun genauer anschauen und dazu einen Stuhl nehmen, um den CUL vom Pi zu entfernen. Die Faulheit ... Dann ist da noch ein durchsichtiger Schrumpfschlauch drum, der ihn bissel schützt. Somit würde ich mich nur ensthaft näher damit beschäftigen, wenn es unbedingt sein muss und keinen anderen Ausweg gibt. Wenn ich nun täglich oder wöchentlich die Frequenz einstellen müsste, würde ich es bestimmt tun. Da ich dies aber nur nach dem Flashen machen muss und dies nicht so oft vorkommen wird, kann ich beruhigt damit leben. Ich muss auch den schönen Schrumpfschlauch nicht kaputt machen und kann auch noch selbst meine Faulheit unterstützen. Aber ich werde mir (versprochen!) den CUL mal genauer anschauen, wenn ich etwas Langeweile habe oder ihn eh mal abziehen muss. Dann werde ich hier nochmal den Beitrag suchen und diesen A0 ausfindig machen, wenn man dies durch den Schrumpfschlauch sieht. Und dann werde ich, wenn ich mal bei mir zu Hause bin, auch schauen, ob ich einen 150 Ohm Widerstand habe, um das überhaupt machen zu können, ohne jetzt extra einen bestellen zu müssen. Und den Schrumpfschlauch vom CUL jetzt extra kaputt machen, wegen nur mal Gucken, möchte ich nun auch nicht unbedingt.

Dennoch ist es gut zu wissen, dass man dies so machen kann. Danke für den Hinweis. Vielleicht überlege ich es mir ja nochmal, wenn ich es mir genauer angeschaut habe. Denn so schnell wie der Widerstand eingelötet ist, ist er ja vom Prinzip auch wieder ausgelötet.

Zitat von: noansi am 17 November 2018, 21:32:13So ist es, bzw. genau genommen solltest Du die Frequenzen mit get (ITSendFreq, get SlowRfSendFreq) erst mal beim nanoCUL auslesen, um garantiert aktuelle Werte zu sehen. Im SlowRf Modus kannst Du auch beide Frequenzen verstellen, um sie feiner an Deine Geräte anpassen zu können.
Im Homematic Modus kannst Du nur die IT-Sendefrequenz verstellen, da die für Homematic ist fest programmiert ist (nur der Frequenzoffset ist für Finetuning noch anpassbar).
Das ist auch gut zu wissen und werde ich mal probieren. Das Letztere hatte ich hier im Thred schon ein oder mehrmals gelesen.

Zitat von: noansi am 17 November 2018, 21:32:13Auf 344Mhz sollst Du sicher nicht senden (Schreibfehler). ;)
Haha, ja da habe ich die Wechstaben verbuchselt bzw. die Zahlen. Da hat wohl das Millitär seinen Mobilfunkdienst ...

Zitat von: noansi am 17 November 2018, 21:32:13Ja, die, die Du in FHEM direkt dabei hast bzw. per Update bekommen kannst, bezeichne ich mal als "Standard".
Könnte ich dann dennoch den 433er mit a-culfw laufen lassen oder beißt sich da was, weil ja die 10_IT.pm überschrieben wird.

Zitat von: noansi am 17 November 2018, 21:32:13Zu den Bildern:
Das 5. Bild mit dem HS2272C-L2 deutet auf IT hin. Vermutlich ähnlich dem PT2272, zu dem man ein Datenblatt finden kann. Dann wären der Basistakt zu ermitteln, um ITClock richtig wählen zu können und die Schaltcodes nach Beschaltung.
Ich tippe mal auf F000FF10 F0 F1 für die IT Schaltcodes. ITClock 224.
Das ist auch sehr interessant. Ich werde es mir noch mal genauer ansehen. Vielleicht bekomme ich die Dinge ja doch noch in´s Fhem.

Danke auf Jeden Fall mal für die prompte Hilfe und einen schönen Sonntag noch.

PS: Als ich heute Morgen nach Hause kam, funktionierte alles noch, wie es sein sollte. Mit der Fernbedienung konnte ich den TV hier anschalten und Alexa schaltete mir auch die DBox2, nebst TV an, welche beide jeweils an einer Funksteckdose hängen. Also 433 ist alles OK.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: noansi am 18 November 2018, 09:09:53
Hallo jw1hal,

ZitatKönnte ich dann dennoch den 433er mit a-culfw laufen lassen oder beißt sich da was, weil ja die 10_IT.pm überschrieben wird.
Du kannst den 433er mit der a-culfw flashen und ihn dann wieder via
define CUL_433 CUL /dev/CUL433@38400 0000
einbinden, also mit CUL statt TSCUL.

Bei Deinen 433er Geräten (Schaltdosen) muss das Attribut IODev auf CUL_433 gesetzt sein (oder werden, falls es nicht so ist). Ohne gesetztes Attribut wählt FHEM ein IODev aus, ohne jedoch auf die Frequenztauglichkeit zu achten, sprich der falsche IODev kann gewählt werden.

Dann nimmst Du Dir Dein Backup, dass Du sicherlicher vor Überschreiben der original Datei im FHEM Ordner gemacht hast, und kopierst daraus die original 10_IT.pm in den FHEM Ordner, überschreibst also meine Sondervariante mit der original Datei.
Sollte wider Erwarten das Backup nicht vorliegen, kannst Du auch von hier https://svn.fhem.de/trac/browser/trunk/fhem (https://svn.fhem.de/trac/browser/trunk/fhem) den aktuellen Stand runter laden.

Und dann bist Du mit dem 433er mit a-culfw hier auch off-topic, wie Arnd schon richtig bemerkt hat.

Gruß, Ansgar.

PS: Der Tip mit den IT Schaltcodes F000FFFF10 F0 F1 bezieht sich nur auf die Platine aus Bild 6. Wenn ich es bei der schlechten Auflösung richtig habe erkennen können.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: jw1hal am 18 November 2018, 15:28:25
Hallo noansi,

ich weiß jetzt nicht, ob wir aneinander vorbeireden. Ich habe 2xCUL, einmal 868 und einmal 433. Beide greifen sicherlich auf die besagte Datei "10_IT.pm" zu. Ich bin kein Experte, weiß nicht was die Datei macht und in wie weit die beiden CUL´s darauf zugreifen werden. Sie hat sicherlich mehr oder weniger mit IT zu tun, was dann wohl eher auf 433 schließen lässt oder wo eben mehr der 433er CUL in Frage kommen würde.
Die Frage ich aber nun für mich und die ist immer noch offen, ob der 868er CUL mit der TS-Firmware und der 433er CUL mit der a-culfw-Firmware (ich glaube 1.67 oder so war das) noch ordentlich ihre Arbeit machen, wenn ich die Datei "10_IT.pm" aus der Sicherung wieder nehme.

Die nächste Frage wäre für mich was nun vorteilhafter für den 433er wäre. Für die die Fensterkontakte brauche ich ja wohl TS auf den 868er. Aber was ist nun ganz ehrlich für 433 besser? Ich meine jetzt gerade, wo beide CUL´s mit TS laufen, habe ich den Eindruck, dass es läuft. Alles was da ist wird geschalten und gut ist. Allerdings habe ich ja noch ein paar Dosen, die noch nicht laufen. Und wenn da mit a-culfw mehr Chancen bestehen (den Eindruck habe ich), wäre dies doch dann besser. Dann wäre ich aber wieder bei der Frage aus dem obrigen Abschnitt.

Die Dosen haben auch alle das Attribut IODev auf CUL_433 gesetzt. Ich würde ja gerne alles posten, damit man es sieht, befürchte aber, dass es dann zu viel wird. Gut, im Einsatz habe ich nur 5. Das sind die Dinger von Brennenstuhl. Und das sind, wenn ich jetzt so überlege, die einzigen Sachen, die über 433 laufen. Der Rest läuft über 868 (HM; Lichtschalter, Thermostate und Fensterkontakte) und IP (Sonoff, DBox2 und Sony-TV).
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: noansi am 18 November 2018, 16:42:45
Hallo jw1hal,

ZitatDie Frage ich aber nun für mich und die ist immer noch offen, ob der 868er CUL mit der TS-Firmware und der 433er CUL mit der a-culfw-Firmware (ich glaube 1.67 oder so war das) noch ordentlich ihre Arbeit machen, wenn ich die Datei "10_IT.pm" aus der Sicherung wieder nehme.
Der 868er wird sie nicht nutzen.

Die aktuelle a-culfw findest Du hier https://forum.fhem.de/index.php/topic,35064.msg273774.html#msg273774 (https://forum.fhem.de/index.php/topic,35064.msg273774.html#msg273774).

ZitatDie nächste Frage wäre für mich was nun vorteilhafter für den 433er wäre.
Das wirst Du wohl schlicht ausprobieren müssen.

Mit einem Backup vom jetzigen Stand, mit dem es anscheinend gar nicht mal so schlecht läuft, kannst Du auch wieder zurück.

ZitatUnd wenn da mit a-culfw mehr Chancen bestehen (den Eindruck habe ich), wäre dies doch dann besser.
In jedem Fall musst Du die Fernbedienung zu diesen Dosen noch funktionsfähig haben, da mit Autcreate nur was gehen kann, wenn der 433er CUL das Schalttelegram empfangen kann.

Gruß, Ansgar
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: jw1hal am 19 November 2018, 09:52:52
Hallo noansi,

ich danke dir. Dann werde ich mal probieren.


Gruß jw1hal
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: presskopf am 26 November 2018, 11:59:15
Hallo Ansgar, hallo alle,

seit geraumer Zeit nutze ich TSCUL eigentlich ohne Probleme; bin auch auf 0.29, wobei 0.26 auch anstandslos bei mir lief.
Ich habe 3 CULs (Arduino Nano) am Start. Zwei über ser2net an Raspberries im LAN; der Erste am Server.

Jetzt macht seit Kurzem einer der drei Burschen: CUL5 Probleme, indem er nicht mehr senden kann.
Erst nach einem reopen läuft er wieder - aber nur für kurze Zeit.

Jemand eine Idee?
Hat der Arduino einen Schatten oder habe ich was falsch konfiguriert?


Um 11:30 habe ich mal ein "set roll_kitchen stop" gesendet.

Hier das relevante Log:


018.11.26 10:09:20 3: LogHist CUL5:  448367 A F402 00779844 00 15 AA001122AA001122AA001122AA001122AA001122AA _ping
2018.11.26 10:09:20 3: LogHist CUL5:  455959 A F401 00787440 00 0C 78 865A 43110F 000000 B4E233 -78dB
2018.11.26 10:09:20 3: LogHist CUL5:  471427 A F402 00802916 00 15 AA001122AA001122AA001122AA001122AA001122AA _ping
2018.11.26 10:09:20 3: LogHist CUL5:  475973 A F401 00807444 00 0C 78 8470 43110F 000000 00E233 -78dB
2018.11.26 10:09:20 3: LogHist CUL5:  478510 A F401 00809972 00 0C 15 865A 3EF2D6 000000 ACDC2E -68.5dB
2018.11.26 10:09:20 3: LogHist CUL5:  485600 A F401 00817020 00 0D FA 8410 5160AA ABCDEF 06012300 -59dB
2018.11.26 10:09:20 3: LogHist CUL5:  498561 A F401 00829976 00 0C 15 8470 3EF2D6 000000 00DC2E -68.5dB
2018.11.26 10:09:20 3: LogHist CUL5:  499300 A F401 00830720 00 0D 26 8410 516081 ABCDEF 06012300 -66dB
2018.11.26 10:09:20 3: LogHist CUL5:  502155 A F402 00833656 00 01 CC _ping
2018.11.26 10:09:20 3: LogHist CUL5:  502970 A F402 00834456 00 15 AA001122AA001122AA001122AA001122AA001122AA _ping
2018.11.26 10:09:20 3: LogHist CUL5:  506314 A F40C 00837800 00 0D F8 A610 44BC95 ABCDEF 06010000 -80.5dB _AEScommReq
2018.11.26 10:09:20 3: LogHist CUL5:  506534 A F403 00837976 15 11 F8 A002 ABCDEF 44BC95 0449F64FDA9BC802 _CCAdly:84 _dhmSt:176
2018.11.26 10:09:20 3: LogHist CUL5:  506585 A F40C 00838072 00 0D F9 A610 44BC95 ABCDEF 06010000 -81dB _AEScommReq
2018.11.26 10:09:20 3: LogHist CUL5:  506858 A F403 00838304 23 11 F9 A002 ABCDEF 44BC95 0418DCBC04F53C02 _CCAdly:140 _dhmSt:232
2018.11.26 10:09:20 3: TSCUL_ParseTsHM: CUL5 HM AES Comm Req device authentication timed out from 44BC95/door_base:  506965 A F412 00838456 00 0D F9 A610 44BC95 ABCDEF 06010000 -81dB _AuthTimeout
2018.11.26 10:09:20 3: LogHist CUL5:  455959 A F401 00787440 00 0C 78 865A 43110F 000000 B4E233 -78dB
2018.11.26 10:09:20 3: LogHist CUL5:  471427 A F402 00802916 00 15 AA001122AA001122AA001122AA001122AA001122AA _ping
2018.11.26 10:09:20 3: LogHist CUL5:  475973 A F401 00807444 00 0C 78 8470 43110F 000000 00E233 -78dB
2018.11.26 10:09:20 3: LogHist CUL5:  478510 A F401 00809972 00 0C 15 865A 3EF2D6 000000 ACDC2E -68.5dB
2018.11.26 10:09:20 3: LogHist CUL5:  485600 A F401 00817020 00 0D FA 8410 5160AA ABCDEF 06012300 -59dB
2018.11.26 10:09:20 3: LogHist CUL5:  498561 A F401 00829976 00 0C 15 8470 3EF2D6 000000 00DC2E -68.5dB
2018.11.26 10:09:20 3: LogHist CUL5:  499300 A F401 00830720 00 0D 26 8410 516081 ABCDEF 06012300 -66dB
2018.11.26 10:09:20 3: LogHist CUL5:  502155 A F402 00833656 00 01 CC _ping
2018.11.26 10:09:20 3: LogHist CUL5:  502970 A F402 00834456 00 15 AA001122AA001122AA001122AA001122AA001122AA _ping
2018.11.26 10:09:20 3: LogHist CUL5:  506314 A F40C 00837800 00 0D F8 A610 44BC95 ABCDEF 06010000 -80.5dB _AEScommReq
2018.11.26 10:09:20 3: LogHist CUL5:  506534 A F403 00837976 15 11 F8 A002 ABCDEF 44BC95 0449F64FDA9BC802 _CCAdly:84 _dhmSt:176
2018.11.26 10:09:20 3: LogHist CUL5:  506585 A F40C 00838072 00 0D F9 A610 44BC95 ABCDEF 06010000 -81dB _AEScommReq
2018.11.26 10:09:20 3: LogHist CUL5:  506858 A F403 00838304 23 11 F9 A002 ABCDEF 44BC95 0418DCBC04F53C02 _CCAdly:140 _dhmSt:232
2018.11.26 10:09:20 3: LogHist CUL5:  506965 A F412 00838456 00 0D F9 A610 44BC95 ABCDEF 06010000 -81dB _AuthTimeout
2018.11.26 10:09:20 3: TSCUL_ParseTsHM: CUL5 HM repeat failed to 44BC95/door_base:  507077 A F409 00838576 00 11 F9 A002 ABCDEF 44BC95 0418DCBC04F53C02 _sfail _noAnsw
2018.11.26 10:09:59 1: RMDIR: ./restoreDir/save/2018-11-23
2018.11.26 10:15:45 3: CUL_HM set roll_kitchen stop
2018.11.26 10:23:33 3: LogHist CUL5:  267087                 As 0D FA 8002 ABCDEF 516475 01012100
2018.11.26 10:23:33 3: LogHist CUL5:  267090 A F101 01647312 00 0D FA A641 516475 ABCDEF 01A02150 -56dB
2018.11.26 10:23:33 3: LogHist CUL5:  267216 A F103 01647408 01 0A FA 8002 ABCDEF 516475 00 _CCAdly:4 _dhmSt:96
2018.11.26 10:23:33 3: LogHist CUL5:  267319 A F103 01647512 01 0D FA 8002 ABCDEF 516475 01012100 _CCAdly:4 _dhmSt:200
2018.11.26 10:23:33 3: LogHist CUL5:  277711 A F101 01657908 00 0C 3A 8470 3F81C7 000000 00AF3B -83dB
2018.11.26 10:23:33 3: LogHist CUL5:  277819 A F101 01657952 00 0D FB 8410 516475 ABCDEF 06012100 -56.5dB
2018.11.26 10:23:33 3: LogHist CUL5:  302587 A F101 01682804 00 0C 74 865A 430EFE 000000 98BF3C -78dB
2018.11.26 10:23:33 3: LogHist CUL5:  306313 A F101 01686556 00 0D FC A641 516475 ABCDEF 01A12150 -59dB
2018.11.26 10:23:33 3: LogHist CUL5:  306321                 As 0D FC 8002 ABCDEF 516475 01012100
2018.11.26 10:23:33 3: LogHist CUL5:  306461 A F103 01686672 06 0A FC 8002 ABCDEF 516475 00 _CCAdly:24 _dhmSt:116
2018.11.26 10:23:33 3: LogHist CUL5:  306572 A F103 01686776 01 0D FC 8002 ABCDEF 516475 01012100 _CCAdly:4 _dhmSt:220
2018.11.26 10:23:33 3: LogHist CUL5:  307092 A F101 01687264 00 0D FE 8410 5160AA ABCDEF 06012300 -58dB
2018.11.26 10:23:33 3: LogHist CUL5:  311155 A F10C 01691396 00 0C FB A641 44BC95 ABCDEF 0132C8 -77dB _AEScommReq
2018.11.26 10:23:33 3: LogHist CUL5:  311298 A F103 01691492 01 11 FB A002 ABCDEF 44BC95 04E3358E717A5B02 _CCAdly:4 _dhmSt:96
2018.11.26 10:23:33 3: TSCUL_ParseTsHM: CUL5 HM repeat failed to 44BC95/door_base:  311522 A F109 01691764 00 11 FB A002 ABCDEF 44BC95 04E3358E717A5B02 _sfail _noAnsw
2018.11.26 10:47:31 1: PERL WARNING: Argument "on" isn't numeric in numeric gt (>) at ./FHEM/98_SVG.pm line 1556.
2018.11.26 10:47:31 1: PERL WARNING: Argument "off" isn't numeric in numeric gt (>) at ./FHEM/98_SVG.pm line 1556.
2018.11.26 10:47:31 1: PERL WARNING: Argument "on" isn't numeric in subtraction (-) at ./FHEM/98_SVG.pm line 1928.
2018.11.26 10:47:31 1: PERL WARNING: Argument "off" isn't numeric in subtraction (-) at ./FHEM/98_SVG.pm line 1928.
2018.11.26 10:47:31 1: PERL WARNING: Argument "off" isn't numeric in sprintf at ./FHEM/98_SVG.pm line 2197.
2018.11.26 10:55:45 3: ABFALL myAbfall - CALENDAR:myCalendar triggered, updating ABFALL myAbfall ...
2018.11.26 10:55:45 3: ABFALL_UPDATE
2018.11.26 10:55:45 2: get myCalendar text is deprecated and will be removed soon. Use get myCalendar events instead.
2018.11.26 11:25:27 2: TSCUL_ReceiveDelayed: CUL5  C 00=07 01=2E 02=01 03=42 04=E9 05=CA 06=31 07=0C 08=45 09=00 0A=00 0B=06 0C=F3 0D=0D 0E=65 0F=6A 10=C8 11=93 12=03 13=22 14=F8 15=34 16=07 17=3C 18=18 19=16 1A=6C 1B=43 1C=67 1D=91 1E=87 1F=6B 20=F8 21=56 22=10 23=AB 24=2B 25=38 26=11 27=41 28=68 29=68 2A=68 2B=3E 2C=68 2D=68 2E=68 2F=00 30=00 31=14 32=F2 33=00 34=C0 35=0D 36=00 37=00 38=30 39=BE 3A=00 3B=00 3C=00 3D=00
2018.11.26 11:30:19 3: CUL_HM set roll_kitchen stop
2018.11.26 11:30:20 3: TSCUL_ParseTsHM: CUL5 HM CCA channel busy error to 3FC88B/roll_kitchen:  124331 A F004 05698628 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:22 3: TSCUL_ParseTsHM: CUL5 HM CCA channel busy error to 3FC88B/roll_kitchen:  125594 A F004 05699888 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:23 3: TSCUL_ParseTsHM: CUL5 HM CCA channel busy error to 3FC88B/roll_kitchen:  126856 A F004 05701148 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:23 3: LogHist CUL5:  412570 A F001 03890324 00 0E 21 8410 3EF2D6 000000 0BACDF0B40 -65.5dB
2018.11.26 11:30:23 3: LogHist CUL5:  414464 A F001 03892284 00 0C 9D 865A 432C73 000000 98CB36 -71.5dB
2018.11.26 11:30:23 3: LogHist CUL5:  415153 A F001 03892944 00 0D 36 8041 3F81A7 4B7E69 0731C880 -63dB
2018.11.26 11:30:23 3: LogHist CUL5:  417501 A F001 03895320 00 0D 30 8410 516081 ABCDEF 06012400 -65dB
2018.11.26 11:30:23 3: LogHist CUL5:  422502 A F001 03900324 00 0C 29 8470 3EF2D6 000000 00DF2E -66dB
2018.11.26 11:30:23 3: LogHist CUL5:  168256 A F002 04170416 00 01 C3 _ping
2018.11.26 11:30:23 3: LogHist CUL5:  314294 A F002 04316488 00 01 CC _ping
2018.11.26 11:30:23 3: LogHist CUL5:  390321 A F002 04916916 00 01 CC _ping
2018.11.26 11:30:23 3: LogHist CUL5:  143680 A F002 05194616 00 01 C3 _ping
2018.11.26 11:30:23 3: LogHist CUL5:  466358 A F002 05517348 00 01 CC _ping
2018.11.26 11:30:23 3: LogHist CUL5:  123284                 As 0B F1 A011 ABCDEF 3FC88B 0301
2018.11.26 11:30:23 3: LogHist CUL5:  124331 A F004 05698628 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:23 3: LogHist CUL5:  125594 A F004 05699888 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:23 3: LogHist CUL5:  126856 A F004 05701148 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:23 3: TSCUL_ParseTsHM: CUL5 HM repeat failed to 3FC88B/roll_kitchen:  127096 A F009 05702408 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail _noAnsw
2018.11.26 11:30:26 3: TSCUL_ParseTsHM: CUL5 HM CCA channel busy error to 3FC88B/roll_kitchen:  129588 A F004 05703880 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:27 3: TSCUL_ParseTsHM: CUL5 HM CCA channel busy error to 3FC88B/roll_kitchen:  130835 A F004 05705140 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:28 3: TSCUL_ParseTsHM: CUL5 HM CCA channel busy error to 3FC88B/roll_kitchen:  132098 A F004 05706400 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:28 3: LogHist CUL5:  168256 A F002 04170416 00 01 C3 _ping
2018.11.26 11:30:28 3: LogHist CUL5:  314294 A F002 04316488 00 01 CC _ping
2018.11.26 11:30:28 3: LogHist CUL5:  390321 A F002 04916916 00 01 CC _ping
2018.11.26 11:30:28 3: LogHist CUL5:  143680 A F002 05194616 00 01 C3 _ping
2018.11.26 11:30:28 3: LogHist CUL5:  466358 A F002 05517348 00 01 CC _ping
2018.11.26 11:30:28 3: LogHist CUL5:  123284                 As 0B F1 A011 ABCDEF 3FC88B 0301
2018.11.26 11:30:28 3: LogHist CUL5:  124331 A F004 05698628 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:28 3: LogHist CUL5:  125594 A F004 05699888 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:28 3: LogHist CUL5:  126856 A F004 05701148 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:28 3: LogHist CUL5:  127096 A F009 05702408 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail _noAnsw
2018.11.26 11:30:28 3: LogHist CUL5:  128534                 As 0B F1 A011 ABCDEF 3FC88B 0301
2018.11.26 11:30:28 3: LogHist CUL5:  129588 A F004 05703880 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:28 3: LogHist CUL5:  130835 A F004 05705140 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:28 3: LogHist CUL5:  132098 A F004 05706400 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:28 3: TSCUL_ParseTsHM: CUL5 HM repeat failed to 3FC88B/roll_kitchen:  132337 A F009 05707660 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail _noAnsw
2018.11.26 11:30:30 3: TSCUL_ParseTsHM: CUL5 HM CCA channel busy error to 3FC88B/roll_kitchen:  134031 A F004 05708328 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:31 3: TSCUL_ParseTsHM: CUL5 HM CCA channel busy error to 3FC88B/roll_kitchen:  135293 A F004 05709588 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:33 3: TSCUL_ParseTsHM: CUL5 HM CCA channel busy error to 3FC88B/roll_kitchen:  136554 A F004 05710848 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:33 3: LogHist CUL5:  123284                 As 0B F1 A011 ABCDEF 3FC88B 0301
2018.11.26 11:30:33 3: LogHist CUL5:  124331 A F004 05698628 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:33 3: LogHist CUL5:  125594 A F004 05699888 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:33 3: LogHist CUL5:  126856 A F004 05701148 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:33 3: LogHist CUL5:  127096 A F009 05702408 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail _noAnsw
2018.11.26 11:30:33 3: LogHist CUL5:  128534                 As 0B F1 A011 ABCDEF 3FC88B 0301
2018.11.26 11:30:33 3: LogHist CUL5:  129588 A F004 05703880 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:33 3: LogHist CUL5:  130835 A F004 05705140 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:33 3: LogHist CUL5:  132098 A F004 05706400 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:33 3: LogHist CUL5:  132337 A F009 05707660 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail _noAnsw
2018.11.26 11:30:33 3: LogHist CUL5:  132983                 As 0B F1 A011 ABCDEF 3FC88B 0301
2018.11.26 11:30:33 3: LogHist CUL5:  134031 A F004 05708328 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:33 3: LogHist CUL5:  135293 A F004 05709588 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:33 3: LogHist CUL5:  136554 A F004 05710848 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:33 3: TSCUL_ParseTsHM: CUL5 HM repeat failed to 3FC88B/roll_kitchen:  136795 A F009 05712108 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail _noAnsw
2018.11.26 11:30:36 3: TSCUL_ParseTsHM: CUL5 HM CCA channel busy error to 3FC88B/roll_kitchen:  139830 A F004 05714132 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:37 3: TSCUL_ParseTsHM: CUL5 HM CCA channel busy error to 3FC88B/roll_kitchen:  141098 A F004 05715392 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:38 3: TSCUL_ParseTsHM: CUL5 HM CCA channel busy error to 3FC88B/roll_kitchen:  142354 A F004 05716652 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:39 3: LogHist CUL5:  128534                 As 0B F1 A011 ABCDEF 3FC88B 0301
2018.11.26 11:30:39 3: LogHist CUL5:  129588 A F004 05703880 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:39 3: LogHist CUL5:  130835 A F004 05705140 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:39 3: LogHist CUL5:  132098 A F004 05706400 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:39 3: LogHist CUL5:  132337 A F009 05707660 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail _noAnsw
2018.11.26 11:30:39 3: LogHist CUL5:  132983                 As 0B F1 A011 ABCDEF 3FC88B 0301
2018.11.26 11:30:39 3: LogHist CUL5:  134031 A F004 05708328 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:39 3: LogHist CUL5:  135293 A F004 05709588 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:39 3: LogHist CUL5:  136554 A F004 05710848 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:39 3: LogHist CUL5:  136795 A F009 05712108 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail _noAnsw
2018.11.26 11:30:39 3: LogHist CUL5:  138786                 As 0B F1 A011 ABCDEF 3FC88B 0301
2018.11.26 11:30:39 3: LogHist CUL5:  139830 A F004 05714132 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:39 3: LogHist CUL5:  141098 A F004 05715392 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:39 3: LogHist CUL5:  142354 A F004 05716652 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
2018.11.26 11:30:39 3: TSCUL_ParseTsHM: CUL5 HM repeat failed to 3FC88B/roll_kitchen:  142594 A F009 05717912 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail _noAnsw


list CUL5

Internals:
   CMDS       ABCEFGJKMNRUVWXYZeilmtx
   CUL5_MSGCNT 648
   CUL5_TIME  2018-11-26 11:00:21
   Clients    STACKABLETS:STACKABLE:CUL_HM:CUL_IR:HMS
   DEF        192.168.0.205:5555 5555
   DeviceName 192.168.0.205:5555
   FD         25
   FHTID      5555
   NAME       CUL5
   NR         791
   PARTIAL   
   RAWMSG     A0C2984703EF2D600000000DF2E::-66:CUL5:
   RSSI       -66
   STATE      Initialized
   TYPE       TSCUL
   VERSION    VTS 0.29 CSM868
   VERSION_HW nanoCUL_V1.x
   VERSION_TS yes AES ChTblSize:220
   XmitOpen   1
   assignUpdCntI 5
   assignedIDsCnt 3
   initString X21
Ar
AM5
AHABCDEF
   owner_CCU  VCCU
   MatchList:
     1:STACKABLETS ^\*
     2:STACKABLE ^\*
     A:CUL_HM   ^A....................
     B:CUL_IR   ^I............
     C:HMS      ^810e04......a001
   READINGS:
     2018-11-26 09:55:45   Xmit-Events     non-HM:1 init:1 disconnected:1 ok:1
     2017-07-29 21:23:58   ccconf          freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:8dB
     2018-11-26 09:55:25   cmds             A B C E F G J K M N R U V W X Y Z e i l m t x
     2018-11-26 09:55:45   cond            ok
     2018-11-26 09:55:20   prot_disconnected last
     2018-11-26 09:55:27   prot_init       last
     2018-11-26 09:55:27   prot_non-HM     last
     2018-11-26 09:55:45   prot_ok         last
     2018-11-26 11:21:55   scF             0.999804466406144
     2018-11-26 09:55:27   state           Initialized
     2018-10-22 23:46:20   uptime          0 15:15:03
     2018-11-26 10:12:38   version         VTS 0.29 CSM868
   helper:
     CUrun      1
     ChkPart    0
     RA_Timeout 0
     VTS        1
     VTS_ACK    1
     VTS_AES    1
     assIdCnt   3
     assIdRep   3
     hmTSAt1Add
     recd       0
     tbuf       
     DEVIO:
       RXfailTO   
     HM:
       ChTblSize  220
       FUP        0
       HMactive   1
       hmCrdts    0
       hmSbusy    0
       ChTbl:
         3FC88B3F   01
         44BC9501   01
         5164753F   01
       msgCNT:
         0x01       633
         0x02       76
         0x03       29
         0x04       12
         0x09       6
         0x0C       7
         0x0E       4
         0x12       1
       unknwn:
     cnd:
       0          1
       250        1
       253        1
       255        1
     hmLogHist:
        130835 A F004 05705140 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
        132098 A F004 05706400 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
        132337 A F009 05707660 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail _noAnsw
        132983                 As 0B F1 A011 ABCDEF 3FC88B 0301
        134031 A F004 05708328 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
        135293 A F004 05709588 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
        136554 A F004 05710848 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
        136795 A F009 05712108 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail _noAnsw
        138786                 As 0B F1 A011 ABCDEF 3FC88B 0301
        139830 A F004 05714132 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
        141098 A F004 05715392 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
        142354 A F004 05716652 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail
        142594 A F009 05717912 00 0B F1 A011 ABCDEF 3FC88B 0301 _sfail _noAnsw
        018109 A F002 06117792 00 01 CC _ping
     hmQ:
       3FC88B:
       44BC95:
       516475:
     ids:
       3FC88B:
         cfg        +3FC88B,00,01,00
         name       roll_kitchen
       44BC95:
         cfg        +44BC95,01,01,02
         name       door_base
       516475:
         cfg        +516475,00,01,00
         name       motion_base
     q:
       ATrNo      0
       HMcndN     0
       InQueues   0
       XRpCnt     0
       XRpTm      1543222546.70196
       answerPend 0
       hmLanQlen  1
       apIDs:
         3FC88B     0
       cap:
         sum        33750
     ref:
       Sdly       0
       ioByteRate 1000000
       ioByteRateMeas 3621.99548418276
       lHMt       6117792
       lSys       261637821
       pTTu       1024
       pndAs      0
       pndCUAp    0
       pngLm      19
       pngMax     1177
       pngMaxTot  1177
       pngMin     11
       pngRef     17
       pngtm      260714800
       scErr      1.26550682727247
       scF        0.999804466406144
       scFN       2
       scHT       4170416
       scST       259690816
Attributes:
   hmId       ABCDEF
   hmLanQlen  1_min
   icon       cul_cul
   rfmode     HomeMatic


list roll_kitchen

Internals:
   CUL1_MSGCNT 5
   CUL1_RAWMSG A0EF080023FC88BABCDEF0101C80059::-63:CUL1:
   CUL1_RSSI  -63
   CUL1_TIME  2018-11-26 10:15:45
   CUL3_MSGCNT 5
   CUL3_RAWMSG A0EF080023FC88BABCDEF0101C80059::-82:CUL3:
   CUL3_RSSI  -82
   CUL3_TIME  2018-11-26 10:15:45
   CUL5_MSGCNT 5
   CUL5_RAWMSG A0EF080023FC88BABCDEF0101C80059::-68.5:CUL5:
   CUL5_RSSI  -68.5
   CUL5_TIME  2018-11-26 10:15:45
   DEF        3FC88B
   IODev      CUL5
   LASTInputDev CUL1
   MSGCNT     15
   NAME       roll_kitchen
   NOTIFYDEV  global
   NR         772
   NTFY_ORDER 50-roll_kitchen
   STATE      MISSING ACK
   TYPE       CUL_HM
   lastMsg    No:F0 - t:02 s:3FC88B d:ABCDEF 0101C80059
   protCmdDel 1
   protLastRcv 2018-11-26 10:15:45
   protRcv    5 last_at:2018-11-26 10:15:45
   protResnd  3 last_at:2018-11-26 11:30:35
   protResndFail 1 last_at:2018-11-26 11:30:39
   protSnd    7 last_at:2018-11-26 11:30:19
   protState  CMDs_done_Errors:1
   rssi_CUL5  cnt:4 min:-89 max:-89 avg:-89 lst:-89
   rssi_at_CUL1 cnt:5 min:-65 max:-62.5 avg:-63.2 lst:-63
   rssi_at_CUL3 cnt:5 min:-85.5 max:-80 avg:-82.2 lst:-82
   rssi_at_CUL5 cnt:5 min:-73 max:-67 avg:-69.09 lst:-68.5
   READINGS:
     2018-11-26 10:15:45   CommandAccepted yes
     2017-07-17 16:36:02   D-firmware      2.8
     2017-07-17 16:36:02   D-serialNr      MEQ1106629
     2018-01-09 20:32:06   PairedTo        0xABCDEF
     2018-01-09 20:32:12   R-driveDown     27 s
     2017-07-17 16:39:37   R-driveTurn     0.5 s
     2018-01-09 20:32:12   R-driveUp       27 s
     2017-07-17 16:39:36   R-pairCentral   0xABCDEF
     2017-07-17 16:39:37   R-powerUpAction off
     2017-07-17 16:39:37   R-sign          off
     2018-01-09 20:32:06   RegL_00.        02:01 0A:E4 0B:73 0C:09 15:FF 18:00 00:00
     2018-01-09 20:32:11   RegL_01.        08:00 09:00 0A:00 0B:01 0C:0E 0D:01 0E:0E 0F:05 10:00  30:06 57:24 56:00 00:00
     2018-11-26 10:15:45   deviceMsg       on (to VCCU)
     2018-11-26 10:15:45   level           100
     2018-11-26 10:15:45   motor           stop:on
     2018-11-26 10:15:45   pct             100
     2017-07-17 16:39:05   powerOn         2017-07-17 16:39:04
     2018-11-26 10:15:45   recentStateType ack
     2018-11-26 11:30:39   state           MISSING ACK
     2018-11-26 10:15:45   timedOn         off
   helper:
     HM_CMDNR   241
     cSnd       11ABCDEF3FC88B0301,11ABCDEF3FC88B0301
     dlvlCmd    ++A011ABCDEF3FC88B0201C80000
     mId        006A
     regLst     ,0,1,3p
     rxType     1
     supp_Pair_Rep 0
     ack:
     dir:
       cur        stop
       rct        up
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       lstRecType 02
       newChn     +3FC88B,00,01,00
       nextSend   1543223745.58339
       nxtSndMcnt F0
       rxt        0
       tgtDly     88
       vccu       VCCU
       lRcTm:
         CUL1       1247948
         CUL3       1232312
         CUL5       1223436
         tnms       256744407
       p:
         3FC88B
         00
         01
         00
       prefIO:
         CUL5
     mRssi:
       mNo        F0
       io:
         CUL1:
           -63
           -63
         CUL3:
           -82
           -82
         CUL5:
           -58.5
           -58.5
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       prs        1
     rssi:
       CUL5:
         avg        -89
         cnt        4
         lst        -89
         max        -89
         min        -89
       at_CUL1:
         avg        -63.2
         cnt        5
         lst        -63
         max        -62.5
         min        -65
       at_CUL3:
         avg        -82.2
         cnt        5
         lst        -82
         max        -80
         min        -85.5
       at_CUL5:
         avg        -69.1
         cnt        5
         lst        -68.5
         max        -67
         min        -73
     tmpl:
Attributes:
   IODev      CUL5
   IOgrp      VCCU:CUL5
   autoReadReg 4_reqStatus
   devStateIcon up:fts_shutter_10@green down:fts_shutter_100@black 9\d.*:fts_shutter_10 8\d.*:fts_shutter_20 7\d.*:fts_shutter_30 6\d.*:fts_shutter_40 5\d.*:fts_shutter_50 4\d.*:fts_shutter_60 3\d.*:fts_shutter_70 2\d.*:fts_shutter_80 1\d.*:fts_shutter_90 0\d.*:fts_shutter_100
   eventMap   on:up off:down stop:stop
   expert     2_raw
   firmware   2.8
   model      HM-LC-Bl1PBU-FM
   peerIDs    00000000,
   room       CUL_HM,roll
   serialNr   MEQ1106629
   subType    blindActuator
   webCmd     stop:up:90:80:70:60:50:40:30:20:10:down


log nach einem Reopen:

2018.11.26 11:41:46 0: TSCUL_Parse: CUL5 External Reset Restart detected: C_RE
2018.11.26 11:41:46 1: TSCUL_Parse: CUL5 Restart detected: C_ReadyCSM868
2018.11.26 11:41:50 3: CUL5: Possible commands: ABCEFGJKMNRUVWXYZeilmtx
2018.11.26 11:41:50 1: CUL5 is VERSION_TS, VTS 0.29 CSM868, nanoCUL_V1.x
2018.11.26 11:41:51 2: TSCUL_condUpdateHM: CUL5 new condition init
2018.11.26 11:41:51 1: 192.168.0.205:5555 reappeared (CUL5)
2018.11.26 11:41:53 2: TSCUL_condUpdateHM: CUL5 new condition ok
2018.11.26 11:42:00 3: CUL_HM set roll_kitchen stop
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: noansi am 26 November 2018, 19:42:16
Hallo Presskopf,

ZitatCUL5 HM CCA channel busy error

besagt, dass der nano meint, der Kanal sei belegt. Sprich er empfängt etwas auf der 868.3MHz Frequenz und sendet daher nicht.

Hast Du ein elektrisches/elektronisches Gerät in der Nähe des nano neu aufgebaut, was zu Störstrahlung führen könnte?
Wie alt ist das Netzteil, über den der nano (mit) versorgt wird. Sterbende oder schlechte Schaltnetzteile können auch tolle Effekt machen.

Spinnt eventuell ein auf 868MHz sendendes device in dem Hausbereich und sendet ständig (hatten wir vor einiger Zeit mal mit einem HM device und hatte ich mal mit einem SlowRF Sensor mit leer werdender Batterie)?

Du kannst ja mal CUL5 gegen CUL3 tauschen und schauen, ob das Problem mit wandert oder ob es am gleichen Ort bleibt.
Wenn es mit wandert, dann hätte der eher nano einen weg.
Wenn es am gleich Ort bleibt, dann musst Du vor Ort, respektive in dem Hausbereich nach dem Problem suchen. Ganz blöd, wenn es vom Nachbarn käme.

Gruß, Ansgar.

PS: Dein ccconf ist veraltet und enspricht nicht HM Betrieb. Den solltest Du mal neu abholen, bevor Du es in ein list packst.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: presskopf am 27 November 2018, 15:01:57
Zitat von: noansi am 26 November 2018, 19:42:16
Hast Du ein elektrisches/elektronisches Gerät in der Nähe des nano neu aufgebaut, was zu Störstrahlung führen könnte?
Wie alt ist das Netzteil, über den der nano (mit) versorgt wird. Sterbende oder schlechte Schaltnetzteile können auch tolle Effekt machen.

Hallo Ansgar,

Danke für die Tipps.
Ich habe mit dem Einfachsten angefangen, dem Netzteil. Der Nanocul lag in der Tat relativ nahe am (originalen) Raspberry-Netzteil.
Mit einem längeren Kabel (1m) zeigt sich, dass es offenbar keinen Absturz mehr gibt (bis jetzt). Zumindest ist der CUL auch nach > 15 Stunden noch einsatzbereit.
Argh.....
Nachtrag 02.01.2019 - keine Probleme bis dato

Dennoch verbleiben Logeinträge, die mich stutzig machen. Hier scheint nun mein Türsensor door_main eine Rolle zu spielen, auch wenn er bisher ohne Anstand  funktioniert.


2018.11.27 11:22:16 3: TSCUL_ParseTsHM: CUL5 HM message cleared while waiting for send 44BC98/door_main:  056371 A F104 09790284 00 00 F3 A002 ABCDEF 44BC98 04AB6836F8052B02
2018.11.27 11:22:17 3: TSCUL_ParseTsHM: CUL5 HM message cleared while waiting for send 44BC98/door_main:  057490 A F104 09791396 00 00 F4 A002 ABCDEF 44BC98 04B693E0D58CBC02
2018.11.27 11:22:21 3: TSCUL_ParseTsHM: CUL5 HM message cleared while waiting for send 44BC98/door_main:  061661 A F104 09795568 00 00 F5 A002 ABCDEF 44BC98 04DE2B699C618602
2018.11.27 11:22:22 3: TSCUL_ParseTsHM: CUL1 HM message cleared while waiting for send 44BC98/door_main:  062468 A F104 03128572 00 00 F6 A002 ABCDEF 44BC98 043CC18BC1606A02
2018.11.27 11:22:23 3: TSCUL_ParseTsHM: CUL1 HM message cleared while waiting for send 44BC98/door_main:  063521 A F104 03129628 00 00 F7 A002 ABCDEF 44BC98 04069C97F41E7002


Viele Grüße
Matthias

PS Ich mag den Thread hier nicht mit dem Thema zuhauen, falls es gar nichts mit TSCUL zu tun hat. Das kann ich aber nicht 100% einschätzen; daher bitte Bescheid geben und ich mache ein eigenes Topic auf.


list door_main

Internals:
   CUL1_MSGCNT 263
   CUL1_RAWMSG A19FDA60344BC98ABCDEFE1E916709750D64EB09D4E47FFC239E4::-72.5:CUL1:
   CUL1_RSSI  -72.5
   CUL1_TIME  2018-11-27 14:23:20
   CUL3_MSGCNT 126
   CUL3_RAWMSG A19FDA60344BC98ABCDEFE1E916709750D64EB09D4E47FFC239E4::-74:CUL3:
   CUL3_RSSI  -74
   CUL3_TIME  2018-11-27 14:23:20
   CUL5_MSGCNT 252
   CUL5_RAWMSG A0DFDA61044BC98ABCDEF06010000:AESCom-ok:-64.5:CUL5:59DFEF62
   CUL5_RSSI  -64.5
   CUL5_TIME  2018-11-27 14:23:20
   DEF        44BC98
   IODev      CUL5
   LASTInputDev CUL5
   MSGCNT     641
   NAME       door_main
   NOTIFYDEV  global
   NR         714
   NTFY_ORDER 50-door_main
   STATE      closed
   TYPE       CUL_HM
   lastMsg    No:FD - t:10 s:44BC98 d:ABCDEF 06010000
   protCmdDel 3
   protEvt_AESCom-ok 55 last_at:2018-11-27 14:23:20
   protLastRcv 2018-11-27 14:23:20
   protNack   4 last_at:2018-11-27 08:45:39
   protRcv    93 last_at:2018-11-27 14:23:20
   protSnd    88 last_at:2018-11-27 14:23:20
   protState  CMDs_done
   rssi_at_CUL1 cnt:135 min:-85.5 max:-64.5 avg:-72.15 lst:-72.5
   rssi_at_CUL3 cnt:126 min:-85.5 max:-66.5 avg:-71.24 lst:-74
   rssi_at_CUL5 cnt:127 min:-77 max:-59 avg:-64.48 lst:-64.5
   READINGS:
     2018-11-27 14:30:51   Activity        alive
     2018-11-27 11:20:52   CommandAccepted yes
     2018-11-27 11:20:50   D-firmware      1.0
     2018-11-27 11:20:50   D-serialNr      NEQ0096313
     2018-11-27 08:45:38   PairedTo        0xABCDEF
     2016-12-16 22:38:09   R-cyclicInfoMsg on
     2016-12-16 22:38:30   R-eventDlyTime  0 s
     2018-11-27 11:20:50   R-pairCentral   set_0xABCDEF
     2016-12-16 22:38:09   R-sabotageMsg   on
     2016-12-16 22:38:30   R-sign          on
     2018-11-27 08:45:38   RegL_01.          08:01 20:9C 21:00 30:06 00:00
     2018-11-27 14:23:20   aesCommToDev    ok
     2018-11-27 14:23:20   aesKeyNbr       02
     2018-11-27 12:49:41   aesReqTo        VCCU
     2018-11-27 14:23:20   alive           yes
     2018-11-27 14:23:20   battery         ok
     2018-11-27 14:23:20   contact         closed (to VCCU)
     2018-11-12 22:57:12   powerOn         2018-11-12 22:57:12
     2018-11-27 14:23:20   recentStateType info
     2018-11-27 14:23:20   sabotageError   off
     2018-11-27 14:23:20   state           closed
     2017-02-19 19:09:33   trigDst_VCCU    noConfig
     2016-12-16 22:34:52   trigDst_broadcast noConfig
     2018-11-27 12:49:41   trig_aes_VCCU   ok:133
     2018-11-27 12:49:41   trigger_cnt     133
   helper:
     HM_CMDNR   253
     cSnd       01ABCDEF44BC98000802010AE40B730C09,01ABCDEF44BC980006
     getCfgList all
     getCfgListNo ,4
     mId        00C7
     regLst     ,0,1,4p
     rxType     28
     supp_Pair_Rep 0
     ack:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       lstRecType 10
       newChn     +44BC98,01,01,02
       nextSend   1543325000.77306
       nxtSndMcnt FD
       rxt        2
       tgtDly     88
       vccu       VCCU
       lRcTm:
         CUL1       64330364
         CUL3       64282504
         CUL5       54211604
         tnms       357999620
       lastAESReq:
         auth       59DFEF62
         authAck    As0EFD8002ABCDEF44BC980059DFEF62
         cntl       166
         data       010000
         lStm       1543325000.71691
         len        0D
         mcnt       FD
         subtp      06
         type       10
       p:
         44BC98
         01
         01
         02
       prefIO:
         CUL5
     mRssi:
       mNo        FD
       io:
         CUL1:
           -72.5
           -72.5
         CUL3:
           -74
           -74
         CUL5:
           -54.5
           -54.5
     prt:
       bErr       0
       sProc      0
       sleeping   1
       try        1
       rspWait:
     q:
       qReqConf   00
       qReqStat   
     role:
       chn        1
       dev        1
     rpt:
       IO         CUL5
       flg        A
       ts         1543325000.71209
       ack:
         HASH(0x2ac0f50)
         FD8002ABCDEF44BC9800
     rssi:
       at_CUL1:
         avg        -72.1592592592593
         cnt        135
         lst        -72.5
         max        -64.5
         min        -85.5
       at_CUL3:
         avg        -71.2420634920635
         cnt        126
         lst        -74
         max        -66.5
         min        -85.5
       at_CUL5:
         avg        -64.4803149606299
         cnt        127
         lst        -64.5
         max        -59
         min        -77
     shadowReg:
       RegL_00.    02:01 0A:E4 0B:73 0C:09
     tmpl:
   role:
Attributes:
   IODev      CUL5
   IOgrp      VCCU:CUL5
   actCycle   000:50
   actStatus  alive
   aesCommReq 1
   autoReadReg 4_reqStatus
   expert     2_full
   firmware   1.0
   model      HM-SEC-SCo
   peerIDs   
   room       CUL_HM
   serialNr   NEQ0096313
   subType    threeStateSensor
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: noansi am 27 November 2018, 21:42:55
Hallo Matthias,

ZitatDer Nanocul lag in der Tat relativ nahe am (originalen) Raspberry-Netzteil.
Schön, wenn es so einfach gewesen wäre.
Wenn es lange Zeit in der alten unveränderten Lage problemlos funktioniert hat und das Problem erst jetzt aufgetreten ist, dann würde ich mir jetzt schon ein Reservenetzteil zulegen.  ;)

Zitatmessage cleared while waiting for send
Das ist eine speziele Timoutmeldung für ein Abbrechen eines Sendeversuchs, wenn während des Wartens auf Kanalzugriff die Sendemessage wegen Timeout gelöscht wurde.

Jede Sendenachricht bekommt in der Firmware einen Timeout "aufgedrückt", um nicht beliebig lange und unsinnig zu versuchen diese auch zu senden und damit auch für eine lange Wartezeit einen der raren Sendepuffer zu belegen. Es gibt normalerweise nur ein relativ enges Zeitfenster für Antworten, danach wird ein Sendeversuch in der Regel sinnlos.

In dem speziell Log Fall versuchte die Firmware das device zum Signieren der Nachricht zu bewegen, aber konnte die Nachricht nicht rechtzeitig absetzen, als dass erwartet werden könnte, dass das device auch noch "wach" sein dürfte.
Das passiert in der Regel, wenn gleichzeigtig zum Warten auf Senden noch eine andere Nachricht eines anderen devices empfangen wird oder die Kommunikation zu einem anderen device früher angefangen wurde und zuerst abgearbeitet wird.

Ob die Nachricht doch noch richtig signiert empfangen werden kann hängt dann von der Anzahl der Wiederholversuche des devices ab. Würde es seine Nachricht nur einmal senden, dann käme sie nicht bei FHEM an. Wiederholt es, dann klappt es meist bei einem der weiteren Versuche.

Da Deine Log Einträge dicht beieinander liegen, würde ich mal interpretieren, dass erst der 6. Versuch erfolgreich war. Ansonsten müsstes Du das Fenster/die Tür relativ schnell hintereinander geöffnet und geschlossen haben.
Das würde weiterhin bedeuten, dass recht viele devices zur nahezu gleichen Zeit dazwischen gefunkt haben oder FHEM einige HM Kommandos abgesetzt hat.
Genauer ließe es sich nur mit mehr verbose (4) interpretieren.

Was noch passiert ist, dass vom 3. auf den 4. Eintrag das IO Device von CUL5 nach CUL1 gewechselt wurde. Der RSSI abhängige IO Devicewechsel hat also offenbar funktioniert. :)

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: klausw am 10 Dezember 2018, 08:54:17
Hallo Ansgar,

Dein Modul nutze ich nun schon eine Weile und bin sehr zufrieden damit.
Nur hat mein nanoCUL ein Problem nach dem start/neustart des Raspberry2.
Er wird einfach nicht erkannt (das hat nichts mit Deinem Modul zu tun).
Ein abziehen/anstecken des CUL reicht, und er taucht wieder als USB Device auf.
Alternativ (mein Pi läuft in 300km Entfernung) kann man mit /bin/echo '1-1' | /usr/bin/tee /sys/bus/usb/drivers/usb/unbind
#kleine pause
/bin/echo '1-1' | /usr/bin/tee /sys/bus/usb/drivers/usb/bind

Den gesamten USB zurücksetzen, was den CUL auch zurückbringt.
Damit wird aber auch die LAN Verbindung gekappt (das bind müsste, wenn das ganze auch über SSH funktionieren soll, z.B. über ein cron Job gemacht werden)

Nun meine Frage zu Deinem TSCUL Modul:
Nach jedem (zumeist ungewollten) Neustart des Raspberry bekomme ich folgende Meldung:
Messages collected while initializing FHEM:
configfile: ASKSIN not supported
ASKSIN not supported
CUL1: Mode HomeMatic not supported, wrong firmware?!?

Autosave deactivated

undattr CUL1 rfmode HomeMatic wurde dabei gelöscht.

Jedes mal wenn TSCUL keinen CUL findet verschwindet das Attribut.
Spricht etwas dagegen, diesen Automatismus zu entfernen?

Grüße
Klaus

PS: muss die Datei 10_CUL_HM.pm derzeit noch in "exclude_from_update" geführt werden?
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: noansi am 10 Dezember 2018, 22:09:41
Hallo Klaus,

ZitatEin abziehen/anstecken des CUL reicht, und er taucht wieder als USB Device auf.
Hast Du mal mit dmsg geschaut, ob er wirklich nicht erkannt wird, oder ob er nur einer anderen Schnittstelle zugewiesen wird (mein Raspi macht so was jedenfalls, wenn 99-usb-serial.rules nicht genutzt wird, da er die USB Port Numerierung beim Reboot anders handhabt, als beim ColdBoot)?

Im letzteren Fall wäre dann die Frage, ob der nano eine eindeutige Seriennummer hat und somit per 99-usb-serial.rules zu seiner Schnittstelle gezwungen werden kann.

ZitatNach jedem (zumeist ungewollten) Neustart des Raspberry bekomme ich folgende Meldung
Das liegt dann schlicht daran, dass der nano nicht in seinen Möglichkeiten erkannt und initialisiert werden kann.

Da beim Setzen des rfmode Attributs dann die letzte Meldung als Fehlermeldung zurückgegeben wird, wird auch das Attribut nicht von fhem gesetzt.

In Deinem Fall natürlich blöd. Normalerweise, wenn die Funktionalität nicht in die Firmware compiliert wurde, jedoch grundsätzlich nützlich.

Ich überleg mal, ob mir dazu was sinnvolles einfällt.

Zitatmuss die Datei 10_CUL_HM.pm derzeit noch in "exclude_from_update" geführt werden?
In MultiIO Umgebung zu Verringerung von IO-Wechseln bei CULs mit wenig Speicher (device Zordnung wird dann im EEPROM gespeichet), empfehle ich mal ja. Auf den EEPROM Verschleiß nimmt die reguläre 10_CUL_HM.pm von Martin keine Rücksicht.
Meine Variante ist jedoch nicht auf Martins aktuellem Stand, was seine funktionalen Änderungen/Ergänzungen angeht.
Grundsätzlich sollte es jedoch mit Martins regulärer Version auch funktionieren, so dass der "exclude_from_update" nicht zwingend ist.
Ich habe es jedoch selbst nicht getestet. Teste und berichte.  ;)

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: klausw am 11 Dezember 2018, 11:22:19
Hallo Ansgar,

Zitat von: noansi am 10 Dezember 2018, 22:09:41
Hast Du mal mit dmsg geschaut, ob er wirklich nicht erkannt wird, oder ob er nur einer anderen Schnittstelle zugewiesen wird (mein Raspi macht so was jedenfalls, wenn 99-usb-serial.rules nicht genutzt wird, da er die USB Port Numerierung beim Reboot anders handhabt, als beim ColdBoot)?
Der nanoCUL wird wirklich nicht erkannt.
Ich nutze sowieso /dev/serial/by-id/... daher ist mir die Schnittstellennummer selbst egal.

user@pi:~ $ dmesg | grep USB
[    0.823068] dwc_otg 3f980000.usb: new USB bus registered, assigned bus number 1
[    0.829609] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    0.831217] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    0.838395] hub 1-0:1.0: USB hub found
[    0.864238] usbhid: USB HID core driver
[    1.260501] usb 1-1: new high-speed USB device number 2 using dwc_otg
[    1.490855] usb 1-1: New USB device found, idVendor=0424, idProduct=9514
[    1.492707] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    1.495519] hub 1-1:1.0: USB hub found
[    1.820512] usb 1-1.1: new high-speed USB device number 3 using dwc_otg
[    1.950899] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00
[    1.952746] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    2.046087] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at usb-3f980000.usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:ab:aa:65
[    2.140555] usb 1-1.2: new full-speed USB device number 4 using dwc_otg
[    2.295380] usb 1-1.2: New USB device found, idVendor=0403, idProduct=6015
[    2.297325] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    2.410546] usb 1-1.3: new full-speed USB device number 5 using dwc_otg
[    2.960553] usb 1-1.3: new full-speed USB device number 6 using dwc_otg
[    3.510592] usb 1-1.3: new full-speed USB device number 7 using dwc_otg
[    4.050615] usb 1-1.3: new full-speed USB device number 8 using dwc_otg
[    4.490884] usb 1-1-port3: unable to enumerate USB device
[    4.800540] usb 1-1.4: new full-speed USB device number 9 using dwc_otg
[    4.933854] usb 1-1.4: New USB device found, idVendor=0658, idProduct=0200
[    4.933869] usb 1-1.4: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[    4.961818] cdc_acm 1-1.4:1.0: ttyACM0: USB ACM device
[    4.962717] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[    5.030533] usb 1-1.5: new full-speed USB device number 10 using dwc_otg
[    5.176568] usbserial: USB Serial support registered for generic
[    5.189671] usb 1-1.5: New USB device found, idVendor=0403, idProduct=6001
[    5.189692] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    5.189700] usb 1-1.5: Product: DuoFern USB-Stick
[    5.190199] usbserial: USB Serial support registered for FTDI USB Serial Device
[    5.193115] ftdi_sio 1-1.2:1.0: FTDI USB Serial Device converter detected
[    5.194969] usb 1-1.2: FTDI USB Serial Device converter now attached to ttyUSB0
[    5.198478] ftdi_sio 1-1.5:1.0: FTDI USB Serial Device converter detected
[    5.203157] usb 1-1.5: FTDI USB Serial Device converter now attached to ttyUSB1
user@pi:~ $ lsusb
Bus 001 Device 010: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 001 Device 009: ID 0658:0200 Sigma Designs, Inc.
Bus 001 Device 004: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO)
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
user@pi:~ $ ls -l /dev/serial/by-id/
insgesamt 0
lrwxrwxrwx 1 root root 13 Dez 11 09:17 usb-0658_0200-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Dez 11 09:17 usb-FTDI_UMFT230XB_FTWJO8UB-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Dez 11 09:17 usb-Rademacher_DuoFern_USB-Stick_WR01E1RT-if00-port0 -> ../../ttyUSB1

-------------------------

/bin/echo '1-1' | /usr/bin/tee /sys/bus/usb/drivers/usb/unbind
#kleine pause
/bin/echo '1-1' | /usr/bin/tee /sys/bus/usb/drivers/usb/bind

-------------------------

user@pi:~ $ ls -l /dev/serial/by-id/
insgesamt 0
lrwxrwxrwx 1 root root 13 Dez 11 10:23 usb-0658_0200-if00 -> ../../ttyACM0
lrwxrwxrwx 1 root root 13 Dez 11 10:23 usb-FTDI_FT232R_USB_UART_SUB02-if00-port0 -> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Dez 11 10:23 usb-FTDI_UMFT230XB_FTWJO8UB-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root 13 Dez 11 10:23 usb-Rademacher_DuoFern_USB-Stick_WR01E1RT-if00-port0 -> ../../ttyUSB2
user@pi:~ $ lsusb
Bus 001 Device 016: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 001 Device 017: ID 0658:0200 Sigma Designs, Inc.
Bus 001 Device 013: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 001 Device 012: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO)
Bus 001 Device 011: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
user@pi:~ $ dmesg | grep USB
...
[  928.418055] usb 1-1.1: USB disconnect, device number 3
[  928.418748] smsc95xx 1-1.1:1.0 eth0: unregister 'smsc95xx' usb-3f980000.usb-1.1, smsc95xx USB 2.0 Ethernet
[  928.496476] usb 1-1.2: USB disconnect, device number 4
[  928.496825] ftdi_sio ttyUSB0: error from flowcontrol urb
[  928.497299] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[  928.498232] usb 1-1.4: USB disconnect, device number 9
[  928.500038] usb 1-1.5: USB disconnect, device number 10
[  928.500555] ftdi_sio ttyUSB1: error from flowcontrol urb
[  928.501073] ftdi_sio ttyUSB1: FTDI USB Serial Device converter now disconnected from ttyUSB1
[  979.237544] hub 1-1:1.0: USB hub found
[  979.555733] usb 1-1.1: new high-speed USB device number 11 using dwc_otg
[  979.686083] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00
[  979.686104] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[  979.781472] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at usb-3f980000.usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:ab:aa:65
[  979.885737] usb 1-1.2: new full-speed USB device number 12 using dwc_otg
[  980.041734] usb 1-1.2: New USB device found, idVendor=0403, idProduct=6015
[  980.041754] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  980.049262] ftdi_sio 1-1.2:1.0: FTDI USB Serial Device converter detected
[  980.050926] usb 1-1.2: FTDI USB Serial Device converter now attached to ttyUSB0
[  980.145725] usb 1-1.3: new full-speed USB device number 13 using dwc_otg
[  980.301859] usb 1-1.3: New USB device found, idVendor=0403, idProduct=6001
[  980.301880] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  980.301890] usb 1-1.3: Product: FT232R USB UART
[  980.310875] ftdi_sio 1-1.3:1.0: FTDI USB Serial Device converter detected
[  980.312270] usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB1
[  980.405736] usb 1-1.4: new full-speed USB device number 14 using dwc_otg
[  980.955751] usb 1-1.4: new full-speed USB device number 15 using dwc_otg
[  981.085741] usb 1-1.5: new full-speed USB device number 16 using dwc_otg
[  981.244606] usb 1-1.5: New USB device found, idVendor=0403, idProduct=6001
[  981.244628] usb 1-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  981.244639] usb 1-1.5: Product: DuoFern USB-Stick
[  981.253583] ftdi_sio 1-1.5:1.0: FTDI USB Serial Device converter detected
[  981.254989] usb 1-1.5: FTDI USB Serial Device converter now attached to ttyUSB2
[  981.565743] usb 1-1.4: new full-speed USB device number 17 using dwc_otg
[  981.709020] usb 1-1.4: New USB device found, idVendor=0658, idProduct=0200
[  981.709040] usb 1-1.4: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[  981.710554] cdc_acm 1-1.4:1.0: ttyACM0: USB ACM device


Zitat von: noansi am 10 Dezember 2018, 22:09:41
Das liegt dann schlicht daran, dass der nano nicht in seinen Möglichkeiten erkannt und initialisiert werden kann.
Da beim Setzen des rfmode Attributs dann die letzte Meldung als Fehlermeldung zurückgegeben wird, wird auch das Attribut nicht von fhem gesetzt.
In Deinem Fall natürlich blöd. Normalerweise, wenn die Funktionalität nicht in die Firmware compiliert wurde, jedoch grundsätzlich nützlich.
Ich überleg mal, ob mir dazu was sinnvolles einfällt.
Wäre super. ;)
Wäre es nicht sowieso sinnvoller die Attribute nur zu setzen, wenn der CUL auch online ist.
Solange keine Verbindung besteht macht es in meinen Augen keinen Sinn Einstellungen zu übertragen.


Zitat von: noansi am 10 Dezember 2018, 22:09:41
In MultiIO Umgebung zu Verringerung von IO-Wechseln bei CULs mit wenig Speicher (device Zordnung wird dann im EEPROM gespeichet), empfehle ich mal ja. Auf den EEPROM Verschleiß nimmt die reguläre 10_CUL_HM.pm von Martin keine Rücksicht.
Meine Variante ist jedoch nicht auf Martins aktuellem Stand, was seine funktionalen Änderungen/Ergänzungen angeht.
Grundsätzlich sollte es jedoch mit Martins regulärer Version auch funktionieren, so dass der "exclude_from_update" nicht zwingend ist.
Ich habe es jedoch selbst nicht getestet. Teste und berichte.  ;)
Ich komme derzeit mit einem CUL durch das ganze Haus. Daher sollte das mit dem EEPROM kein Problem sein.
Ich werde es mal testen ... aber erst wenn ich vor Ort bin ... die Heizung muss ich noch schalten können ;)

Grüße
Klaus
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: noansi am 12 Dezember 2018, 14:35:48
Hallo Klaus,

ZitatWäre es nicht sowieso sinnvoller die Attribute nur zu setzen, wenn der CUL auch online ist.
Solange keine Verbindung besteht macht es in meinen Augen keinen Sinn Einstellungen zu übertragen.
Das ist ja gerade das Problem.

Bei der FHEM Initialisierung werden erst die defines durchgearbeitet und dann erst die (FHEM-) Attribute gesetzt.

Beim define wird das CUL bezüglich seiner Fähigkeiten abgefragt und erst mal in den default SlowRF Modus initialisiert.
Wird dann das Attribut "rmode" gesetzt, stehen die Informationen zu den "Fähigkeiten" zur Verfügung, sofern das CUL zum define Zeitpunkt angeschlossen und nutzbar ist.

Wenn es HomeMatic nicht kann, dann macht auch rfmode HomeMatic, hmId etc. keinen Sinn und es wird ein Fehler zurück geliefert (entsprechend Deinem Log), was zur Folge hat, dass diese attribute nicht gesetzt werden. Die sekundäre Folge ist dann dass keine Einstellungen an das nicht erreichbare CUL übertragen werden.

Die Readings werden erst nach dem Durchackern der fhem.cfg gesetzt, so dass auch der letzte Zustand zu diesem Zeitpunkt noch nicht verfügbar ist.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: noansi am 12 Dezember 2018, 22:00:32
Hallo Klaus,

versuch es mal mit der angehängten Version von 00_TSCUL.pm.
Wenn die Schnittstelle zum device beim fhem Neustart nicht geöffnet werden kann, dann werden die hm relevanten Attribute damit trotzdem gesetzt.
Bitte gib mir Feedback ob es so problemlos funktioniert.

Ich hoffe, das hilft Dir bei Deinem Problem.
Dein USB Problem musst Du aber unabhängig davon angehen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: klausw am 12 Dezember 2018, 23:09:59
Das ging ja schnell.
Ich werde es testen sobald ich vor Ort bin. Das wird Mitte kommender Woche sein.
Aus der Ferne ist mir das zu heiß, oder ehr zu kalt ;)
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: noansi am 12 Dezember 2018, 23:29:48
Hallo Klaus,

oder nimm gleich die angehängte.

Darin ist der neu eingebaute Time Broadcast sauberer drin.
Für rfmode HomeMatic wird damit zyklisch die Uhrzeit an alle hm devices per broadcast geschickt (Danke an Michael für die Info zum  Broadcast).
Mit dem Attribut hmTmBrdcstInt kann man das Sendeintervall von 86400s entsprechend 24h auch verstellen oder mit 0 den Broadcast auch abstellen.

Also wunder Dich nicht, wenn auf einmal auch die Uhren richtig gehen.  ;)

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: klausw am 16 Dezember 2018, 00:02:29
Zitat von: noansi am 12 Dezember 2018, 23:29:48
oder nimm gleich die angehängte.

Habe sie jetzt mal aufgespielt, nach dem Reboot wir das rfmode Attribut nicht gelöscht. Super, genau das, was ich benötige.
Die Zeit habe ich bisher nicht beachtet  8)

Die Standard 10_CUL_HM funktioniert auch problemlos. Da ich nur einen CUL nutze, sollte das auch nicht stören.

Für das USB Problem habe ich ja eine Lösung. Eventuell automatisiere ich das noch.
Scheinbar bin ich der Einzige mit diesem Problem, was mich zu der Frage führt ob es an dem Arduino Nano liegt was eingebaut ist.

Danke für die schnelle Unterstützung Ansgar!
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: RaspiLED am 16 Dezember 2018, 00:22:25
Hi,
kann es sein, dass Dein FTDI unter dem Testpin Bug leidet?
https://ketturi.kapsi.fi/2014/04/how-to-fix-moody-arduino-nano/
Gruß Arnd


Gesendet von iPhone mit Tapatalk
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: klausw am 16 Dezember 2018, 22:56:08
Zitat von: RaspiLED am 16 Dezember 2018, 00:22:25
kann es sein, dass Dein FTDI unter dem Testpin Bug leidet?

Danke für den Tip Arndt.
Ich ringe noch mit mir den nanoCUL auseinaner zu löten  ::)
Titel: Antw:Firmware zu CUL und Co. mit Timestamp Option ASKSIN tsculfw V0.29
Beitrag von: Cube am 12 Januar 2019, 02:32:16
Ich lese mich gerade in die tsculfw-Thematik ein, da ich mit der Standard-Firmware in letzter Zeit auch immer häufiger Probleme habe. Dabei stelle ich mir die folgende Frage: Wieso wird diese Firmware und die FHEM-Module, die dafür benötigt werden, nicht über ein Third-Party-Repo und die update-Funktion bereitgestellt? Das würde die Einbindung und das Aktualisieren doch deutlich vereinfachen.
Titel: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: noansi am 20 Januar 2019, 15:38:34
Hallo Testwillige,

hier eine neue Version 0.30 der Timestamp Firmware und der dazu benötigten FHEM Module.

Diese Version bietet neben einigen Verbesserungen insbesondere nun auch Support für CUNX.

Für CUL-IOs mit großem SRAM Speicher (SCC,COC,CUNO2,PIGATOR,CUNX...) ist die HM-Device Tabelle vom EEPROM ins SRAM verlagert und somit der EEPROM Verschleiss bei HM für diese entfallen. In dieser Version ist de SRAM Tabelle vergrößert (je nach verfügbarem SRAM).

Kurzer Auszug für SlowRf Änderungen aus der CHANGED:
- support for CUNX with USB and network, dfu-programmer 0.7.2 required for flashing. Flashable via USB only. TSCULflash supports it.
  dhcp works
  PIM modules are supported (tested with cc1101 PIGATOR only). PIGATOR flashing is also possible, but via USB only. TSCULflash supports it.
  Unfortunately the bootloader clears the CUNX EEPROM every time the unit is flashed.
  00_TSCUL.pm allows backup of EEPROM with get eeprom into log directory. get eerestore allows to restore the EEPROM with this file.
  For linux use take a look at devices/99-usb-serial.rules for an example to make sure to allways get the same TTY connection.

- SlowRF Send Frequeny to set with Xs
- Xs delivers SlowRF Send Frequeny Offset and Send Frequeny (answer Xf:ooffffff)
- Xo added to set SlowRF (default is the offset for reception)
- if delivers Send Frequeny Offset and Send Frequeny (answer if:ooffffff)
- io added to set InterTechno Send Frequeny Offset (default is 0)
- it removed, ic remains to set it_interval
- isr just sets InterTechno Repetition-count but does no more respond with ir:
- ir and ix removed
- Yx removed

Es ist eine Prüfung auf Stacküberlauf eingebaut. Am Anfang des heap werden zwei Byte mit einem Bitmuster beschrieben. Wird das verändert, dann ist der Speicher wahrscheinlich korrumpiert, was durch einen Stacküberlauf ausgelöst sein sollte. Sofern der CUL dann noch kann sendet er ein "C_M" an TSCUL, was zu einem entsprechenden Log Eintrag führt.
Damit kann man vorsichtig die Speichergrenzen ausloten. Ein langer Testzeitraum ist aber erforderlich, um einigermaßen sicher zu sein, dass der worst case auch mal durchlaufen worden ist.
Außerdem ist ein Kommando mU (je nach Firmware) eingebaut, mit dem man den vom Stack ungenutzen heap in etwa auslesen kann (auch als get unusedstack in TSCUL verfügbar). Auch hier gilt, nur nach langer Laufzeit einigermaßen sinnvoll. Es macht sicher keinen Sinn auf Grund des Wertes den Speicher bis auf das letzte Byte auszuquetschen, denn weiterhin hängt die Stacknutzung vom gewählten Protokoll und Einstellungen ab.

In TSCULflash ist Flashen auch von NanoCULs und MiniCULs ergänzt. Vor dem Flashen wird ein "B00" also Reset für die TSCUL Firmware an den nano/Mini geschickt, 1 Sekunde gewartet und dann versucht mit avrdude zu flashen.
Also erst die Firmware in den FHEM/Firmware Ordner kopieren und dann in FHEM mit
TSCULflash <nanodevicename> TSnanoCUL
bzw.
TSCULflash <minidevicename> TSminiCUL
versuchen zu Flashen. Im Log sollte danach (dauert etwas) die avrdude Ausgabe zu finden sein.

Ebenfalls möglich ist das Flashen eines PIGATOR Moduls an einem CUNX
TSCULflash <pigatordevicename>|<cunxdevicename> TSPIGATOR

AESCommReq wird unterstützt. Die Nutzung ist unverändert zu Standard CUL, sprich, beim gewünschten Gerät/Kanal aesCommReq auf 1 setzen und ggf. noch aesKey passend zum verteilten Key setzen.
Es werden von tsculfw nur die Keys 0 (Default Key) bis 3 unterstützt.

Diese Erweiterung erfordert jedoch auch zusätzliche Empfangspuffer im knappen Speicher des CULs. Ein CUL V3 nutzt bis zu 6 Empfangspuffer. Auch der FlashSpeicherbdarf ist angestiegen, so dass einige Protokolle nicht mehr gleichzeitig in ein Kompilat passen. Das sollte aber weniger tragisch sein, da im ASKSIN Modus ohnehin nur HM empfangen werden kann.

Bei CUL V2 reicht der verfügbare Speicher leider hinten und vorne nicht aus, um diese Version nutzen zu können.

Im Anhang ist in TSCUL_fwcode_00_30_FHEM_Modules_00_41_8.zip wieder die Timestamp Firmware zu finden. Getestet habe ich TSCUNX, TSPIGATOR , TSCUL_V3, TSCUNO2 , TSCOC und TSSCC.

Die tsculfw Firmware kann für TSCUL_V3,  TSCUNX und TSPIGATOR (an CUNX) mit FHEM mit dem TSCULflash geflashed werden. Die anderen müssen mit dem jeweiligen Flash Programmer geflashed werden.
So z.B. https://forum.fhem.de/index.php/topic,24436.msg631743.html#msg631743 kann es mit einem USB CUL Stick gehen, wenn man nicht TSCULflash verwendet.
TSCULflash ist erweitert auf COC, SCC, CCD, rpiaddon, CUNO2 und CUNO. Jedoch ist es nicht ganz so einfach zu handhaben, da zum einen teilweise die Taste zu drücken ist und bei Raspberry PI Modulen die Rechteproblematik für den Zugriff auf die IO-Pins überwunden werden muss. Tips dazu in der Command-Ref auch bei RPI_GPIO.
Bei einem Stapel aus SCC mit aufgesetztem COC, CCD oder (rpiaddon?) ist unbedingt beim SCC Flash darauf zu achten, die Taste am gewünschten Modul zu drücken. Sonst wird das oberste Nicht-SCC Modul mit der SCC Firmware geflashed.
Mit CUNO2 ist das flashen noch nicht getestet (generell nur über USB!). Wichtig, aber auch hier, die Taste zu drücken.

Es gibt nicht den Luxus des Downloads beim TSCULflash, sondern die Firmware muss händisch in den FHEM/firmware Ordner kopiert werden. Der Typ ist dann TSCUL_V3.
Beispiel:
TSCULflash MeinCulDevice TSCUL_V3

Wichtig für SCC Nutzer. TSSTACKED ist entfallen und wird nicht mehr unterstützt.
Statt dessen gibt es das neue Modul STACKABLETS (als Abwandlung von Rudolfs STACKABLE).
Dieses wird sozusagen zwischen die Stackteilnehmer eingebaut.

Beispiel für fhem.cfg:
#erstes SCC Modul als Basis
define SCC_WS868 TSCUL /dev/ttyAMA0@38400 0000
attr SCC_WS868 event-on-change-reading Ints_per_sec,IntCalcStat,MatchStat
attr SCC_WS868 rfmode SlowRF
attr SCC_WS868 room Receiver
attr SCC_WS868 sendpool CUL_HM868,SCC_WS868
attr SCC_WS868 verbose 1

#neues STACKABLETS virtuelles IO device
define STACK_1 STACKABLETS SCC_WS868
attr STACK_1 verbose 1

#zweites SCC Modul
define SCC_HM868 TSCUL FHEM:DEVIO:STACK_1:38400 1034
attr SCC_HM868 event-on-change-reading cond
attr SCC_HM868 hmId F11034


Ergänzender Hinweis zu USB CULs: 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_08\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 1234
bzw.
define CUL_433 TSCUL /dev/CUL433_0@12000000 0000
definiert werden und es gibt keine Probleme mit wechselnder Schnittstelle mehr.
Die Seriennummer kann beim Compilieren der Firmware in der board.h festgelegt werden, so dass damit dann auch /dev/CUL868_1 etc. für mehrere gleiche CULs möglich sind.

Oder für CUNX
define CUNX_868 TSCUL /dev/CUNX868_0@12000000 0000
oder für PIGATOR an CUNX
define PIGATOR_433 TSCUL /dev/CUNXPIM_0@38400 0000
die Seriennummer wird aus der Seriennummer des XMEGA Chips des CUNX gebildet. Unter Linux lsusb nutzen!

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.

Bei nicht nativen USB CULs wie z.B. nanoCUL, miniCUL oder CUNO2, beträgt die Baudrate 38400, dementsprechend muss die Definition beispielsweise so aussehen:
define CUL_868 TSCUL /dev/CUL868@38400 1234
bzw.
define CUL_433 TSCUL /dev/CUL433@38400 0000

Und noch ein Beispiel für eine Definition eines Netzwerk CUNX:
define CUL_868 TSCUL 192.168.178.111:2323 0000
oder für PIGATOR an CUNX
define PIGATOR_433 TSCUL 192.168.178.111:2324 0000
beim PIGATOR sollten zuvor mit Anschluss an USB und öffnen der Schnittstelle mit gewünschten Kommunikationsparametern mit ps oder unter TSCUL mit set PIMstoreBaud die seriellen Kommunikationsparameter zum PIGATOR Modul gespeichert werden, falls sie vom default abweichen.

Oder Netzwerk CUNO2:
define CUNO2_868 TSCUL 192.168.178.110:2323 0000

Die aktuell eingestellte oder per DHCP erhaltene Netzwerkadresse kann mit Lc repektive in TSCUL mit get NetAdresses abgefragt werden. Mit Lp repektive in TSCUL mit get NetPHYlink kann der Linkzustand des Netzwerkanschlusses angezeigt werden.


In der Zip Datei sind ebenfalls die ergänzten Module zu finden, die zur Nutzung der Firmware erforderlich sind.

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
16_STACKABLETS.pm -> statt der 16_STACKABLE.pm, aus STACKABLE werden damit STACKABLETS devices in der fhem.cfg (händisch anzupassen)

10_UNIRoll_TS.pm  -> statt der 10_UNIRoll.pm, mit TSCUL 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 IO-devices zu verwenden, aus TSKS300 wird dann TSKS300  in der fhem.cfg (händisch anzupassen). Obsolet, da 14_TSCUL_WS.pm nun KS300 unterstützt.
14_TSCUL_TX.pm    -> statt der 14_CUL_TX.pm, mit TSCUL 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 IO-devices zu verwenden, aus CUL_WS wird dann TSCUL_WS  in der fhem.cfg (händisch anzupassen)
15_TSCUL_EM.pm   -> statt der 15_CUL_EM.pm, mit TSCUL IO-devices zu verwenden, aus CUL_EM wird dann TSCUL_EM  in der fhem.cfg (händisch anzupassen)
CalcUtil.pm               -> Hilfsrechenroutinen für Taupunkt und Windstärkeindex
ReadingUtil.pm          -> Hilfsroutinen für Readings

Da diese Module ergänzt werden (müssen!), überleben sie auch ein Update von FHEM.

10_IT.pm                   -> vermeidet unnötiges busy waiting beim Senden. Wird ohne Schutz von FHEM update überschrieben

Außerdem:

98_TSCULflash.pm     -> Zum Flash von TSCUL_V3, TSPIGATOR (an CUNX) mit Datei in FHEM/firmware

10_CUL_HM.pm         -> angepasste Version zur Nutzung mit TSCUL/tsculfw. Die Nutzung dieses Moduls ist optional. Für CUL_V3, nanoCUL, miniCUL im Multio-HM-IO Betrieb jedoch empfohlen, da sie den EEPROM Verschleiss über das Attribut "rssiSwitchHyst" verringert.
HMConfig.pm             -> optional, Einstelllimits für HM-CC-RT-DN Regler P und I Anteil erweitert. Damit kann man mit R-regAdaptive offDeter deutlich mehr an den Regelparametern spielen.
98_HMinfo.pm           -> optional, Spaltenbreiten in Tabelle von protoEvents variabel zu verbesserten Übersicht in der Darstellung.

10_CULG.pm              -> optional, enthalten, da die Firmware es unterstützt

97_timerTS.pm           -> optional, Austausch-Timerroutinen. Wenn es nicht genutzt werden soll, dann löschen oder umbennen.
98_apptime.pm          -> apptime zur zwingenden Nutzung mit 97_timerTS.pm.
98_apptm.pm            -> apptime zur zwingenden Nutzung mit 97_timerTS.pm, mit geringerem Speicherverbrauch bei weniger Details

98_autocreate.pm       -> autocreate mit TSCUL Unterstützung

98_Cumulate               -> Kumulieren von Zählwerten, wie Strom, Regenmenge etc.
98_SAverage.pm         -> Mittelwertbildung von z.B. Temperaturen. Stunde, Tag, Monat und Jahr, sowie ein gleitender Mittelwert der letzten Stunde sind damit möglich.


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_STACKABLETS.pm DevIoTS.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.pm CalcUtil.pm 97_timerTS.pm 98_TSCULflash.pm 97_timerTS.pm 98_apptime.pm 98_apptm.pm 10_IT.pm 10_CULG.pm 10_CUL_HM.pm HMConfig.pm 98_HMinfo.pm ReadingUtil.pm 98_autocreate.pm 98_Cumulate.pm 98_SAverage.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` }

Noch ein Hinweis: TSCUL fragt auch die Firmwareversion der tsculfw auf 0.30 ab. Eine ältere Version wird also nicht unterstützt, da das Timestamp Protokoll (inkompatibel zu vorherigen Ständen) geändert hat, so dass mit dem Austausch der FHEM Module auch ein Firmwareupdate des CUL devices erforderlich ist!

Noch ein Tip zur Haltbarkeit der CULs mit wenig SRAM (CUL V3, nanoCUL, miniCUL ...). Jedesmal, wenn einem HM-Device das IODev durch Roaming neu zugeordnet wird, führt das zu EEPROM Schreibvorgängen in den beteiligten CULs. Die Lebensdauer des EEPROMs ist begrenzt (100000 Schreibzyklen laut Datenblatt). Daher rate ich zur Nutzung des VorzugsIOs beim Device Attribut IOgrp. Also nicht einfach stumpf
attr HMdeviceName IOgrp VCCU
setzen, sondern
attr HMdeviceName IOgrp VCCU:CUL_mit_gutem_Empfang_fuer_Device
sofern die Roaming Funktionalität entsprechend RSSI für das jeweilige device nicht zwingend benötigt wird. Ein Fallback auf einen anderen CUL bleibt dennoch möglich.
Mit dem Attribut "rssiSwitchHyst", das in der beigefügten 10_CUL_HM.pm verfügbar ist, kann bei den HM-devices die Umschalthysterese für das Roaming von 10 bis auf 2 bei Bedarf für mobile devices verringert werden.

Ergänzt ist auch noch ein set TX3Send.
Damit lassen sich TX3 Sensordatentelegramme auf 433er CULs versenden.
Beispiel:

define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 TX3Send T:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." SID:23 U")}

define NF_HumOut notify Sen_Aussen:humidity.* {fhem("set TSCUL_WS433 TX3Send H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." SID:23 U")}


Ergänzt ist auch noch ein set KSSend.
Damit lassen sich WS Sensordatentelegramme versenden.
Beispiel:

define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 KSSend T:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." Code:2")}


Gruß, Ansgar.

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

EDIT1: 10_IT.pm aktualisiert wegen \r im Commandref Text.
EDIT2: 97_timerTS.pm 98_apptime.pm 98_apptm.pm aktualisiert, um undefinierte PrioQueue Einträge abzufangen
            00_TSCUL.pm aktualisiert, kleinere Anpassungen für Datenratemessung
EDIT3: 97_timerTS.pm 98_apptime.pm 98_apptm.pm aktualisiert, für korrekte Funktion von PrioQueues
EDIT4: unnötige u. ggf. fehlerträchtige use vars aus Modulen entfernt
EDIT5: 00_TSCUL.pm aktualisiert, Korrektur für dummy Attribut
           98_apptime.pm 98_apptm.pm aktualisiert
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: noansi am 20 Januar 2019, 17:15:17
Hallo Cube,

ZitatWieso wird diese Firmware und die FHEM-Module, die dafür benötigt werden, nicht über ein Third-Party-Repo und die update-Funktion bereitgestellt? Das würde die Einbindung und das Aktualisieren doch deutlich vereinfachen.

Weil mein Fokus auf der Firmwareentwicklung liegt und nicht darauf einen eigentlich nicht so schwierigen Vorgang noch einfacher zu gestallten.

Zweites Hemmnis, meine Modulvarianten haben großenteils ein Pendant in der Standard FHEM Version zur Unterstützung der Standard culfw. Damit gäbe es dann zwei Möglichkeiten für Ähnliches aber nicht voll Kompatibles, was dann zu ganz anderen User Verständnisproblemen führen würde.
Und ich denke schon aus Support Gründen nicht, das Rudolf sehr glücklich über über solch eine Zweigleisigkeit in FHEM wäre.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: sash.sc am 20 Januar 2019, 17:39:08
Habe da mal so ne frage.

Besteht die Möglichkeit, die Firmware auf nen esp 8266 oder esp32 zu portieren?
Mit wlan Anbindung, oder so?

Die beiden Chips dürften ja auch mehr Speicher zur Verfügung stellen, oder?

Gruß Sascha

Gesendet von meinem E6653 mit Tapatalk

Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: noansi am 20 Januar 2019, 19:45:58
Hallo sash.sc,

ZitatBesteht die Möglichkeit, die Firmware auf nen esp 8266 oder esp32 zu portieren?
Mag sein.
Weder kenne, noch habe ich die Hardware.
Ein 16Bit Timer mit 8µs Takt und Interruptmöglichkeiten ist eine Vorraussetzung.
Für SlowRF muss ein I/O Pin Interrupts auslösen können.

Ist auf jeden Fall ne Menge Arbeit, sogar, wenn die Hardware, wie beim XMEGA nicht ganz so weit vom ATMEGA weg ist. Die andere Registerdefinition alleine macht es schon unangenehm.
Versuchen kannst Du es.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: sash.sc am 20 Januar 2019, 20:04:39
Danke für die Info.

Leider reichen da meine Kenntnisse in keinster Weise für aus. [emoji6]

Gesendet von meinem E6653 mit Tapatalk
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: MadMax-FHEM am 20 Januar 2019, 20:34:22
Vermutlich ist es einfacher den USB-Adapterteil von einem CUL wegzulassen und stattdessen direkt an Rx/Tx einen ESP dran und da dann serialBridge drauf.

Ähnlich wie: HMOD-PCB per WLAN...

...evtl. gibt es das schon im Forum aber halt mit aculfw oder so...
Wäre aber egal, weil man ja auf den Atmega (o.ä.) Teil ja "jede FW" flashen kann...

Gruß, Joachim
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: Cube am 26 Januar 2019, 01:46:49
Ich habe heute meine Installation umgestellt und alle meine HomeMatic-Probleme sind verschwunden. Vielen Dank für diese Firmware.  :)

Zitat von: noansi am 20 Januar 2019, 17:15:17
Weil mein Fokus auf der Firmwareentwicklung liegt und nicht darauf einen eigentlich nicht so schwierigen Vorgang noch einfacher zu gestallten.

Zweites Hemmnis, meine Modulvarianten haben großenteils ein Pendant in der Standard FHEM Version zur Unterstützung der Standard culfw. Damit gäbe es dann zwei Möglichkeiten für Ähnliches aber nicht voll Kompatibles, was dann zu ganz anderen User Verständnisproblemen führen würde.
Und ich denke schon aus Support Gründen nicht, das Rudolf sehr glücklich über über solch eine Zweigleisigkeit in FHEM wäre.

Wäre es aber nicht sinnvoll deine Arbeit einem größeren Publikum zugänglich zu machen? Hier im Forum kriegt ja kaum jemand mit, dass es diese Firmware gibt - sieht man auch an den geringen Downloadzahlen der neusten Version. Ein weiterer Punkt der mich zunächst vom Umstieg abgehalten hat ist weniger der initiale Aufwand (der ist wirklich minimal), sondern die Tatsache, dass ich meine Installation jetzt nicht mehr einfach aktuell halten kann. Wenn bei mir alles stabil läuft, dann halte ich sie einfach über die interne Update-Funktion aktuell und treibe mich nicht im Forum rum. Und es werden dann ja nicht nur die exklusiven Module dieser Firmware nicht aktualisiert, sondern auch diverse offiziellen Module.

Noch besser wäre natürlich, wenn diese Firmware offizieller Teil von FHEM werden würde. Die Standard-culfw wird doch schon seit Jahren nicht mehr wirklich weiterentwickelt. Gibt es überhaupt noch vom CUL V2 abgesehen irgendetwas wofür man diese bräuchte? Ich habe beim Überfliegen des Threads gesehen, dass Rudolf das eher skeptisch sieht. Aber das ist letztendlich das allgemeine Problem von FHEM, dass man sich mit größeren Modernisierungen und dem Abschneiden alter Zöpfe schwer tut.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: Cube am 26 Januar 2019, 02:17:15
Zitat von: noansi am 20 Januar 2019, 15:38:34
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_STACKABLETS.pm DevIoTS.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.pm CalcUtil.pm 97_timerTS.pm 98_TSCULflash.pm 97_timerTS.pm 98_apptime.pm 98_apptm.pm 10_IT.pm 10_CULG.pm 10_CUL_HM.pm HMConfig.pm 98_HMinfo.pm

Diese Angabe ist nicht vollständig, da fehlen mehrere Dateien. Hier die vollständige Version:

attr global exclude_from_update 00_TSCUL.pm 16_STACKABLETS.pm DevIoTS.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.pm CalcUtil.pm 97_timerTS.pm 98_TSCULflash.pm  98_apptime.pm 98_apptm.pm 10_IT.pm 10_CULG.pm 10_CUL_HM.pm HMConfig.pm 98_HMinfo.pm ReadingUtil.pm 98_autocreate.pm 98_Cumulate.pm 98_SAverage.pm


Zitat von: noansi am 20 Januar 2019, 15:38:34
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` }

Das funktioniert für die angepasst 10_IT.pm nicht.


*** EN FHEM/10_IT.pm: ignoring text due to DOS encoding
*** DE FHEM/10_IT.pm: ignoring text due to DOS encoding
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: noansi am 26 Januar 2019, 13:05:30
Hallo Cube,

ZitatDas funktioniert für die angepasst 10_IT.pm nicht.
Danke für den Hinweis, ich habe es korrigiert und oben aktualisiert. Und nebenbei noch eine Änderung von Björn mit rein genommen.

ZitatDiese Angabe ist nicht vollständig, da fehlen mehrere Dateien.
Bei ergänzten Dateien ist das auch erst dann wirklich notwendig, wenn die Dateinamen im "regulären" Fhem mal verwendet werden.
Ich habs aber ergänzt. Offensichtlich hast Du aber verstanden, was es bewirken soll.  :)
10_CUL_HM.pm HMConfig.pm 98_HMinfo.pm sind aber u.U. zu viel, denn die sollten auch grundsätzlich in Martins aktueller Form laufen. Es ist User Entscheidung, was genutzt werden soll.

ZitatWäre es aber nicht sinnvoll deine Arbeit einem größeren Publikum zugänglich zu machen?
Martin weist bei nahezu jeder Frage in CUL Zusammehang auf die TS Firmware hin.
Dieser Thread hier ist öffentlich, jeder kann ihn nutzen.
Wenn Du im Forum selbst auf Fragen Hilfesuchender antwortest, kannst Du direkt hierhin verweisen.

Zitatdann halte ich sie einfach über die interne Update-Funktion aktuell und treibe mich nicht im Forum rum.
Dann bist Du mitunter auch schon mal unfreiwillig Alpha oder Beta Tester. Lies mal im Forum.
Es mach schon Sinn, vor einem Update sein Backup auf Stand zu bringen respektive auch Platz dafür zu haben, um bei einem Bug in einem der aktualisierten Module schnell zurück zu kommen. Und auch vorher mal im Forum zu schauen, ob da nicht gerade entsprechende Threads zu u.U. gravierenden Problemen veröffentlicht werden.

ZitatNoch besser wäre natürlich, wenn diese Firmware offizieller Teil von FHEM werden würde.
In wieweit alle Funktionen der Firmware funktionieren, kann ich nur mit vorhandener eigener Hardware testen und die umfasst längst nicht alle Funktionen oder Hardwareplatformen.
Von daher von meiner Seite her derzeit keine gute Idee.
User Feedback, um auch diese Funktionen ggf. zu korrigieren ist spärlich, weil die Hauptnutzung wohl auf HM läuft. (Spärlich aber auch, weil eben HM auch schon mit älteren Versionen gut läuft.)

Außerdem gibt es noch die a-culfw mit ihren Ergänzungen insbesondere für SlowRF.

Der User entscheidet, was er braucht und was er will, so sehe ich es.

ZitatAber das ist letztendlich das allgemeine Problem von FHEM, dass man sich mit größeren Modernisierungen und dem Abschneiden alter Zöpfe schwer tut.
Oder aber auch positiv, denn was würdest Du sagen, wenn es Deine mühsam aufgebaute Haussteuerung wegen einer FHEM Modernisierung plötzlich nicht mehr tut?

ZitatUnd es werden dann ja nicht nur die exklusiven Module dieser Firmware nicht aktualisiert, sondern auch diverse offiziellen Module.
Was bei Verwendung der tsculfw dann auch durchaus Sinn macht.  ;)
Wenn Du 10_IT.pm nicht benutzt, dann ist es egal. Wenn Du es benutzt, dann ginge es sicher schief. Wobei bei einem 868MHz CUL die Nutzung auf 433MHz ohnehin sehr anzuzweifeln ist.
Auf die Änderungen in 98_autocreate.pm kannst Du auch gut verzichten, wenn Du FHEM devices händisch anlegst.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: Mr.Floppy am 27 Januar 2019, 13:15:42
Hallo

Da mein Homematic netzwerk nicht optimal läuft wollte ich meinen zweiten nanoCUL mal mit dieser firmware flashen und schauen ob es verbesserungen bringt.
Das Flashen hat soweit funktioniert aber ich verstehe die sache mit den zu ersetzenden .pm dateien nicht richtig.
Werden die Dateien nur hinzugefügt und ggf. überschrieben oder ersetzen sie komplett die angegebenen Dateien?
Die Beschreibung verstehe ich so das die Dateien die alten komplett ersetzen was mich dann zu einer weiteren frage kommen lässt.
Wie sage ich FHEM in der .cfg (wie in der Beschreibung angegeben) das es die neuen dateien benutzen soll?

Gruß
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: MadMax-FHEM am 27 Januar 2019, 13:32:40
Zitat von: Mr.Floppy am 27 Januar 2019, 13:15:42
Werden die Dateien nur hinzugefügt und ggf. überschrieben oder ersetzen sie komplett die angegebenen Dateien?

Neue Dateien (also welche die Standard-fhem nicht hat) kommen dazu...
...Dateien die bereits da sind werden natürlich überschrieben...

Rechte/"Eigentumsverhältnisse" anpassen nicht vergessen: sudo chown fhem: /opt/fhem/FHEM/KopierteDatei.pm

(KopierteDatei.pm natürlich jeweils entsprechend / oder "global" über das Verzeichnis: sudo chown -R fhem: /opt/fhem/FHEM   das alles bei Standard-fhem-Installation! Und auf eigenes Risiko! ;)  )


Zitat von: Mr.Floppy am 27 Januar 2019, 13:15:42
Die Beschreibung verstehe ich so das die Dateien die alten komplett ersetzen was mich dann zu einer weiteren frage kommen lässt.
Wie sage ich FHEM in der .cfg (wie in der Beschreibung angegeben) das es die neuen dateien benutzen soll?

Wie nach einem Update auch: shutdown restart (in Fhem-Web)

EDIT: natürlich das Define des CUL anpassen nicht vergessen!

Dann eine Frage die nicht gestellt wurde...
...trotzdem die Antwort: ;)

wie sage ich fhem, dass die überschriebenen pm-Dateien (von TS-CUL-FW) bei einem Update NICHT wieder durch die "originalen"/Standard-fhem-Dateien ersetzt werden: Attribut exclude_from_update bei global

Gruß, Joachim
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: noansi am 27 Januar 2019, 13:42:40
Hallo Mr. Floppy,

ZitatWerden die Dateien nur hinzugefügt und ggf. überschrieben oder ersetzen sie komplett die angegebenen Dateien?
Die, die es gibt, ersetzt Du und die, die es nicht gibt ergänzt Du durch Kopieren in das FHEM Verzeichnis.

ZitatWie sage ich FHEM in der .cfg (wie in der Beschreibung angegeben) das es die neuen dateien benutzen soll?
In der fhem.cfg Datei hast Du für Deinen nanoCUL einen Eintrag in der Art:
define nanoCUL CUL /dev/ttyUSB0@38400 0000
Das CUL sorgt dafür dass das Modul 00_CUL.pm verwendet wird.
Folglich musst Du es durch TSCUL ersetzen, damit 00_TSCUL.pm verwendet wird:
define nanoCUL TSCUL /dev/ttyUSB0@38400 0000

Anschließend ein restart von FHEM und die geänderte Konfiguration wird verwendet.
Wenn Du den nanoCUL nur für HM verwendest und die Attribute passen, bist Du damit für einen Test schon fertig.

Das globale Attribut exclude_from_update kannst Du noch setzen, um die fhem Update Funktion an einer Ersetzung der Dateien zu hindern.

Und die Commandref Aktualisierung geht über Rudolfs Hinweis, wie beschrieben.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: Mr.Floppy am 27 Januar 2019, 15:32:08
Danke für die schnellen Antworten.   :D
Also doch einfacher wie ich gedacht hatte.
Werde es gleich mal testen.
Echt super Arbeit und Support.

Dank & Gruß
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: Burberius am 30 Januar 2019, 22:39:34
Hallo

Ich bin recht neu hier im Forum und möchte meinen nanoCUL auch auf diese Firmware umstellen, da ich nur noch Missing Acks bekomme.  >:(
Kann ich TSCULflash auch zum allerersten Flashen verwenden? Oder muss ich das irgendwie anders machen?

Ciao, Burb
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: noansi am 31 Januar 2019, 21:02:41
Hallo Burb,

ZitatKann ich TSCULflash auch zum allerersten Flashen verwenden? Oder muss ich das irgendwie anders machen?
Sollte funktionieren. Du musst dabei dafür sorgen, dass der Bootloader beim ausgelösten Reset auch aufgerufen wird, also Taste drücken oder Brücke setzen, so wie es bei Deínem nanoCUL eben gemacht werden muss.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: Burberius am 03 Februar 2019, 09:57:29
Das hat geklappt!
Danach hab ich FHEM gestoppt, in der Config CUL durch TSCUL ersetzt und FHEM wieder gestartet.
Leider bekomme ich immer noch ganz viele Fehler und MISSING ACKs.
Im Log steht zum Beispiel:

2019.02.03 09:54:43 3: TSCUL_ParseTsHM: CUL868 HM CCA channel busy error to 6390E1/Thermostat_WZ_Mitte:  075383 A F204 01883204 00 09 A3 A112 F10000 6390E1  _sfail
2019.02.03 09:54:43 3: LogHist CUL868:  473891 A F204 01757240 00 09 1D A112 F10000 638F45  _sfail
2019.02.03 09:54:43 3: LogHist CUL868:  475138 A F204 01758500 00 09 1D A112 F10000 638F45  _sfail
2019.02.03 09:54:43 3: LogHist CUL868:  475377 A F209 01759760 00 09 1D A112 F10000 638F45  _sfail _noAnsw
2019.02.03 09:54:43 3: LogHist CUL868:  488521 A F201 01772916 00 0F 4B 8610 638F38 000000 0AA8E20E0300 -62dB
2019.02.03 09:54:43 3: LogHist CUL868:  498009 A F201 01782420 00 0F 6F 8610 638F43 000000 0AA8E40C0000 -60dB
2019.02.03 09:54:43 3: LogHist CUL868:  499130 A F204 01782512 00 09 70 A112 F10000 638F43  _sfail
2019.02.03 09:54:43 3: LogHist CUL868:  499401 A F203 01783792 05 09 70 A112 F10000 638F43  _CCAdly:20 _dhmSt:1372
2019.02.03 09:54:43 3: LogHist CUL868:  500552 A F203 01784932 DB 09 70 A112 F10000 638F43  _CCAdly:876 _dhmSt:2512
2019.02.03 09:54:43 3: LogHist CUL868:  500798 A F209 01785196 00 09 70 A112 F10000 638F43  _sfail _noAnsw
2019.02.03 09:54:43 3: LogHist CUL868:  522434 A F201 01806872 00 0C C7 8470 64CE3D 000000 00E32A -69.5dB
2019.02.03 09:54:43 3: LogHist CUL868:  073383 A F201 01882224 00 0F A2 8610 6390E1 000000 0AA8E30B0000 -62.5dB
2019.02.03 09:54:43 3: LogHist CUL868:  073850 A F203 01882660 56 09 A3 A112 F10000 6390E1  _CCAdly:344 _dhmSt:436
2019.02.03 09:54:43 3: LogHist CUL868:  074122 A F203 01882940 04 09 A3 A112 F10000 6390E1  _CCAdly:16 _dhmSt:716
2019.02.03 09:54:43 3: LogHist CUL868:  075383 A F204 01883204 00 09 A3 A112 F10000 6390E1  _sfail
2019.02.03 09:54:43 3: TSCUL_ParseTsHM: CUL868 HM repeat failed to 6390E1/Thermostat_WZ_Mitte:  075622 A F209 01884464 00 09 A3 A112 F10000 6390E1  _sfail _noAnsw


Was ist da los?
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: noansi am 03 Februar 2019, 10:39:16
Hallo Burberius,

welche hmID willst Du eigentlich verwenden?
F10000 erscheint mir recht ungewöhnlich.

Nutzt Du eine VCCU?

Bitte ein list von Deinem CUL.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: Burberius am 03 Februar 2019, 11:40:53
Nein, keine VCCU.


Liste:
Thermostat_Viola                           serialNr        OEQ1712818
                                           model           HM-CC-RT-DN
Thermostat_WZ_Links                        serialNr        OEQ1712810
                                           model           HM-CC-RT-DN
Thermostat_WZ_Mitte                        serialNr        OEQ1714618
                                           model           HM-CC-RT-DN
Thermostat_Yasmin                          serialNr        OEQ1712823
                                           model           HM-CC-RT-DN
WandThermostat                             serialNr        OEQ1672197
                                           model           HM-TC-IT-WM-W-EU

Eigenschaften des CUL:
CMDS - ABCEFGJKMNRUVWXYZeilmtx
CUL868_MSGCNT - 356
CUL868_TIME - 2019-02-03 11:37:32
Clients - STACKABLETS:STACKABLE:CUL_HM:CUL_IR:HMS
DEF   - /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0@38400 0000
DeviceName - /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0@38400
FD - 8
FHTID - 0000
FUUID - 5c56a4f8-f33f-0dd0-49e4-27067279f8702e54
NAME - CUL868
NR - 19
PARTIAL -
RAWMSG - A0CF0847064CE3D00000000E52A::-60:CUL868:
RSSI - -60
STATE - Initialized
TYPE - TSCUL
VERSION - VTS 0.30 CSM868
VERSION_HW - nanoCUL_V1.x
VERSION_TS - yes AES ChTblSize:220
XmitOpen - 1
assignUpdCntI - 26
assignedIDsCnt - 5
initString - AP< X21 Ar AM5 AHF10000
msgLoadCurrent - 0
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: noansi am 03 Februar 2019, 13:25:13
Hallo Burberius,

ein list bedeutet Du gibst oben in der FHEM Kommandozeile
Zitatlist <fhemdevicename>
ein und postest die Ausgabe in code Tags (geht mit dem # button über den emoticons).

Also konkret für Deinen nanoCUL
list CUL868

Denn die Attribute sind nicht dabei. Sprich Deine Angaben sind unvollständig und lassen die Glaskugel nur dunkel glimmen.

Du hast möglicherweise nicht
attr CUL868 hmId F10000
in Deinen Attributen.
F10000 ist derzeit die hmId, welche Du mit Deinem nanoCUL verwendest, aber vielleicht gar nicht so wolltest.
In Beispielen wird meist F11034 verwendet. Sollte nicht mit Nachbarn kollidieren.

Dann bitte noch ein list von einem Deiner Thermostate
list Thermostat_WZ_Mitte

Denn ich nehme mal an, dass Du die noch nicht erfolgreich mit FHEM gepaired hast. Dann antworten die auch nicht.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: Burberius am 03 Februar 2019, 13:38:26
CUL:
Internals:
   CMDS       ABCEFGJKMNRUVWXYZeilmtx
   CUL868_MSGCNT 624
   CUL868_TIME 2019-02-03 13:33:30
   Clients    STACKABLETS:STACKABLE:CUL_HM:CUL_IR:HMS
   DEF        /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0@38400 0000
   DeviceName /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0@38400
   FD         8
   FHTID      0000
   FUUID      5c56a4f8-f33f-0dd0-49e4-27067279f8702e54
   NAME       CUL868
   NR         19
   PARTIAL   
   RAWMSG     A0C1E865A64CE3D000000A8E52B::-63.5:CUL868:
   RSSI       -63.5
   STATE      Initialized
   TYPE       TSCUL
   VERSION    VTS 0.30 CSM868
   VERSION_HW nanoCUL_V1.x
   VERSION_TS yes AES ChTblSize:220
   XmitOpen   1
   assignUpdCntI 26
   assignedIDsCnt 5
   initString AP<
X21
Ar
AM5
AHF10000
   msgLoadCurrent 0
   MatchList:
     1:STACKABLETS ^\*
     2:STACKABLE ^\*
     A:CUL_HM   ^A....................
     B:CUL_IR   ^I............
     C:HMS      ^810e04......a001
   READINGS:
     2019-02-03 09:23:41   Xmit-Events     ok:1 non-HM:1 init:1 disconnected:1
     2019-02-03 09:23:25   cmds             A B C E F G J K M N R U V W X Y Z e i l m t x
     2019-02-03 09:23:41   cond            ok
     2019-02-03 09:23:20   prot_disconnected last
     2019-02-03 09:23:26   prot_init       last
     2019-02-03 09:23:26   prot_non-HM     last
     2019-02-03 09:23:41   prot_ok         last
     2019-01-30 14:38:55   raw             No answer
     2019-02-03 13:27:52   scF             0.998565671143186
     2019-02-03 09:23:26   state           Initialized
   helper:
     CUrun      1
     ChkPart    0
     RA_Timeout 0
     VTS        1
     VTS_ACK    1
     VTS_AES    1
     assIdCnt   5
     assIdRep   5
     recd       1
     DEVIO:
       RXfailTO   
     HM:
       ChTblSize  220
       FUP        0
       HMactive   1
       hmCrdts    0
       hmSbusy    0
       ChTbl:
         638F383F   00
         638F433F   00
         638F453F   00
         6390E13F   00
         64CE3D3F   00
       msgCNT:
         0x01       624
         0x02       122
         0x03       90
         0x04       91
         0x09       38
       unknwn:
     cnd:
       0          1
       250        1
       253        1
       255        1
     hmLogHist:
        281431 A F002 14691580 00 01 C3 _ping
        282445 A F001 14692596 00 0F C4 8610 638F43 000000 0AA8EA0C0000 -56dB
        284267 A F001 14694420 00 0F A0 8610 638F38 000000 0AA8E40E0600 -60dB
        319076 A F001 14729280 00 0C 1C 865A 64CE3D 000000 A8E52B -61.5dB
        339077 A F001 14749308 00 0C 1C 8470 64CE3D 000000 00E52B -61.5dB
        351039 A F001 14761276 00 0F F7 8610 6390E1 000000 0AA8E50B0000 -58dB
        413849 A F001 14824188 00 0F 72 8610 638F45 000000 0AA8E50D0000 -56dB
        417699 A F001 14828044 00 0F C5 8610 638F43 000000 0AA8EB0C0000 -54.5dB
        464586 A F001 14874992 00 0C 1D 8470 64CE3D 000000 00E52B -61.5dB
        467268 A F001 14877680 00 0F A1 8610 638F38 000000 0AA8E50E0300 -60dB
        507776 A F001 14918252 00 0F F8 8610 6390E1 000000 0AA8E50B0000 -58.5dB
        014415 A F001 14949216 00 0F C6 8610 638F43 000000 0AA8EB0C0000 -54.5dB
        030821 A F001 14965644 00 0F 73 8610 638F45 000000 0AA8E50D0000 -55.5dB
        095551 A F001 15030464 00 0C 1E 865A 64CE3D 000000 A8E52B -63.5dB
     hmQ:
       000000:
       638F38:
       638F43:
       638F45:
       6390E1:
       64CE3D:
     ids:
       638F38:
         cfg        +638F38,00,00,00
         name       Thermostat_Yasmin
       638F43:
         cfg        +638F43,00,00,00
         name       Thermostat_Viola
       638F45:
         cfg        +638F45,00,00,00
         name       Thermostat_WZ_Links
       6390E1:
         cfg        +6390E1,00,00,00
         name       Thermostat_WZ_Mitte
       64CE3D:
         cfg        +64CE3D,00,00,00
         name       WandThermostat
     loadLvl:
       bl         40
     q:
       ATrNo      0
       HMcndN     0
       InQueues   0
       RQLSt      0
       RQLt       0
       XRpCnt     0
       XRpTm      1549183918.10397
       answerPend 0
       hmLanQlen  1
       apIDs:
         638F38     0
         638F43     0
         638F45     0
         6390E1     0
         64CE3D     0
     ref:
       Sdly       3
       TmBmCnt    1
       ioByteRate 3840
       ioByteRateMeas 3650.36597946376
       lHMt       15030464
       lSys       861500735
       pTTu       1024
       pndAs      0
       pndCUAp    0
       pngFrc     1
       pngLm      11
       pngMax     862
       pngMaxTot  862
       pngMin     3
       pngRef     10
       pngtm      861162324
       scErr      0.869818769861013
       scF        0.998565671143186
       scFN       2
       scHT       13666104
       scST       860138328
Attributes:
   icon       cul_868
   rfmode     HomeMatic


Thermostat:
Internals:
   CUL868_MSGCNT 94
   CUL868_RAWMSG A0FF986106390E10000000AA8E50B0000::-59:CUL868:
   CUL868_RSSI -59
   CUL868_TIME 2019-02-03 13:34:01
   DEF        6390E1
   FUUID      5c56a4ff-f33f-0dd0-c45b-0acf51837aea539d
   IODev      CUL868
   LASTInputDev CUL868
   MSGCNT     94
   NAME       Thermostat_WZ_Mitte
   NOTIFYDEV  global
   NR         37
   NTFY_ORDER 50-Thermostat_WZ_Mitte
   STATE      MISSING ACK
   TYPE       CUL_HM
   channel_01 Thermostat_WZ_Mitte_Weather
   channel_02 Thermostat_WZ_Mitte_Climate
   channel_03 Thermostat_WZ_Mitte_WindowRec
   channel_04 Thermostat_WZ_Mitte_Clima
   channel_05 Thermostat_WZ_Mitte_ClimaTeam
   channel_06 Thermostat_WZ_Mitte_remote
   lastMsg    No:F9 - t:10 s:6390E1 d:000000 0AA8E50B0000
   protCmdDel 27
   protLastRcv 2019-02-03 13:34:01
   protRcv    94 last_at:2019-02-03 13:34:01
   protResnd  6 last_at:2019-02-03 10:00:04
   protResndFail 2 last_at:2019-02-03 10:02:23
   protSnd    8 last_at:2019-02-03 10:02:18
   protState  CMDs_done_Errors:1
   rssi_at_CUL868 cnt:94 min:-64.5 max:-53 avg:-58.05 lst:-59
   READINGS:
     2019-02-03 09:33:28   Activity        alive
     2019-01-30 12:32:27   CommandAccepted yes
     2018-10-31 11:40:40   D-firmware      1.4
     2018-10-31 11:40:40   D-serialNr      OEQ1714618
     2018-12-21 20:36:44   PairedTo        0xF10000
     2018-10-31 11:43:37   R-backOnTime    10 s
     2018-10-31 11:43:37   R-burstRx       on
     2018-10-31 11:43:37   R-cyclicInfoMsg on
     2018-10-31 11:43:37   R-cyclicInfoMsgDis 0
     2018-10-31 11:43:37   R-pairCentral   0xF10000
     2019-02-03 13:34:01   actuator        0
     2019-02-03 13:34:01   battery         ok
     2019-02-03 13:34:01   batteryLevel    2.6
     2019-02-03 13:34:01   desired-temp    21.0
     2019-02-03 13:34:01   measured-temp   22.9
     2019-02-03 13:34:01   motorErr        ok
     2019-02-03 10:02:23   state           MISSING ACK
     2019-01-30 12:13:48   time-request    -
   helper:
     HM_CMDNR   249
     mId        0095
     regLst     ,0
     rxType     140
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       lstRecType 10
       newChn     +6390E1,00,00,00
       nextSend   1549197241.22113
       nxtSndMcnt F9
       prefIO     
       rxt        2
       tgtDly     88
       vccu       
       lRcTm:
         CUL868     15060708
         tnms       861530926
       p:
         6390E1
         00
         00
         00
     mRssi:
       mNo        F9
       io:
         CUL868:
           -49
           -49
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       prs        1
     rssi:
       at_CUL868:
         avg        -58.0585106382979
         cnt        94
         lst        -59
         max        -53
         min        -64.5
     shRegW:
       07         04
     tmpl:
Attributes:
   IODev      CUL868
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.4
   icon       sani_heating
   model      HM-CC-RT-DN
   room       CUL_HM,Wohnzimmer
   serialNr   OEQ1714618
   subType    thermostat
   webCmd     getConfig:clear msgEvents:burstXmit


Gepairt waren sie. FHEM empfängt auch die Messwerte.

hmId war beim CUL noch nicht gesetzt, hat aber auch nicht geholfen.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: noansi am 03 Februar 2019, 15:49:16
Hallo Burberius,

hast Du häufig
ZitatCUL868 HM CCA channel busy error
in den LOG Einträgen?

Dann würde etwas auf 868.3MHz stören, so dass nicht gesendet wird, da die tsculfw erst schaut, ob der Kanal belegt ist und nur dann sendet, wenn er frei ist.
Kann schon die Nähe zum Netzteil sein oder die Nähe zu einem Rechner oder Monitor.
Dauersendende HM devices oder 868.3MHz Sensoren hatten wir auch schon.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: Burberius am 03 Februar 2019, 21:07:15
Hi Ansgar

Das war das Problem...
Hab den Pi jetzt mal provisorisch umgezogen und jetzt funktioniert es ohne Probleme!
Nach einigen Experimenten hab ich das Hauptproblem gefunden, ich hatte den PI per HDMI an den TV angeschlossen. Ohne bekomme ich ganz wenige Übertragungsfehler.
Vielen DANK!!!

Ciao, Burb
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: noansi am 04 Februar 2019, 18:58:53
Hallo Burberius,

kannst Du bitte mal beim nanoCUL nach mindestens einem Tag Laufzeit ein get unusedstack ausführen und mir das Ergebnis mitteilen. Danke!

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: ram am 08 Februar 2019, 10:47:46
Hallo zusammen,

kurzes Feedback eines "Testwilligen": rf_mode "HomeMatic" funktioniert - Danke!

Lange Version: Ich habe einen knapp zwei Jahre alten CUL_v3.? gegen einen jetzt fabrikneuen und mit der normalen FW geflashten CUL_v3.4 am USB-Port des PCs ausgetauscht. Das Interface wurde direkt von FHEM initialized.
Aber ohne weitere Änderungen an der Hardware oder FHEM bekam ich ab nun "Missing ACK"s. Nach dem "um"-flashen auf die tsculfw, kopieren der FHEM/*-Dateien und Anpassen des FHEM Interface von CUL auf TSCUL funktioniert ab nun die Kommunikation wieder (und bisher auch) ohne jedes "Missing Ack"s. Leider läuft die CUL jetzt erst paar Minuten, sodass das Testergebnis noch die so belastbar sein könnte.

Dennoch folgend ein LIST des bei mir (wohl) funktionierenden CUL_v3:

Internals:
   CFGFN     
   CMDS       ABCFGJKRUVWXYeilmtx
   CUL_868_MSGCNT 90
   CUL_868_TIME 2019-02-08 10:36:06
   Clients    STACKABLETS:STACKABLE:CUL_HM:CUL_IR:HMS
   DEF        /dev/serial/by-id/usb-busware.de_CUL868_868000-if00@12000000 1xx6
   DeviceName /dev/serial/by-id/usb-busware.de_CUL868_868000-if00@12000000
   FD         5
   FHTID      1xx6
   NAME       CUL_868
   NR         220
   PARTIAL   
   RAWMSG     A0Fxxxxxxxxxxxxxxxxxxxxx0000::-59:CUL_868:
   RSSI       -59
   ReReadTO   0.001
   STATE      Initialized
   TYPE       TSCUL
   VERSION    VTS 0.30 CUL868
   VERSION_HW CUL_V3.4
   VERSION_TS yes AES ChTblSize:220
   XmitOpen   1
   assignUpdCntI 9
   assignedIDsCnt 9
   initString AP<
X21
Ar
AM5
AH54xxB3
   msgLoadCurrent 0
   owner_CCU  VCCU
   MatchList:
     1:STACKABLETS ^\*
     2:STACKABLE ^\*
     A:CUL_HM   ^A....................
     B:CUL_IR   ^I............
     C:HMS      ^810e04......a001
   READINGS:
     2019-02-08 09:29:47   ITSndFreq       433.920MHz +0.000kHz
     2019-02-08 09:36:13   Xmit-Events     non-HM:1 ok:2 disconnected:4 init:2
     2019-02-08 09:36:09   cmds             A B C F G J K R U V W X Y e i l m t x
     2019-02-08 09:36:13   cond            ok
     2019-02-08 09:35:49   prot_disconnected last
     2019-02-08 09:36:11   prot_init       last
     2019-02-08 09:26:55   prot_non-HM     last
     2019-02-08 09:36:13   prot_ok         last
     2019-02-08 10:27:25   scF             0.99997216910739
     2019-02-08 09:36:11   state           Initialized
   helper:
     CUrun      1
     ChkPart    0
     RA_Timeout 0
     VTS        1
     VTS_ACK    1
     VTS_AES    1
     assIdCnt   9
     assIdRep   9
     recd       0
     DEVIO:
       RXfailTO   
     HM:
       ChTblSize  220
       FUP        0
       HMactive   1
       hmCrdts    0
       hmSbusy    0
       ChTbl:
         5xxxx63F   00
         54xxx43F   00
         5xxx103F   00
         578F1D3F   00
         5xxx6C3F   00
         5xxxDE3F   00
         61xxx93F   00
         6xxxEE3F   00
         6xxx2D3F   00
       msgCNT:
         0x01       90
         0x02       77
         0x03       64
       unknwn:
     cnd:
       0          2
       250        1
       253        4
       255        2
     hmLogHist:
        180781 A F101 02803996 00 16 CE A010 5xxxx6 54xxB3 03820000326400FF00FF211463 -56dB
        180781 A F103 02804092 01 0A CE 8002 54xxB3 5xxxx6 00 _CCAdly:4 _dhmSt:96
        180786 A F101 02804244 00 0C CF A010 5xxxx6 54xxB3 030000 -55.5dB
        180786 A F103 02804340 01 0A CF 8002 54xxB3 5xxxx6 00 _CCAdly:4 _dhmSt:96
        244023 A F001 02867184 00 0F 05 8610 61xxx9 000000 0A88C10C0000 -59.5dB
        311792 A F001 02937676 00 0D 20 A610 5xxx10 54xxB3 06010000 -61dB
        311911 A F103 02937772 01 0A 20 8002 54xxB3 5xxx10 00 _CCAdly:4 _dhmSt:96
        390801 A F001 03016692 00 0F 06 8610 61xxx9 000000 0A88C20C0000 -59.5dB
        451091 A F002 03076984 00 01 C3 _ping
        490536 A F002 03116432 00 01 CC _ping
        001512 A F001 03151696 00 0F 07 8610 61xxx9 000000 0A88C30C0000 -59.5dB
        122012 A F001 03272204 00 0F 08 8610 61xxx9 000000 0A88C40C0000 -59.5dB
        292262 A F001 03442460 00 0F 09 8610 61xxx9 000000 0A88C50C0000 -59.5dB
        448013 A F001 03598216 00 0F 0A 8610 61xxx9 000000 0A88C60C0000 -59dB
     hmQ:
       000000:
       5xxxx6:
       54xxx4:
       5xxx10:
       5xxx6C:
       5xxxDE:
       6xxxEE:
       6xxx2D:
     ids:
       5xxxx6:
         cfg        +5xxxx6,00,00,00
         name       HM_SW2_1
       54xxx4:
         cfg        +54xxx4,00,00,00
         name       HM_Switch1
       5xxx10:
         cfg        +5xxx10,00,00,00
         name       HM_Tuerkontakt1
       578F1D:
         cfg        +578F1D,00,00,00
         name       HM_Tuerkontakt2
       5xxx6C:
         cfg        +5xxx6C,00,00,00
         name       HM_Rauchmelder_1
       5xxxDE:
         cfg        +5xxxDE,00,00,00
         name       HM_Rauchmelder_2
       61xxx9:
         cfg        +61xxx9,00,00,00
         name       HmThermo1
       6xxxEE:
         cfg        +6xxxEE,00,00,00
         name       HM_Oberlicht_02
       6xxx2D:
         cfg        +6xxx2D,00,00,00
         name       HM_Oberlicht_01
     loadLvl:
       bl         40
     q:
       ATrNo      0
       HMcndN     0
       InQueues   0
       RQLSt      0
       RQLt       0
       XRpCnt     0
       XRpTm      1549614447.95257
       answerPend 0
       hmLanQlen  1
       apIDs:
         5xxxx6     0
         54xxx4     0
     ref:
       Sdly       0
       TmBmCnt    1
       ioByteRate 1200000
       ioByteRateMeas 72372.8250751939
       lHMt       3598216
       lSys       209114637
       pTTu       256
       pndAs      0
       pndCUAp    0
       pngFrc     1
       pngLm      8
       pngMax     -300000
       pngMaxTot  1
       pngMin     0
       pngRef     1
       pngtm      208593426
       scErr      24.9996601697057
       scF        0.99997216910739
       scFN       0
       scHT       3076984
       scST       208593427
Attributes:
   hmId       54xxB3
   rfmode     HomeMatic

(AES Key ist auf der VCCU)

Viele Grüße
Reza
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: Cube am 08 Februar 2019, 22:54:54
Bei mir hat FHEM gestern begonnen durchgehend mit der folgenden Meldung abzustürzen:

Can't use an undefined value as a subroutine reference at ./FHEM/97_timerTS.pm line 75.

Ich bin mir nicht sicher was der Auslöser war, weil das Ganze vorher fehlerfrei lief. Nachdem ich diese Zeile auskommentiert habe, läuft FHEM jetzt auch wieder.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: noansi am 09 Februar 2019, 10:32:20
Hallo Cube,

welche Version Firmware und Module verwendest Du?

Wenn es die aktuelle Version ist, dann sieht die Zeile so aus:
    &{$entry->{fn}}($entry->{arg});

Statt die Zeile auzukommentieren würde es so mehr Sinn machen:
    &{$entry->{fn}}($entry->{arg}) if (defined($entry->{fn}));
um den Problemfall abzufangen.

Die Frage ist nun, woher kommt der Fall der undefinierten Funktionsreferenz?

ZitatCan't use an undefined value as a subroutine reference at ./FHEM/97_timerTS.pm line 75.
besagt, dass der Funktionsverweis in $entry->{fn} nicht definiert ist. Und das liegt nicht an 97_timerTS.pm, so weit ich das sehe.
Damit werden Prioritätswarteschlangen abgearbeitet und das identisch zu Rudolfs Code in fhem.pl.

Einzige Verwendung von Prioritätswarteschlangen finde ich in 10_MQTT2_DEVICE.pm Zeile 167ff.
Verwendest Du MQTT2_DEVICE?
Hast Du autocreate aktiv?
Welche perl Version verwendest Du?

Dann gibt es noch apptime, apptm und freezemon die die Prioritätswarteschlange anpacken.
apptime und apptm arbeiten sie ab, wie timerTS oder fhem.pl. Es würde also in den Modulen knallen.
freezemon "fasst" sie zumindest an. Hast Du freezemon im Einsatz?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: noansi am 09 Februar 2019, 10:35:32
Hallo ram,

danke für's Feedback.

Was hatte den der alte CUL3.x für eine Krankheit?
Nutzt Du den CUL auch, um 433.92MHz Geräte zu schalten?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: noansi am 09 Februar 2019, 12:33:53
Hallo Cube,

ich habe hier https://forum.fhem.de/index.php/topic,24436.msg891756.html#msg891756 (https://forum.fhem.de/index.php/topic,24436.msg891756.html#msg891756) die FHEM Module aktualisiert, um undefinierte PrioQueue Funktionsaufrufe abzufangen.

Ich habe 10_MQTT2_DEVICE.pm möglicherweise in Verbindung mit der perl Version in Verdacht. Daher antworte bitte noch auf meine Fragen oben.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: noansi am 09 Februar 2019, 19:06:53
Hallo Zusammen,

ich habe hier https://forum.fhem.de/index.php/topic,24436.msg891756.html#msg891756 (https://forum.fhem.de/index.php/topic,24436.msg891756.html#msg891756) die FHEM Module nochmals aktualisiert weil ich feststellen musste, dass PrioQueues gar nicht korrekt abgearbeitet wurden.

Das fällt aber nur auf, wenn 10_MQTT2_DEVICE.pm zur Anwendung kommt, was ggf. schon mit aktivem autocreate unbewust passieren kann.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: Cube am 10 Februar 2019, 02:20:49
Zitat von: noansi am 09 Februar 2019, 10:32:20
Einzige Verwendung von Prioritätswarteschlangen finde ich in 10_MQTT2_DEVICE.pm Zeile 167ff.
Verwendest Du MQTT2_DEVICE?
Hast Du autocreate aktiv?
Welche perl Version verwendest Du?

Ja, ich verwende MQTT2_DEVICE für zigbee2mqtt. Autocreate ist aktiv, neue Geräte sind aber nicht hinzugekommen. Ich habe allerdings an dem Tag, an dem das Problem aufgetreten ist, zigbee2mqtt aktualisiert und Einstellungen geändert. Ich verwende Perl v5.24.1.

Zitat von: noansi am 09 Februar 2019, 19:06:53
ich habe hier https://forum.fhem.de/index.php/topic,24436.msg891756.html#msg891756 (https://forum.fhem.de/index.php/topic,24436.msg891756.html#msg891756) die FHEM Module nochmals aktualisiert weil ich feststellen musste, dass PrioQueues gar nicht korrekt abgearbeitet wurden.

Ich habe die Module aktualisiert und der Fehler tritt nicht mehr auf. Super.  :)
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: noansi am 10 Februar 2019, 08:39:38
Hallo Cube,

danke!

Hier https://forum.fhem.de/index.php/topic,97159.msg903510.html#msg903510 (https://forum.fhem.de/index.php/topic,97159.msg903510.html#msg903510) hoffe ich mal, dass Rudolf es liest und in fhem.pl ebenfalls Veränderungen vornimmt.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: noansi am 10 Februar 2019, 15:30:32
Hallo Zusammen,

wie ab hier https://forum.fhem.de/index.php/topic,97159.msg903956.html#msg903956 (https://forum.fhem.de/index.php/topic,97159.msg903956.html#msg903956) in Diskussion mit Rudolf zu lesen ist, tritt das oben genannte potentielle Crash Problem nur mit der bisherigen Version von timerTS auf.

Also bitte die aktuellen Module mit aktueller Firmware nutzen https://forum.fhem.de/index.php/topic,24436.msg891756.html#msg891756 (https://forum.fhem.de/index.php/topic,24436.msg891756.html#msg891756).

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: ram am 11 Februar 2019, 21:19:27
Hallo.

Zitat
Hallo ram,
danke für's Feedback.

gerne!

Zitat
Was hatte den der alte CUL3.x für eine Krankheit?
Nutzt Du den CUL auch, um 433.92MHz Geräte zu schalten?
Gruß, Ansgar.

Ich denke die alte CUL hat einen Hardwareschaden... könnte eine Spannungspitze gewesen sein ;-) Jedenfalls sendet sie nicht mehr (SDR gecheckt), meldet aber auch kein CCA Fehler.

Für 433 MHz habe ich eine weitere CUL.

Ich habe aber aktuell ein einziges HM-Gerät, mit welchem wohl die Kommunikation nicht mehr funktioniert. FHEM scheint das Gerät nicht mehr pairen zu können. Ich weiss aber nicht, ob das ein "normales" Problem, z.B. Abstand CUL/Antenne zu HM-Gerät ist, oder doch ggf. auch etwas mit der tsculfw zu tun haben könnte.


...
2019.02.11 20:52:54 3 : TSCUL_ParseTsHM: CUL_868 HM repeat failed to 543764/HM_543764: 433222 A F109 14603916 00 10 31 A001 54F2B3 543764 00040000000000 _sfail _noAnsw
2019.02.11 20:52:56 4 : TSCUL_XmitAwaitHMTo CUL_868: timeout - 543764
2019.02.11 20:52:59 4 : TSCUL_send: CUL_868 437999 As 10 31 A001 54F2B3 543764 00040000000000
2019.02.11 20:52:59 4 : TSCUL_XmitDlyHM: CUL_868 id:543764 rtoms:2328
2019.02.11 20:52:59 4 : TSCUL_Parse: CUL_868 438036 A F103 14608700 02 10 31 A001 54F2B3 543764 00040000000000 _CCAdly:8
2019.02.11 20:52:59 4 : TSCUL_Parse: CUL_868 438309 A F103 14608972 01 10 31 A001 54F2B3 543764 00040000000000 _CCAdly:4
2019.02.11 20:52:59 4 : TSCUL_Parse: CUL_868 438581 A F103 14609244 01 10 31 A001 54F2B3 543764 00040000000000 _CCAdly:4
2019.02.11 20:53:00 3 : LogHist CUL_868: 427277 As 10 31 A001 54F2B3 543764 00040000000000
2019.02.11 20:53:00 3 : LogHist CUL_868: 427315 A F103 14597976 01 10 31 A001 54F2B3 543764 00040000000000 _CCAdly:4
2019.02.11 20:53:00 3 : LogHist CUL_868: 427589 A F103 14598252 01 10 31 A001 54F2B3 543764 00040000000000 _CCAdly:4
2019.02.11 20:53:00 3 : LogHist CUL_868: 427861 A F103 14598524 01 10 31 A001 54F2B3 543764 00040000000000 _CCAdly:4
2019.02.11 20:53:00 3 : LogHist CUL_868: 428098 A F109 14598792 00 10 31 A001 54F2B3 543764 00040000000000 _sfail _noAnsw
2019.02.11 20:53:00 3 : LogHist CUL_868: 432403 As 10 31 A001 54F2B3 543764 00040000000000
2019.02.11 20:53:00 3 : LogHist CUL_868: 432440 A F103 14603104 02 10 31 A001 54F2B3 543764 00040000000000 _CCAdly:8
2019.02.11 20:53:00 3 : LogHist CUL_868: 432713 A F103 14603376 01 10 31 A001 54F2B3 543764 00040000000000 _CCAdly:4
2019.02.11 20:53:00 3 : LogHist CUL_868: 432985 A F103 14603648 01 10 31 A001 54F2B3 543764 00040000000000 _CCAdly:4
2019.02.11 20:53:00 3 : LogHist CUL_868: 433222 A F109 14603916 00 10 31 A001 54F2B3 543764 00040000000000 _sfail _noAnsw
2019.02.11 20:53:00 3 : LogHist CUL_868: 437999 As 10 31 A001 54F2B3 543764 00040000000000
2019.02.11 20:53:00 3 : LogHist CUL_868: 438036 A F103 14608700 02 10 31 A001 54F2B3 543764 00040000000000 _CCAdly:8
2019.02.11 20:53:00 3 : LogHist CUL_868: 438309 A F103 14608972 01 10 31 A001 54F2B3 543764 00040000000000 _CCAdly:4
2019.02.11 20:53:00 3 : LogHist CUL_868: 438581 A F103 14609244 01 10 31 A001 54F2B3 543764 00040000000000 _CCAdly:4
2019.02.11 20:53:00 3 : TSCUL_ParseTsHM: CUL_868 HM repeat failed to 543764/HM_543764: 438818 A F109 14609512 00 10 31 A001 54F2B3 543764 00040000000000 _sfail _noAnsw
2019.02.11 20:53:01 4 : TSCUL_XmitAwaitHMTo CUL_868: timeout - 543764


Mir sagt das "raw" Log aber leider nicht viel ;-)

Viele Grüße
Reza

Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: noansi am 11 Februar 2019, 21:34:25
Hallo Reza,

das log sagt, Du sendest an das Gerät mit der ID 543764 (immer wieder 3x), aber es antwortet nicht, bzw. CUL empfängt keine Antwort.

Entweder es ist außer Reichweite (eventuell ist der neue CUL etwas schlechter, als der alte) oder es ist defekt oder die Batterien sind leer/zu schwach.
Oder es schläft schon wieder und du musst eventuell immer wieder das Knöpfchen drücken.
Mehr Infos zum Gerät erhellen meist die Glaskugel.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: noansi am 11 Februar 2019, 21:39:55
Hallo Zusammen,

ich habe die Module nochmals aktualisiert https://forum.fhem.de/index.php/topic,24436.msg891756.html#msg891756 (https://forum.fhem.de/index.php/topic,24436.msg891756.html#msg891756).
Ich habe aus den letzten Testerfahrungen heraus unnötige use vars rausgeworfen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: ram am 11 Februar 2019, 22:05:01
Hallo Ansgar,

Zitat von: noansi am 11 Februar 2019, 21:34:25
Hallo Reza,

das log sagt, Du sendest an das Gerät mit der ID 543764 (immer wieder 3x), aber es antwortet nicht, bzw. CUL empfängt keine Antwort.

Entweder es ist außer Reichweite (eventuell ist der neue CUL etwas schlechter, als der alte) oder es ist defekt oder die Batterien sind leer/zu schwach. Oder es schläft schon wieder und du musst eventuell immer wieder das Knöpfchen drücken.
Würde mich tatsächlich nicht wundern, wenn das Geräte und nicht die CUL ein Problem hat. Konnte ich aber nicht unterscheiden, und daher habe ich gerne das Log angeboten.

Zitat
Mehr Infos zum Gerät erhellen meist die Glaskugel.

Gruß, Ansgar.

Okay.. etwas mehr Licht in der Glaskugel :-)

Internals:
   CFGFN     
   CUL_868_MSGCNT 7
   CUL_868_RAWMSG A0D38841054376400000006010000::-58.5:CUL_868:
   CUL_868_RSSI -58.5
   CUL_868_TIME 2019-02-11 21:01:16
   DEF        543764
   IODev      CUL_868
   LASTInputDev CUL_868
   MSGCNT     7
   NAME       HM_543764
   NOTIFYDEV  global
   NR         311
   STATE      MISSING ACK
   TYPE       CUL_HM
   lastMsg    No:38 - t:10 s:543764 d:000000 06010000
   protCmdDel 8
   protLastRcv 2019-02-11 21:01:16
   protResnd  12 last_at:2019-02-11 21:26:43
   protResndFail 4 last_at:2019-02-11 21:26:48
   protSnd    6 last_at:2019-02-11 21:26:27
   protState  CMDs_done_Errors:1
   rssi_CUL_868 min:-52 lst:-52 avg:-52 max:-52 cnt:1
   rssi_at_CUL_868 min:-58.5 lst:-58.5 avg:-55.99 cnt:7 max:-53
   READINGS:
     2019-02-11 20:44:19   D-firmware      2.8
     2019-02-11 20:44:19   D-serialNr      OEQ0181580
     2019-02-11 21:28:14   RegL_00.       
     2019-02-11 21:01:16   deviceMsg       off (to broadcast)
     2019-02-11 21:01:16   level           0
     2019-02-11 21:01:16   pct             0
     2019-02-11 21:01:16   recentStateType info
     2019-02-11 21:26:48   state           MISSING ACK
     2019-02-11 21:01:16   timedOn         off
   helper:
     HM_CMDNR   57
     cSnd       0154F2B354376400040000000000,1154F2B35437640201C80000
     dlvl       C8
     dlvlCmd    ++A01154F2B35437640201C80000
     getCfgList all
     getCfgListNo ,3
     mId        0069
     regLst     ,0,1,3p
     rxType     1
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       lstRecType 10
       newChn     +543764,00,00,00
       nextSend   1549915276.34045
       nxtSndMcnt 38
       prefIO     
       rxt        0
       tgtDly     88
       vccu       VCCU
       lRcTm:
         CUL_868    300318260
         tnms       505824220
       p:
         543764
         00
         00
         00
     mRssi:
       mNo        38
       io:
         CUL_868:
           -52.5
           -52.5
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       prs        1
     rssi:
       CUL_868:
         avg        -52
         cnt        1
         lst        -52
         max        -52
         min        -52
       at_CUL_868:
         avg        -56
         cnt        7
         lst        -58.5
         max        -53
         min        -58.5
     tmpl:
Attributes:
   IODev      CUL_868
   IOgrp      VCCU
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   2.8
   model      HM-LC-Sw1PBU-FM
   room       CUL_HM
   serialNr   OEQ0181580
   subType    switch
   webCmd     statusRequest:toggle:on:off
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: noansi am 11 Februar 2019, 22:45:13
Hallo Reza,

also Du hast heute schon was von dem device empfangen (21:01:16), siehe readings und der RSSI ist auch nicht schlecht.
Der Register Read misslingt aber offenbar.

Das Pairing war wohl nicht erfolgreich und daher fühlt er sich eventuell nicht angesprochen.

Hast Du das Pairing korrekt angestoßen?

Das Pairing war nicht im Logauszug, nur der Registerreadversuch von FHEM.

Pairing mit Serienummer kannst Du auch mal probieren.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: Bastel-Frank am 05 April 2019, 13:12:33
Hallo Ansgar,

meine Installation mit den mittlerweile 6 CUL's läuft sehr gut  ;D.

Mir ist jetzt aufgefallen, dass nach einem Reboot des fhem-Servers das Attribut "rfmode = Homematic" nicht mehr gesetzt wurde, d.h. das Attribut war nicht mehr definiert. Dies führte (anscheinend) dazu, dass die Kommunikation nicht mehr sauber lief. Es kam zu Aussetzern und nicht erreichbaren Devices. Hinweis: Bei einem "shutdown restart" hingegen bleibt "rfmode" erhalten.
Hast Du eine Idee dazu?

Viele Grüße
Frank
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: noansi am 05 April 2019, 20:21:14
Hallo Frank,

ZitatMir ist jetzt aufgefallen, dass nach einem Reboot des fhem-Servers das Attribut "rfmode = Homematic" nicht mehr gesetzt wurde, d.h. das Attribut war nicht mehr definiert.
Nur wenn in dem Fall die Kommunikation bei der CUL Initialisierung nicht sauber laufen würde, dann könnte es passieren, dass das Attribut nicht gesetzt wird. Dann würde beim CUL cmds kein A enthalten oder die Version nicht gelesen werden können und VERSION_TS wäre nicht yes.
Ein List nach dem Reboot könnte mehr Klarheit bringen.

Dein fhem-server läuft auf was für einem System?
Bei einem Raspi können die USB Schnittstellzuordnungen bei Reboot anders sein, als bei Runterfahren und Abschalten mit anschließendem Einschalten. Das ist nur mit 99-usb-serial.rules mit eindeutiger Seriennummerzuordnung gelöst werden. USB-Ports sind nach meiner Erfahrung nicht eindeutig. Dann können andere serielle USB devices unerwartet auf den CUL Schnittstellen landen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: Bastel-Frank am 06 April 2019, 11:51:49
Hallo Ansgar,

der fhem-Server läuft auf Ubuntu 18.10. Nochmal zur Erinnerung: Meine CULs (bis auf Einen) sind per ser2net von externen Raspi's angebunden.

List eines mit ser2net angebundenen CULs:
Internals:
   CMDS       ABCEFGJKMNRUVWXYZeilmtx
   Clients    STACKABLETS:STACKABLE:TSCUL_WS:IT:CUL_FHTTK:CUL_HOERMANN:TSCUL_TX:CUL_IR:SOMFY:Revolt:ESA2000:TSCUL_EM:BS:USF1000:FS20:FHT.*:TSKS300:HMS:CUL_TCM97001:CUL_REDIRECT
   DEF        raspi-og:2003 1447
   DeviceName raspi-og:2003
   FD         389
   FHTID      1447
   FUUID      5c813716-f33f-3d91-1023-56993d29182ce4a6
   NAME       CUL_OG
   NR         287
   PARTIAL   
   RAWMSG     
   STATE      Initialized
   SlowRF_BitBufferOvrfl 0
   SlowRF_BucketOvrfl 0
   TYPE       TSCUL
   VERSION    VTS 0.29 CSM868
   VERSION_HW nanoCUL_V1.x
   VERSION_TS yes AES ChTblSize:220
   XmitOpen   0
   assignedIDsCnt 18
   initString X21
AM5
AH738396
   owner_CCU  vccu
   MatchList:
     1:STACKABLETS ^\*
     2:STACKABLE ^\*
     A:TSCUL_WS ^K.....
     B:IT       ^i.(:.|.....)
     C:CUL_FHTTK ^T[\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F]
     D:CUL_HOERMANN ^R..........
     E:TSCUL_TX ^TXA.........
     F:CUL_IR   ^I............
     G:SOMFY    ^Y[r|t|s]:?[\dA-F]+
     H:Revolt   ^r......................$
     I:ESA2000  ^S................................$
     K:TSCUL_EM ^E0.0[\dA-F]..............
     L:BS       ^81..(04|0c)..0101a001a5cf
     M:USF1000  ^81..(04|0c)..0101a001a5ceaa00....
     N:FS20     ^81..(04|0c)..0101a001
     O:FHT      ^81..(04|09|0d)..(0909a001|83098301|c409c401)..
     P:TSKS300  ^810d04..4027a001
     Q:HMS      ^810e04......a001
     R:CUL_TCM97001 ^s[\dA-F]+
     S:CUL_REDIRECT ^o
   READINGS:
     2018-11-05 20:32:08   Ints_per_sec    SI: 3192.20748  TI: 2.06736  S: 763.20699  L: 2.06736  U: 34.60319  M: 5.74713
     2019-04-06 11:47:24   Xmit-Events     non-HM:1 disconnected:1
     2018-11-07 07:47:02   ccconf          freq:868.300MHz freqOffs:-20.630kHz bWidth:101kHz freqIF:152.34kHz rAmpl:33dB sens:8dB dRate:9.993kBit/s
agcPrio:1 agcWait:16 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:1 AGC_FREEZE:0
CCAmode:3 csRelThr:10dB csAbsThr:7dB
     2019-04-06 11:47:23   cmds             A B C E F G J K M N R U V W X Y Z e i l m t x
     2019-04-06 11:47:24   cond            non-HM
     2017-01-31 20:35:05   credit10ms      1800
     2019-01-28 09:16:34   prot_ERROR-Overload last
     2018-11-08 16:02:36   prot_Warning-HighLoad last
     2019-04-06 11:46:20   prot_disconnected last
     2019-04-03 11:26:57   prot_init       last
     2019-04-06 11:47:24   prot_non-HM     last
     2019-04-03 11:26:57   prot_ok         last
     2019-04-06 11:38:34   scF             0.999593593134096
     2019-04-06 11:47:24   state           Initialized
   helper:
     ChkPart    0
     RA_Timeout 0
     VTS        1
     VTS_ACK    1
     VTS_AES    1
     assIdCnt   18
     assIdRep   18
     hmTSAt1Add
     recd       0
     tbuf       
     DEVIO:
       RXfailTO   
     HM:
       ChTblSize  220
       HMactive   0
       hmCrdts    9
       ChTbl:
         254C4C3F   00
         2710FA3F   00
         27128B3F   00
         2CABFE3F   00
         2CAC613F   00
         2CAC743F   00
         2CAC993F   00
         2E51C93F   00
         3032663F   00
         31D0AD3F   00
         384B403F   00
         384B4D3F   00
         384B523F   00
         384B573F   00
         384DE53F   00
         3C8D913F   00
         3C8D9D3F   00
         56543D3F   00
     cnd:
       250        1
       253        1
     ids:
       254C4C:
         cfg        +254C4C,00,00,00
         name       OG.hz.01
       2710FA:
         cfg        +2710FA,00,00,00
         name       OG.k2.TH
       27128B:
         cfg        +27128B,00,00,00
         name       OG.wz.TH
       2CABFE:
         cfg        +2CABFE,00,00,00
         name       OG.wz.l.RO
       2CAC61:
         cfg        +2CAC61,00,00,00
         name       OG.sz.l.RO
       2CAC74:
         cfg        +2CAC74,00,00,00
         name       OG.wz.m.RO
       2CAC99:
         cfg        +2CAC99,00,00,00
         name       OG.wz.r.RO
       2E51C9:
         cfg        +2E51C9,00,00,00
         name       OG.hz.02
       303266:
         cfg        +303266,00,00,00
         name       OG.sz.TH
       31D0AD:
         cfg        +31D0AD,00,00,00
         name       OG.k1.TH
       384B40:
         cfg        +384B40,00,00,00
         name       OG.th.r.RO
       384B4D:
         cfg        +384B4D,00,00,00
         name       OG.k1.l.RO
       384B52:
         cfg        +384B52,00,00,00
         name       OG.k2.RO
       384B57:
         cfg        +384B57,00,00,00
         name       OG.k1.r.RO
       384DE5:
         cfg        +384DE5,00,00,00
         name       OG.kueche.RO
       3C8D91:
         cfg        +3C8D91,00,00,00
         name       EG.sz.FK
       3C8D9D:
         cfg        +3C8D9D,00,00,00
         name       OG.th.l.FK
       56543D:
         cfg        +56543D,00,00,00
         name       OG.sz.r.RO
     q:
       HMcndN     250
       hmLanQlen  1
       cap:
         sum        0
     ref:
       doNbyterate 50
       ioByteRate 1000000
       ioByteRateMeas 0
       lHMt       4294967295
       lSys       1640943980.30327
       pngFrc     1
       pngLm      70
       pngMax     -100000000
       pngMaxTot  -100000000
       pngMin     100000000
       pngRef     100000000
       scF        1
       scFN       1
       scHT       4294967295
       scST       1640943980.30327
Attributes:
   hmId       738396
   hmLanQlen  1_min
   model      CUL
   room       CUL_TS
   verbose    0


Hinweis, nachdem Reboot bekommt ich von fhem auch folgende Fehlermeldung:
configfile: ASKSIN not supported
ASKSIN not supported
CUL_KG: Mode HomeMatic not supported, wrong firmware?!?
ASKSIN not supported
ASKSIN not supported
CUL_EG: Mode HomeMatic not supported, wrong firmware?!?
ASKSIN not supported
ASKSIN not supported
CUL_OG: Mode HomeMatic not supported, wrong firmware?!?
ASKSIN not supported
ASKSIN not supported
CUL_GH: Mode HomeMatic not supported, wrong firmware?!?
ASKSIN not supported
ASKSIN not supported
CUL_DG: Mode HomeMatic not supported, wrong firmware?!?
ASKSIN not supported


Wenn ich dann fhem per "shutdown restart" nochmal neu starte, kommen diese Fehlermeldung meistens nicht mehr.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: RaspiLED am 06 April 2019, 18:06:09
Hi,
Ser2net braucht das netz, kann es sein, dass dein FHEM vor der Init des Netzwerks gestartet wird?
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: noansi am 06 April 2019, 19:16:45
Hallo Frank,

ZitatNochmal zur Erinnerung: Meine CULs (bis auf Einen) sind per ser2net von externen Raspi's angebunden.
Die biologische SSD hat leider auch die Funktion, nicht mehr benötigte und veränderliche Informationen auch wieder zu löschen.  ;)
Und die Funktion funktioniert von Jahr zu Jahr immer besser und aktiviert sich früher.   :( ;)
Wäre hilfreich, wenn Du Systemdaten immer direkt mit erwähnst.

Sehe ich das richtig, das nur die per ser2net angebundenen CULs betroffen sind?

Dann tippe ich beim Reboot darauf, dass ser2net beim fhem Start noch nicht oder nicht vollständig aktiv ist die Kommunikation zu den per ser2net angebundenen CULs beim fhem Start gestört ist.
Mit einem globalen verbose 5 und einem reboot könnte man im log sehen, was dabei an Daten zum CUL ausgetauscht werden kann.

Die Meldungen "Mode HomeMatic not supported, wrong firmware?!?" können nur dann kommen, wenn beim Setzen des Attributs beim fhem Start die Version und Fähigkeiten des CULs noch nicht korrekt bestimmt werden können (aber eine Verbindung geöffnet werden kann?). Die Funktion/Prüfung soll verhindern, dass ein CUL ohne HM Support auf HomeMatic gesetzt wird und damit andere Fehler auftreten.

Vielleicht musst Du auch noch irgendwie eine Verzögerung einbauen? Da ich ser2net nicht nutze, kann ich Dir konkretere Tips dazu nicht geben.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: Bastel-Frank am 15 April 2019, 12:36:05
Hallo Ansgar, Hallo Arnd,

ich habe in der Vergangenheit immer wieder Probleme nach einem Reboot mit ser2net gehabt. Ich habe sie für mich dadurch gelöst, indem ich den entfernen Raspi neu gestartet habe. Dann ging es meistens.
Ich habe jetzt einen Thread gefunden, bei dem genau "mein" Problem richtig gelöst wurde. Siehe https://forum.fhem.de/index.php/topic,79262.msg712557.html#msg712557 (https://forum.fhem.de/index.php/topic,79262.msg712557.html#msg712557).  :)

Viele Grüße
Frank
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: Bytechanger am 21 April 2019, 19:30:05
Hallo,

kann es sein, dass es durch verschiedene Update-Änderungen in FHEM auch eine Anpassung der 10_CUL_HM.pm benötigt?
Diese sind ja derzeit vom Update ausgeschlossen, da für diese Firmware hier eine spezielle Version benötigt wird?!?!

Ich habe aktuell Probleme mit dem Display HM-Dis-WM55, ich kann dort keine Texte mehr setzten.

>>Hier wurden in der aktuellen (im Update befindlichen 10_CUL-HM.pm Änderungen vorgeneommen, dass es wieder geht.
https://forum.fhem.de/index.php?topic=99579.0 <<

Bei mir bleibt es weiterhin defekt.

Greets

Byte

Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: noansi am 22 April 2019, 00:22:53
Hallo Byte,

Martin hat
"HM-Dis-WM55"
in 10_CUL_HM und HMConfig in
"HM-DIS-WM55"
umbenannt.

Versuch mal testweise beim Display und seinen Subdevices das Attribut "model" entsprechend umzubenennen, wenn Du Martins aktuellen Stand benutzt.
Ich nehme mal an, dass es dann bei Dir wieder geht.
Bei generellen Problemen bezüglich IO müßten sonst noch mehr HM devices Probleme machen.

Ich bin Martins Änderungen über den Winter nicht gefolgt, da mein System mit meinem Stand stabil gelaufen ist, was mir wichtiger ist.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: Bytechanger am 22 April 2019, 07:49:53
Guten Morgen,

das war es leider nicht.
Logs:


FHEM_CUSTOM: FHEM restartet!
2019.04.22 07:46:43.501 3: userCfg return value: Unknown argument displayWM, choose one of clear:readings,trigger,register,oldRegs,rssi,msgEvents,msgErrors,attack,all getConfig:noArg getRegRaw peerBulk peerChan regBulk regSet tplDel
Unknown argument displayWM, choose one of clear:readings,trigger,register,oldRegs,rssi,msgEvents,msgErrors,attack,all getConfig:noArg getRegRaw peerBulk peerChan regBulk regSet tplDel
Unknown argument displayWM, choose one of clear:readings,trigger,register,oldRegs,rssi,msgEvents,msgErrors,attack,all
[...]



Mir fehlt im Device also das "displayWM".


Greets
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: noansi am 22 April 2019, 08:44:50
Hallo Byte,

eventuell habe ich mich unklar ausgedrückt.
Bei allen channels des Display musst Du die Anderung am model Attribut durchführen, nicht nur am Display selbst.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: noansi am 22 April 2019, 08:54:25
Hallo Byte,

und Du musst 10_CUL_HM, 98_HMinfo und HMConfig entweder allesamt von meinem letzten Stand nutzen oder allesamt aus Martins letztem Stand aus dem Update.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: Bytechanger am 22 April 2019, 08:57:05
Jepp,

ich hatte mit Suchen/Ersetzen nur die 10_CUL_HM geändert,
jetzt auch die fhem.cfg, nun geht es wieder.
Danke.

Bezüglich letzter Stand: ich habe alle ausgeschlossen, die Du in Deinem Thread beschrieben hast. Damit sollte dies gewährleistet gewesen sein.

attr global exclude_from_update 00_TSCUL.pm 16_STACKABLETS.pm DevIoTS.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.pm CalcUtil.pm 97_timerTS.pm 98_TSCULflash.pm 97_timerTS.pm 98_apptime.pm 98_apptm.pm 10_IT.pm 10_CULG.pm 10_CUL_HM.pm HMConfig.pm 98_HMinfo.pm ReadingUtil.pm 98_autocreate.pm 98_Cumulate.pm 98_SAverage.pm

War es aber offensichtlich nicht...

EDIT:
Dachte ich, habe nun gesehen, dass es doch nicht so war. Misst, jetzt habe ich wohl einen Mischmasch....
Ich hoffe, das war das einzige Problem...

Wirst Du bald nochmal die ausgeschlossenen Dateien updaten?
Warum wird Deine Änderung nicht ins Hauptsystem aufgenommen? Läuft doch super...


Greets

Byte
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: noansi am 22 April 2019, 09:42:40
Hallo Byte,

Zitatich hatte mit Suchen/Ersetzen nur die 10_CUL_HM geändert,
???

ZitatDachte ich, habe nun gesehen, dass es doch nicht so war. Misst, jetzt habe ich wohl einen Mischmasch....
Das kannst Du wohl relativ einfach wieder auf meinen letzten Stand bringen.  ;)

ZitatWirst Du bald nochmal die ausgeschlossenen Dateien updaten?
Wenn ich den Eindruck habe, dass Martin wieder auf einem wenig wandlungsfreudigen Stand ist.  :)
Der Homematic Thread spricht in letzter Zeit noch dagegen.
Wenn ich das mache, dann gibt es sicherlich für User Änderungszwänge an ihrer config, so wie es im Homematic Thread zu lesen ist und wie Du gerade selbst festgestellt hast.

ZitatWarum wird Deine Änderung nicht ins Hauptsystem aufgenommen? Läuft doch super...
Martin hat das übernommen, was er für ausreichend gehalten hat. Was Prävention von EEPROM Verschleiß für CULs mit wenig RAM (CUL_V3, nanoCUL, miniCUL etc.) angeht aber nicht.
D.h. grundsätzlich sollte TSCUL mit Firmware als IO auch mit Martins aktuellem Stand nutzbar sein, ggf. halt mit Nachteilen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: Bastel-Frank am 22 April 2019, 13:48:07
Hallo Ansgar,

ich habe seit kurzem ein Kommunikationsproblem mit dem HM-LC-SW4-DR (Hut-Schalter 4-Kanal). Bei meinem konkreten Problem mit 2 Stk (2E5085 und 2E51C8) dieser Spezies.

Ich habe folgendes schon probiert: CUL getauscht, CUL neu geflasht (Versionen 0.29 und 0.30), HM-LC-SW4-DR getauscht. Es hat alles nichts genutzt.

Zur Erinnerung: Meine Umgebung besteht aus einem lokalen CUL (=CUL_KG) und 5 weiteren CUL per ser2net angebunden und mit vccu zusammengefasst. Alle CUL's haben den Stand 0.29

Der CUL CUL_GH (GH=Gartenhaus) befindet sich direkt neben den HM-LC-SW4-DR. Die anderen sind weiter weg. Trotzdem suchen sich die HM-LC-SW4-DR den Weg zum CUL_AS (im Keller) ...sehr komisch.

Das Log meldet (verbose=5):
CUL_GH: dispatch A14DB845E3703D4000000808D400000000000090E02::-94.5:CUL_GH:
2019.04.22 13:07:28 3: LogHist CUL_AS:  160896 A F103 12787476 02 10 09 A001 738396 2E5085 00040000000000 _CCAdly:8
2019.04.22 13:07:28 3: LogHist CUL_AS:  161169 A F103 12787748 01 10 09 A001 738396 2E5085 00040000000000 _CCAdly:4
2019.04.22 13:07:28 3: LogHist CUL_AS:  161445 A F103 12788024 01 10 09 A001 738396 2E5085 00040000000000 _CCAdly:4
2019.04.22 13:07:28 3: LogHist CUL_AS:  161685 A F109 12788296 00 10 09 A001 738396 2E5085 00040000000000 _sfail _noAnsw
2019.04.22 13:07:28 3: LogHist CUL_AS:  165545                 As 10 09 A001 738396 2E5085 00040000000000
2019.04.22 13:07:28 3: LogHist CUL_AS:  165584 A F103 12792164 02 10 09 A001 738396 2E5085 00040000000000 _CCAdly:8
2019.04.22 13:07:28 3: LogHist CUL_AS:  165856 A F103 12792436 01 10 09 A001 738396 2E5085 00040000000000 _CCAdly:4
2019.04.22 13:07:28 3: LogHist CUL_AS:  166128 A F103 12792708 01 10 09 A001 738396 2E5085 00040000000000 _CCAdly:4
2019.04.22 13:07:28 3: LogHist CUL_AS:  166368 A F109 12792980 00 10 09 A001 738396 2E5085 00040000000000 _sfail _noAnsw
2019.04.22 13:07:28 3: LogHist CUL_AS:  176966                 As 10 0A A001 738396 2E5085 00040000000000
2019.04.22 13:07:28 3: LogHist CUL_AS:  176994 A F101 12803588 00 14 DB 845E 3703D4 000000 808D400000000000090E02 -82.5dB
2019.04.22 13:07:28 3: LogHist CUL_AS:  177016 A F103 12803592 03 10 0A A001 738396 2E5085 00040000000000 _CCAdly:12
2019.04.22 13:07:28 3: LogHist CUL_AS:  177284 A F103 12803864 01 10 0A A001 738396 2E5085 00040000000000 _CCAdly:4
2019.04.22 13:07:28 3: LogHist CUL_AS:  178459 A F103 12804136 01 10 0A A001 738396 2E5085 00040000000000 _CCAdly:4
2019.04.22 13:07:28 3: TSCUL_ParseTsHM: CUL_AS HM repeat failed to 2E5085/HM_2E5085:  178459 A F109 12804408 00 10 0A A001 738396 2E5085 00040000000000 _sfail _noAnsw
2019.04.22 13:07:28 5: TSCUL_Read CUL_GH: /AF00200F336100015AA001122AA001122AA001122AA001122AA001122AA80
2019.04.22 13:07:28 4: TSCUL_Parse: CUL_GH  178464 A F002 13424704 00 15 AA001122AA001122AA001122AA001122AA001122AA _ping
2019.04.22 13:07:33 3: LogHist CUL_AS:  165584 A F103 12792164 02 10 09 A001 738396 2E5085 00040000000000 _CCAdly:8
2019.04.22 13:07:33 3: LogHist CUL_AS:  165856 A F103 12792436 01 10 09 A001 738396 2E5085 00040000000000 _CCAdly:4
2019.04.22 13:07:33 3: LogHist CUL_AS:  166128 A F103 12792708 01 10 09 A001 738396 2E5085 00040000000000 _CCAdly:4
2019.04.22 13:07:33 3: LogHist CUL_AS:  166368 A F109 12792980 00 10 09 A001 738396 2E5085 00040000000000 _sfail _noAnsw
2019.04.22 13:07:33 3: LogHist CUL_AS:  176966                 As 10 0A A001 738396 2E5085 00040000000000
2019.04.22 13:07:33 3: LogHist CUL_AS:  176994 A F101 12803588 00 14 DB 845E 3703D4 000000 808D400000000000090E02 -82.5dB
2019.04.22 13:07:33 3: LogHist CUL_AS:  177016 A F103 12803592 03 10 0A A001 738396 2E5085 00040000000000 _CCAdly:12
2019.04.22 13:07:33 3: LogHist CUL_AS:  177284 A F103 12803864 01 10 0A A001 738396 2E5085 00040000000000 _CCAdly:4
2019.04.22 13:07:33 3: LogHist CUL_AS:  178459 A F103 12804136 01 10 0A A001 738396 2E5085 00040000000000 _CCAdly:4
2019.04.22 13:07:33 3: LogHist CUL_AS:  178459 A F109 12804408 00 10 0A A001 738396 2E5085 00040000000000 _sfail _noAnsw
2019.04.22 13:07:33 3: LogHist CUL_AS:  182654                 As 10 0A A001 738396 2E5085 00040000000000
2019.04.22 13:07:33 3: LogHist CUL_AS:  182693 A F103 12809272 01 10 0A A001 738396 2E5085 00040000000000 _CCAdly:4
2019.04.22 13:07:33 3: LogHist CUL_AS:  182968 A F103 12809548 01 10 0A A001 738396 2E5085 00040000000000 _CCAdly:4
2019.04.22 13:07:33 3: LogHist CUL_AS:  183244 A F103 12809824 01 10 0A A001 738396 2E5085 00040000000000 _CCAdly:4


Viele Grüße
Frank
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: noansi am 22 April 2019, 15:35:29
Hallo Frank,

und wie hast Du das Attribut IOgrp beim HM-LC-SW4-DR gesetzt?

Sinn würde es machen, den CUL_GH für die als präferiertes IO zu setzen.

Die HM-LC-SW4-DR senden von sich aus keinen Status (es sei denn Du drückst einen der Taster zum Schalten).
Dann fehlt der IO-Auswahl ein Empfangs-RSSI um damit ein günstiges IO wählen zu können.

In Deinem Log Auszug sehe ich keinen Empfang eines der beiden devices durch CUL_GH. So läßt sich nicht mehr dazu sagen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: Bastel-Frank am 23 April 2019, 17:53:20
Hallo Ansgar,

ich habe die beiden HM-LC-SW4-DR (2E5085 und 2E51C8) auf Werkszustand zurückgesetzt und versucht neu zu pairen. Anbei das Log dazu. Das Pairing wird bei Beiden nicht vollständig durchlaufen, u.a. PairedTo und IOgrp wird nicht gesetzt. Aus meiner Sicht sind die schlechten RSSI-Werte aufgefallen, obwohl sich der CUL nur 1m daneben befindet. Ich habe bei meinen vielen Versuchen auch schon IoErr im Log gefunden.

Ich hoffe, Du hast eine Idee.

Viele Grüße
Frank

Log:
2019.04.23 17:35:57 5: TSCUL_Read CUL_GH: /AF0010035CB3B000DC6804127128B2E51C907880080E5

2019.04.23 17:35:57 4: TSCUL_Parse: CUL_GH  451050 A F001 14101740 00 0D C6 8041 27128B 2E51C9 07880080 -87.5dB
2019.04.23 17:35:57 5: CUL_GH: dispatch A0DC6804127128B2E51C907880080::-87.5:CUL_GH:
2019.04.23 17:36:08 5: TSCUL_Read CUL_GH: /AF0010035D2F100147C845E3703D4000000808DEB00000000000903FEF3

2019.04.23 17:36:08 4: TSCUL_Parse: CUL_GH  462181 A F001 14109636 00 14 7C 845E 3703D4 000000 808DEB00000000000903FE -80.5dB
2019.04.23 17:36:08 5: CUL_GH: dispatch A147C845E3703D4000000808DEB00000000000903FE::-80.5:CUL_GH:
2019.04.23 17:36:13 5: TSCUL_Read CUL_GH: /AF0010035DAE0000CA3865A31D1A20000009CE328CD

2019.04.23 17:36:13 4: TSCUL_Parse: CUL_GH  467071 A F001 14117760 00 0C A3 865A 31D1A2 000000 9CE328 -99.5dB
2019.04.23 17:36:13 5: CUL_GH: dispatch A0CA3865A31D1A20000009CE328::-99.5:CUL_GH:
2019.04.23 17:36:13 5: TSCUL_Read CUL_GH: /AF0020035DB230001C380

2019.04.23 17:36:13 4: TSCUL_Parse: CUL_GH  467339 A F002 14118028 00 01 C3 _ping
2019.04.23 17:36:15 5: TSCUL_Read CUL_GH: /AF0010035DCC9000EE484103032660000000BB8EC0B40D6

2019.04.23 17:36:15 4: TSCUL_Parse: CUL_GH  469026 A F001 14119716 00 0E E4 8410 303266 000000 0BB8EC0B40 -95dB
2019.04.23 17:36:15 5: CUL_GH: dispatch A0EE484103032660000000BB8EC0B40::-95:CUL_GH:
2019.04.23 17:36:16 5: TSCUL_Read CUL_GH: /AF0010035DD7B000C7AA6412ED0ED7383960141C8F0

2019.04.23 17:36:16 4: TSCUL_Parse: CUL_GH  469742 A F001 14120428 00 0C 7A A641 2ED0ED 738396 0141C8 -82dB
2019.04.23 17:36:16 5: CUL_GH: dispatch A0C7AA6412ED0ED7383960141C8::-82:CUL_GH:
2019.04.23 17:36:16 5: TSCUL_Read CUL_GH: /AF0010035DD99000A7A80027383962ED0ED00E6

2019.04.23 17:36:16 4: TSCUL_Parse: CUL_GH  469859 A F001 14120548 00 0A 7A 8002 738396 2ED0ED 00 -87dB
2019.04.23 17:36:16 5: CUL_GH: dispatch A0A7A80027383962ED0ED00::-87:CUL_GH:
2019.04.23 17:36:16 5: TSCUL_Read CUL_GH: /AF0010035DDB4000D7A80027383962ED0ED0101C800E6

2019.04.23 17:36:16 4: TSCUL_Parse: CUL_GH  469965 A F001 14120656 00 0D 7A 8002 738396 2ED0ED 0101C800 -87dB
2019.04.23 17:36:16 5: CUL_GH: dispatch A0D7A80027383962ED0ED0101C800::-87:CUL_GH:
2019.04.23 17:36:18 5: TSCUL_Read CUL_GH: /AF0010035DFEB000D06A6104DF39673839606010000EF

2019.04.23 17:36:18 4: TSCUL_Parse: CUL_GH  472233 A F001 14122924 00 0D 06 A610 4DF396 738396 06010000 -82.5dB
2019.04.23 17:36:18 5: CUL_GH: dispatch A0D06A6104DF39673839606010000::-82.5:CUL_GH:
2019.04.23 17:36:19 5: TSCUL_Read CUL_GH: /AF0010035E02F000D07A6104DF39673839606010000ED

2019.04.23 17:36:19 4: TSCUL_Parse: CUL_GH  472506 A F001 14123196 00 0D 07 A610 4DF396 738396 06010000 -83.5dB
2019.04.23 17:36:19 5: CUL_GH: dispatch A0D07A6104DF39673839606010000::-83.5:CUL_GH:
2019.04.23 17:36:19 5: TSCUL_Read CUL_GH: /AF0010035E06B000C7BA6412ED0ED738396014200F9

2019.04.23 17:36:19 4: TSCUL_Parse: CUL_GH  472747 A F001 14123436 00 0C 7B A641 2ED0ED 738396 014200 -77.5dB
2019.04.23 17:36:19 5: CUL_GH: dispatch A0C7BA6412ED0ED738396014200::-77.5:CUL_GH:
2019.04.23 17:36:19 5: TSCUL_Read CUL_GH: /AF0010035E089000A7B80027383962ED0ED00DA

2019.04.23 17:36:19 4: TSCUL_Parse: CUL_GH  472864 A F001 14123556 00 0A 7B 8002 738396 2ED0ED 00 -93dB
2019.04.23 17:36:19 5: CUL_GH: dispatch A0A7B80027383962ED0ED00::-93:CUL_GH:
2019.04.23 17:36:19 5: TSCUL_Read CUL_GH: /AF0010035E0A3000D7B80027383962ED0ED0101C800DD

2019.04.23 17:36:19 4: TSCUL_Parse: CUL_GH  472971 A F001 14123660 00 0D 7B 8002 738396 2ED0ED 0101C800 -91.5dB
2019.04.23 17:36:19 5: CUL_GH: dispatch A0D7B80027383962ED0ED0101C800::-91.5:CUL_GH:
2019.04.23 17:36:19 5: TSCUL_Read CUL_GH: /AF0010035E0B6000D08A6104DF39673839606010000F0

2019.04.23 17:36:19 4: TSCUL_Parse: CUL_GH  473047 A F001 14123736 00 0D 08 A610 4DF396 738396 06010000 -82dB
2019.04.23 17:36:19 5: CUL_GH: dispatch A0D08A6104DF39673839606010000::-82:CUL_GH:
2019.04.23 17:36:20 5: TSCUL_Read CUL_GH: /AF0010035E17E000D09A6104DF39673839606010080ED

2019.04.23 17:36:20 4: TSCUL_Parse: CUL_GH  473847 A F001 14124536 00 0D 09 A610 4DF396 738396 06010080 -83.5dB
2019.04.23 17:36:20 5: CUL_GH: dispatch A0D09A6104DF39673839606010080::-83.5:CUL_GH:
2019.04.23 17:36:21 5: TSCUL_Read CUL_GH: /AF0010035E29B000D0AA6104DF39673839606010000ED

2019.04.23 17:36:21 4: TSCUL_Parse: CUL_GH  474985 A F001 14125676 00 0D 0A A610 4DF396 738396 06010000 -83.5dB
2019.04.23 17:36:21 5: CUL_GH: dispatch A0D0AA6104DF39673839606010000::-83.5:CUL_GH:
2019.04.23 17:36:22 5: TSCUL_Read CUL_GH: /AF0010035E3F3000D0BA6104DF39673839606010000EB

2019.04.23 17:36:22 4: TSCUL_Parse: CUL_GH  476364 A F001 14127052 00 0D 0B A610 4DF396 738396 06010000 -84.5dB
2019.04.23 17:36:22 5: CUL_GH: dispatch A0D0BA6104DF39673839606010000::-84.5:CUL_GH:
2019.04.23 17:36:25 5: TSCUL_Read CUL_GH: /AF0010035E68C000C4A847030326600000000EC2AD3

2019.04.23 17:36:25 4: TSCUL_Parse: CUL_GH  479024 A F001 14129712 00 0C 4A 8470 303266 000000 00EC2A -96.5dB
2019.04.23 17:36:25 5: CUL_GH: dispatch A0C4A847030326600000000EC2A::-96.5:CUL_GH:
2019.04.23 17:36:33 5: TSCUL_Read CUL_GH: /AF0010035EE68000CA3847031D1A200000000E328C7

2019.04.23 17:36:33 4: TSCUL_Parse: CUL_GH  487072 A F001 14137760 00 0C A3 8470 31D1A2 000000 00E328 -102.5dB
2019.04.23 17:36:33 5: CUL_GH: dispatch A0CA3847031D1A200000000E328::-102.5:CUL_GH:
2019.04.23 17:36:51 5: TSCUL_Read CUL_GH: /AF0010035FFF60013CB8670002C1A00000000DA2D0033C0004346AD05

2019.04.23 17:36:51 4: TSCUL_Parse: CUL_GH  505046 A F001 14155736 00 13 CB 8670 002C1A 000000 00DA2D0033C0004346AD -71.5dB
2019.04.23 17:36:51 5: CUL_GH: dispatch A13CB8670002C1A00000000DA2D0033C0004346AD::-71.5:CUL_GH:
2019.04.23 17:36:55 5: TSCUL_Read CUL_GH: /AF001003603F6001A0484002E50850000002400614C4551303839393535381004010041

2019.04.23 17:36:55 4: TSCUL_Parse: CUL_GH  509142 A F001 14159832 00 1A 04 8400 2E5085 000000 2400614C45513038393935353810040100 -41.5dB
2019.04.23 17:36:55 5: CUL_GH: dispatch A1A0484002E50850000002400614C45513038393935353810040100::-41.5:CUL_GH:
2019.04.23 17:36:55 2: CUL_HM Unknown device HM_2E5085 is now defined

2019.04.23 17:36:55 2: autocreate: define HM_2E5085 CUL_HM 2E5085
2019.04.23 17:37:00 5: TSCUL_Read CUL_GH: /AI2E50853F00

2019.04.23 17:37:00 4: TSCUL_Parse: CUL_GH AI2E50853F00
2019.04.23 17:37:23 5: TSCUL_Read CUL_GH: /AF00100361EED001A0484002E51C80000002400614C4551303839393230361004010030

2019.04.23 17:37:23 4: TSCUL_Parse: CUL_GH  012464 A F001 14187444 00 1A 04 8400 2E51C8 000000 2400614C45513038393932303610040100 -50dB
2019.04.23 17:37:23 5: CUL_GH: dispatch A1A0484002E51C80000002400614C45513038393932303610040100::-50:CUL_GH:

2019.04.23 17:37:23 2: CUL_HM Unknown device HM_2E51C8 is now defined
2019.04.23 17:37:23 2: autocreate: define HM_2E51C8 CUL_HM 2E51C8
2019.04.23 17:37:28 5: TSCUL_Read CUL_GH: /AI2E51C83F00

2019.04.23 17:37:28 4: TSCUL_Parse: CUL_GH AI2E51C83F00
2019.04.23 17:37:45 5: TSCUL_Read CUL_GH: /AF00100363326000C7CA6412ED0ED7383960143C8EB
AF00100363344000A7C80027383962ED0ED00D0

2019.04.23 17:37:45 4: TSCUL_Parse: CUL_GH  034254 A F001 14208152 00 0C 7C A641 2ED0ED 738396 0143C8 -84.5dB
2019.04.23 17:37:45 4: TSCUL_Parse: CUL_GH  034254 A F001 14208272 00 0A 7C 8002 738396 2ED0ED 00 -98dB

2019.04.23 17:37:45 5: CUL_GH: dispatch A0C7CA6412ED0ED7383960143C8::-84.5:CUL_GH:
2019.04.23 17:37:45 5: CUL_GH: dispatch A0A7C80027383962ED0ED00::-98:CUL_GH:
2019.04.23 17:37:47 5: TSCUL_Read CUL_GH: /AF00100363447000D7C80027383962ED0ED0101C800D7

2019.04.23 17:37:47 4: TSCUL_Parse: CUL_GH  036270 A F001 14209308 00 0D 7C 8002 738396 2ED0ED 0101C800 -94.5dB
2019.04.23 17:37:47 5: CUL_GH: dispatch A0D7C80027383962ED0ED0101C800::-94.5:CUL_GH:
2019.04.23 17:37:50 5: TSCUL_Read CUL_GH: /AF00100363995000C7DA6412ED0ED738396014400FF

2019.04.23 17:37:50 4: TSCUL_Parse: CUL_GH  039760 A F001 14214740 00 0C 7D A641 2ED0ED 738396 014400 -74.5dB
2019.04.23 17:37:50 5: CUL_GH: dispatch A0C7DA6412ED0ED738396014400::-74.5:CUL_GH:
2019.04.23 17:37:50 5: TSCUL_Read CUL_GH: /AF001003639B3000A7D80027383962ED0ED00D1

2019.04.23 17:37:50 4: TSCUL_Parse: CUL_GH  039878 A F001 14214860 00 0A 7D 8002 738396 2ED0ED 00 -97.5dB
2019.04.23 17:37:50 5: CUL_GH: dispatch A0A7D80027383962ED0ED00::-97.5:CUL_GH:
2019.04.23 17:37:50 5: TSCUL_Read CUL_GH: /AF001003639CD000D7D80027383962ED0ED0101C800D0

2019.04.23 17:37:50 4: TSCUL_Parse: CUL_GH  039985 A F001 14214964 00 0D 7D 8002 738396 2ED0ED 0101C800 -98dB
2019.04.23 17:37:50 5: CUL_GH: dispatch A0D7D80027383962ED0ED0101C800::-98:CUL_GH:
2019.04.23 17:37:52 5: TSCUL_Read CUL_GH: /AF00100363B51000C83865A31CF9D000000A4F925F3

2019.04.23 17:37:52 4: TSCUL_Parse: CUL_GH  041537 A F001 14216516 00 0C 83 865A 31CF9D 000000 A4F925 -80.5dB
2019.04.23 17:37:52 5: CUL_GH: dispatch A0C83865A31CF9D000000A4F925::-80.5:CUL_GH:
2019.04.23 17:37:57 5: TSCUL_Read CUL_GH: /AF00100364032000C2D865A31D0AD000000BCE828CB

2019.04.23 17:37:57 4: TSCUL_Parse: CUL_GH  046531 A F001 14221512 00 0C 2D 865A 31D0AD 000000 BCE828 -100.5dB
2019.04.23 17:37:57 5: CUL_GH: dispatch A0C2D865A31D0AD000000BCE828::-100.5:CUL_GH:
2019.04.23 17:38:14 5: TSCUL_Read CUL_GH: /AF00100364EDA000C83847031CF9D00000000F925FB

2019.04.23 17:38:14 4: TSCUL_Parse: CUL_GH  063158 A F001 14236520 00 0C 83 8470 31CF9D 000000 00F925 -76.5dB
2019.04.23 17:38:14 5: CUL_GH: dispatch A0C83847031CF9D00000000F925::-76.5:CUL_GH:
2019.04.23 17:38:16 5: TSCUL_Read CUL_GH: /AF001003652A0000C5B865A27128B000000B0E62CE8

2019.04.23 17:38:16 4: TSCUL_Parse: CUL_GH  065404 A F001 14240384 00 0C 5B 865A 27128B 000000 B0E62C -86dB
2019.04.23 17:38:16 5: CUL_GH: dispatch A0C5B865A27128B000000B0E62C::-86:CUL_GH:
2019.04.23 17:38:17 5: TSCUL_Read CUL_GH: /AF001003653BA000C2D847031D0AD00000000E828CB

2019.04.23 17:38:17 4: TSCUL_Parse: CUL_GH  066575 A F001 14241512 00 0C 2D 8470 31D0AD 000000 00E828 -100.5dB
2019.04.23 17:38:17 5: CUL_GH: dispatch A0C2D847031D0AD00000000E828::-100.5:CUL_GH:
2019.04.23 17:38:18 5: TSCUL_Read CUL_GH: /AF0010036545D000C7EA6412ED0ED7383960145C8F3

2019.04.23 17:38:18 4: TSCUL_Parse: CUL_GH  067182 A F001 14242164 00 0C 7E A641 2ED0ED 738396 0145C8 -80.5dB
2019.04.23 17:38:18 5: CUL_GH: dispatch A0C7EA6412ED0ED7383960145C8::-80.5:CUL_GH:
2019.04.23 17:38:18 3: CUL_HM set EG.wz.mr.RO inhibit on
2019.04.23 17:38:18 5: TSCUL_Read CUL_GH: /AF0010036547B000A7E80027383962ED0ED00E7

2019.04.23 17:38:18 4: TSCUL_Parse: CUL_GH  067302 A F001 14242284 00 0A 7E 8002 738396 2ED0ED 00 -86.5dB
2019.04.23 17:38:18 5: CUL_GH: dispatch A0A7E80027383962ED0ED00::-86.5:CUL_GH:
2019.04.23 17:38:18 5: TSCUL_Read CUL_GH: /AF00100365495000D7E80027383962ED0ED0101C800E6

2019.04.23 17:38:18 4: TSCUL_Parse: CUL_GH  067408 A F001 14242388 00 0D 7E 8002 738396 2ED0ED 0101C800 -87dB
2019.04.23 17:38:18 5: CUL_GH: dispatch A0D7E80027383962ED0ED0101C800::-87:CUL_GH:
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: noansi am 23 April 2019, 20:32:37
Hallo Frank,

ich sehe, es wird jeweils ein neues device angelegt, aber dann passiert nichts mehr.

Hast Du bei der VCCU vorher auch jeweils hmPairForSec gesetzt? Oder nutzt Du 10_CUL_HM und HMConfig aus dem aktuellen Update, statt meiner letzten Version?

Der RSSI ist nicht so doll, aber auch nicht so grottig, dass nichts gehen müßte. Eventuell hilft es noch mit dem hmFreqOffs bei dem CUL zu spielen, aber das ist nicht das erste Problem.

Gruß,

Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: Bastel-Frank am 26 April 2019, 14:55:19
Hallo Ansgar,

Zitat von: noansi am 23 April 2019, 20:32:37
Hast Du bei der VCCU vorher auch jeweils hmPairForSec gesetzt? Oder nutzt Du 10_CUL_HM und HMConfig aus dem aktuellen Update, statt meiner letzten Version?

hmPairForSec habe ich vor dem Lernen gesetzt  :). Ich nutzt die Module aus der V29. Die CULs sind auch alle V29. V30 habe ich auch probiert. Das Verhalten ist gleich und brachte keine Besserung.

Jetzt ist mir aufgefallen, dass in den CUL, die per ser2net angebunden bei "cond" = "non-HM" steht. Hat dies was zu besagen? In der vccu sind diese CULs auch als "non-HM" in "state" aufgeführt.

Wenn ich meinen HUT-Schalter am stationären CUL anlerne, geht es. An den ser2net-CULs geht es nicht ...

Ich hoffe, auf deine Eingebungen  :P

Viele Grüße
Frank
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: noansi am 26 April 2019, 20:50:47
Hallo Frank,

dann erhell bitte die Eingebung mit lists von VCCU und allen CULs.

In der VCCU sollten die CULs mit Namen:ok stehen. Eventuell noch Warning-HighLoad oder ERROR-Overload, wenn die credits zur Neige gehen.
Eventuell ist Dein "rfmode = Homematic" Problem noch nicht wirklich gelöst.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: Bastel-Frank am 28 April 2019, 12:38:34
Hallo Ansgar,

die Lists konnte ich leider nicht mehr liefern, da ich in der Zwischenzeit die CUL neu in fhem angelegt habe und dann temporär alles wieder in Ordnung schien. Der rfMode wurde/wird mit Homematic wieder richtig gesetzt und auch der vccu-state der einzelnen CULs war wieder ok.

Nach einer kurzen Zeit ging dann bei den besagten Devices wieder nichts mehr. Ich habe mir dann nochmal die defines der CULs bei ser2net angesehen. Dort war als fhtid (=Hauscode, aber eigentlich ist dies die HmId) immer 0000 angegeben. Ich habe aber "damals" als ich mit den ser2net-CULs anfing gelesen, dass diese fhtid immer unterschiedlich bei jedem CUL sein muss. Bei den Konfigurationen anderer fhem-Nutzer habe ich nun aber gesehen, dass dort immer eine 0000 angegeben war. Ich habe dies daher jetzt auch bei mir umsetzt und es geht wieder alles.

Ob es am Ende wirklich daran gelegen hat, muss die Zukunft zeigt. Es dürfen Daumen gedrückt werden.

Viele Grüße
Frank
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: noansi am 28 April 2019, 14:52:17
Hallo Frank,

ZitatOb es am Ende wirklich daran gelegen hat, muss die Zukunft zeigt.
Vom Code her kann ich es derzeit nicht nachvollziehen.

ZitatDort war als fhtid (=Hauscode, aber eigentlich ist dies die HmId)
Das ist so nicht richtig.

In Single-CUL HM Konfiguration ist es ein historisch implementiertes Feature, dass "F1<housecode>" als hmId genutzt wird, sofern das Atribut hmId nicht gesetzt wird. Vermutlich um die Konfigurationsstartschwierigkeiten für Neuuser zu verringern.

In Multi-CUL VCCU HM Konfiguration geht das nicht, weil der housecode bei FHT in den ersten beiden Ziffern einzigartig für alle CULs sein muss und sich dann bei der CUL Definition entsprechende Fehlermeldungen und Probleme zeigen.
Da FHT zusammen mit  HM gar keinen Sinn macht, macht auch nur 0000 (schaltet FHT ab) wirklich Sinn für die FHTID (=housecode) bei den CULs.

Allerdings überschreibt die VCCU die hmId, die sich aus dem "default" aus "F1<housecode>" ergeben würde, durch setzen des Attributs hmId bei ihren IOs. Von daher sollte es eigentlich auch mit unterschiedlich gesetzten FHTIDs bei den CULs funktionieren.

Die VCCU Definition gehört hinter die CUL Definitionen in der config. Das könnte eventuell noch schief laufen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: Bastel-Frank am 29 April 2019, 07:45:20
Zitat von: noansi am 28 April 2019, 14:52:17
Die VCCU Definition gehört hinter die CUL Definitionen in der config. Das könnte eventuell noch schief laufen.

Das wäre ein Ansatz, da ich historisch zunächst einen stationären CUL angelegt habe, anschließend zur vccu gewechselt bin und jetzt nach und nach zusätzliche CULs hinzufüge.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: MarkusWEN am 01 Juni 2019, 18:16:35
Irgendwie bin ich gerade blind - wo kann ich bitte die tsculfw herunterladen?
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: noansi am 01 Juni 2019, 18:35:20
Hallo Markus,

im ersten Beitrag dieses Threads ist der link zum passenden Beitrag zu finden.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.30
Beitrag von: MarkusWEN am 01 Juni 2019, 18:40:21
Vielen Dank. Hatte den Link zur Datei nicht gesehen
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.31
Beitrag von: noansi am 02 Juni 2019, 17:29:51
Hallo Testwillige,

hier eine neue Version 0.31 der Timestamp Firmware und der dazu benötigten FHEM Module.

Diese Version bietet einige Verbesserungen insbesondere für CUNX und CUNO2.

TSCUNX kann mit entsprechendem RS485 Modul nun auch DMX.
Auch HM485 ist für TXCUNX angepasst.
In dem Zuge ist auch die DMX Funktionalität bei CUNO2 etwas erweitert.
IR läuft nun auch richtig mit TSCONO2.
Außerdem läuft RF-Router auf der tsculfw, allerdings mit einer Änderung. Das 'U' ist durch '~' ersetzt. 'U' kollidierte mit dem Uniroll Senden.

Kurzer Auszug aus der CHANGED:
- IO optimizations CUNX, especially to/from PIM and Ethernet
- CUNX DHCP non blocking operation
- IO optimizations
- HM485 support for CUNX (like CUNO2) with RS485 PIM.
  HM485 switch off with Hx for CUNX. With CUNX after Hx RS485 PIM again accessible via PIM USB or Ethernet Interface
- CUNX support for DMX and HM485 with RS485 PIM (to be tested), a Dwxxxxyy switches to DMX via CUNX Interface, a Hsxxxxxxxxxxxxxxxxxx switches to HM485 via CUNX Interface
- DMX switch off with Dx. With CUNX after Dx RS485 PIM is again accessible via PIM USB- or Ethernet Interface
  DMX flexible channel usage. Channels are sent out upto the highest channel set (0 sent as default for unset channels). With switching off with Dx the highest channel is reset.
  DMX changed in timing and resting behaviour. Rests on IDLE if less then 24 device, only, to keep 1204µs min. BREAK to BREAK (to be tested)
  DMX Dt command to set/view timing of MarkAfterBreak and BREAK
  DMX less disturbed while sending SlowRF
- W function gives feedback after writing EEPROM
- clock timer unburdened, may impact onewire and fht (to be tested)
- corrections for IRTX
- IR base timings changed to 12500Hz or 20000Hz
- RF-Router working, but 'U' changed to '~' (definable in board.h, but 'U' disables HAS_UNIROLL)

Es ist eine Prüfung auf Stacküberlauf eingebaut. Am Anfang des heap werden zwei Byte mit einem Bitmuster beschrieben. Wird das verändert, dann ist der Speicher wahrscheinlich korrumpiert, was durch einen Stacküberlauf ausgelöst sein sollte. Sofern der CUL dann noch kann sendet er ein "C_M" an TSCUL, was zu einem entsprechenden Log Eintrag führt.
Damit kann man vorsichtig die Speichergrenzen ausloten. Ein langer Testzeitraum ist aber erforderlich, um einigermaßen sicher zu sein, dass der worst case auch mal durchlaufen worden ist.
Außerdem ist ein Kommando mU (je nach Firmware) eingebaut, mit dem man den vom Stack ungenutzen heap in etwa auslesen kann (auch als get unusedstack in TSCUL verfügbar). Auch hier gilt, nur nach langer Laufzeit einigermaßen sinnvoll. Es macht sicher keinen Sinn auf Grund des Wertes den Speicher bis auf das letzte Byte auszuquetschen, denn weiterhin hängt die Stacknutzung vom gewählten Protokoll und Einstellungen ab.

In TSCULflash ist Flashen auch von NanoCULs und MiniCULs ergänzt. Vor dem Flashen wird ein "B00" also Reset für die TSCUL Firmware an den nano/Mini geschickt, 1 Sekunde gewartet und dann versucht mit avrdude zu flashen.
Also erst die Firmware in den FHEM/Firmware Ordner kopieren und dann in FHEM mit
TSCULflash <nanodevicename> TSnanoCUL
bzw.
TSCULflash <minidevicename> TSminiCUL
versuchen zu Flashen. Im Log sollte danach (dauert etwas) die avrdude Ausgabe zu finden sein.

Ebenfalls möglich ist das Flashen eines PIGATOR Moduls an einem CUNX
TSCULflash <pigatordevicename>|<cunxdevicename> TSPIGATOR

AESCommReq wird unterstützt. Die Nutzung ist unverändert zu Standard CUL, sprich, beim gewünschten Gerät/Kanal aesCommReq auf 1 setzen und ggf. noch aesKey passend zum verteilten Key setzen.
Es werden von tsculfw nur die Keys 0 (Default Key) bis 3 unterstützt.

Diese Erweiterung erfordert jedoch auch zusätzliche Empfangspuffer im knappen Speicher des CULs. Ein CUL V3 nutzt bis zu 6 Empfangspuffer. Auch der FlashSpeicherbdarf ist angestiegen, so dass einige Protokolle nicht mehr gleichzeitig in ein Kompilat passen. Das sollte aber weniger tragisch sein, da im ASKSIN Modus ohnehin nur HM empfangen werden kann.

Bei CUL V2 reicht der verfügbare Speicher leider hinten und vorne nicht aus, um diese Version nutzen zu können.

Im Anhang ist in TSCUL_fwcode_00_31_FHEM_Modules_00_42.zip wieder die Timestamp Firmware zu finden. Getestet habe ich TSCUNX, TSPIGATOR , TSCUL_V3, TSCUNO2, TSCOC und TSSCC.

Die tsculfw Firmware kann für TSCUL_V3, TSCUNO2, TSCOC, TSSCC, TSCUNX und TSPIGATOR (an CUNX) mit FHEM mit dem TSCULflash geflashed werden. Die anderen müssen mit dem jeweiligen Flash Programmer geflashed werden. Bei CUNO2 und SCC muss die Bootloadertaste gedrückt werden, bis der Flashvorgang anläuft.
So z.B. https://forum.fhem.de/index.php/topic,24436.msg631743.html#msg631743 kann es mit einem USB CUL Stick gehen, wenn man nicht TSCULflash verwendet.
TSCULflash ist erweitert auf COC, SCC, CCD, rpiaddon, CUNO2 und CUNO. Jedoch ist es nicht ganz so einfach zu handhaben, da zum einen teilweise die Taste zu drücken ist und bei Raspberry PI Modulen die Rechteproblematik für den Zugriff auf die IO-Pins überwunden werden muss. Tips dazu in der Command-Ref auch bei RPI_GPIO.
Bei einem Stapel aus SCC mit aufgesetztem COC, CCD oder (rpiaddon?) ist unbedingt beim SCC Flash darauf zu achten, die Taste am gewünschten Modul zu drücken. Sonst wird das oberste Nicht-SCC Modul mit der SCC Firmware geflashed.
Mit CUNO2 ist das flashen noch nicht getestet (generell nur über USB!). Wichtig, aber auch hier, die Taste zu drücken.

Es gibt nicht den Luxus des Downloads beim TSCULflash, sondern die Firmware muss händisch in den FHEM/firmware Ordner kopiert werden. Der Typ ist dann TSCUL_V3.
Beispiel:
TSCULflash MeinCulDevice TSCUL_V3

Wichtig für SCC Nutzer. TSSTACKED ist entfallen und wird nicht mehr unterstützt.
Statt dessen gibt es das neue Modul STACKABLETS (als Abwandlung von Rudolfs STACKABLE).
Dieses wird sozusagen zwischen die Stackteilnehmer eingebaut.

Beispiel für fhem.cfg:
#erstes SCC Modul als Basis
define SCC_WS868 TSCUL /dev/ttyAMA0@38400 0000
attr SCC_WS868 event-on-change-reading Ints_per_sec,IntCalcStat,MatchStat
attr SCC_WS868 rfmode SlowRF
attr SCC_WS868 room Receiver
attr SCC_WS868 sendpool CUL_HM868,SCC_WS868
attr SCC_WS868 verbose 1

#neues STACKABLETS virtuelles IO device
define STACK_1 STACKABLETS SCC_WS868
attr STACK_1 verbose 1

#zweites SCC Modul
define SCC_HM868 TSCUL FHEM:DEVIO:STACK_1:38400 1034
attr SCC_HM868 event-on-change-reading cond
attr SCC_HM868 hmId F11034


Ergänzender Hinweis zu USB CULs: 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_08\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 1234
bzw.
define CUL_433 TSCUL /dev/CUL433_0@12000000 0000
definiert werden und es gibt keine Probleme mit wechselnder Schnittstelle mehr.
Die Seriennummer kann beim Compilieren der Firmware in der board.h festgelegt werden, so dass damit dann auch /dev/CUL868_1 etc. für mehrere gleiche CULs möglich sind.

Oder für CUNX
define CUNX_868 TSCUL /dev/CUNX868_0@12000000 0000
oder für PIGATOR an CUNX
define PIGATOR_433 TSCUL /dev/CUNXPIM_0@38400 0000
die Seriennummer wird aus der Seriennummer des XMEGA Chips des CUNX gebildet. Unter Linux lsusb nutzen!

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.

Bei nicht nativen USB CULs wie z.B. nanoCUL, miniCUL oder CUNO2, beträgt die Baudrate 38400, dementsprechend muss die Definition beispielsweise so aussehen:
define CUL_868 TSCUL /dev/CUL868@38400 1234
bzw.
define CUL_433 TSCUL /dev/CUL433@38400 0000

Und noch ein Beispiel für eine Definition eines Netzwerk CUNX:
define CUL_868 TSCUL 192.168.178.111:2323 0000
oder für PIGATOR an CUNX
define PIGATOR_433 TSCUL 192.168.178.111:2324 0000
beim PIGATOR sollten zuvor mit Anschluss an USB und öffnen der Schnittstelle mit gewünschten Kommunikationsparametern mit ps oder unter TSCUL mit set PIMstoreBaud die seriellen Kommunikationsparameter zum PIGATOR Modul gespeichert werden, falls sie vom default abweichen.

Oder Netzwerk CUNO2:
define CUNO2_868 TSCUL 192.168.178.110:2323 0000

Die aktuell eingestellte oder per DHCP erhaltene Netzwerkadresse kann mit Lc repektive in TSCUL mit get NetAdresses abgefragt werden. Mit Lp repektive in TSCUL mit get NetPHYlink kann der Linkzustand des Netzwerkanschlusses angezeigt werden.


In der Zip Datei sind ebenfalls die ergänzten Module zu finden, die zur Nutzung der Firmware erforderlich sind.

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
16_TSCUL_RFR.pm -> der 16_CUL_RFR.pm, aus CUL_RFR devices werden damit TSCUL_RFR devices in der fhem.cfg (händisch anzupassen)
16_STACKABLETS.pm -> statt der 16_STACKABLE.pm, aus STACKABLE werden damit STACKABLETS devices in der fhem.cfg (händisch anzupassen)

10_UNIRoll_TS.pm  -> statt der 10_UNIRoll.pm, mit TSCUL 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 IO-devices zu verwenden, aus TSKS300 wird dann TSKS300  in der fhem.cfg (händisch anzupassen). Obsolet, da 14_TSCUL_WS.pm nun KS300 unterstützt.
14_TSCUL_TX.pm    -> statt der 14_CUL_TX.pm, mit TSCUL 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 IO-devices zu verwenden, aus CUL_WS wird dann TSCUL_WS  in der fhem.cfg (händisch anzupassen)
15_TSCUL_EM.pm   -> statt der 15_CUL_EM.pm, mit TSCUL IO-devices zu verwenden, aus CUL_EM wird dann TSCUL_EM  in der fhem.cfg (händisch anzupassen)
CalcUtil.pm               -> Hilfsrechenroutinen für Taupunkt und Windstärkeindex
ReadingUtil.pm          -> Hilfsroutinen für Readings

Da diese Module ergänzt werden (müssen!), überleben sie auch ein Update von FHEM.

10_IT.pm                   -> vermeidet unnötiges busy waiting beim Senden. Wird ohne Schutz von FHEM update überschrieben

Außerdem:

98_TSCULflash.pm     -> Zum Flash von TSCUL_V3, TSPIGATOR (an CUNX) mit Datei in FHEM/firmware

10_CUL_HM.pm         -> angepasste Version zur Nutzung mit TSCUL/tsculfw. Die Nutzung dieses Moduls ist optional. Für CUL_V3, nanoCUL, miniCUL im Multio-HM-IO Betrieb jedoch empfohlen, da sie den EEPROM Verschleiss über das Attribut "rssiSwitchHyst" verringert.
HMConfig.pm             -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden. Einstelllimits für HM-CC-RT-DN Regler P und I Anteil erweitert. Damit kann man mit R-regAdaptive offDeter deutlich mehr an den Regelparametern spielen.
98_HMinfo.pm           -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden. Spaltenbreiten in Tabelle von protoEvents variabel zu verbesserten Übersicht in der Darstellung.
Die 3 Dateien entsprechen einem Stand von Mitte 12/2019. Seither gab es viele Änderungen, so dass entweder diese 3 verwendet werden müssen oder die 3 aus aktuellem Update (meinerseits nicht getestet und der EEPROM-Verschleißhinweis unten ist zu beachten).

10_CULG.pm              -> optional, enthalten, da die Firmware es unterstützt

97_timerTS.pm           -> optional, Austausch-Timerroutinen. Wenn es nicht genutzt werden soll, dann löschen oder umbennen.
98_apptime.pm          -> apptime zur zwingenden Nutzung mit 97_timerTS.pm.
98_apptm.pm            -> apptime zur zwingenden Nutzung mit 97_timerTS.pm, mit geringerem Speicherverbrauch bei weniger Details

98_autocreate.pm       -> autocreate mit TSCUL Unterstützung

98_Cumulate               -> Kumulieren von Zählwerten, wie Strom, Regenmenge etc.
98_SAverage.pm         -> Mittelwertbildung von z.B. Temperaturen. Stunde, Tag, Monat und Jahr, sowie ein gleitender Mittelwert der letzten Stunde sind damit möglich.


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_STACKABLETS.pm DevIoTS.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.pm CalcUtil.pm 97_timerTS.pm 98_TSCULflash.pm 97_timerTS.pm 98_apptime.pm 98_apptm.pm 10_IT.pm 10_CULG.pm 10_CUL_HM.pm HMConfig.pm 98_HMinfo.pm ReadingUtil.pm 98_autocreate.pm 98_Cumulate.pm 98_SAverage.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` }

Noch ein Hinweis: TSCUL fragt auch die Firmwareversion der tsculfw auf 0.31 ab. Eine ältere Version wird also nicht unterstützt, da das Timestamp Protokoll (inkompatibel zu vorherigen Ständen) geändert hat, so dass mit dem Austausch der FHEM Module auch ein Firmwareupdate des CUL devices erforderlich ist!

Frequenzoffset: Für HM ist ein Frequenzoffset von -20.6kHz im EEPROM als default in der tsculfw hinterlegt (das ist ein individuelles Optimum für meinen COC). Dieser Frequenzoffset kann mit set hmFreqOffs umgestellt werden. 0 ist default in der Standard-culfw.
Wenn also keine Antwort von angesprochenen HM devices kommt, dann hmFreqOffs von 0 ausgehend verstellen. CUNX z.B. geht eher in Richtung + mit dem Offset.
Wer das Frequenzspektrum sichtbar machen kann, kann sich die optimale Mitte aller devices ermitteln und mit dem Offset sein CUL dazu passend einstellen.

Noch ein Tip zur Haltbarkeit der CULs mit wenig SRAM (CUL V3, nanoCUL, miniCUL ...). Jedesmal, wenn einem HM-Device das IODev durch Roaming neu zugeordnet wird, führt das zu EEPROM Schreibvorgängen in den beteiligten CULs. Die Lebensdauer des EEPROMs ist begrenzt (100000 Schreibzyklen laut Datenblatt). Daher rate ich zur Nutzung des VorzugsIOs beim Device Attribut IOgrp. Also nicht einfach stumpf
attr HMdeviceName IOgrp VCCU
setzen, sondern
attr HMdeviceName IOgrp VCCU:CUL_mit_gutem_Empfang_fuer_Device
sofern die Roaming Funktionalität entsprechend RSSI für das jeweilige device nicht zwingend benötigt wird. Ein Fallback auf einen anderen CUL bleibt dennoch möglich.
Mit dem Attribut "rssiSwitchHyst", das in der beigefügten 10_CUL_HM.pm verfügbar ist, kann bei den HM-devices die Umschalthysterese für das Roaming von 10 bis auf 2 bei Bedarf für mobile devices verringert werden.

Ergänzt ist auch noch ein set TX3Send.
Damit lassen sich TX3 Sensordatentelegramme auf 433er CULs versenden.
Beispiel:

define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 TX3Send T:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." SID:23 U")}

define NF_HumOut notify Sen_Aussen:humidity.* {fhem("set TSCUL_WS433 TX3Send H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." SID:23 U")}


Ergänzt ist auch noch ein set KSSend.
Damit lassen sich WS Sensordatentelegramme versenden.
Beispiel:

define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 KSSend T:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." Code:2")}


Gruß, Ansgar.

Vorherige Version: https://forum.fhem.de/index.php/topic,24436.msg891756.html#msg891756 (https://forum.fhem.de/index.php/topic,24436.msg891756.html#msg891756)
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.31
Beitrag von: killah78 am 22 Juli 2019, 12:27:35
Hallo noansi,
habe von 0.30 auf 0.31 upgedated, da ich einen Absturz (fhem hat sich beendet) durch timerTS bekam, wenn ich ein MQTT2 Device anlegen wollte.
Hatte als letzte Meldung immer:

Can't use an undefined value as a subroutine reference at ./FHEM/97_timerTS.pm line 75.


Mit der neuen 0.31 tritt dieser Fehler nicht mehr auf.
Danke für das Update.
Gruss
killah78
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.31
Beitrag von: ph573 am 04 August 2019, 08:59:27
Mich hat das Problem hierher geführt, dass mehrere HM-Aktoren zu "MISSING ACK" in FHEM führen. An ein funktechnisches Übertragungsproblem will ich nicht so recht glauben, da 30 cm weiter sich funktionierende Aktoren befinden. Also warum nicht diese Firmware an meinem CUNX austesten - gleich vorweg jetzt lässt sich kein Aktor mehr ansprechen, jedes Kommando an jeden Aktor wird mit


TSCUL_ParseTsHM: RFCUNX1 HM repeat failed to 698A2E/OG_WOH_Deckenspot:  245604 A F209 04807992 00 0B 93 A001 FA2CE4 698A2E 030E _sfail _noAnsw


quittiert.

Die Schritte im Einzelnen:

a) CUNX erfolgreich mit V0.31 geflasht


Internals:
   CMDS       ABCDEFGHJKLMNRTUVWXYZefilmpqtux
   Clients    STACKABLETS:STACKABLE:CUL_HM:CUL_IR:HMS
   DEF        192.168.200.134:2323 0000
   DeviceName 192.168.200.134:2323
   FD         13
   FHTID      0000
   FUUID      5d45904c-f33f-5e09-74b0-e2c0d518e43c5c23
   NAME       RFCUNX1
   NR         44
   PARTIAL   
   RAWMSG     A0FCBA410698A2EFA2CE4060300003F00::-59.5:RFCUNX1:
   RFCUNX1_MSGCNT 4
   RFCUNX1_TIME 2019-08-04 08:29:18
   RSSI       -59.5
   STATE      Initialized
   TYPE       TSCUL
   VERSION    VTS 0.31 CUL868
   VERSION_HW CUNX_V1.0
   VERSION_TS yes AES ChTblSize:384
   XmitOpen   1
   assignUpdCntI 30
   assignedIDsCnt 15
   initString AP<
X21
Ar
AM5
AHFA2CE4
   msgLoadCurrent 10
   owner_CCU  RFVHM
   Helper:
     DBLOG:
       Xmit-Events:
         logdb:
           TIME       1564898206.75477
           VALUE      init:1 disconnected:1 non-HM:1 ok:1
       cond:
         logdb:
           TIME       1564898206.75477
           VALUE      ok
       prot_ok:
         logdb:
           TIME       1564898206.75477
           VALUE      last
   MatchList:
     1:STACKABLETS ^\*
     2:STACKABLE ^\*
     A:CUL_HM   ^A....................
     B:CUL_IR   ^I............
     C:HMS      ^810e04......a001
   READINGS:
     2019-08-04 07:56:46   Xmit-Events     init:1 disconnected:1 non-HM:1 ok:1
     2019-08-04 07:56:10   cmds             A B C D E F G H J K L M N R T U V W X Y Z e f i l m p q t u x
     2019-08-04 07:56:46   cond            ok
     2019-08-04 07:56:10   prot_disconnected last
     2019-08-04 07:56:12   prot_init       last
     2019-08-04 07:56:11   prot_non-HM     last
     2019-08-04 07:56:46   prot_ok         last
     2019-08-04 08:14:26   scF             1.0083672737872
     2019-08-04 07:56:12   state           Initialized
   helper:
     CUrun      1
     ChkPart    0
     RA_Timeout 0
     SVTS       1
     VTS        1
     VTS_ACK    1
     VTS_AES    1
     assIdCnt   15
     assIdRep   15
     nRec       0
     recAlive   1
     recd       1
     DEVIO:
       RXfailTO   
     HM:
       ChTblRAM   1
       ChTblSize  384
       FUP        0
       HMactive   1
       hmCrdts    1
       hmSbusy    0
       ChTbl:
         698A2E3F   01
         698B423F   01
         698B5E3F   01
         698C0F3F   01
         698C3A3F   01
         698C523F   01
         698CCD3F   01
         698CFA3F   01
         698D223F   01
         698D6E3F   01
         6B7AB33F   01
         6B7AB43F   01
         6B7AC23F   01
         6B7AC43F   01
         6B7AC93F   01
       msgCNT:
         0x01       4
         0x02       175
         0x03       343
         0x09       109
       unknwn:
     cnd:
       0          1
       250        1
       253        1
       255        1
     hmLogHist:
        110172 A F203 02328760 01 0B 28 A001 FA2CE4 698D22 010E _CCAdly:4
        110322 A F209 02329024 00 0B 28 A001 FA2CE4 698D22 010E _sfail _noAnsw
        110357 A F203 02329032 01 0B A3 A001 FA2CE4 6B7AC2 010E _CCAdly:4
        110627 A F203 02329300 01 0B A3 A001 FA2CE4 6B7AC2 010E _CCAdly:4
        110897 A F203 02329568 01 0B A3 A001 FA2CE4 6B7AC2 010E _CCAdly:4
        111136 A F209 02329832 00 0B A3 A001 FA2CE4 6B7AC2 010E _sfail _noAnsw
        114012                 As 0B 28 A001 FA2CE4 698D22 010E
        114048 A F203 02332692 02 0B 28 A001 FA2CE4 698D22 010E _CCAdly:8
        114341 A F203 02332984 06 0B 28 A001 FA2CE4 698D22 010E _CCAdly:24
        114614 A F203 02333256 01 0B 28 A001 FA2CE4 698D22 010E _CCAdly:4
        114854 A F209 02333520 00 0B 28 A001 FA2CE4 698D22 010E _sfail _noAnsw
        141235 A F202 02359676 00 01 AE _ping
        175140 A F202 02393308 00 01 AE _ping
        210661 A F102 02428540 00 01 AE _ping
     hmQ:
       000000:
       698A2E:
       698B42:
       698B5E:
       698C0F:
       698C3A:
       698C52:
       698CCD:
       698CFA:
       698D22:
       698D6E:
       6B7AB3:
       6B7AB4:
       6B7AC2:
       6B7AC4:
       6B7AC9:
     ids:
       698A2E:
         cfg        +698A2E,00,01,00
         name       OG_WOH_Deckenspot
       698B42:
         cfg        +698B42,00,01,00
         name       OG_ESS_Deckenspot
       698B5E:
         cfg        +698B5E,00,01,00
         name       OG_TRE_Deckenspot
       698C0F:
         cfg        +698C0F,00,01,00
         name       OG_BAD_Deckenspot
       698C3A:
         cfg        +698C3A,00,01,00
         name       OG_KUC_Deckenspot
       698C52:
         cfg        +698C52,00,01,00
         name       OG_SCH_Deckenspot
       698CCD:
         cfg        +698CCD,00,01,00
         name       OG_SCH_Nachtlampe_L
       698CFA:
         cfg        +698CFA,00,01,00
         name       OG_SCH_Nachtlampe_R
       698D22:
         cfg        +698D22,00,01,00
         name       OG_WOH_Tischlampe
       698D6E:
         cfg        +698D6E,00,01,00
         name       OG_WOH_Kugellampe
       6B7AB3:
         cfg        +6B7AB3,00,01,00
         name       OG_WOH_Leinwand
       6B7AB4:
         cfg        +6B7AB4,00,01,00
         name       OG_SCH_Rolladen
       6B7AC2:
         cfg        +6B7AC2,00,01,00
         name       OG_WOH_Rolladen
       6B7AC4:
         cfg        +6B7AC4,00,01,00
         name       OG_KUC_Rolladen
       6B7AC9:
         cfg        +6B7AC9,00,01,00
         name       OG_ESS_Rolladen
     loadLvl:
       bl         40
     q:
       ATrNo      0
       HMcndN     0
       InQueues   0
       RQLSt      0
       RQLt       0
       XRpCnt     0
       XRpTm      1564900148.36344
       answerPend 0
       hmLanQlen  1
       apIDs:
         698A2E     0
         698B42     0
         698B5E     0
         698C0F     0
         698C3A     0
         698C52     0
         698CCD     0
         698CFA     0
         698D22     0
         698D6E     0
         6B7AB3     0
         6B7AB4     0
         6B7AC2     0
         6B7AC4     0
         6B7AC9     0
     ref:
       Sdly       28
       TmBmCnt    1
       ioBR       113943.621545667
       ioBRMax    113943.621545667
       ioBRMean   84825.765874739
       ioBRn      0
       lHMt       35865160
       lSys       458319582
       pTTu       1024
       pndAs      0
       pndCUAp    0
       pngLm      3
       pngMax     13740
       pngMaxTot  13740
       pngMin     -5
       pngRef     -5
       pngtm      457429126
       scErr      0
       scF        1.0083672737872
       scFN       1
       scHT       33966572
       scST       456405120
Attributes:
   group      CUL
   hmId       FA2CE4
   rfmode     HomeMatic
   room       Heizung
   verbose    5


b) Die angegebenen Perl-Programme in das FHEM Verzeichnis kopiert

c) Die Einstellungen der VCCU kontrolliert


Internals:
   DEF        FA2CE4
   FUUID      5d45904e-f33f-5e09-06f0-284901a43f974e4d
   IODev      RFCUNX1
   NAME       RFVHM
   NOTIFYDEV  global
   NR         49
   NTFY_ORDER 50-RFVHM
   STATE      RFCUNX1:ok,
   TYPE       CUL_HM
   assignedIOs
   Helper:
     DBLOG:
       state:
         logdb:
           TIME       1564898206.91722
           VALUE      RFCUNX1:ok,
   READINGS:
     2019-08-03 18:45:26   IOopen          2
     2019-08-04 07:56:46   state           RFCUNX1:ok,
     2019-07-27 13:57:24   unknown_18B83F  received
     2019-08-03 16:15:48   unknown_2B728B  received
     2019-08-02 08:05:48   unknown_30401E  received
     2019-08-02 20:37:43   unknown_62B794  received
     2019-07-29 14:45:25   unknown_65FACE  received
     2019-08-01 21:56:07   unknown_66F920  received
     2019-07-26 08:15:27   unknown_66F96F  received
     2019-08-03 22:58:12   unknown_670BBD  received
     2019-07-31 19:38:55   unknown_680191  received
     2019-07-27 11:53:32   unknown_698CCD  received
     2019-07-27 12:00:02   unknown_698CFA  received
     2019-07-27 12:40:11   unknown_698D22  received
     2019-07-27 11:33:15   unknown_698D6E  received
     2019-08-03 14:05:50   unknown_6A1618  received
     2019-08-01 17:27:21   unknown_6B7AB3  received
     2019-08-01 21:57:18   unknown_6B7AB4  received
     2019-08-01 21:55:49   unknown_6B7AC2  received
     2019-08-01 22:22:41   unknown_6B7AC4  received
     2019-08-03 18:42:02   unknown_6B7AC9  received
     2019-08-03 10:41:48   unknown_6CCD00  received
     2019-08-03 18:57:37   unknown_83ECC9  received
     2019-08-03 22:00:17   unknown_95F7F5  received
     2019-08-03 22:46:05   unknown_97DB2E  received
     2019-08-02 01:29:22   unknown_987BDD  received
     2019-08-03 22:56:21   unknown_A5BB34  received
     2019-08-03 13:43:56   unknown_B8CEE6  received
   helper:
     HM_CMDNR   76
     mId        FFF0
     regLst     ,0
     rxType     1
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       prefIO     
       vccu       RFVHM
       ioList:
         RFCUNX1
     mRssi:
       mNo       
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       vrt        1
Attributes:
   IODev      RFCUNX1
   IOList     RFCUNX1
   expert     2_defReg+raw
   hmKey      01:a43f1b6a59137f3980e070cf3e8e0637
   model      CCU-FHEM
   subType    virtual
   verbose    5
   webCmd     virtual:update


d) exemplarisch den Dimm-Aktor OG_WOH_Deckenspot überprüft


Internals:
   DEF        698A2E
   FUUID      5d45904e-f33f-5e09-7ed2-7b6c303719ff5e8a
   IODev      RFCUNX1
   LASTInputDev RFCUNX1
   MSGCNT     3
   NAME       OG_WOH_Deckenspot
   NOTIFYDEV  global
   NR         85
   NTFY_ORDER 50-OG_WOH_Deckenspot
   RFCUNX1_MSGCNT 3
   RFCUNX1_RAWMSG A0FCBA410698A2EFA2CE4060300003F00::-59.5:RFCUNX1:
   RFCUNX1_RSSI -59.5
   RFCUNX1_TIME 2019-08-04 08:29:18
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 OG_WOH_Deckenspot_Dim
   channel_02 OG_WOH_Deckenspot_Dim_V_01
   channel_03 OG_WOH_Deckenspot_Dim_V_02
   lastMsg    No:CB - t:10 s:698A2E d:FA2CE4 060300003F00
   protCmdDel 3
   protLastRcv 2019-08-04 08:29:18
   protRcv    3 last_at:2019-08-04 08:29:18
   protResnd  9 last_at:2019-08-04 08:29:16
   protResndFail 1 last_at:2019-08-04 07:58:39
   protSnd    7 last_at:2019-08-04 08:29:18
   protState  CMDs_done
   rssi_RFCUNX1 cnt:3 min:-63 max:-62 avg:-62.66 lst:-63
   rssi_at_RFCUNX1 cnt:3 min:-60 max:-59 avg:-59.5 lst:-59.5
   Helper:
     DBLOG:
       state:
         logdb:
           TIME       1564900158.5733
           VALUE      CMDs_done
   READINGS:
     2019-07-22 08:09:23   D-firmware      1.1
     2019-07-22 08:09:23   D-serialNr      PEQ0826054
     2019-08-03 18:23:52   PairedTo        0xFA2CE4
     2019-07-27 13:53:21   R-pairCentral   0xFA2CE4
     2019-08-03 22:35:17   RegL_00.       
     2019-07-27 14:40:20   powerOn         2019-07-27 14:40:20
     2019-08-04 08:29:18   state           CMDs_done
   helper:
     HM_CMDNR   203
     cSnd       01FA2CE4698A2E020E,01FA2CE4698A2E030E
     mId       
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       lstRecType 10
       newChn     +698A2E,00,01,00
       nextSend   1564900158.61736
       nxtSndMcnt CB
       rxt        0
       tgtDly     88
       vccu       RFVHM
       lRcTm:
         RFCUNX1    35866528
         tnms       458320964
       p:
         698A2E
         00
         01
         00
       prefIO:
         RFCUNX1
     mRssi:
       mNo        CB
       io:
         RFCUNX1:
           -49.5
           -49.5
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
     rpt:
       IO         RFCUNX1
       flg        A
       ts         1564900158.54183
       ack:
         HASH(0x24a2168)
         CB8002FA2CE4698A2E00
     rssi:
       RFCUNX1:
         avg        -62.6666666666667
         cnt        3
         lst        -63
         max        -62
         min        -63
       at_RFCUNX1:
         avg        -59.5
         cnt        3
         lst        -59.5
         max        -59
         min        -60
     tmpl:
Attributes:
   IODev      RFCUNX1
   IOgrp      RFVHM:RFCUNX1
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.1
   model      HM-LC-DIM1T-DR
   room       CUL_HM
   serialNr   PEQ0826054
   subType    dimmer
   webCmd     getConfig:clear msgEvents


e) Wie schon eingangs erwähnt endet jedes Kommando in einem timeout gleichwohl welcher Aktor angesprochen wird und bestehende bzw. neue Aktoren lassen sich nicht anlernen (als wenn der Aktor im Anlernmodus keinen Funk aussendet).

2019.08.04 08:48:08 4: TSCUL_XmitAwaitHMTo RFCUNX1: timeout - 698A2E
2019.08.04 08:48:09 4: CUL_HM_Resend: OG_WOH_Deckenspot nr 2
2019.08.04 08:48:09 5: TSCUL_Write: RFCUNX1 sending As0ECFA011FA2CE4698A2E0201C80000
2019.08.04 08:48:09 4: TSCUL_send:  RFCUNX1  175797                 As 0E CF A011 FA2CE4 698A2E 0201C80000
2019.08.04 08:48:09 4: TSCUL_XmitDlyHM:  RFCUNX1  id:698A2E rtoms:2328
2019.08.04 08:48:09 5: TSCUL_Read RFCUNX1: /A

2019.08.04 08:48:09 5: TSCUL_Read RFCUNX1: /AF103008D196D010ECFA011FA2CE4698A2E0201C8000080

2019.08.04 08:48:09 4: TSCUL_Parse: RFCUNX1  175834 A F103 03433908 01 0E CF A011 FA2CE4 698A2E 0201C80000 _CCAdly:4
2019.08.04 08:48:09 5: TSCUL_Read RFCUNX1: /AF103008D19B1010ECFA011FA2CE4698A2E0201C8000080

2019.08.04 08:48:09 4: TSCUL_Parse: RFCUNX1  176106 A F103 03434180 01 0E CF A011 FA2CE4 698A2E 0201C80000 _CCAdly:4
2019.08.04 08:48:10 5: TSCUL_Read RFCUNX1: /AF103008D19F5010ECFA011FA2CE4698A2E0201C8000080

2019.08.04 08:48:10 4: TSCUL_Parse: RFCUNX1  176380 A F103 03434452 01 0E CF A011 FA2CE4 698A2E 0201C80000 _CCAdly:4
2019.08.04 08:48:10 5: TSCUL_Read RFCUNX1: /AF109008D1A38000ECFA011FA2CE4698A2E0201C8000080

2019.08.04 08:48:10 3: LogHist RFCUNX1:  143114 A F103 03401444 05 0E D5 A011 FA2CE4 698C0F 0201C80000 _CCAdly:20
2019.08.04 08:48:10 3: LogHist RFCUNX1:  144600 A F103 03401716 01 0E D5 A011 FA2CE4 698C0F 0201C80000 _CCAdly:4
2019.08.04 08:48:10 3: LogHist RFCUNX1:  144600 A F103 03401988 01 0E D5 A011 FA2CE4 698C0F 0201C80000 _CCAdly:4
2019.08.04 08:48:10 3: LogHist RFCUNX1:  144600 A F109 03402256 00 0E D5 A011 FA2CE4 698C0F 0201C80000 _sfail _noAnsw
2019.08.04 08:48:10 3: LogHist RFCUNX1:  165618 A F002 03423804 00 01 AE _ping
2019.08.04 08:48:10 3: LogHist RFCUNX1:  172574                 As 0E CF A011 FA2CE4 698A2E 0201C80000
2019.08.04 08:48:10 3: LogHist RFCUNX1:  172609 A F103 03430712 01 0E CF A011 FA2CE4 698A2E 0201C80000 _CCAdly:4
2019.08.04 08:48:10 3: LogHist RFCUNX1:  172883 A F103 03430984 01 0E CF A011 FA2CE4 698A2E 0201C80000 _CCAdly:4
2019.08.04 08:48:10 3: LogHist RFCUNX1:  173158 A F103 03431256 01 0E CF A011 FA2CE4 698A2E 0201C80000 _CCAdly:4
2019.08.04 08:48:10 3: LogHist RFCUNX1:  173399 A F109 03431524 00 0E CF A011 FA2CE4 698A2E 0201C80000 _sfail _noAnsw
2019.08.04 08:48:10 3: LogHist RFCUNX1:  175797                 As 0E CF A011 FA2CE4 698A2E 0201C80000
2019.08.04 08:48:10 3: LogHist RFCUNX1:  175834 A F103 03433908 01 0E CF A011 FA2CE4 698A2E 0201C80000 _CCAdly:4
2019.08.04 08:48:10 3: LogHist RFCUNX1:  176106 A F103 03434180 01 0E CF A011 FA2CE4 698A2E 0201C80000 _CCAdly:4
2019.08.04 08:48:10 3: LogHist RFCUNX1:  176380 A F103 03434452 01 0E CF A011 FA2CE4 698A2E 0201C80000 _CCAdly:4
2019.08.04 08:48:10 3: TSCUL_ParseTsHM: RFCUNX1 HM repeat failed to 698A2E/OG_WOH_Deckenspot:  176621 A F109 03434720 00 0E CF A011 FA2CE4 698A2E 0201C80000 _sfail _noAnsw
2019.08.04 08:48:11 4: TSCUL_XmitAwaitHMTo RFCUNX1: timeout - 698A2E


Bin aktuell etwas ratlos was ich noch ausprobieren bzw. anpassen kann, außer die gemachten Änderungen wieder rückgängig zu machen. Vielleicht übersehe ich auch etwas Essentielles und jemand hat einen guten Tipp für mich.

Herzliche Grüße,
Peter
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.31
Beitrag von: frank am 04 August 2019, 12:03:43
hallo peter,

seltsam finde ich das reading IOopen=2 bei deiner vccu, da es ja nur ein io gibt. dem entsprechend gibt es beim state reading wahrscheinlich am ende auch ein komma für ein weiteren state eines 2. ios.

bei der vccu fehlt noch das attr IOgrp.

nutzt du 10_cul_hm.pm, hmconfig.pm, 98_hminfo.pm aus der zip datei, oder die aktuellen "normalen" dateien?

fhem restart hast du sicherlich gemacht.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.31
Beitrag von: noansi am 04 August 2019, 13:50:30
Hallo Peter,

was sagt ccconf beim CUNX?

Vermutlich liegt es am hmFreqOffset.
Versuch mal ein set hmFreqOffset 0 beim CUNX. Damit wärest Du beim Stand vor dem Flashen der Firmware, was den hmFreqOffset angeht.

Wenn dann was geht, dann kannst Du mit hmFreqOffset vermutlich noch weiter ins + gehen.
Mein CUNX, der auf  HM läuft, hat z.B. mit 17.456kHz Offset sein Optimum zu meinen HM devices.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.31
Beitrag von: ph573 am 05 August 2019, 09:39:22
Hallo Frank,
hallo Ansgar,

danke für Eure Rückmeldungen und Beobachtungen:

Zitatseltsam finde ich das reading IOopen=2 bei deiner vccu, da es ja nur ein io gibt. dem entsprechend gibt es beim state reading wahrscheinlich am ende auch ein komma für ein weiteren state eines 2. ios.

In der Tat hat es bis vor ein paar Tagen eine zweite stackable CUL gegeben die in der VCCU konfiguriert war. Ich hatte sie rausgenommen, da ich nicht sofort alle mit der TSCUL Firmware flashen wollte. Dabei übersehen, dass FHEM ein Gedächtnis in Form der SAVE- und EVENTS-Dateien hat. Inzwischen gelöscht, IOopen ist nun 1, aber das Komma im state bleibt. Habe daher auch eine weitere VCCU erzeugt um zu sehen, ob dort das Komma bei nur einer CUL weggeht: dem ist nicht so, Komma bleibt.

Dann irrtümlich die "produktive" VCCU gelöscht, und siehe da die CUNX kann mit allen Aktoren perfekt kommunizieren. Jetzt habe ich direkt alle Aktoren an der CUNX angelernt.

Zitatbei der vccu fehlt noch das attr IOgrp.

nutzt du 10_cul_hm.pm, hmconfig.pm, 98_hminfo.pm aus der zip datei, oder die aktuellen "normalen" dateien?

fhem restart hast du sicherlich gemacht.

IOgrp hatte ich ergänzt, hat keine Verbesserung gebracht. Dateien aus dem TS-Zip wurden kopiert, und die ganze Box wurde neu gestartet.

ZitatVermutlich liegt es am hmFreqOffset.
Versuch mal ein set hmFreqOffset 0 beim CUNX. Damit wärest Du beim Stand vor dem Flashen der Firmware, was den hmFreqOffset angeht.

Ich habe ich vorm Löschen der VCCU mit verschiedensten Frequenzoffsets gespielt, keine Verbesserung erzielt.

Vielleicht schaffe ich es die Tage noch den zweiten CUL zu flashen, dabei auch eine neue VCCU anlegen, einfach nur um zu sehen ob es an der "nur mit einer Sendestation verbundenen VCCU" liegt.

Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.31
Beitrag von: handy80 am 06 September 2019, 10:45:52
Hallo,
wie kann ich meine TSCUL updaten? Bin noch auf FW 0.18 (VERSION VTS 0.18 CUL868) und (VERSION_HW ist CUL_V3.4)
hab mich hier im Thread zurück-gewurschtelt, aber dann bin ich bei den Preconditions irgendwie verwirrt.
Kann jemand kurz für mich als Dummie skizzieren, welche Schritte ich auf meinem Raspi in welcher Reihenfolge machen muss um den USB-Stick von busware inkl. FHEM upzudaten. Wichtig sind vermutlich die richtigen Versionen und wo ich die Dateien runterladen kann.


nach etlichen Versuche über fhem habe ich mich für den manuelle Weg (DFU Bootloader) entschieden. Eine Anleitung habe ich bei busware http://busware.de/tiki-index.php?page=DFU+Bootloader (http://busware.de/tiki-index.php?page=DFU+Bootloader) gefunden. Prozessor-Name noch auf der Produkt-Seite bei busware gefunden (atmega32u4 in meinem Fall für einen CUL V3)

Dann den Rest von Ansgars Anleitung befolgt und ich bin auf dem neusten Stand.

Gruß Holger
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.31
Beitrag von: CHDI am 04 Oktober 2019, 18:20:26
Hallo zusammen,

ich werde nicht wirklich fündig, bin aber die 57 Seiten auch "nur" überflogen.

Ich habe folgende Konstellation:

Raspi
- nanoCul_433 IT
- nanoCul_868 HM

wegen Homematic möchte ich gerne die TS Variante nutzen:
- nanoCul_868 geflashed
- FHEM Files eingespielt (vor Update geschützt)
- TSCUL defined
- soweit alles gut

Ich war davon ausgegangen, dass ich meinen 433er wegen dem Austausch der FHEM Dateien nun auch flashen muss. IT ist ja auch in der FW mit drin. Also:
- 433er hex erstellt (bis auf 443 nichts in der board.h verändert IT ist ja eingeschaltet) und geflashed.
- CUL als TSCUL defined.

list CUL443:

Internals:
   CMDS       ABCEFGJKMRUVWXYZeilmtux
   Clients    STACKABLETS:STACKABLE:TSCUL_WS:IT:CUL_FHTTK:CUL_HOERMANN:TSCUL_TX:CUL_IR:SOMFY:Revolt:ESA2000:TSCUL_RFR:TSCUL_EM:BS:USF1000:FS20:FHT.*:TSKS300:HMS:FS20V:CUL_TCM97001:CUL_REDIRECT
   DEF        /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@38400 1334
   DeviceName /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@38400
   FD         13
   FHTID      1334
   FUUID      5d925f33-f33f-ee52-e6e2-02eea5efc750bddf
   NAME       VH.CUL433
   NR         91
   PARTIAL   
   RAWMSG     
   STATE      Initialized
   SlowRF_BitBufferOvrfl 0
   SlowRF_BucketOvrfl 0
   SlowRF_IntCalcStat Last: 25.0  Min: 25.0  Mean: 25.0  Max: 40.0
   TYPE       TSCUL
   VERSION    VTS 0.31 CSM433
   VERSION_HW nanoCUL_V1.x
   VERSION_TS yes AES ChTblSize:209
   XmitOpen   0
   initString AP<
X21
AM5
AHF11334
   msgLoadCurrent 30
   MatchList:
     1:STACKABLETS ^\*
     2:STACKABLE ^\*
     A:TSCUL_WS ^K.....
     B:IT       ^i.(?::.|.....)
     C:CUL_FHTTK ^T[\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F]
     D:CUL_HOERMANN ^R..........
     E:TSCUL_TX ^TXA.........
     F:CUL_IR   ^I............
     G:SOMFY    ^Y[r|t|s]:?[\dA-F]+
     H:Revolt   ^r......................$
     I:ESA2000  ^S................................$
     J:TSCUL_RFR ^[\dA-F][\dA-F][\dA-F][\dA-F]~.
     K:TSCUL_EM ^E0.0[\dA-F]..............
     L:FS20V    ^81..(?:04|0c)..0101a001......00[89a-f]...
     M:BS       ^81..(?:04|0c)..0101a001a5cf
     N:USF1000  ^81..(?:04|0c)..0101a001a5ceaa00....
     O:FS20     ^81..(?:04|0c)..0101a001
     P:FHT      ^81..(?:04|09|0d)..(?:0909a001|83098301|c409c401)..
     Q:TSKS300  ^810d04..4027a001
     R:HMS      ^810e04......a001
     S:CUL_TCM97001 ^s[\dA-F]+
     T:CUL_REDIRECT ^o
   READINGS:
     2019-10-04 17:21:05   Ints_per_sec    SI: 2.31664  TI: 0.50999  S: 0.38000  L: 0.00000  U: 0.03333  M: 0.00333
     2019-10-04 18:10:53   Xmit-Events     disconnected:1 non-HM:2
     2019-10-04 17:56:04   ccconf          freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:12dB
     2019-10-04 18:07:40   cmds             A B C E F G J K M R U V W X Y Z e i l m t u x
     2019-10-04 18:10:53   cond            non-HM
     2019-10-04 18:07:39   prot_disconnected last
     2019-10-04 18:10:53   prot_non-HM     last
     2019-10-04 18:07:42   state           Initialized
   helper:
     CUrun      1
     ChkPart    0
     RA_Timeout 0
     SVTS       1
     VTS        1
     VTS_ACK    1
     VTS_AES    1
     nRec       0
     recAlive   1
     recd       0
     DEVIO:
       RXfailTO   
     HM:
       ChTblSize  209
       FUP        0
       hmCrdts    3
       ChTbl:
       msgCNT:
         0x02       18
     SRf:
       lastIntC   1203
       lastIntCTime 1570205562.30631
       lastIntTOC 191
       lastSyncC  242
       lastloFltC 0
       lastmtchErrC 0
       lastupFltC 24
       IntStat:
         Max        40
         Mean       25
         Min        2
         N          1
     cnd:
       250        2
       253        1
     ids:
     q:
       HMcndN     250
       hmLanQlen  1
     ref:
       ioBR       3840
       ioBRMax    3684.94040572729
       ioBRMean   3652.98752223861
       ioBRMeas   3657.40622498186
       ioBRn      82
       ioBRnC     18
       ioBRptm    1570205627.25507
       ioBRs      65753.775400295
       lHMt       4294967295
       lSys       1656605259.95772
       scF        1
Attributes:
   room       CUL


Leider funkt er nun nicht mehr an die IT Steckdosen. Mir ist aufgefallen, dass RAWMSG leer ist, das ist bei der a-culfw anders
- a-culfw wieder drauf gespielt: Steckdosen schalten funktioniert wieder...

Mit der a-culfw bekomme ich im EventMonitor raw: is10..... angezeigt, das tut es mit der TSCUL_FW nicht.

Was wäre denn das richtige Vorgehen?
Muss ich den 443er mit TSCULFW betreiben? (wegen Austausch der FHEM Dateien)
    Wenn ja: muss ich ihn auch als TSCUL definieren
    Wenn nein: definiere ich ihn als CUL nicht als TSCUL und der Austausch der FHEM Dateien ist egal?

Ich fürchte es fehlt im Moment noch eher grundlegende Verständnis für das parallele Betreiben mit unterschiedlicher FW. Als die Konfig. Bisher hatte ich die immer analog.
Gruß Chris
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.31
Beitrag von: noansi am 04 Oktober 2019, 22:06:53
Hallo Chris,

Zitatich werde nicht wirklich fündig, bin aber die 57 Seiten auch "nur" überflogen.
Wie jetzt...?  :o  ;)

Wenn Du die tsculfw nutzen willst, dann musst Du die fhem Module aus der zip benutzen.
Für IT insbesondere auch die 10_IT.pm aus der zip.

Was eventuell ein Problem sein könnte, ist die Anzahl der Wiederholungen beim IT device.
Die a-culfw wiederholt 6 mal per default. Die tsculfw 3 mal per default.
Versuch mal beim IT device das Attribut "ITrepetition" auf 6 zu setzen. Eventuell will Dein device mehr Wiederholungen, um zu verstehen.
Ein list vom IT device hast Du leider nicht beigepackt.

ZitatMit der a-culfw bekomme ich im EventMonitor raw: is10..... angezeigt, das tut es mit der TSCUL_FW nicht.
Auch die tsculfw schickt ein "is..." zurück, wenn sie hat senden können. Es kann aber passieren, dass sie nicht senden kann. Bei mangelnden credits käme ein "LOVF" und wenn der Sendekanal als belegt erkannt wird käme ein "NOCCA", statt zu senden. Mit einem verbose 5 beim 433er nano würdest Du das auch im Log sehen können.


Da Du nur zwei nanoCuls verwendest solltest Du problemlos auch den 433er mit a-culfw flashen können und diesen auch, als CUL definiert (nicht TSCUL), wie zuvor gewohnt nutzen können. Allerdings musst Du dann das standard 10_IT.pm verwenden und nicht das aus der zip.
Den 868er würdest Du mit tsculfw flashen und als TSCUL definieren und damit Homematic machen. Das 10_IT.pm ist dafür irrerelvant.

Nur wenn Du gestackte CULs, also bspw. SCC oder COC verwenden würdest, dann könnte ich mir Unverträglichkeiten im Mischbetrieb vorstellen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.31
Beitrag von: noansi am 04 Oktober 2019, 22:17:01
Hallo Holger,

die Nutzung con TSCULflash setzt, ebenso, wie CULflash, für einen CUL V3 den installierten dfu-programmer vorraus.

Andere CULs mit serieller Schnittstelle erforden den installierten avrdude.

Wenn das CommandRef nach Kopieren der FHEM Module aktualisiert ist, ist die Nutzung von TSCULflash dort zu lesen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.31
Beitrag von: CHDI am 05 Oktober 2019, 10:27:30
Hallo Ansgar,

danke für den Tip, das hat mich weiter gebracht. Mit verbose 5 sehe ich bei jedem Schaltvorgang NOCCA.
Und ja, hätte ich jede Seite ordentlich gelesen, dann wäre ich evtl auch selbst auf Seite 46 dieses Threats gelandet - shame on me  :P
Gleiches Verhalten, auch wenn CCAmode auf 0 ist.
Ich habe am CC1101 433 die mitgelieferte Antenne (Stabantenne ca. 4cm - ich gehe mal davon aus, dass hier nicht Lambda/4 geschweigedenn Lambda/2 vorliegen kann!?) und habe mir mal eine 433 Antenne bestellt. Evtl. hilft das ja auch bei mir. Weiteres hierzu dann am Montag, wenn die Antenne da ist.
Der Workaround mit der a-culfw bleibt als Möglichkeit, aber wenn es mit TSculfw funktionieren müsste dann will ich es nun wissen. Scheint ja irgendwas anderes nicht zu passen.

Bekomme ich irgendwie raus, wieso der CUL davon ausgeht, dass der Funkkanal belegt ist?
- USB Verlänferung habe ich und habe dias Modul ca. 30cm vom RASPI weg.

Wieso interessiert den CUL das mit der a-culfw nicht und er sendet?

Gruß Chris
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.31
Beitrag von: noansi am 05 Oktober 2019, 12:14:31
Hallo Chris,

ZitatGleiches Verhalten, auch wenn CCAmode auf 0 ist.
Weil nach Code die SlowRF CC1101 Register Einstellungen für Intertechno fest mit CCAmode 1 (mit CARRIER_SENSE_REL_THR 14dB, CARRIER_SENSE_ABS_THR MAGN_TARGET 5dB) genutzt werden.
Sollte ich wohl mal ändern.
Das würde bedeuten, dass ständig irgendwas (Störungen) empfangen wird. -> von Störquelle entfernen

ZitatIch habe am CC1101 433 die mitgelieferte Antenne (Stabantenne ca. 4cm - ich gehe mal davon aus, dass hier nicht Lambda/4 geschweigedenn Lambda/2 vorliegen kann!?)
Wenn es nur so ein kurzer Draht ist, dann wohl nicht. Wenn es ein zu einer Spule gewickelter Draht ist, schon.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.31
Beitrag von: CHDI am 11 Oktober 2019, 22:05:38
ZitatIch habe am CC1101 433 die mitgelieferte Antenne (Stabantenne ca. 4cm - ich gehe mal davon aus, dass hier nicht Lambda/4 geschweigedenn Lambda/2 vorliegen kann!?) und habe mir mal eine 433 Antenne bestellt. Evtl. hilft das ja auch bei mir. Weiteres hierzu dann am Montag, wenn die Antenne da ist.

Die neue Antenne war wohl die Lösung. Bei der a-culfw war das egal, mit der tsculfw nur mit neuer Antenne...

Besten Dank!

Gruß Chris
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: noansi am 15 Oktober 2019, 21:52:31
Hallo Testwillige,

hier eine neue Version 0.32 der Timestamp Firmware und der dazu benötigten FHEM Module.

Diese Version bietet einige Verbesserungen für SlowRF Empfang und RF-Router. Ein Peakfilter für SlowRF Empfang ist ergänzt und mit "peakfilter" einstellbar.
In dem Zusammenhang ist auch das RF-Router Ping Timing geändert, damit also auch nicht kompatibel mit Standard culffw oder a-culfw.
Außerdem kann das Senden von RF-Router Daten nach deren Empfang einstellbar verzögert werden (RfRdelay).

CCAMode wirkt nun auch auf IT-Senden und SOMY-Senden, sowie auf das Senden des RF-Router Pings. Mit fRfCCAMode kann auch das CCA Verhalten für RF-Router Senden und FastRF geändert werden.

Das EEPROM Layout ist wegen der neuen Parameter geändert und daher werden nach dem Flashen alle Einstellungen auf default zurück gestellt. Also vor dem Flashen individuelle Einstellungen, z.B. Frequenzoffsets, notieren und nacher neu einstellen.

Auszug aus der Changed:
- IT and SOMYFY use SlowRF EEPROM CCA setting now for sending
- changes in SlowRF reception for reset and sync start. IT V1 reception tested succsessfully.
- SlowRF filter and match adaption
- SlowRF spike filter improved, max. peak lenght settable with Xpxx, xx hex time in 8us units
- IR receive/transmit pause during send of SlowRF changed to not globally switching off all interrupts
- periodic RF-Router ping RSSI display as "Cuxx\r\n" with xx = RSSI Hex
- RF-Router ping timing changed for better distinguish from other protocols
- RF-Router pre silence before send settable with uRxx, xx hex time in 4ms units
- Xrrt commands bits:
   rr:
   report known protocol data                                                      Bit 0
   report repeated data                                                            Bit 1
   report received bits                                                            Bit 2
   report 'r' (rising) or 'f' (falling) edge, '.' (collect) or '?' (sync) timeout  Bit 3
   report edges, bit times and timeouts                                            Bit 4
   report S300 data with valid checksum only                                       Bit 5
   report FHT                                                                      Bit 6
   report 'l' RSSI decimal data continuosly                                        Bit 7
   t:
   report recorded SlowRF timing                                                   Bit 0
- corrections in interrupt flag clearing
- correction in delay function
- fastRF bug corrected, untested
- EEPROM layout changed for the new parameters


TSCUNX kann mit entsprechendem RS485 Modul nun auch DMX.
Auch HM485 ist für TXCUNX angepasst.
In dem Zuge ist auch die DMX Funktionalität bei CUNO2 etwas erweitert.
IR läuft nun auch richtig mit TSCONO2.
Außerdem läuft RF-Router auf der tsculfw, allerdings mit einer Änderung. Das 'U' ist durch '~' ersetzt. 'U' kollidierte mit dem Uniroll Senden.

Kurzer Auszug aus der CHANGED:
- IO optimizations CUNX, especially to/from PIM and Ethernet
- CUNX DHCP non blocking operation
- IO optimizations
- HM485 support for CUNX (like CUNO2) with RS485 PIM.
  HM485 switch off with Hx for CUNX. With CUNX after Hx RS485 PIM again accessible via PIM USB or Ethernet Interface
- CUNX support for DMX and HM485 with RS485 PIM (to be tested), a Dwxxxxyy switches to DMX via CUNX Interface, a Hsxxxxxxxxxxxxxxxxxx switches to HM485 via CUNX Interface
- DMX switch off with Dx. With CUNX after Dx RS485 PIM is again accessible via PIM USB- or Ethernet Interface
  DMX flexible channel usage. Channels are sent out upto the highest channel set (0 sent as default for unset channels). With switching off with Dx the highest channel is reset.
  DMX changed in timing and resting behaviour. Rests on IDLE if less then 24 device, only, to keep 1204µs min. BREAK to BREAK (to be tested)
  DMX Dt command to set/view timing of MarkAfterBreak and BREAK
  DMX less disturbed while sending SlowRF
- W function gives feedback after writing EEPROM
- clock timer unburdened, may impact onewire and fht (to be tested)
- corrections for IRTX
- IR base timings changed to 12500Hz or 20000Hz
- RF-Router working, but 'U' changed to '~' (definable in board.h, but 'U' disables HAS_UNIROLL)

Es ist eine Prüfung auf Stacküberlauf eingebaut. Am Anfang des heap werden zwei Byte mit einem Bitmuster beschrieben. Wird das verändert, dann ist der Speicher wahrscheinlich korrumpiert, was durch einen Stacküberlauf ausgelöst sein sollte. Sofern der CUL dann noch kann sendet er ein "C_M" an TSCUL, was zu einem entsprechenden Log Eintrag führt.
Damit kann man vorsichtig die Speichergrenzen ausloten. Ein langer Testzeitraum ist aber erforderlich, um einigermaßen sicher zu sein, dass der worst case auch mal durchlaufen worden ist.
Außerdem ist ein Kommando mU (je nach Firmware) eingebaut, mit dem man den vom Stack ungenutzen heap in etwa auslesen kann (auch als get unusedstack in TSCUL verfügbar). Auch hier gilt, nur nach langer Laufzeit einigermaßen sinnvoll. Es macht sicher keinen Sinn auf Grund des Wertes den Speicher bis auf das letzte Byte auszuquetschen, denn weiterhin hängt die Stacknutzung vom gewählten Protokoll und Einstellungen ab.

In TSCULflash ist Flashen auch von NanoCULs und MiniCULs ergänzt. Vor dem Flashen wird ein "B00" also Reset für die TSCUL Firmware an den nano/Mini geschickt, 1 Sekunde gewartet und dann versucht mit avrdude zu flashen.
Also erst die Firmware in den FHEM/Firmware Ordner kopieren und dann in FHEM mit
TSCULflash <nanodevicename> TSnanoCUL
bzw.
TSCULflash <minidevicename> TSminiCUL
versuchen zu Flashen. Im Log sollte danach (dauert etwas) die avrdude Ausgabe zu finden sein.

Ebenfalls möglich ist das Flashen eines PIGATOR Moduls an einem CUNX
TSCULflash <pigatordevicename>|<cunxdevicename> TSPIGATOR

AESCommReq wird unterstützt. Die Nutzung ist unverändert zu Standard CUL, sprich, beim gewünschten Gerät/Kanal aesCommReq auf 1 setzen und ggf. noch aesKey passend zum verteilten Key setzen.
Es werden von tsculfw nur die Keys 0 (Default Key) bis 3 unterstützt.

Diese Erweiterung erfordert jedoch auch zusätzliche Empfangspuffer im knappen Speicher des CULs. Ein CUL V3 nutzt bis zu 6 Empfangspuffer. Auch der FlashSpeicherbdarf ist angestiegen, so dass einige Protokolle nicht mehr gleichzeitig in ein Kompilat passen. Das sollte aber weniger tragisch sein, da im ASKSIN Modus ohnehin nur HM empfangen werden kann.

Bei CUL V2 reicht der verfügbare Speicher leider hinten und vorne nicht aus, um diese Version nutzen zu können.

Im Anhang ist in TSCUL_fwcode_00_32_FHEM_Modules_00_43_0.zip wieder die Timestamp Firmware zu finden. Getestet habe ich TSCUNX, TSPIGATOR , TSCUL_V3 , TSCUL_V3_RFR, TSCUNO2, TSCOC und TSSCC. (TSCUL_V3_RFR ist ohne HM Unterstützung, also nur SlowRF)

Die tsculfw Firmware kann für TSCUL_V3, TSCUNO2, TSCOC, TSSCC, TSCUNX und TSPIGATOR (an CUNX) mit FHEM mit dem TSCULflash geflashed werden. Die anderen müssen mit dem jeweiligen Flash Programmer geflashed werden. Bei CUNO2 und SCC muss die Bootloadertaste gedrückt werden, bis der Flashvorgang anläuft.
So z.B. https://forum.fhem.de/index.php/topic,24436.msg631743.html#msg631743 kann es mit einem USB CUL Stick gehen, wenn man nicht TSCULflash verwendet.
TSCULflash ist erweitert auf COC, SCC, CCD, rpiaddon, CUNO2 und CUNO. Jedoch ist es nicht ganz so einfach zu handhaben, da zum einen teilweise die Taste zu drücken ist und bei Raspberry PI Modulen die Rechteproblematik für den Zugriff auf die IO-Pins überwunden werden muss. Tips dazu in der Command-Ref auch bei RPI_GPIO.
Bei einem Stapel aus SCC mit aufgesetztem COC, CCD oder (rpiaddon?) ist unbedingt beim SCC Flash darauf zu achten, die Taste am gewünschten Modul zu drücken. Sonst wird das oberste Nicht-SCC Modul mit der SCC Firmware geflashed.
Mit CUNO2 ist das flashen getestet (generell nur über USB!). Wichtig, aber auch hier, die Taste zu drücken.

Es gibt nicht den Luxus des Downloads beim TSCULflash, sondern die Firmware muss händisch in den FHEM/firmware Ordner kopiert werden. Der Typ ist dann z.B. TSCUL_V3.
Beispiel:
TSCULflash MeinCulV3Device TSCUL_V3

Wichtig für SCC Nutzer. TSSTACKED ist entfallen und wird nicht mehr unterstützt.
Statt dessen gibt es das neue Modul STACKABLETS (als Abwandlung von Rudolfs STACKABLE).
Dieses wird sozusagen zwischen die Stackteilnehmer eingebaut.

Beispiel für fhem.cfg:
#erstes SCC Modul als Basis
define SCC_WS868 TSCUL /dev/ttyAMA0@38400 0000
attr SCC_WS868 event-on-change-reading Ints_per_sec,IntCalcStat,MatchStat
attr SCC_WS868 rfmode SlowRF
attr SCC_WS868 room Receiver
attr SCC_WS868 sendpool CUL_HM868,SCC_WS868
attr SCC_WS868 verbose 1

#neues STACKABLETS virtuelles IO device
define STACK_1 STACKABLETS SCC_WS868
attr STACK_1 verbose 1

#zweites SCC Modul
define SCC_HM868 TSCUL FHEM:DEVIO:STACK_1:38400 1034
attr SCC_HM868 event-on-change-reading cond
attr SCC_HM868 hmId F11034


Ergänzender Hinweis zu USB CULs: 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_08\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 1234
bzw.
define CUL_433 TSCUL /dev/CUL433_0@12000000 0000
definiert werden und es gibt keine Probleme mit wechselnder Schnittstelle mehr.
Die Seriennummer kann beim Compilieren der Firmware in der board.h festgelegt werden, so dass damit dann auch /dev/CUL868_1 etc. für mehrere gleiche CULs möglich sind.

Oder für CUNX
define CUNX_868 TSCUL /dev/CUNX868_0@12000000 0000
oder für PIGATOR an CUNX
define PIGATOR_433 TSCUL /dev/CUNXPIM_0@38400 0000
die Seriennummer wird aus der Seriennummer des XMEGA Chips des CUNX gebildet. Unter Linux lsusb nutzen!

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.

Bei nicht nativen USB CULs wie z.B. nanoCUL, miniCUL oder CUNO2, beträgt die Baudrate 38400, dementsprechend muss die Definition beispielsweise so aussehen:
define CUL_868 TSCUL /dev/CUL868@38400 1234
bzw.
define CUL_433 TSCUL /dev/CUL433@38400 0000

Und noch ein Beispiel für eine Definition eines Netzwerk CUNX:
define CUL_868 TSCUL 192.168.178.111:2323 0000
oder für PIGATOR an CUNX
define PIGATOR_433 TSCUL 192.168.178.111:2324 0000
beim PIGATOR sollten zuvor mit Anschluss an USB und öffnen der Schnittstelle mit gewünschten Kommunikationsparametern mit ps oder unter TSCUL mit set PIMstoreBaud die seriellen Kommunikationsparameter zum PIGATOR Modul gespeichert werden, falls sie vom default abweichen.

Oder Netzwerk CUNO2:
define CUNO2_868 TSCUL 192.168.178.110:2323 0000

Die aktuell eingestellte oder per DHCP erhaltene Netzwerkadresse kann mit Lc repektive in TSCUL mit get NetAdresses abgefragt werden. Mit Lp respektive in TSCUL mit get NetPHYlink kann der Linkzustand des Netzwerkanschlusses angezeigt werden.


In der Zip Datei sind ebenfalls die ergänzten Module zu finden, die zur Nutzung der Firmware erforderlich sind.

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
16_TSCUL_RFR.pm -> der 16_CUL_RFR.pm, aus CUL_RFR devices werden damit TSCUL_RFR devices in der fhem.cfg (händisch anzupassen)
16_STACKABLETS.pm -> statt der 16_STACKABLE.pm, aus STACKABLE werden damit STACKABLETS devices in der fhem.cfg (händisch anzupassen)

10_UNIRoll_TS.pm  -> statt der 10_UNIRoll.pm, mit TSCUL 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 IO-devices zu verwenden, aus TSKS300 wird dann TSKS300  in der fhem.cfg (händisch anzupassen). Obsolet, da 14_TSCUL_WS.pm nun KS300 unterstützt.
14_TSCUL_TX.pm    -> statt der 14_CUL_TX.pm, mit TSCUL 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 IO-devices zu verwenden, aus CUL_WS wird dann TSCUL_WS  in der fhem.cfg (händisch anzupassen)
15_TSCUL_EM.pm   -> statt der 15_CUL_EM.pm, mit TSCUL IO-devices zu verwenden, aus CUL_EM wird dann TSCUL_EM  in der fhem.cfg (händisch anzupassen)
CalcUtil.pm               -> Hilfsrechenroutinen für Taupunkt und Windstärkeindex
ReadingUtil.pm          -> Hilfsroutinen für Readings

Da diese Module ergänzt werden (müssen!), überleben sie auch ein Update von FHEM.

10_IT.pm                   -> vermeidet unnötiges busy waiting beim Senden. Wird ohne Schutz von FHEM update überschrieben

Außerdem:

98_TSCULflash.pm     -> Zum Flash von TSCUL_V3, TSPIGATOR (an CUNX) mit Datei in FHEM/firmware

10_CUL_HM.pm         -> angepasste Version zur Nutzung mit TSCUL/tsculfw. Die Nutzung dieses Moduls ist optional. Für CUL_V3, nanoCUL, miniCUL im Multio-HM-IO Betrieb jedoch empfohlen, da sie den EEPROM Verschleiss über das Attribut "rssiSwitchHyst" verringert.
HMConfig.pm             -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden. Einstelllimits für HM-CC-RT-DN Regler P und I Anteil erweitert. Damit kann man mit R-regAdaptive offDeter deutlich mehr an den Regelparametern spielen.
98_HMinfo.pm           -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden. Spaltenbreiten in Tabelle von protoEvents variabel zu verbesserten Übersicht in der Darstellung.
Die 3 Dateien entsprechen einem Stand von Mitte 12/2019. Seither gab es viele Änderungen, so dass entweder diese 3 verwendet werden müssen oder die 3 aus aktuellem Update (meinerseits nicht getestet und der EEPROM-Verschleißhinweis unten ist zu beachten).

10_CULG.pm              -> optional, enthalten, da die Firmware es unterstützt

97_timerTS.pm           -> optional, Austausch-Timerroutinen. Wenn es nicht genutzt werden soll, dann löschen oder umbennen.
98_apptime.pm          -> apptime zur zwingenden Nutzung mit 97_timerTS.pm.
98_apptm.pm            -> apptime zur zwingenden Nutzung mit 97_timerTS.pm, mit geringerem Speicherverbrauch bei weniger Details

98_autocreate.pm       -> autocreate mit TSCUL Unterstützung

98_Cumulate               -> Kumulieren von Zählwerten, wie Strom, Regenmenge etc.
98_SAverage.pm         -> Mittelwertbildung von z.B. Temperaturen. Stunde, Tag, Monat und Jahr, sowie ein gleitender Mittelwert der letzten Stunde sind damit möglich.


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_STACKABLETS.pm DevIoTS.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.pm CalcUtil.pm 97_timerTS.pm 98_TSCULflash.pm 97_timerTS.pm 98_apptime.pm 98_apptm.pm 10_IT.pm 10_CULG.pm 10_CUL_HM.pm HMConfig.pm 98_HMinfo.pm ReadingUtil.pm 98_autocreate.pm 98_Cumulate.pm 98_SAverage.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` }

Noch ein Hinweis: TSCUL fragt auch die Firmwareversion der tsculfw auf 0.32 ab. Eine ältere Version wird also nicht unterstützt!

Frequenzoffset: Für HM ist ein Frequenzoffset von -20.6kHz im EEPROM als default in der tsculfw hinterlegt (das ist ein individuelles Optimum für meinen COC). Dieser Frequenzoffset kann mit set hmFreqOffs umgestellt werden. 0 ist default in der Standard-culfw.
Wenn also keine Antwort von angesprochenen HM devices kommt, dann hmFreqOffs von 0 ausgehend verstellen. CUNX z.B. geht eher in Richtung + mit dem Offset.
Wer das Frequenzspektrum sichtbar machen kann, kann sich die optimale Mitte aller devices ermitteln und mit dem Offset sein CUL dazu passend einstellen.

Noch ein Tip zur Haltbarkeit der CULs mit wenig SRAM (CUL V3, nanoCUL, miniCUL ...). Jedesmal, wenn einem HM-Device das IODev durch Roaming neu zugeordnet wird, führt das zu EEPROM Schreibvorgängen in den beteiligten CULs. Die Lebensdauer des EEPROMs ist begrenzt (100000 Schreibzyklen laut Datenblatt). Daher rate ich zur Nutzung des VorzugsIOs beim Device Attribut IOgrp. Also nicht einfach stumpf
attr HMdeviceName IOgrp VCCU
setzen, sondern
attr HMdeviceName IOgrp VCCU:CUL_mit_gutem_Empfang_fuer_Device
sofern die Roaming Funktionalität entsprechend RSSI für das jeweilige device nicht zwingend benötigt wird. Ein Fallback auf einen anderen CUL bleibt dennoch möglich.
Mit dem Attribut "rssiSwitchHyst", das in der beigefügten 10_CUL_HM.pm verfügbar ist, kann bei den HM-devices die Umschalthysterese für das Roaming von 10 bis auf 2 bei Bedarf für mobile devices verringert werden.

Ergänzt ist auch noch ein set TX3Send.
Damit lassen sich TX3 Sensordatentelegramme auf 433er CULs versenden.
Beispiel:

define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 TX3Send T:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." SID:23 U")}

define NF_HumOut notify Sen_Aussen:humidity.* {fhem("set TSCUL_WS433 TX3Send H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." SID:23 U")}


Ergänzt ist auch noch ein set KSSend.
Damit lassen sich WS Sensordatentelegramme versenden.
Beispiel:

define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 KSSend T:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." Code:2")}


Gruß, Ansgar.

Vorherige Version: https://forum.fhem.de/index.php/topic,24436.msg945418.html#msg945418 (https://forum.fhem.de/index.php/topic,24436.msg945418.html#msg945418)
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: 1wire am 20 November 2019, 16:09:48
Hallo Ansgar,

ich hatte Timing-Probleme mit culfw 1.67. Konnte nie alle CMD abarbeiten und R_tempList_Stare incomplete.
Habe heute per FLIP meine CUL auf tsculfw upgedatet und die entsprechenden Module in FHEM eingespielt.

Sofort wurden alle CMDs abgearbeitet und es funktioniert jetzt mit meinen HM Modulen alles prima.

Dies als kleine Rückmeldung das die V0.32 bei mir funktioniert. und ein Super-Danke an die beteiligten.

Meine Hardware: FHEM auf Win10 in Qnap-Virtualization, 2x CUL (1x Draht, 1x Antenne, 3 Homematic-Heizkörperthermostate V1.3 und V1.4, 3 threeStateSensor)
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: Crania am 04 Dezember 2019, 18:14:20
Kurze Statusmeldung

Auf der Suche nach einer CUNX Firmware bin ich auf diesen Thread gestoßen und habe daraufhin
die tsculfw 0.32 geflashed(TSCUNX.hex) und die zugehörigen Module installiert.
Ein paar HomeMatic Teile angelernt und getestet. Bis jetzt läuft alles super.

Gruß Crania
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: riker1 am 05 Dezember 2019, 20:05:41
Hallo,

habe nun auch den tscul angelegt und 2 devices definiert.

Trotzdem habe ich CMD_Pending Probleme.

was mache ich da denn falsch?

Muss ich noch besondere Parameter setzen?


habe alle Fhem module kopiert, und nanoCul geflashed.


list tscul:

Save config
CUL_HM
Plots
Unsorted
nanocul
icoEverything Everything
Logfile
Commandref
Remote doc
Edit files
Select style
Event monitor
Internals:
   CMDS       ABCEFGJKMRUVWXYZeilmtux
   Clients    STACKABLETS:STACKABLE:CUL_HM:CUL_IR:HMS
   DEF        /dev/ttyUSB0@38400 2934
   DeviceName /dev/ttyUSB0@38400
   FD         11
   FHTID      2934
   FUUID      5de94123-f33f-4d6e-52ea-e245585317d4d74e
   NAME       cul_TSCULF_LAPTOP
   NR         73
   PARTIAL   
   RAWMSG     A0F428610610C0B0000000A50B40C0040::-68.5:cul_TSCULF_LAPTOP:
   RSSI       -68.5
   STATE      Initialized
   TYPE       TSCUL
   VERSION    VTS 0.32 CSM868
   VERSION_HW nanoCUL_V1.x
   VERSION_TS yes AES ChTblSize:209
   XmitOpen   1
   assignUpdCntI 7
   assignedIDsCnt 2
   cul_TSCULF_LAPTOP_MSGCNT 9
   cul_TSCULF_LAPTOP_TIME 2019-12-05 20:03:50
   initString AP<
X21
Ar
AM5
AH121212
   msgLoadCurrent 70
   owner_CCU  VCCU_LT
   MatchList:
     1:STACKABLETS ^\*
     2:STACKABLE ^\*
     A:CUL_HM   ^A....................
     B:CUL_IR   ^I............
     C:HMS      ^810e04......a001
   READINGS:
     2019-12-05 19:59:47   Xmit-Events     disconnected:1 init:1 ok:1 non-HM:1
     2019-12-05 19:59:45   cmds             A B C E F G J K M R U V W X Y Z e i l m t u x
     2019-12-05 19:59:47   cond            ok
     2019-12-05 19:59:40   prot_disconnected last
     2019-12-05 19:59:46   prot_init       last
     2019-12-05 19:59:46   prot_non-HM     last
     2019-12-05 19:59:47   prot_ok         last
     2019-12-05 19:42:45   scF             0.999948700920772
     2019-12-05 19:59:46   state           Initialized
   helper:
     CUrun      1
     ChkPart    0
     RA_Timeout 0
     SVTS       1
     VTS        1
     VTS_ACK    1
     VTS_AES    1
     assIdCnt   2
     assIdRep   2
     nRec       0
     recAlive   1
     recd       1
     DEVIO:
       RXfailTO   
     HM:
       ChTblSize  209
       FUP        0
       HMactive   1
       hmCrdts    7
       hmSbusy    0
       ChTbl:
         29553A3F   00
         3567393F   00
       msgCNT:
         0x01       9
         0x02       12
         0x03       25
         0x09       8
       unknwn:
         3567CF:
           lstRecType 10
           nextSend   1575572591.91019
           nxtSndMcnt 63
           tgtDly     88
           lRcTm:
             cul_TSCULF_LAPTOP 209968
             tnms       393336023
         3571F1:
           lstRecType 10
           nextSend   1575572600.56534
           nxtSndMcnt BF
           tgtDly     88
           lRcTm:
             cul_TSCULF_LAPTOP 218624
             tnms       393344671
         610BA6:
           lstRecType 10
           nextSend   1575572589.35021
           nxtSndMcnt 6A
           tgtDly     88
           lRcTm:
             cul_TSCULF_LAPTOP 207408
             tnms       393333454
         610C0B:
           lstRecType 10
           nextSend   1575572630.63298
           nxtSndMcnt 42
           tgtDly     88
           lRcTm:
             cul_TSCULF_LAPTOP 248696
             tnms       393374737
         610CF8:
           lstRecType 10
           nextSend   1575572533.08623
           nxtSndMcnt 9A
           tgtDly     88
           lRcTm:
             cul_TSCULF_LAPTOP 151136
             tnms       393277190
     cnd:
       0          1
       250        1
       253        1
       255        1
     hmLogHist:
        117454 A F701 00207408 00 0F 6A 8610 610BA6 000000 0A4CCD0C0000 -56.5dB
        120023 A F701 00209968 00 0F 63 8610 3567CF 000000 0A5CCC0A0040 -81dB
        121216 A F702 00211172 00 34 AA00112200000098AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
        127822 A F702 00217772 00 34 AA00112200000097AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
        128671 A F701 00218624 00 0F BF 8610 3571F1 000000 0A98C80B0240 -84.5dB
        140574 A F702 00230520 00 34 AA00112200000096AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
        153420 A F702 00243372 00 34 AA00112200000095AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
        155192                 As 0F 01 943F 121212 000000 0202257C1112
        155577 A F703 00245168 01 0F 01 943F 121212 000000 0202257C1112 _bst _CCAdly:4
        158737 A F701 00248696 00 0F 42 8610 610C0B 000000 0A50B40C0040 -68.5dB
        167241 A F702 00257200 00 34 AA00112200000094AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
        180596 A F702 00270556 00 34 AA00112200000093AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
        185652 A F702 00275608 00 01 CC _ping
        188226 A F702 00278180 00 34 AA00112200000092AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
     hmQ:
       000000:
       29553A:
     ids:
       29553A:
         cfg        +29553A,00,00,00
         name       HM_29553A_Switch
       356739:
         cfg        +356739,02,00,00
         name       HM_356739_Kueche
     loadLvl:
       bl         40
     q:
       ATrNo      0
       HMcndN     0
       InQueues   0
       RQLSt      0
       RQLt       0
       XRpCnt     0
       XRpTm      1575572387.23254
       answerPend 0
       hmLanQlen  1
       apIDs:
         29553A     0
     ref:
       Sdly       4
       TmBmCnt    1
       ioBR       3840
       ioBRMax    3744.89987338411
       ioBRMean   3351.40756691468
       ioBRMeas   3100.35852928057
       ioBRn      92
       ioBRnC     8
       ioBRptm    1575572659.99143
       ioBRs      26811.2605353174
       lHMt       248696
       lSys       393374737
       pTTu       1024
       pndAs      0
       pndCUAp    0
       pngLm      23
       pngMax     15
       pngMaxTot  15
       pngMin     12
       pngRef     15
       pngtm      393135934
       scF        0.999948700920772
       scFN       0
       scHT       9868
       scST       393135949
Attributes:
   comment    set cul_update_hm hmPairSerial OEQ1248979

https://forum.fhem.de/index.php?topic=65222.0


wz rechts set cul_TSCULF_LAPTOP hmPairSerial OEQ1248681
kueche set cul_TSCULF_LAPTOP hmPairSerial LTK0135825
LTK0135825
   hmId       121212
   model      nanoCUL
   rfmode     HomeMatic
   room       nanocul,CUL_HM
   verbose    5





und ein device:

Internals:
   DEF        356739
   FUUID      5de942be-f33f-4d6e-a4c6-4390b5617083f4d1
   IODev      cul_TSCULF_LAPTOP
   NAME       HM_356739_Kueche
   NOTIFYDEV  global
   NR         74
   NTFY_ORDER 50-HM_356739_Kueche
   STATE      CMDs_pending
   TYPE       CUL_HM
   channel_01 HM_356739_Weather
   channel_02 HM_356739_Climate
   channel_03 HM_356739_WindowRec
   channel_04 HM_356739_Clima_Kueche
   channel_05 HM_356739_ClimaTeam
   channel_06 HM_356739_remote
   protCmdPend 5 CMDs_pending
   protState  CMDs_pending
   READINGS:
     2019-12-05 19:59:47   Activity        unknown
     2019-12-05 18:47:42   D-firmware      1.4
     2019-12-05 18:47:42   D-serialNr      LTK0135825
     2019-12-05 18:47:42   R-pairCentral   set_0x121212
     2019-12-05 20:02:46   state           CMDs_pending
   cmdStack:
     ++A011121212356739860414
     ++A011121212356739860414
     ++803F1212123567390204257C02C1
     ++A01112121235673986041F
     ++A01112121235673986041F
   helper:
     HM_CMDNR   39
     mId        0095
     regLst     ,0
     rxType     140
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +356739,02,00,00
       restoredIO cul_TSCULF_LAPTOP
       rxt        2
       vccu       VCCU_LT
       p:
         356739
         00
         00
         00
       prefIO:
         cul_TSCULF_LAPTOP
     mRssi:
       mNo       
       io:
         cul_TSCULF_LAPTOP:
           100
           100
     prt:
       bErr       0
       sProc      2
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       prs        1
     shRegW:
       07         04
     tmpl:
Attributes:
   IODev      cul_TSCULF_LAPTOP
   IOgrp      VCCU_LT:cul_TSCULF_LAPTOP
   actCycle   000:10
   actStatus  unknown
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.4
   model      HM-CC-RT-DN
   room       CUL_HM
   serialNr   LTK0135825
   subType    thermostat
   webCmd     getConfig:clear msgEvents:burstXmit





danke für die Hilfe.

VG T
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: OiledAmoeba am 05 Dezember 2019, 21:18:59
Lass dem CUL ein bisschen Zeit. Das Sendeprotokoll sieht nur recht wenig Sendezeit pro Stunde vor. Pending bedeutet im allgemeinen, dass er entweder wartet, bis sich das Device wieder meldet, damit er sein Kommando als Antwort senden kann, oder dass die Sendezeit knapp ist.
Gerade wenn man bei einer Neueinrichtung viel zu senden hat (oft schickt man ja ein getConfig ab, das frisst unglaublich viel Sendezeit!).
Mit get <iodevice> credit10ms bekommst du heraus, wie voll der Puffer ist.
Im Wiki gibt es dazu einen guten Artikel, wie das mit dem Sendepuffer und der Sendezeit aussieht.
Die meisten Probleme mit Pending lösen sich nach ner Zeit von selbst.
Hellhörig solltest du erst werden, wenn da ein MISSING_ACK auftaucht.

Gesendet von meinem VOG-L29 mit Tapatalk

Edit: mit list <iodevice> bekommst du angezeigt, was da noch auf Übertragung wartet.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: noansi am 05 Dezember 2019, 21:53:27
Hallo riker1.

zu Deinem device ist das pairing nicht durchgelaufen.

Zitat2019-12-05 18:47:42   R-pairCentral   set_0x121212

Einen Empfangs-RSSI kann ich am device nicht sehen. Eventuell hast Du Empfangsprobleme, falls die Lists nicht gerade nach einem Neustart entstanden sind.
Mit set hmFreqOffs kannst Du die Sende-/Empfangsfrequenz des CUL für HM ggf. noch etwas nachtunen (kam hier schon vor, dass nanos zu sehr daneben lagen).
Mit get ccconf kannst Du den aktuell genutzten Frequenzoffset anzeigen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: riker1 am 06 Dezember 2019, 07:19:35
Zitat von: noansi am 05 Dezember 2019, 21:53:27
Hallo riker1.

zu Deinem device ist das pairing nicht durchgelaufen.

Einen Empfangs-RSSI kann ich am device nicht sehen. Eventuell hast Du Empfangsprobleme, falls die Lists nicht gerade nach einem Neustart entstanden sind.
Mit set hmFreqOffs kannst Du die Sende-/Empfangsfrequenz des CUL für HM ggf. noch etwas nachtunen (kam hier schon vor, dass nanos zu sehr daneben lagen).
Mit get ccconf kannst Du den aktuell genutzten Frequenzoffset anzeigen.

Gruß, Ansgar.

Danke Ansgar,

merkwürdig Fehlermeldung beim Anpassen der FreqOffset: This command is not valid in the current rfmode

RFMode ist Homematic.

Mache ich was falsch ? Danke thomas
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: riker1 am 06 Dezember 2019, 08:27:54
Zitat von: noansi am 05 Dezember 2019, 21:53:27
Hallo riker1.

zu Deinem device ist das pairing nicht durchgelaufen.

Einen Empfangs-RSSI kann ich am device nicht sehen. Eventuell hast Du Empfangsprobleme, falls die Lists nicht gerade nach einem Neustart entstanden sind.
Mit set hmFreqOffs kannst Du die Sende-/Empfangsfrequenz des CUL für HM ggf. noch etwas nachtunen (kam hier schon vor, dass nanos zu sehr daneben lagen).
Mit get ccconf kannst Du den aktuell genutzten Frequenzoffset anzeigen.

Gruß, Ansgar.

Hallo,

stimmt, es war auch kein Sende-Icon im Thermostat.

wahrscheinlich waren die credts leer....viel probiert.

Mal ne Frage wegen dem Timing.

Wie lange dauert das senden an ein Thermostat? es dauert schon lange bei mir .
Der HM switch schaltet sofort.


Danke Thomas

Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: riker1 am 06 Dezember 2019, 08:31:43
Hallo

hätte ne Frage zur Umstellung.

Habe im aktuellem Fhem eine VCCU mit 3 nanoCul normal.

Nun am Testsystem mal eine VCCU mit TSCUL.


In welcher Reihenfolge stelle ich am Besten um?

Muss ja alles devices neu anlernen und die entsprechenden TSCULS erstellen?


Ich dachte.
- anlegen neuer TSCUL
- Anlegen neue VCCU_TS
- Zuordnen TSCUL zu VCCU_TS
- dann alles Geräte neu anlernen
- dann andere CULS umflashen, neu anlegen und zu VCCU_TS zuordnen


Macht das so Sinn?

Danke für die Hilfe


Danke Thomas



PS. ganz vergessen:
Wenn ich die neuen erforderlichen fhem Module einspiele, kann ich dann das alte CUL noch betreiben?
Dies müsste ja die erste Aktion sein, oder?


Gibt es eine Möglichkeit die alten Devices, paired mit den VCCU CUL wieder zu verwenden mit den neu angelernten Devices am TSCUL?  Dort werden dann doch sicher neue Devices erkannt.....

Ist mir irgendwie nicht ganz klar.

Danke
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: MadMax-FHEM am 06 Dezember 2019, 09:41:22
Zitat von: riker1 am 06 Dezember 2019, 08:27:54
Mal ne Frage wegen dem Timing.

Wie lange dauert das senden an ein Thermostat? es dauert schon lange bei mir .
Der HM switch schaltet sofort.


Danke Thomas

Das Senden selbst dauert gleich lang ;)

Allerdings ist der HM-Switch (vermutlich) am Strom und daher "dauerwach"...
...das HM-Thermostat ist ein Batteriegerät und daher nur "manchmal wach"...

D.h. das Senden wird erst dann ausgeführt, wenn das Gerät mal wieder wach ist (so ca. alle 3min).

Außer du aktivierst "burst", dann reagiert auch der sofort.
Geht aber auf die Batterielebensdauer...

Beim Übertragen von nicht nur "Schaltkommandos" sondern z.B. Temp-Profilen (oder Registern etc.) können auch schon mal mehrere 3min-Zyklen nötig sein...

EDIT: daher heißt es oft (und mache ich auch so) ab und an mal das "Knöpfchen drücken", dadurch wird er aufgeweckt und man muss beim Übertragen von mehreren Daten (Temp-Profil oder beim Anlernen: Register etc.) nicht so lange warten...

Gruß, Joachim
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: riker1 am 06 Dezember 2019, 10:11:47
Danke Joachim,
werde ich dann mal beobachten
vg Thomas
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: noansi am 06 Dezember 2019, 20:20:33
Hallo Thomas,

ZitatThis command is not valid in the current rfmode
set hmFreqOffs
und nicht set FreqOffs

Zitathätte ne Frage zur Umstellung.
Was willst Du denn umstellen? Willst Du alle Geräte am Testsystem anlernen? Oder willst Du Dein Hauptsystem umstellen?


Wenn Du Dein Hauptsystem umstellen möchtest, dann hast Du es prinzipiell mit der schon bestehenden VCCU einfach, da nur die IOs, sprich CULs umgestellt werden müssen.
Backup vom Hauptsystem erstellen.
Die CULs alle auf tsculfw flashen und am Hauptsystem anschließen, wie gehabt.
Die FHEM Dateien austauschen.
In der fhem.cfg alle CUL Definitionen in TSCUL Definitionen umändern (CUL Device Namen beibehalten!). Wichtig, die TSCULs müssen alle vor der VCCU definiert sein.
FHEM mit der geänderten Konfiguration neu starten.
Es muss nicht neu angelernt werden, da die HM-Devices bereits angemeldet sein sollten (sofern das natürlich mal in der Vergangenheit erfolgreich erfolgt ist).

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: riker1 am 07 Dezember 2019, 08:16:08
Hallo Ansgar,

ja das Hauptsystem soll umgestellt werden.

Ok danke. werde das mal angehen. Danke

Thomas
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: riker1 am 07 Dezember 2019, 11:24:53
Hallo Ansgar,

noch  eine Frage.

habe noch normale CUL mit RF Mode: SLOWRF.

Die muss ich dann auch umflaschen und mit RF Mode SLOWRF freq 433 normal betreiben?

oder?

Danke Thomas

Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: riker1 am 07 Dezember 2019, 13:25:57
Hallo Ansgar,

nach der Umstellung hatte ich einige

HM_4A2F49: unknown attribute .mId. Type 'attr HM_4A2F49 ?' for a detailed list.
HM_4A3089: unknown attribute .mId. Type 'attr HM_4A3089 ?' for a detailed list.
HM_4A302A: unknown attribute .mId. Type 'attr HM_4A302A ?' for a detailed list.
HM_4A29EE: unknown attribute .mId. Type 'attr HM_4A29EE ?' for a detailed list.


bin mir nicht sicher ob das so ok ist?

Danke

Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: noansi am 07 Dezember 2019, 14:44:29
Hallo Thomas,

Zitathabe noch normale CUL mit RF Mode: SLOWRF.

Die muss ich dann auch umflaschen und mit RF Mode SLOWRF freq 433 normal betreiben?

Nein, aber Du darfst sie dann auch nicht zu TSCUL umdefinieren. Dann läuft SlowRf wie gehabt.
Was empfängst/sendest Du mit diesen CULs.

ZitatHM_4A2F49: unknown attribute .mId. Type 'attr HM_4A2F49 ?' for a detailed list.
Das attribut kenne ich nicht. Vermutlich Weiterentwicklungen von Martin, was somit bei meiner älteren 10_CUL_HM.pm auffällt.
Funktioniert denn alle HM Devices?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: riker1 am 07 Dezember 2019, 15:58:51
Hallo Ansgar,


ja die meisten funktionieren.

Danke für die Hilfe.


habe einen hartnäckigen Fall

2019-12-07_12:58:00 HM_4A2C9A off
2019-12-07_12:58:01 HM_4A2C9A on
2019-12-07_12:58:40 HM_4A2C9A ResndFail
2019-12-07_12:58:40 HM_4A2C9A RESPONSE TIMEOUT:RegisterRead
2019-12-07_13:01:16 HM_4A2C9A ResndFail
2019-12-07_13:01:16 HM_4A2C9A MISSING ACK
2019-12-07_13:07:27 HM_4A2C9A ResndFail



aber auc bei anderen öfters:
xxx RESPONSE TIMEOUT:RegisterRead

wahrscheinlich wurde aktuell zu viel gefunkt.

Aktuell sind die credits10ms gut > 2700.

Gibt es das mit dem TIMEOUT öfters?

Danke LG Thomas
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: noansi am 07 Dezember 2019, 16:23:50
Hallo Thomas,

Zitathabe einen hartnäckigen Fall
Zitataber auc bei anderen öfters:

Lists für die Glaskugel?!
Eventuell das schon erwähnte hmFreqOffs Problem, wenn der RSSI schlecht ist, obwohl der Abstand nicht schlecht ist.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: riker1 am 08 Dezember 2019, 08:11:38
Hallo Ansgar,

hier Licht für die Glaskugel, sorry....


Der Switch ist eigentlich direkt neben dem TSCUL...zu nah dran? gibt es sowas?

nternals:
   DEF        4A2C9A
   FUUID      5c633177-f33f-74bb-aed7-fecd09904ab55dc6
   IODev      cul_wohn_ser2net_rpi
   LASTInputDev cul_rpi_91_ser2net_lan
   MSGCNT     15
   NAME       HM_4A2C9A
   NOTIFYDEV  global
   NR         1097
   NTFY_ORDER 50-HM_4A2C9A
   STATE      MISSING ACK
   TYPE       CUL_HM
   cul_rpi_91_ser2net_lan_MSGCNT 15
   cul_rpi_91_ser2net_lan_RAWMSG A0D03A4104A2C9AAABBCC0601C800::-63:cul_rpi_91_ser2net_lan:
   cul_rpi_91_ser2net_lan_RSSI -63
   cul_rpi_91_ser2net_lan_TIME 2019-12-07 12:58:28
   lastMsg    No:03 - t:10 s:4A2C9A d:AABBCC 0601C800
   protCmdDel 42
   protLastRcv 2019-12-07 12:58:01
   protRcv    5 last_at:2019-12-07 12:58:01
   protResnd  96 last_at:2019-12-08 08:09:15
   protResndFail 32 last_at:2019-12-08 08:09:21
   protSnd    43 last_at:2019-12-08 08:09:01
   protState  CMDs_done_Errors:1
   rssi_at_cul_rpi_91_ser2net_lan cnt:15 min:-73.5 max:-63 avg:-66.93 lst:-63
   READINGS:
     2019-07-10 09:03:12   CommandAccepted yes
     2019-12-07 12:54:58   D-firmware      2.4
     2019-12-07 12:54:58   D-serialNr      NEQ0180560
     2019-12-07 13:06:33   RegL_00.       
     2019-12-07 12:58:01   deviceMsg       on (to VCCU)
     2019-12-07 12:58:01   level           100
     2019-12-07 12:58:01   pct             100
     2019-12-07 12:57:20   powerOn         2019-12-07 12:57:20
     2019-12-07 12:58:01   recentStateType info
     2019-12-08 08:09:21   statStateDay    MISSING_ACK: 08:09:23 MISSING_ACK_Count: 4 ResndFail: 00:00:00 ResndFail_Count: 3
     2019-12-07 23:59:58   statStateDayLast MISSING_ACK: 12:00:58 MISSING_ACK_Count: 27 RESPONSE_TIMEOUT:RegisterRead: 00:13:36 RESPONSE_TIMEOUT:RegisterRead_Count: 2 ResndFail: 00:00:01 ResndFail_Count: 29 off: 00:00:01 off_Count: 1 on: 11:24:38 on_Count: 11 unreachable: 00:20:33 unreachable_Count: 4
     2019-12-08 08:09:21   statStateMonth  MISSING_ACK: 20:10:21 MISSING_ACK_Count: 30 RESPONSE_TIMEOUT:RegisterRead: 00:13:36 RESPONSE_TIMEOUT:RegisterRead_Count: 2 ResndFail: 00:00:01 ResndFail_Count: 32 off: 00:00:01 off_Count: 1 on: 6d 11:24:53 on_Count: 11 unreachable: 00:20:33 unreachable_Count: 4
     2019-11-30 23:59:56   statStateMonthLast on: 29d 23:59:48 on_Count: 1
     2019-12-08 08:09:21   statStateYear   MISSING_ACK: 20:10:21 MISSING_ACK_Count: 30 RESPONSE_TIMEOUT:RegisterRead: 00:13:36 RESPONSE_TIMEOUT:RegisterRead_Count: 2 ResndFail: 00:00:01 ResndFail_Count: 32 off: 00:15:24 off_Count: 5 on: 340d 11:09:30 on_Count: 15 set_toggle: 00:00:01 set_toggle_Count: 2 unreachable: 00:20:33 unreachable_Count: 4
     2018-12-31 23:59:55   statStateYearLast IOerr: 00:00:19 IOerr_Count: 1 MISSING_ACK: 01:50:44 MISSING_ACK_Count: 2 ResndFail: 00:00:00 ResndFail_Count: 2 off: 00:01:06 off_Count: 4 on: 69d 02:05:52 on_Count: 5 (since: 2018-10-23_21:01:54)
     2019-12-08 08:09:21   state           MISSING ACK
     2019-12-07 12:58:01   timedOn         off
   helper:
     HM_CMDNR   15
     PONtest    0
     _98_statistics myStatDevice
     cSnd       01AABBCC4A2C9A010E,01AABBCC4A2C9A010E
     dlvl       C8
     dlvlCmd    ++A011AABBCC4A2C9A0201C80000
     getCfgList all
     getCfgListNo ,3
     mId        00A1
     regLst     ,0,1,3p
     rxType     1
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       lstRecType 10
       newChn     +4A2C9A,00,00,00
       nextSend   1575719908.66387
       nxtSndMcnt 03
       rxt        0
       tgtDly     88
       vccu       VCCU
       lRcTm:
         cul_rpi_91_ser2net_lan 7080432
         tnms       540652824
       p:
         4A2C9A
         00
         00
         00
       prefIO:
         cul_wohn_ser2net_rpi
     mRssi:
       mNo        03
       io:
         cul_LAPTOP_ser2net:
         cul_rpi_91_ser2net_lan:
           -63
           -63
         cul_rpi_remote_ser2net:
         cul_rpi_remote_ser2net_lan:
         cul_wohn_ser2net_rpi:
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       prs        1
     rpt:
       IO         cul_rpi_91_ser2net_lan
       flg        A
       ts         1575719908.67208
       ack:
         HASH(0x55db19b8d7b0)
         038002AABBCC4A2C9A00
     rssi:
       at_cul_rpi_91_ser2net_lan:
         avg        -66.9333333333333
         cnt        15
         lst        -63
         max        -63
         min        -73.5
     tmpl:
Attributes:
   IODev      cul_wohn_ser2net_rpi
   IOgrp      VCCU:cul_wohn_ser2net_rpi
   alias      Z59_99_ACHTUNG_REMOTE_NICHT SCHALTEN_HM_SW_OSMC_Remote_HM_4A2C9A_NEQ0180560
   autoReadReg 4_reqStatus
   event-on-change-reading state
   expert     2_raw
   firmware   2.4
   model      HM-LC-SW1-PL2
   peerIDs    00000000,
   room       0_test,3_OSMC,CUL_HM
   serialNr   NEQ0180560
   subType    switch
   webCmd     statusRequest:toggle:on:off
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: noansi am 08 Dezember 2019, 11:14:46
Hallo Thomas,

Zitathier Licht für die Glaskugel, sorry....
Hast Du auch den Plural in Lists bemerkt? Deine CULs auch...

Das Funkeln verrät:

Zitatrssi_at_cul_rpi_91_ser2net_lan cnt:15 min:-73.5 max:-63 avg:-66.93 lst:-63
ZitatmRssi:
       mNo        03
       io:
         cul_LAPTOP_ser2net:
         cul_rpi_91_ser2net_lan:
           -63
           -63
         cul_rpi_remote_ser2net:
         cul_rpi_remote_ser2net_lan:
         cul_wohn_ser2net_rpi:
Empfangen wird etwas ausschließlich vom cul_rpi_91_ser2net_lan.
Mit
ZitatIOgrp      VCCU:cul_wohn_ser2net_rpi
Hast Du Dir wohl etwas anderes vorgestellt.

ser2net Anbinung darf nicht zu hohen Kommunuikationsverzögerungen zum CUL führen. Kann auch ein Problem sein, da Timing bei Antworten der Zentrale zum Device weiterhin eine Rolle spielt.

ZitatDer Switch ist eigentlich direkt neben dem TSCUL...zu nah dran? gibt es sowas?
Ja! 0.5-1m Minimum.
Geräte können sich bei zu geringem Abstand auch einfach stören, z.B. durch ihre Netzteile.

Bezüglich Frequenzoffsetproblematik zeigt dieser Thread https://forum.fhem.de/index.php/topic,91740.0.html (https://forum.fhem.de/index.php/topic,91740.0.html) worum es geht.
Lösungsmöglichkeit z.B. hier: https://forum.fhem.de/index.php/topic,24436.msg964240.html#msg964240 (https://forum.fhem.de/index.php/topic,24436.msg964240.html#msg964240)

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: riker1 am 10 Dezember 2019, 23:09:13
Hallo Ansgar,

eine Frage

habe ein Problem mit dem STATE und state des TSCUL

siehe hier:

Anscheinend ändert das Device seinen Status "STATE", aber aktualisiert das Reading "state" nicht. Deswegen triggert er, aber Du kriegst mit ReadingsTimestamp(...., state) immer den gleichen Wert.

Leider weiss ich nicht genau wie TSCUL funktioniert.


https://forum.fhem.de/index.php/topic,106149.msg1000867.html#msg1000867 (https://forum.fhem.de/index.php/topic,106149.msg1000867.html#msg1000867)


Dies führt dann zu laufendem Triggern des DOIFs.

Was meinst du dazu? Danke Thomas
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: noansi am 12 Dezember 2019, 19:16:16
Hallo Thomas,

das Reading "state" wird von TSCUL teilweise nur gesetzt, ohne ein Event auszulösen.

Dagegen wird die Änderung des Readings "cond" immer von einem Event begleitet.

Es kann die Werte
'ok'
'Warning-HighLoad'
'ERROR-Overload'
'non-HM'
'dummy'
'timeout'
'disconnected'
'Overload-released'
'init'
annehmen.

Da dieses Reading/Event auch von CUL_HM genutzt wird, habe ich unötige und störende Events bei "state" eingespart.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: riker1 am 13 Dezember 2019, 18:15:04
Hallo Ansgar,

danke , verstehe aber nicht warum das DOIF dann trotzdem laufend feuert. Scheinbar reagiert das nicht nur auf state..... Muss mal im DOIF nachforschen.

Danke
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: Crania am 18 Dezember 2019, 18:13:57
Hallo,

ich habe hier TSCUL Vers. 0.32 installiert und am Laufen.
Nun habe ich jede Menge unterschiedlicher Messages im Log, mit RSSI -80dB(m?) ... -90dB(m?).

Z.B.

2019.12.18 17:05:24.460 3: MyCunx: Unknown code A1907A0032D86763987574009ED270CCFBBF1C90AFC894FF231EC::-88.5:MyCunx:, help me!
2019.12.18 17:05:24.579 3: MyCunx: Unknown code A0E0780023987572D867600C5C28FE6::-89.5:MyCunx:, help me!


Sind alle nicht von meinen Devices, ich glaube vom Nachbarn.
Wie kann ich diese Messages im Log unterdrücken?
Möchte aber Level 3 beibehalten.

Gruß
Crania
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: frank am 18 Dezember 2019, 18:56:13
definiere eine vccu.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: Crania am 18 Dezember 2019, 21:09:09
Hallo frank,

vielen Dank für den Hinweis. Werde mich mal mit der VCCU
auseinandersetzen, was sie macht und ob das hier Zielführend ist.

Gruß
Crania
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: mwllgr am 02 Januar 2020, 20:38:53
Hi, gibt's eine Möglichkeit diese Meldungen auszuschalten, ohne das Loglevel auf 0 zu setzen?

Zitat2020.01.02 20:27:32 1: TSCUL_Parse: CUL433 SlowRF receive timeout detected: C_TOR00 01
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: noansi am 03 Januar 2020, 10:24:22
Hallo mwllgr,

ja, im 00_TSCUL.pm in Zeile 805
        Log3 ${$pname}, 1, tsculParseName.${$pname}." SlowRF receive timeout detected: ".${$prmsg};

die 1 auf den Wunschloglevel erhöhen.

Der Log Eintrag soll sagen, das auf SlowRf längere Zeit nichts empfangen wird. Wenn also kein regelmäßiger Sender gültig empfangen werden kann, dann kommt die Meldung.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: mwllgr am 03 Januar 2020, 10:27:57
Okay - dachte es geht vllt. über ein Attribut auch - aber gut, danke.
Muss mit dem CUL nämlich nur senden, da wird normalerweise nichts empfangen.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: noansi am 03 Januar 2020, 10:55:36
Hallo mwllgr,

die Anwendung hatte ich bisher nicht.
Aber in der nächsten Version wird der LogLevel dafür per Attribut einstellbar sein.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: pantau am 04 Januar 2020, 14:31:08
Hallo,

ich habe eine relativ umfangreiche Installation mit mehreren CUL und einem CUNX. Dies versuche ich jetzt nach und nach auf TSCUL umzustellen.
Dabei tritt nun folgendes Problem mit den SlowRF devices auf. Ich habe zuerst den CUNX umgeflasht und mit FHEM zum laufen gebracht (rcul). Dann wurden per autocreate etliche TSCUL_EM und TSCUL_WS devices angelegt. Nun habe ich einen CULv3 mit TSCUL geflasht und in FHEM an TSCUL eingebunden (CUL_0). Nun ist mein Log voll mit diesen Meldungen:
TSCUL_WS CUL_0 UNDEFINED temp/hum sensor detected, code 51
2020.01.04 14:21:15 2: autocreate: define FileLog_TSCUL_WS_51 FileLog ./log/TSCUL_WS_51.log TSCUL_WS_51:T:.*
2020.01.04 14:21:15 2: autocreate: define SVG_TSCUL_WS_51 SVG FileLog_TSCUL_WS_51:temp4hum6:CURRENT
D.h. TSCUL will alle Geräte die mit rcul angelegt werden noch einmal mit CUL_0 erzeugen. Erstens tut er es dann nicht, d.h. der Eintrag IODev bleibt auf rcul und die Meldung taucht immer wierder im Log auf, zweitens halte ich es nicht für sinnvoll bei einem IODev Wechsel alle Geräte neu anzulernen?

Zusätzlich hatte ich ein TSCUL_EM_6 in EM_xxx umbenannt. Das wurde jetzt mit dem neuen IODev wieder neu als TSCUL_EM_6 angelernt. Jetzt habe ich 2x das gleiche Gerät, mit verschiedenem IODev.

Ist das das gewünschte Verhalten, oder habe ich eine Einstellung übersehen?

P.S: Wenn ich das IODev händisch auf das neue CUL ändere ist für das Gerät Ruhe ...

Gruß

Peter
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: noansi am 04 Januar 2020, 16:35:56
Hallo Peter,

doch mal ein SlowRf Nutzer.

ZitatIst das das gewünschte Verhalten, oder habe ich eine Einstellung übersehen?
Ich denke im wesentlichen sagt der Code ja dazu und hängt damit zusammen, dass für die TSCUL_WS, TSCUL_EM, TSCUL_TX (und TSKS300) die Möglichkeit besteht, mehrere dieser Sensoren mit unterschiedlichem IODev zu nutzen und damit bei genügend räumlichem Abstand dem Code mehrfach nutzen zu können (CUL A empfängt nur Sensor A mit Code X und CUL B empfängt nur Sensor B mit ebenfalls Code X).

Mit dem Attribut IODev wird der jeweilige Sensor dann intern individuell per diesem IODev angelegt.

ZitatD.h. TSCUL will alle Geräte die mit rcul angelegt werden noch einmal mit CUL_0 erzeugen.
autocreate will das, nicht TSCUL.
Und eben, weil der jeweilige Sensor dem anderen CUL schon zugeordnet ist und somit der Sensor vom jeweilen TSCUL_XX Modul als "neu" gesehen wird.

ZitatErstens tut er es dann nicht, d.h. der Eintrag IODev bleibt auf rcul
Tut autocreate nicht, weil des den automatisch generierten Namen aus Modulnamen und Code mitbekommt, der aber schon exisitert.

ZitatWenn ich das IODev händisch auf das neue CUL ändere ist für das Gerät Ruhe ...
Das ist derzeit auch die Lösung dazu. Händisch das IODev bei Multiempfängersystem zuordnen.
Bzw. bei bestehender Konfiguration auch diese Sensordevices händisch auf TSCUL_XX in der fhem.cfg umstellen, was den bestehenden Devicenamen erhält. Da autcreate zunächst stört, erst mal abschalten.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: pantau am 04 Januar 2020, 16:56:24
Zitat von: noansi am 04 Januar 2020, 16:35:56

Mit dem Attribut IODev wird der jeweilige Sensor dann intern individuell per diesem IODev angelegt.
autocreate will das, nicht TSCUL.
Und eben, weil der jeweilige Sensor dem anderen CUL schon zugeordnet ist und somit der Sensor vom jeweilen TSCUL_XX Modul als "neu" gesehen wird.

Hm, ich rüste ein bestehendes System um, die Devices und die Multiempfänger gab es schon "immer". Da hat autocreate aber nicht immer zugeschlagen. Da macht TSCUL doch den Unterschied.

Gerade getestet: In der Konfiguration ohne TSCUL kann ich ein CUL "weglassen" (oder es fällt aus oder ich zieh es ab im Betrieb). Dann sehe ich bei LastIODev das der Sensor noch über ein anderes IODev kommt. Sonst ändert sich nichts, kein autocreate im Log.
Mit TSCUL wird dann wieder für das nun empfangende Device ein "endloses" autocreate erzeugt.
Das spricht etwas gegen die mögliche Redundanz durch Multiempfänger und für ein "problem" bei TSCUL?
Getestet habe ich übrigens mit aktueller FHEM (von gestern) und Deinem und dem Original autocreate. Da ist das Verhalten gleich.

Wenn ich autocreate abschalte, habe ich immer noch haufenweise UNDEFINED Einträge im Log - unschön....
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: noansi am 04 Januar 2020, 17:36:37
Hallo Peter,

hast Du eventuell "ignoreTypes" bei autocreate eingestellt, um CUL_WS_xx etc. zu ignorieren?

Das ist zumindest in den TSCUL_XX Modulen noch nicht drin.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: noansi am 04 Januar 2020, 17:53:59
Hallo Peter,

und es gibt noch eine kleine Gemeinheit in fhem.pl.

Dort gibt es (Zeile 2201 in aktueller Version):
    $attr{$hn}{IODev} = $hash->{IODev}{NAME}
      if($hasIODevAttr && $hash->{TYPE} ne "CUL_WS");

Was für CUL_WS verhindert, dass automatisch ein IODev zugewiesen wird.

Das wäre zu ändern in:
    $attr{$hn}{IODev} = $hash->{IODev}{NAME}
      if($hasIODevAttr && $hash->{TYPE} !~ /^(?:CUL_WS|TSCUL_WS|TSCUL_EM|TSCUL_TX|TSCUL_NC7427)$/);

Damit all diese Module nicht automatisch ein IODev zugeordnet bekommen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: pantau am 04 Januar 2020, 17:55:49
Zitat von: noansi am 04 Januar 2020, 17:36:37
Hallo Peter,

hast Du eventuell "ignoreTypes" bei autocreate eingestellt, um CUL_WS_xx etc. zu ignorieren?

Das ist zumindest in den TSCUL_XX Modulen noch nicht drin.

Gruß, Ansgar.
ignoreTypes sieht bei mir so aus
FHT_.*|CUL_FHTTK_.*|FS20.*

Das erklärt es dann wohl nicht?!

Gesendet von meinem SM-N9500 mit Tapatalk

Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: noansi am 04 Januar 2020, 18:06:10
Hallo Peter,

ZitatDas erklärt es dann wohl nicht?!
Aber die automatische Zuordnung eines IODev, siehe oben sollte es erklären.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: pantau am 04 Januar 2020, 22:47:11
Zitat von: noansi am 04 Januar 2020, 18:06:10
Hallo Peter,
Aber die automatische Zuordnung eines IODev, siehe oben sollte es erklären.

Gruß, Ansgar.
Ich baue das morgen mal ein. Momentan stört mich das CUL_EM da nicht behandelt wird. Die werden auch nur mit TSCUL autocreatet. Ich schau mir mal den Code drum rum an.

Gesendet von meinem SM-N9500 mit Tapatalk

Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: noansi am 04 Januar 2020, 23:31:12
Hallo Peter,

ich habe hier https://forum.fhem.de/index.php/topic,107032.msg1008792.html#msg1008792 (https://forum.fhem.de/index.php/topic,107032.msg1008792.html#msg1008792) mal bei Rudolf angefragt, ob er diese spezielle CUL_WS Behandlung mal generischer implementieren möchte.
Dann könnte ich so eine generische Anpassung einfach in meinen Modulen ergänzen. Und auch andere Module anderer Entwickler könnten es nutzen.

Ein eigenes fhem.pl werde ich nicht hier rein packen. Sprich, wenn Rudolf nicht tätig wird, dann musst Du diese kleine händische Änderung in fhem.pl nach jedem FHEM Update neu vornehmen.
Oder eben für jedes SlowRf IO einen eigenes Sensordevice mit passendem IODev Attribut anlegen.

ZitatIch schau mir mal den Code drum rum an.
Ich hab's bei mir in die fhem.pl eingebaut und getestet, dass es das Verhalten abstellt.
Sprich, ein Sensordevice wird angelegt und Ruhe ist dann mit den unbekannten devices und das eine Sensordevice bekommt alle seine Empfangstelegramme von den mehreren Empfängern.

Wenn dann das Atrribut IODev beim Sensordevice definiert wird, dann wird es auch speziell für die Empfangsdaten für das IO. Und das will ich selber auch so haben. Da setzt meine Empfangsstatistik für die IOs drauf auf.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: pantau am 05 Januar 2020, 02:06:31
Hallo Ansgar,
vielen Dank fuer die schnellen und ausfuehrlichen Antworten!

Zitat von: noansi am 04 Januar 2020, 23:31:12
Ich hab's bei mir in die fhem.pl eingebaut und getestet, dass es das Verhalten abstellt.
Sprich, ein Sensordevice wird angelegt und Ruhe ist dann mit den unbekannten devices und das eine Sensordevice bekommt alle seine Empfangstelegramme von den mehreren Empfängern.
Im Prinzip ja, aber
- erst nachdem ich alle schon angelegten TSCUL_* noch mal geloescht habe. (Ich hatte probehalber schon vorher versucht einfach das attr IODEV zu loeschen, das hatte aber keinen Effekt)
- in Internals steht jetzt als IODev bei mir bei allen Devices TS_CUL_RFR_02. Wird da einfach immer das letzte definierte TSCUL eingetragen? (LastInputDev ist unterschiedlich)
- wenn ich ein rename eines Devices mache (z.B. rename TSCUL_EM_6 EM_Pati), dann wird beim naechsten Empfang wieder ein TSCUL_EM_6 angelegt und EM_Pati wird nicht mehr aktualisiert
Den letzten Punkt halte ich fuer "suboptimal". Ist das ein Nebeneffekt der fhem.pl Aenderung? Zumindest hat das Umbenennen noch vor der Aenderung geklappt.... Waere fuer mich ein Killerkriterium, wenn ich Devices nicht umbennen koennte - trotz Deiner ausgezeichneten Default-Namensgebung  ;)

Positiv sehe ich die Verbesserungen an HM und RFR. Der Rest haette einfach so funktionieren duerfen wie vorher. :-\ Kann ich TSCUL_RFR ohne die TSCUL_WS/EM benutzen? Ich sehe hier den Zielkonflikt zwischen Deinem Ansatz (getrennte Empfaenger fuer mehr Sensoren) und meinem Ziel Redundanz im Empfang zu haben. Nach (sehr) kurzem Blick in TSCUL_WS scheint das nicht einfach beides erreichbar zu sein...
Gruss
Peter

Nachtrag: Ein TSCUL_WS konnte ich umbenennen, ebenso ein anderes TSCUL_EM. Beide funktionieren danach weiter und es wird kein "Ersatz" mehr angelegt. Aber das TSCUL_EM_6 ist auch nach wiederholtem Umbennen hartnaeckig.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: noansi am 05 Januar 2020, 03:13:17
Hallo Peter,

Zitat(Ich hatte probehalber schon vorher versucht einfach das attr IODEV zu loeschen, das hatte aber keinen Effekt)
Das Attribut IODev wird eben ohne die Anpassung an fhem.pl wieder neu gesetzt.

ZitatWird da einfach immer das letzte definierte TSCUL eingetragen?
Ja, und ohne die Änderung an fhem.pl eben auch als Attribut gesetzt (in fhem.pl etwas nach obne scrollen...).

Zitatwenn ich ein rename eines Devices mache (z.B. rename TSCUL_EM_6 EM_Pati), dann wird beim naechsten Empfang wieder ein TSCUL_EM_6 angelegt und EM_Pati wird nicht mehr aktualisiert
Und wenn Du es mal in der fhem.cfg umbenennst, statt rename zu nutzen autocreate Leichen löschst und neu startest? (Oder rename, save config und dann Neustart + autocreate Leichen löschen)
Hmm, das scheint mir spontan eher ein Problem mit rename zu sein???

Zitatund meinem Ziel Redundanz im Empfang zu haben.
Genau das sollte nach der Änderung an fhem.pl und richtigem Umbenennen + autocreateleichen löschen eigentlich funktionieren.

Mit EM sollte das vorher mit CUL_EM nichts gewesen sein mit Redundanz.

Statt Dich mit dem autocreate abzumühen, wäre es wohl deutlich schneller, direkt händisch die jeweilgen Sensordevices mit Code anzulegen.

ZitatKann ich TSCUL_RFR ohne die TSCUL_WS/EM benutzen?
Nein, not as is.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: noansi am 05 Januar 2020, 17:33:22
Hallo Peter,

die Diskussion mit Rudolf und einges Code Studium hat doch ergeben, dass ich das IO-AutoAssign in meinen Sensor-Modulen weglassen kann.
Anbei eine neu Zip mit geänderten Modulen.

Damit wird bei bei via autocreate angelegten Sensoren erst mal kein IODev angelegt. Das Sensordevice sammelt dann erst mal alles was rein kommt (Redundanzempfang).

Wenn man das via IODev aufspalten möchte, dann muss man IODev vie Attribut definieren.

Das hat dann aber zur Folge, dass ein neues device angelegt wird, sobal eine message via einem anderen IDDev empfangen wird. D.h. man muss den Weg dann konsequent für alle IODevices gehen. Praktischerweise sagt der automatisch erzeugte devicename auch, über welches IO empfangen wurde.

autocreate "ignoreTypes" support habe ich auch gleich ergänzt.

Gruß, Ansgar.

@mwllgr: Das Attribut "SlowRfRecToLogLev" ist auch in 00_TSCUL.pm drin.

EDIT: verflixt, Anhang löschen hat funktioniert, aber wieder dranhängen will nicht mehr....
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: pantau am 05 Januar 2020, 17:53:45
Zitat von: noansi am 05 Januar 2020, 17:33:22
Anbei eine neu Zip mit geänderten Modulen.

Super, kann aber leider nicht gleich testen, mal sehen wann ich es nächste Woche reinschieben kann. Vielen Dank schon mal.

Bei Autocreate von TSCUL_EM ist mit noch ein Fehler aufgefallen:
Das FileLog wird mit DEF ./log/TSCUL_EM_8.log TSCUL_EM_8:CNT.* angelegt.
Die Regex CNT.* gibt es aber bei Deinen EM Devices nicht mehr (was war denn der Grund die ganzen Readings gegenüber dem "Original" zu ändern???)

P.S: Das rename scheint ein nicht TSCUL bezogenes Problem zu sein, wie Du schon vermutet hast. Wenn ich einen exakten Testcase habe, poste ich das separat.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: noansi am 05 Januar 2020, 18:14:18
Hallo Peter,

ZitatDie Regex CNT.* gibt es aber bei Deinen EM Devices nicht mehr (was war denn der Grund die ganzen Readings gegenüber dem "Original" zu ändern???)
Stimmt. Ist mir auch noch nicht aufgefallen, weil ich autocreate nicht nutze.

Der Grund war, dass es andere Module anders nennen, wenn ich mich recht entsinne.

Gruß, Ansgar.

Edit: anbei eine zip nur mit den geänderten FHEM Modulen und gplot file für TSCUL_EM
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: pantau am 07 Januar 2020, 22:47:07
Zitat von: noansi am 05 Januar 2020, 18:14:18
Edit: anbei eine zip nur mit den geänderten FHEM Modulen und gplot file für TSCUL_EM
Hallo Ansgar,

vielen Dank für das Update. Ich habe es jetzt getestet, läuft soweit, autocreate und SVG erzeugt sinnvolle Defaults.
Nächster Level:
Bei den EM und KS hast Du die kumulierten Werte in den Readings "eingespart". Bei EM nutze ich sowieso den ElectricityCalculator, stört mich also nicht. Ich vermute mal für den KS300 sollte ich dann das Cumulate.pm und SAverage.pm verwenden?
Das schöne am alten KS300 war, das es die avg_* und cum_* Werte als Readings im originalen Device dargestellt hat und sie mir auch nur 1x am Event (24:00 Uhr oder Monatsende) upgedated hat.
Ist das mit Deinem Ansatz irgendwie darstellbar? Ich habe es nur als eigenes Device geschafft, das bei jedem neuen Wert upgedated wird.

Sind dabei die Readings identisch, ob ich TSCUL_WS oder TSKS300 verwende? Ich habe jetzt nur _WS benutzt, da ich es so verstanden habe, das TSKS300 obsolet ist?!

Vielen Dank nochmal!

Peter
P.S: Ich liebe Deinen Hang zu Abkürzungen: ::)
Avg_ks1 AHTS: 3.2 AHT: 3.2 ADT: 3.2 AMT: 3.2 AYT: 3.2 AHHS: 77 AHH: 77 ADH: 77 AMH: 77 AYH: 77 AHWS: 0.1 AHW: 0.1 ADW: 0.1 AMW: 0.1 AYW: 0.1
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: noansi am 08 Januar 2020, 19:31:18
Hallo Peter,

ZitatIch vermute mal für den KS300 sollte ich dann das Cumulate.pm und SAverage.pm verwenden?
Den KS300 solltest Du mit TSCUL_WS einbinden, so ist jedenfalls der Plan.
Für Mittelwertbildung z.B. Temperatur oder Luftfeuchtigkeit ist SAverage gedacht.
Für das Erfassen von Zählwerten wie z.B. Regen oder EM-Zähler ist Cumulate gedacht. Es machte für mich mehr Sinn, diese Funktionen in eigene Module zu packen, als es bei einen speziellen Sensor zu packen, um sie auch für andere devices nutzen zu können.
Würde mich Min/Max interessieren, würde ich das in ein extra Modul packen. Das würde wohl übrigens auch schon mit dem "average" Modul gehen. Das bietet jedoch nicht einen gleitenden Stundenmittelwert.

Das S bei SAverage steht für Sliding. Spricht, die "S" (am Ende) Werte bzw. "_hour_avg" sind gleitende Mittelwerte und werden nur über eine Stunde gleitend erfasst (um den Speicherbedarf dafür in Grenzen zu halten, nur für die Stundenwerte). Sie werden mit jedem neuen Messwert (genau genommen Notify vom Sensordevice) aktualisiert.

Der state wird ebenfalls mit jedem Messwert (genau genommen Notify vom Sensordevice) aktualisiert.

Die "_avg_hour", "_avg_day", "avg_month" und "_avg_year" Werte sind die laufenden (quasi heranwachsenden) Mittelwerte seit dem jeweils letzten Rücksetzen zu jeder Stunde, jedem Tag usw. und werden ebenfalls mit jedem neuen Messwert aktualisiert.
Die "_avg_last_" Werte sind jeweils die letzen Stunden-, Tag-, Monat- und Jahresmittelwerte und werden nur zum Stunden-, Tages-, Monats- und Jahreswechsel aktualisiert (mit dem nächsten eintreffenden Messwert, also nicht sekundengenau).
Sprich, wenn Dich nur die interesieren müsstest Du auch nur für die das Attribut event-on-update-reading einstellen und die Daten entweder in getrennten oder in einem Log sammeln, wie es Dir beliebt.

Bei Cumulate gibt es noch eine Verbindung zu TSCUL_WS und TSCUL_EM. Wenn dort mit z.B. set totalVal oder dem Attribut CounterOffset (durch Setzen in FHEM) der Zählwert auf den aktuell am Gerät eingestellten angepasst wird, dann werden auch die kumulierten Werte mit um den Offset korrigiert.

Die Aktualisierung über ein einziges, beliebiges Notify vom Sensordevice hat den Vorteil, dass nur ein Norify, z.B. state, beim Sensordevice aktiviert sein muss und sollte, damit alle konfigurierten Sensor-Messwerte bei SAverage bzw. Cumulate neu geholt und verarbeitet werden.
Damit lässt sich die Notify-Rechenlast im System erheblich senken. Somit bleibt HM mehr Rechenzeit um rechzeitig Antworten an HM-Devices zu senden.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: riker1 am 11 Januar 2020, 08:43:43
Hallo

hätte eine Frage. Hatte ein HM heiztermostat auf Firmware 1.5 geupgradet.

Nun klappt es aber nicht mehr.

Hatte es neu angelernt sonst geht aber nichts. Es wird eerkannt aber es kommen keine Readings und man kann nichts steuern.



Hier mal ein List. device und cul


Internals:
   CFGFN     
   CMDS       ABCEFGJKMRUVWXYZeilmtux
   Clients    STACKABLETS:STACKABLE:CUL_HM:CUL_IR:HMS
   DEF        /dev/ttyUSB1@38400 3934
   DeviceName /dev/ttyUSB1@38400
   FD         22
   FHTID      3934
   FUUID      5e18da11-f33f-4d6e-b990-ed0347e453ec3f04
   HM_CMDNR   1
   NAME       cul_TSCULF_rpi91
   NR         261
   PARTIAL   
   RAWMSG     A0F908610610C0B0000000A50C80B0000::-76.5:cul_TSCULF_rpi91:
   RSSI       -76.5
   STATE      Initialized
   TYPE       TSCUL
   VERSION    VTS 0.32 CSM868
   VERSION_HW nanoCUL_V1.x
   VERSION_TS yes AES ChTblSize:209
   XmitOpen   1
   assignUpdCntI 2
   assignedIDsCnt 1
   cul_TSCULF_rpi91_MSGCNT 619
   cul_TSCULF_rpi91_TIME 2020-01-11 08:42:31
   initString AP<
X21
Ar
AM5
AHF13934
   msgLoadCurrent 0
   MatchList:
     1:STACKABLETS ^\*
     2:STACKABLE ^\*
     A:CUL_HM   ^A....................
     B:CUL_IR   ^I............
     C:HMS      ^810e04......a001
   READINGS:
     2020-01-10 21:11:55   Xmit-Events     non-HM:1 init:1 disconnected:1 ok:1
     2020-01-10 21:10:46   ccconf          freq:868.300MHz freqOffs:0.000kHz bWidth:325kHz freqIF:203.12kHz rAmpl:42dB sens:12dB dRate:2.467kBit/s
agcPrio:0 agcWait:16 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:0 AGC_FREEZE:0
CCAmode:1 csRelThr:14dB csAbsThr:7dB
     2020-01-10 21:09:57   cmds             A B C E F G J K M R U V W X Y Z e i l m t u x
     2020-01-10 21:11:55   cond            ok
     2020-01-10 21:09:53   prot_disconnected last
     2020-01-10 21:11:55   prot_init       last
     2020-01-10 21:09:59   prot_non-HM     last
     2020-01-10 21:11:55   prot_ok         last
     2020-01-11 08:27:25   scF             0.999923253860879
     2020-01-10 21:09:59   state           Initialized
   helper:
     CUrun      1
     ChkPart    0
     RA_Timeout 0
     SVTS       1
     VTS        1
     VTS_ACK    1
     VTS_AES    1
     assIdCnt   1
     assIdRep   1
     nRec       0
     recAlive   1
     recd       1
     DEVIO:
       RXfailTO   
     HM:
       ChTblSize  209
       FUP        0
       HMactive   1
       hmCrdts    0
       hmSbusy    0
       ChTbl:
         3567393F   00
       msgCNT:
         0x01       619
         0x02       144
         0x03       2
       unknwn:
         1DCC51:
           lstRecType 10
           nextSend   1578691439.12414
           nxtSndMcnt 7F
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 4444524
             tnms       290957760
         2C5AA7:
           lstRecType 10
           nextSend   1578728263.91889
           nxtSndMcnt 9B
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 41272528
             tnms       327782639
         356739:
           lstRecType 00
           nextSend   1578687147.03241
           nxtSndMcnt 01
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 152204
             tnms       286665664
         3567CF:
           lstRecType 10
           nextSend   1578728547.55461
           nxtSndMcnt D5
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 41556180
             tnms       328066275
         3571F1:
           lstRecType 10
           nextSend   1578728449.1617
           nxtSndMcnt DD
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 41457788
             tnms       327967882
         4106C1:
           lstRecType 10
           nextSend   1578728081.80588
           nxtSndMcnt 42
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 41090400
             tnms       327600526
         423774:
           lstRecType 02
           nextSend   1578726827.32269
           nxtSndMcnt B1
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 39835828
             tnms       326346043
         426A9E:
           lstRecType 10
           nextSend   1578693563.61174
           nxtSndMcnt 94
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 6569112
             tnms       293082254
         44BD5B:
           lstRecType 8E
           nextSend   1578688016.21433
           nxtSndMcnt 10
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 1021444
             tnms       287534854
         480AA7:
           lstRecType 10
           nextSend   1578727104.10725
           nxtSndMcnt 2F
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 40112640
             tnms       326622827
         480AB9:
           lstRecType 10
           nextSend   1578727901.76834
           nxtSndMcnt 7D
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 40910356
             tnms       327420488
         497DAC:
           lstRecType 10
           nextSend   1578728001.08528
           nxtSndMcnt CA
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 41009676
             tnms       327519805
         4A29EE:
           lstRecType 02
           nextSend   1578727852.56471
           nxtSndMcnt DC
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 40861152
             tnms       327371285
         4A2F49:
           lstRecType 02
           nextSend   1578726945.61854
           nxtSndMcnt C3
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 39954136
             tnms       326464339
         4A3089:
           lstRecType 10
           nextSend   1578728269.9228
           nxtSndMcnt 2A
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 41278532
             tnms       327788643
         610BA6:
           lstRecType 10
           nextSend   1578728439.82202
           nxtSndMcnt C7
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 41448440
             tnms       327958542
         610C0B:
           lstRecType 10
           nextSend   1578728550.98717
           nxtSndMcnt 90
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 41559612
             tnms       328069707
         610CF8:
           lstRecType 10
           nextSend   1578728414.74066
           nxtSndMcnt B9
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 41423356
             tnms       327933461
         94CDA8:
           lstRecType 8E
           nextSend   1578687232.82544
           nxtSndMcnt 10
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 238000
             tnms       286751457
         AABBCC:
           lstRecType 02
           nextSend   1578728273.56437
           nxtSndMcnt 30
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 41282168
             tnms       327792284
         BBF249:
           lstRecType 8E
           nextSend   1578692539.48579
           nxtSndMcnt 10
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 5544928
             tnms       292058130
     cnd:
       0          1
       250        1
       253        1
       255        1
     hmLogHist:
        103198 A F001 07718660 00 0F 8E 8610 610C0B 000000 0A50C80B0000 -74.5dB
        108643 A F001 07724100 00 0D 2A A410 4A3089 AABBCC 06010000 -59.5dB
        108756 A F001 07724216 00 0A 2A 8002 AABBCC 4A3089 00 -61.5dB
        112155 A F001 07727616 00 0D 30 A410 2E3200 AABBCC 06010000 -65.5dB
        112284 A F001 07727736 00 0A 30 8002 AABBCC 2E3200 00 -62.5dB
        144643 A F001 07760096 00 0F DC 8610 3571F1 000000 0A30DF0B0040 -80dB
        199043 A F002 07814508 00 01 CC _ping
        234766 A F001 07850240 00 0F D4 8610 3567CF 000000 0A94E30A0040 -85.5dB
        253461 A F001 07868924 00 0F B9 8610 610CF8 000000 0A4CCF0A0040 -53.5dB
        253700 A F001 07869172 00 0F 8F 8610 610C0B 000000 0A50C80B0000 -75dB
        278542 A F001 07894008 00 0F C7 8610 610BA6 000000 0A4CD60B0040 -56dB
        287882 A F001 07903356 00 0F DD 8610 3571F1 000000 0A30DF0B0040 -80dB
        386275 A F001 08001748 00 0F D5 8610 3567CF 000000 0A94E30A0040 -88.5dB
        389707 A F001 08005180 00 0F 90 8610 610C0B 000000 0A50C80B0000 -76.5dB
     hmQ:
       000000:
     ids:
       356739:
         cfg        +356739,02,00,00
         name       HM_356739
     loadLvl:
       bl         40
     q:
       ATrNo      0
       HMcndN     0
       InQueues   0
       RQLSt      0
       XRpCnt     0
       XRpTm      1578687115.39341
       answerPend 0
       hmLanQlen  1
     ref:
       Sdly       1015
       TmBmCnt    1
       ioBR       3840
       ioBRMax    3789.05479084003
       ioBRMean   3320.58050669961
       ioBRn      0
       lHMt       39793396
       lSys       326302612
       pTTu       256
       pndAs      0
       pndCUAp    0
       pngFrc     1
       pngLm      11
       pngMax     3
       pngMaxTot  18
       pngMin     3
       pngRef     5
       pngtm      327164188
       scErr      498.873763564974
       scF        0.999923253860879
       scFN       0
       scHT       40654044
       scST       327164193
Attributes:
   comment    cul_TSCULF_rpi91 ccconf => freq:868.300MHz freqOffs:0.000kHz bWidth:325kHz freqIF:203.12kHz rAmpl:42dB sens:12dB dRate:2.467kBit/s
agcPrio:0 agcWait:16 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:0 AGC_FREEZE:0
CCAmode:1 csRelThr:14dB csAbsThr:7dB
   rfmode     HomeMatic
   room       CUL_HM



Internals:
   CFGFN     
   DEF        356739
   FUUID      5e18daab-f33f-4d6e-b427-cf31d337c6502a2b
   IODev      cul_TSCULF_rpi91
   LASTInputDev cul_TSCULF_rpi91
   MSGCNT     1
   NAME       HM_356739
   NOTIFYDEV  global
   NR         280
   STATE      CMDs_pending
   TYPE       CUL_HM
   channel_01 HM_356739_Weather
   channel_02 HM_356739_Climate
   channel_03 HM_356739_WindowRec
   channel_04 HM_356739_Clima
   channel_05 HM_356739_ClimaTeam
   channel_06 HM_356739_remote
   cul_TSCULF_rpi91_MSGCNT 1
   cul_TSCULF_rpi91_RAWMSG A1A0184003567390000001500954C544B303133353832355900FFFF::-29:cul_TSCULF_rpi91:
   cul_TSCULF_rpi91_RSSI -29
   cul_TSCULF_rpi91_TIME 2020-01-10 21:12:27
   lastMsg    No:01 - t:00 s:356739 d:000000 1500954C544B303133353832355900FFFF
   protCmdPend 16 CMDs_pending
   protLastRcv 2020-01-10 21:12:27
   protRcv    1 last_at:2020-01-10 21:12:27
   protState  CMDs_pending
   rssi_at_cul_TSCULF_rpi91 cnt:1 min:-29 max:-29 avg:-29 lst:-29
   READINGS:
     2020-01-10 21:32:32   Activity        dead
     2020-01-10 21:12:27   D-firmware      1.5
     2020-01-10 21:12:27   D-serialNr      LTK0135825
     2020-01-10 21:27:09   state           CMDs_pending
   cmdStack:
     ++A011F13934356739860415
     ++A011F13934356739860415
     ++A001F1393435673900040000000000
     ++A001F139343567390103
     ++A001F1393435673901040000000001
     ++A001F139343567390203
     ++A001F1393435673902040000000001
     ++A001F139343567390303
     ++A001F1393435673903040000000001
     ++A001F139343567390403
     ++A001F1393435673904040000000001
     ++A001F1393435673900040000000007
     ++A001F139343567390503
     ++A001F1393435673905040000000001
     ++A001F139343567390603
     ++A001F1393435673906040000000001
   helper:
     HM_CMDNR   40
     PONtest    1
     mId        0095
     regLst     ,0,1
     rxType     140
     supp_Pair_Rep 1
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +356739,02,00,00
       nextSend   1578687147.10257
       prefIO     
       rxt        2
       vccu       
       p:
         356739
         00
         00
         00
     mRssi:
       mNo        01
       io:
         cul_TSCULF_rpi91:
           -19
           -19
     prt:
       bErr       0
       sProc      2
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
     rssi:
       at_cul_TSCULF_rpi91:
         avg        -29
         cnt        1
         lst        -29
         max        -29
         min        -29
     shRegW:
       07         04
     tmpl:
Attributes:
   actCycle   000:10
   actStatus  dead
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.5
   model      HM-CC-RT-DN
   room       CUL_HM
   serialNr   LTK0135825
   subType    thermostat
   webCmd     getConfig:clear msgEvents:burstXmit





nternals:
   CFGFN     
   DEF        35673904
   FUUID      5e18daab-f33f-4d6e-df65-83697cd6b405e66b
   NAME       HM_356739_Clima
   NOTIFYDEV  global
   NR         285
   STATE      set_desired-temp 10.5
   TYPE       CUL_HM
   chanNo     04
   device     HM_356739
   READINGS:
     2020-01-10 21:26:22   state           set_desired-temp 10.5
   helper:
     getCfgListNo
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     role:
       chn        1
     shRegR:
       07         00
     tmpl:
Attributes:
   model      HM-CC-RT-DN
   room       CUL_HM


Internals:
   CFGFN     
   CMDS       ABCEFGJKMRUVWXYZeilmtux
   Clients    STACKABLETS:STACKABLE:CUL_HM:CUL_IR:HMS
   DEF        /dev/ttyUSB1@38400 3934
   DeviceName /dev/ttyUSB1@38400
   FD         22
   FHTID      3934
   FUUID      5e18da11-f33f-4d6e-b990-ed0347e453ec3f04
   HM_CMDNR   1
   NAME       cul_TSCULF_rpi91
   NR         261
   PARTIAL   
   RAWMSG     A0F908610610C0B0000000A50C80B0000::-76.5:cul_TSCULF_rpi91:
   RSSI       -76.5
   STATE      Initialized
   TYPE       TSCUL
   VERSION    VTS 0.32 CSM868
   VERSION_HW nanoCUL_V1.x
   VERSION_TS yes AES ChTblSize:209
   XmitOpen   1
   assignUpdCntI 2
   assignedIDsCnt 1
   cul_TSCULF_rpi91_MSGCNT 619
   cul_TSCULF_rpi91_TIME 2020-01-11 08:42:31
   initString AP<
X21
Ar
AM5
AHF13934
   msgLoadCurrent 0
   MatchList:
     1:STACKABLETS ^\*
     2:STACKABLE ^\*
     A:CUL_HM   ^A....................
     B:CUL_IR   ^I............
     C:HMS      ^810e04......a001
   READINGS:
     2020-01-10 21:11:55   Xmit-Events     non-HM:1 init:1 disconnected:1 ok:1
     2020-01-10 21:10:46   ccconf          freq:868.300MHz freqOffs:0.000kHz bWidth:325kHz freqIF:203.12kHz rAmpl:42dB sens:12dB dRate:2.467kBit/s
agcPrio:0 agcWait:16 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:0 AGC_FREEZE:0
CCAmode:1 csRelThr:14dB csAbsThr:7dB
     2020-01-10 21:09:57   cmds             A B C E F G J K M R U V W X Y Z e i l m t u x
     2020-01-10 21:11:55   cond            ok
     2020-01-10 21:09:53   prot_disconnected last
     2020-01-10 21:11:55   prot_init       last
     2020-01-10 21:09:59   prot_non-HM     last
     2020-01-10 21:11:55   prot_ok         last
     2020-01-11 08:27:25   scF             0.999923253860879
     2020-01-10 21:09:59   state           Initialized
   helper:
     CUrun      1
     ChkPart    0
     RA_Timeout 0
     SVTS       1
     VTS        1
     VTS_ACK    1
     VTS_AES    1
     assIdCnt   1
     assIdRep   1
     nRec       0
     recAlive   1
     recd       1
     DEVIO:
       RXfailTO   
     HM:
       ChTblSize  209
       FUP        0
       HMactive   1
       hmCrdts    0
       hmSbusy    0
       ChTbl:
         3567393F   00
       msgCNT:
         0x01       619
         0x02       144
         0x03       2
       unknwn:
         1DCC51:
           lstRecType 10
           nextSend   1578691439.12414
           nxtSndMcnt 7F
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 4444524
             tnms       290957760
         2C5AA7:
           lstRecType 10
           nextSend   1578728263.91889
           nxtSndMcnt 9B
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 41272528
             tnms       327782639
         356739:
           lstRecType 00
           nextSend   1578687147.03241
           nxtSndMcnt 01
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 152204
             tnms       286665664
         3567CF:
           lstRecType 10
           nextSend   1578728547.55461
           nxtSndMcnt D5
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 41556180
             tnms       328066275
         3571F1:
           lstRecType 10
           nextSend   1578728449.1617
           nxtSndMcnt DD
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 41457788
             tnms       327967882
         4106C1:
           lstRecType 10
           nextSend   1578728081.80588
           nxtSndMcnt 42
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 41090400
             tnms       327600526
         423774:
           lstRecType 02
           nextSend   1578726827.32269
           nxtSndMcnt B1
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 39835828
             tnms       326346043
         426A9E:
           lstRecType 10
           nextSend   1578693563.61174
           nxtSndMcnt 94
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 6569112
             tnms       293082254
         44BD5B:
           lstRecType 8E
           nextSend   1578688016.21433
           nxtSndMcnt 10
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 1021444
             tnms       287534854
         480AA7:
           lstRecType 10
           nextSend   1578727104.10725
           nxtSndMcnt 2F
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 40112640
             tnms       326622827
         480AB9:
           lstRecType 10
           nextSend   1578727901.76834
           nxtSndMcnt 7D
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 40910356
             tnms       327420488
         497DAC:
           lstRecType 10
           nextSend   1578728001.08528
           nxtSndMcnt CA
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 41009676
             tnms       327519805
         4A29EE:
           lstRecType 02
           nextSend   1578727852.56471
           nxtSndMcnt DC
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 40861152
             tnms       327371285
         4A2F49:
           lstRecType 02
           nextSend   1578726945.61854
           nxtSndMcnt C3
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 39954136
             tnms       326464339
         4A3089:
           lstRecType 10
           nextSend   1578728269.9228
           nxtSndMcnt 2A
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 41278532
             tnms       327788643
         610BA6:
           lstRecType 10
           nextSend   1578728439.82202
           nxtSndMcnt C7
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 41448440
             tnms       327958542
         610C0B:
           lstRecType 10
           nextSend   1578728550.98717
           nxtSndMcnt 90
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 41559612
             tnms       328069707
         610CF8:
           lstRecType 10
           nextSend   1578728414.74066
           nxtSndMcnt B9
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 41423356
             tnms       327933461
         94CDA8:
           lstRecType 8E
           nextSend   1578687232.82544
           nxtSndMcnt 10
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 238000
             tnms       286751457
         AABBCC:
           lstRecType 02
           nextSend   1578728273.56437
           nxtSndMcnt 30
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 41282168
             tnms       327792284
         BBF249:
           lstRecType 8E
           nextSend   1578692539.48579
           nxtSndMcnt 10
           tgtDly     88
           lRcTm:
             cul_TSCULF_rpi91 5544928
             tnms       292058130
     cnd:
       0          1
       250        1
       253        1
       255        1
     hmLogHist:
        103198 A F001 07718660 00 0F 8E 8610 610C0B 000000 0A50C80B0000 -74.5dB
        108643 A F001 07724100 00 0D 2A A410 4A3089 AABBCC 06010000 -59.5dB
        108756 A F001 07724216 00 0A 2A 8002 AABBCC 4A3089 00 -61.5dB
        112155 A F001 07727616 00 0D 30 A410 2E3200 AABBCC 06010000 -65.5dB
        112284 A F001 07727736 00 0A 30 8002 AABBCC 2E3200 00 -62.5dB
        144643 A F001 07760096 00 0F DC 8610 3571F1 000000 0A30DF0B0040 -80dB
        199043 A F002 07814508 00 01 CC _ping
        234766 A F001 07850240 00 0F D4 8610 3567CF 000000 0A94E30A0040 -85.5dB
        253461 A F001 07868924 00 0F B9 8610 610CF8 000000 0A4CCF0A0040 -53.5dB
        253700 A F001 07869172 00 0F 8F 8610 610C0B 000000 0A50C80B0000 -75dB
        278542 A F001 07894008 00 0F C7 8610 610BA6 000000 0A4CD60B0040 -56dB
        287882 A F001 07903356 00 0F DD 8610 3571F1 000000 0A30DF0B0040 -80dB
        386275 A F001 08001748 00 0F D5 8610 3567CF 000000 0A94E30A0040 -88.5dB
        389707 A F001 08005180 00 0F 90 8610 610C0B 000000 0A50C80B0000 -76.5dB
     hmQ:
       000000:
     ids:
       356739:
         cfg        +356739,02,00,00
         name       HM_356739
     loadLvl:
       bl         40
     q:
       ATrNo      0
       HMcndN     0
       InQueues   0
       RQLSt      0
       XRpCnt     0
       XRpTm      1578687115.39341
       answerPend 0
       hmLanQlen  1
     ref:
       Sdly       1015
       TmBmCnt    1
       ioBR       3840
       ioBRMax    3789.05479084003
       ioBRMean   3320.58050669961
       ioBRn      0
       lHMt       39793396
       lSys       326302612
       pTTu       256
       pndAs      0
       pndCUAp    0
       pngFrc     1
       pngLm      11
       pngMax     3
       pngMaxTot  18
       pngMin     3
       pngRef     5
       pngtm      327164188
       scErr      498.873763564974
       scF        0.999923253860879
       scFN       0
       scHT       40654044
       scST       327164193
Attributes:
   comment    cul_TSCULF_rpi91 ccconf => freq:868.300MHz freqOffs:0.000kHz bWidth:325kHz freqIF:203.12kHz rAmpl:42dB sens:12dB dRate:2.467kBit/s
agcPrio:0 agcWait:16 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:0 AGC_FREEZE:0
CCAmode:1 csRelThr:14dB csAbsThr:7dB
   rfmode     HomeMatic
   room       CUL_HM

Danke T
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: noansi am 11 Januar 2020, 10:31:08
Hallo Thomas,

ich sehe kein erfolgreiches Pairing in Deinem List. Auch nicht den Versuch dazu. Das Reading "PairedTo 0xF13934" fehlt bei dem RT vollständig . Dazu gibt es haufenweise Tips und Hinweise im Homematic Forum.


Zitatcul_TSCULF_rpi91_TIME 2020-01-10 21:12:27
Gestern Abend war der letzte Empfang von dem RT.

Ist das Flashen überhaupt erfolgreich durchgelaufen?

Hat der RT noch Saft in den Batterien? Ist er noch im Empfangsbereich Deines IOs?

Außerdem noch seltsam bei Deinem CUL, die ccconf Daten sagen, dass es auf SlowRf läuft, ist aber eventuell veraltet. Mach bitte mal ein neues get ccconf bei dem.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: riker1 am 11 Januar 2020, 12:26:13
Hallo Ansgar,

ich habe auch die Vermutung der der Firmwareupgrade irgendwie nicht vollständig war.
Er zeigt nach dem Reset zwar 1.5 an, sieht auch am Device Display selbst normal aus, aber pairen geht nicht.

PS. rfmode ist umgestellt worden, get cconf war wohl alt, kam ja die Fehlermeldung bei hmPairSerial....  aber trotzdem danke


Batterien sind voll.

habe mehrfach resetet, device gelöscht und neu angelegt.....hängt eigentlich immer ....neues Device wird erkannt, aber dann war es das auch ...

Weiss aber nicht wie ich den Firmware process nochmal starten kann ohne pairing?

Muss mal mehr im Homematic forum lesen.


Danke für die Hilfe.

LG T



Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: riker1 am 11 Januar 2020, 12:44:51
Hallo

eventuell sieht jemand etwas in dem Log .

neues Anlernen:

2020.01.11 12:43:49 2 : CUL_HM Unknown device HM_356739 is now defined
2020.01.11 12:43:49 2 : autocreate: define HM_356739 CUL_HM 356739
2020.01.11 12:43:49 2 : autocreate: define FileLog_HM_356739 FileLog ./log/HM_356739-%Y.log HM_356739
2020-01-11 12:43:49 Global global UNDEFINED HM_356739 CUL_HM 356739
2020-01-11 12:43:49 Global global DEFINED HM_356739
2020-01-11 12:43:49 Global global DEFINED FileLog_HM_356739
2020-01-11 12:43:49 Global global SAVE
2020-01-11 12:43:49 Global global DEFINED HM_356739_Weather
2020-01-11 12:43:49 Global global DEFINED HM_356739_Climate
2020-01-11 12:43:49 Global global DEFINED HM_356739_WindowRec
2020-01-11 12:43:49 Global global DEFINED HM_356739_Clima
2020-01-11 12:43:49 Global global DEFINED HM_356739_ClimaTeam
2020-01-11 12:43:49 Global global DEFINED HM_356739_remote
2020.01.11 12:43:49 3 : Device HM_356739 added to ActionDetector with 000:10 time
2020-01-11 12:43:49 CUL_HM ActionDetector alive:1 dead:1 unkn:0 off:0
2020-01-11 12:43:49 CUL_HM ActionDetector status_HM_356739: alive
2020-01-11 12:43:49 CUL_HM HM_356739 Activity: alive
2020-01-11 12:43:49 CUL_HM HM_356739 D-firmware: 1.5
2020-01-11 12:43:49 CUL_HM HM_356739 D-serialNr: LTK0135825
2020-01-11 12:43:49 CUL_HM HM_29553A_Switch IOerr
2020.01.11 12:43:49 5 : CUL_HM HM_29553A_Switch protEvent:CMDs_done_Errors:1
2020-01-11 12:43:52 TSCUL cul_TSCULF_rpi91 UNKNOWNCODE A0FEF8610610C0B0000000A50D40B0000::-81:cul_TSCULF_rpi91:
2020.01.11 12:43:52 3 : cul_TSCULF_rpi91: Unknown code A0FEF8610610C0B0000000A50D40B0000::-81:cul_TSCULF_rpi91:, help me!
2020-01-11 12:43:54 CUL_HM HM_2E3200 IOerr
2020.01.11 12:43:54 3 : Device HM_356739 added to ActionDetector with 000:10 time
2020-01-11 12:43:54 CUL_HM HM_356739 Activity: alive
2020-01-11 12:43:54 TSCUL cul_TSCULF_rpi91 UNKNOWNCODE A09F0A112AABBCC610C0B::-53.5:cul_TSCULF_rpi91:
2020.01.11 12:43:54 3 : cul_TSCULF_rpi91: Unknown code A09F0A112AABBCC610C0B::-53.5:cul_TSCULF_rpi91:, help me!
2020-01-11 12:43:54 TSCUL cul_TSCULF_rpi91 UNKNOWNCODE A09F0A112AABBCC610C0B::-53.5:cul_TSCULF_rpi91:
2020.01.11 12:43:54 3 : cul_TSCULF_rpi91: Unknown code A09F0A112AABBCC610C0B::-53.5:cul_TSCULF_rpi91:, help me!
2020-01-11 12:43:55 TSCUL cul_TSCULF_rpi91 UNKNOWNCODE A09F0A112AABBCC610C0B::-53.5:cul_TSCULF_rpi91:
2020.01.11 12:43:55 3 : cul_TSCULF_rpi91: Unknown code A09F0A112AABBCC610C0B::-53.5:cul_TSCULF_rpi91:, help me!
Titel: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: RaspiLED am 11 Januar 2020, 12:57:12
Hi,
Sind die A Nachrichten nicht das Thema mit der AES Verschlüsselung? Hast Du evtl. AES aktiviert aber Dein TSCUL nicht bzw. mit falschem Schlüssel?

Gruß Arnd


Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: noansi am 11 Januar 2020, 13:15:03
Hallo Thomas,

Zitatich habe auch die Vermutung der der Firmwareupgrade irgendwie nicht vollständig war.
Was hat das device während/nach dem Update im state angezeigt?
Was sagt das fhem log dazu? Wenn Du verbose 2 aktiv gehabt hast, dann gibt es da log Einträge zu.
Was hat das device nach dem Update im state angezeigt?

Hast Du den set fwUpdate beim deviceverfügbar? Dann kannst Du den wohl nochmal nutzen.

Hier https://forum.fhem.de/index.php/topic,24436.msg853733.html#msg853733 (https://forum.fhem.de/index.php/topic,24436.msg853733.html#msg853733) findest Du auch noch den sourcecode zu einer angepassten Version von Michaels Firmware Update Tool.
Der funktioniert unabhäng von FHEM.

Du musst ggf. den RT händisch in den Bootloader Modus bringen (wie steht in der Firmware Update Paket Datei, wenn Du sie von eq-3 runter lädst), wenn es nicht automatisch via Funk geht.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: riker1 am 11 Januar 2020, 13:18:16
Hi Ansgar,

ok muss ich mal prüfen.

Leider habe ich die alten logs nicht mehr und die alten state informationen.

Hatte das device gelöscht und neu angelernt.....hätte das mal vorher sichern sollen..

danke Thomas

Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: riker1 am 11 Januar 2020, 13:20:32


Hallo

dazu noch ne Frage.

kann ich eventuell am Device selbst erkennen ob der Firmware upgrade nicht korrekt war?

den dem Reset zeigt sie eigentlich sauber 1.5 an....

Danke

Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: noansi am 11 Januar 2020, 13:23:51
Hallo Thomas,

Zitateventuell sieht jemand etwas in dem Log .
Nur autocreate, was aber nicht Pairing bedeutet!

hmPairForSec beim CUL (oder VCCU falls genutzt) setzen.
Dann beim RT Pairing aktivieren (natürlich innerhalb der hmPairForSec Zeit).

Ist auch noch HMIP in der Nähe aktiv?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: noansi am 11 Januar 2020, 13:29:01
Hallo Thomas,

Zitatkann ich eventuell am Device selbst erkennen ob der Firmware upgrade nicht korrekt war?

den dem Reset zeigt sie eigentlich sauber 1.5 an....
Meine Glaskugel sagt dazu gar nichts. Da müsstest Du schon eq-3 fragen.

Hast Du im Log nach Hinweisen geschaut? Wenn alle Blöcke sauber bestätigt übertragen worden sind und nun 1.5 angezeigt werden, dann ist es sehr wahrscheinlich, dass es komplett erfolgreich war (frische Batterien vorrausgesetzt).

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: frank am 11 Januar 2020, 15:41:42
im device vom rt fehlt das attr IODev.
somit wird nichts gesendet.
mit vccu muss zusätzlich auch attr IOgrp existieren.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: riker1 am 11 Januar 2020, 16:10:49
Zitat von: frank am 11 Januar 2020, 15:41:42
im device vom rt fehlt das attr IODev.
somit wird nichts gesendet.
mit vccu muss zusätzlich auch attr IOgrp existieren.

Hallo Frank,

verstehe deine Antwort nicht ganz.

Im Device HM_356739 thermostat


Internals:
IODev
cul_TSCULF_rpi91
LASTInputDev
cul_TSCULF_rpi91


warum das IODev nochmal als Attribut existiert weiß ich sowieso nicht.


Aktuell verwende ich keine VCCU



Danke für die Hilfe
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: riker1 am 11 Januar 2020, 16:16:44
Zitat von: noansi am 11 Januar 2020, 13:23:51
Hallo Thomas,
Nur autocreate, was aber nicht Pairing bedeutet!

hmPairForSec beim CUL (oder VCCU falls genutzt) setzen.
Dann beim RT Pairing aktivieren (natürlich innerhalb der hmPairForSec Zeit).

Ist auch noch HMIP in der Nähe aktiv?

Gruß, Ansgar.

Ja, danke, das meinte ich ja. Irgendie sendet das Thermostat ja. sonst würde es ja kein autocreate machen.
Dann beim Pairen mittels hmPairForSec, kommt scheinbar nichts mehr an . Das habe ich zig mal durchgespielt
Meistens mache ich hmPairSerial, mit Sec habe ich nicht so gute Erfahrungen.


Ja noch ein HMIO in der Nähe. Aktuell versuche ich das upgegradete HM - nachdem es vorher am Produciven System mit 1.4 war, dann  nur noch Missing ACK meldete und ich es nicht mehr anlernen konnte - auf dem Testsystem. Ist leider etwas blöd das Productive System kann ich nicht so einfach abschalten.....versuche es mal um zu sehen ob es dann besser ist . Die anderen Devices senden ja aber trotzdem was....


Danke VG T


PS.
kann ich eigentlich ein Device aus den unknown erkennen?
2020.01.11 16:19:00 3 : cul_TSCULF_rpi91: Unknown code A0F8A86103567CF0000000A94E70A0040::-90.5:cul_TSCULF_rpi91:, help me!
2020-01-11 16:19:03 TSCUL cul_TSCULF_rpi91 UNKNOWNCODE A0F6E8610610CF80000000A4CD30A0040::-52.5:cul_TSCULF_rpi91:
2020.01.11 16:19:03 3 : cul_TSCULF_rpi91: Unknown code A0F6E8610610CF80000000A4CD30A0040::-52.5:cul_TSCULF_rpi91:, help me!
2020-01-11 16:19:04 TSCUL cul_TSCULF_rpi91 UNKNOWNCODE A0F9386103571F10000000A30E10B0040::-85:cul_TSCULF_rpi91:
2020.01.11 16:19:04 3 : cul_TSCULF_rpi91: Unknown code A0F9386103571F10000000A30E10B0040::-85:cul_TSCULF_rpi91:, help me!
2020-01-11 16:19:14 Global global ATTR cul_TSCULF_rpi91 comment set cul_TSCULF_rpi91 hmPairForSec 200 set cul_TSCULF_rpi91 hmPairSerial LTK0135825
2020-01-11 16:19:41 TSCUL cul_TSCULF_rpi91 UNKNOWNCODE A0F458610610C0B0000000A50D30B0000::-72.5:cul_TSCULF_rpi91:
2020.01.11 16:19:41 3 : cul_TSCULF_rpi91: Unknown code A0F458610610C0B0000000A50D30B0000::-72.5:cul_TSCULF_rpi91:, help me!


Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: noansi am 11 Januar 2020, 18:26:48
Hallo Thomas,

Zitatkann ich eigentlich ein Device aus den unknown erkennen?
Ab Zeichen 10 stehen 6 Stellen der HMID des devices in diesen unknown messages.

ZitatDann beim Pairen mittels hmPairForSec, kommt scheinbar nichts mehr an . Das habe ich zig mal durchgespielt
Dann verbose 4 beim CUL und Dein Pairing mitloggen.

Edit: und setz mal das Attribut hmId auf F13934 beim CUL. Nicht, dass es daran scheitert.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: riker1 am 12 Januar 2020, 15:08:34
Hallo Ansgar,

nun hat es geklappt.

Habe alles resettet, fhem neugestartet und auf einmal ist das Pairing ok.

verstehen tue ich es nicht. ...

device sieht nun so aus: denke ist ok wkan signal auch im device....

Danke für die viele Hilfe

Internals:
   CFGFN     
   DEF        356739
   FUUID      5e1b26ed-f33f-4d6e-959a-4562b63d6e0270d1
   IODev      cul_TSCULF_LAPTOP
   LASTInputDev cul_TSCULF_LAPTOP
   MSGCNT     10
   NAME       HM_356739
   NOTIFYDEV  global
   NR         64
   STATE      CMDs_pending
   TYPE       CUL_HM
   channel_01 HM_356739_Weather
   channel_02 HM_356739_Climate
   channel_03 HM_356739_WindowRec
   channel_04 HM_356739_Clima
   channel_05 HM_356739_ClimaTeam
   channel_06 HM_356739_remote
   cul_TSCULF_LAPTOP_MSGCNT 10
   cul_TSCULF_LAPTOP_RAWMSG A0F0B86103567390000000A50F5090000::-29.5:cul_TSCULF_LAPTOP:
   cul_TSCULF_LAPTOP_RSSI -29.5
   cul_TSCULF_LAPTOP_TIME 2020-01-12 15:05:04
   lastMsg    No:0B - t:10 s:356739 d:000000 0A50F5090000
   protCmdPend 2 CMDs_pending
   protLastRcv 2020-01-12 15:05:04
   protRcv    10 last_at:2020-01-12 15:05:04
   protSnd    4 last_at:2020-01-12 15:02:52
   protState  CMDs_pending
   rssi_at_cul_TSCULF_LAPTOP cnt:10 min:-82.5 max:-29.5 avg:-69.2 lst:-29.5
   READINGS:
     2020-01-12 15:02:26   Activity        alive
     2020-01-12 15:02:22   CommandAccepted yes
     2020-01-12 15:02:21   D-firmware      1.5
     2020-01-12 15:02:21   D-serialNr      LTK0135825
     2020-01-12 15:02:21   R-pairCentral   set_0x121212
     2020-01-12 15:05:04   actuator        0
     2020-01-12 15:05:04   battery         ok
     2020-01-12 15:05:04   batteryLevel    2.4
     2020-01-12 15:05:04   desired-temp    10.0
     2020-01-12 15:05:04   measured-temp   24.5
     2020-01-12 15:05:04   motorErr        ok
     2020-01-12 15:06:45   state           CMDs_pending
     2020-01-12 15:02:52   time-request    -
   cmdStack:
     ++A01112121235673986040D
     ++A01112121235673986040D
   helper:
     HM_CMDNR   11
     PONtest    1
     cSnd       01121212356739000802010A120B120C12,011212123567390006
     mId        0095
     regLst     ,0,1
     rxType     140
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       lstRecType 10
       newChn     +356739,02,00,00
       nextSend   1578837904.70969
       nxtSndMcnt 0B
       prefIO     
       rxt        2
       tgtDly     88
       vccu       
       lRcTm:
         cul_TSCULF_LAPTOP 488308
         tnms       437423342
       p:
         356739
         00
         00
         00
     mRssi:
       mNo        0B
       io:
         cul_TSCULF_LAPTOP:
           -19.5
           -19.5
     prt:
       bErr       0
       sProc      2
       sleeping   1
       try        1
       rspWait:
     q:
       qReqConf   00
       qReqStat   
     role:
       dev        1
     rssi:
       at_cul_TSCULF_LAPTOP:
         avg        -69.2
         cnt        10
         lst        -29.5
         max        -29.5
         min        -82.5
     shRegW:
       07         04
     shadowReg:
       RegL_00.    02:01 0A:12 0B:12 0C:12
     tmpl:
Attributes:
   IODev      cul_TSCULF_LAPTOP
   IOgrp      VCCU_LT:cul_TSCULF_LAPTOP
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.5
   model      HM-CC-RT-DN
   room       CUL_HM
   serialNr   LTK0135825
   subType    thermostat
   webCmd     getConfig:clear msgEvents:burstXmit



log dazu :

2020.01.12 15:01:39 3 : CUL_HM set VCCU_LT hmPairForSec 200
2020.01.12 15:01:47 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF60200011C08
2020.01.12 15:01:47 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF60200011C08/0034AA00112200000089AA001122AA001122AA001122AAAA001122AA00112
2020.01.12 15:01:47 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF60200011C080034AA00112200000089AA001122AA001122AA001122AAAA001122AA00112/2AA001122AA001122AA001122AA001122AA001122AA001180
2020.01.12 15:01:47 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  493980 A F602 00290848 00 34 AA00112200000089AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2020.01.12 15:01:53 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF6
2020.01.12 15:01:53 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF6/010001225C000FA686103567CF0000000A94DF0A0040E8
2020.01.12 15:01:53 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  500457 A F601 00297328 00 0F A6 8610 3567CF 000000 0A94DF0A0040 -86dB
2020.01.12 15:01:53 5 : cul_TSCULF_LAPTOP: dispatch A0FA686103567CF0000000A94DF0A0040::-86:cul_TSCULF_LAPTOP:
2020.01.12 15:02:00 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF602000128CA
2020.01.12 15:02:00 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF602000128CA/0034AA00112200000088AA001122AA001122AA001122AAAA001122AA00112
2020.01.12 15:02:00 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF602000128CA0034AA00112200000088AA001122AA001122AA001122AAAA001122AA00112/2AA001122AA001122AA001122AA001122AA001122AA001180
2020.01.12 15:02:00 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  507040 A F602 00303912 00 34 AA00112200000088AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2020.01.12 15:02:01 1 : TSCUL_SendPingHM cul_flash fatal: ApC0 timed out! Failsafe release send.
2020.01.12 15:02:09 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF60100013245000FAD86103571
2020.01.12 15:02:09 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF60100013245000FAD86103571/F10000000A30DA0B0040D6
2020.01.12 15:02:09 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  516755 A F601 00313620 00 0F AD 8610 3571F1 000000 0A30DA0B0040 -95dB
2020.01.12 15:02:09 5 : cul_TSCULF_LAPTOP: dispatch A0FAD86103571F10000000A30DA0B0040::-95:cul_TSCULF_LAPTOP:
2020.01.12 15:02:13 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF602000135960034AA00112
2020.01.12 15:02:13 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF602000135960034AA00112/200000087AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA001180
2020.01.12 15:02:13 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  520148 A F602 00317016 00 34 AA00112200000087AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2020.01.12 15:02:21 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF60100013D86001A0184003567390000001500954C
2020.01.12 15:02:21 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF60100013D86001A0184003567390000001500954C/544B303133353832355900FFFFF8
2020.01.12 15:02:21 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  003990 A F601 00325144 00 1A 01 8400 356739 000000 1500954C544B303133353832355900FFFF -78dB
2020.01.12 15:02:21 5 : cul_TSCULF_LAPTOP: dispatch A1A0184003567390000001500954C544B303133353832355900FFFF::-78:cul_TSCULF_LAPTOP:
2020.01.12 15:02:21 2 : CUL_HM Unknown device HM_356739 is now defined
2020.01.12 15:02:21 2 : autocreate: define HM_356739 CUL_HM 356739
2020.01.12 15:02:21 2 : autocreate: define FileLog_HM_356739 FileLog ./log/HM_356739-%Y.log HM_356739
2020-01-12 15:02:21 Global global UNDEFINED HM_356739 CUL_HM 356739
2020-01-12 15:02:21 Global global DEFINED HM_356739
2020-01-12 15:02:21 Global global DEFINED FileLog_HM_356739
2020-01-12 15:02:21 Global global DEFINED HM_356739_Weather
2020-01-12 15:02:21 Global global DEFINED HM_356739_Climate
2020-01-12 15:02:21 Global global DEFINED HM_356739_WindowRec
2020-01-12 15:02:21 Global global DEFINED HM_356739_Clima
2020-01-12 15:02:21 Global global DEFINED HM_356739_ClimaTeam
2020-01-12 15:02:21 Global global DEFINED HM_356739_remote
2020.01.12 15:02:21 3 : Device HM_356739 added to ActionDetector with 000:10 time
2020.01.12 15:02:21 3 : CUL_HM pair: HM_356739 thermostat, model HM-CC-RT-DN serialNr
2020.01.12 15:02:21 5 : TSCUL_Write: cul_TSCULF_LAPTOP sending As1029A00112121235673900050000000000
2020.01.12 15:02:21 4 : TSCUL_send:  cul_TSCULF_LAPTOP  004029                 As 10 29 A001 121212 356739 00050000000000
2020.01.12 15:02:21 4 : TSCUL_XmitDlyHM:  cul_TSCULF_LAPTOP  id:356739 rtoms:2347
2020-01-12 15:02:21 CUL_HM ActionDetector alive:2 dead:0 unkn:0 off:0
2020-01-12 15:02:21 CUL_HM ActionDetector status_HM_356739: alive
2020-01-12 15:02:21 CUL_HM HM_356739 Activity: alive
2020-01-12 15:02:21 CUL_HM HM_356739 D-firmware: 1.5
2020-01-12 15:02:21 CUL_HM HM_356739 D-serialNr: LTK0135825
2020-01-12 15:02:21 CUL_HM HM_356739 CMDs_pending
2020.01.12 15:02:21 5 : TSCUL_Read cul_TSCULF_LAPTOP: /A
2020.01.12 15:02:21 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF60300013D9E011029A0011212123567390005000000000080
2020.01.12 15:02:21 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF60300013D9E011029A0011212123567390005000000000080 /
2020.01.12 15:02:21 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  004123 A F603 00325240 01 10 29 A001 121212 356739 00050000000000 _CCAdly:4
2020.01.12 15:02:21 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF6010
2020.01.12 15:02:21 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF6010/0013DC4000A29800235673912121200F7
2020.01.12 15:02:21 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  004237 A F601 00325392 00 0A 29 8002 356739 121212 00 -78.5dB
2020.01.12 15:02:21 5 : cul_TSCULF_LAPTOP: dispatch A0A29800235673912121200::-78.5:cul_TSCULF_LAPTOP:
2020.01.12 15:02:21 5 : TSCUL_Write: cul_TSCULF_LAPTOP sending As132AA001121212356739000802010A120B120C12
2020.01.12 15:02:21 4 : TSCUL_send:  cul_TSCULF_LAPTOP  004253                 As 13 2A A001 121212 356739 000802010A120B120C12
2020.01.12 15:02:21 4 : TSCUL_XmitDlyHM:  cul_TSCULF_LAPTOP  id:356739 rtoms:2350
2020.01.12 15:02:21 5 : TSCUL_Read cul_TSCULF_LAPTOP: /A
2020.01.12 15:02:21 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF603000
2020.01.12 15:02:21 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF603000/13DDC01132AA001121212356739000802010A120B120C1280
2020.01.12 15:02:21 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  004360 A F603 00325488 01 13 2A A001 121212 356739 000802010A120B120C12 _CCAdly:4 _dhmSt:96
2020.01.12 15:02:21 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF60100013E02000A2A80023567391212
2020.01.12 15:02:21 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF60100013E02000A2A80023567391212/1200F1
2020.01.12 15:02:21 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  004492 A F601 00325640 00 0A 2A 8002 356739 121212 00 -81.5dB
2020.01.12 15:02:21 5 : cul_TSCULF_LAPTOP: dispatch A0A2A800235673912121200::-81.5:cul_TSCULF_LAPTOP:
2020.01.12 15:02:21 5 : TSCUL_Write: cul_TSCULF_LAPTOP sending As0B2BA0011212123567390006
2020.01.12 15:02:21 4 : TSCUL_send:  cul_TSCULF_LAPTOP  004506                 As 0B 2B A001 121212 356739 0006
2020.01.12 15:02:21 4 : TSCUL_XmitDlyHM:  cul_TSCULF_LAPTOP  id:356739 rtoms:2342
2020.01.12 15:02:21 5 : TSCUL_Read cul_TSCULF_LAPTOP: /A
2020.01.12 15:02:22 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF60300013E1A010B2BA001121212356739000680
2020.01.12 15:02:22 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  004604 A F603 00325736 01 0B 2B A001 121212 356739 0006 _CCAdly:4 _dhmSt:96
2020.01.12 15:02:22 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF60100013E40000A2B800235673912121200EF
2020.01.12 15:02:22 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  004732 A F601 00325888 00 0A 2B 8002 356739 121212 00 -82.5dB
2020.01.12 15:02:22 5 : cul_TSCULF_LAPTOP: dispatch A0A2B800235673912121200::-82.5:cul_TSCULF_LAPTOP:
2020-01-12 15:02:22 CUL_HM HM_356739 CMDs_done
2020.01.12 15:02:22 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF60200013E5F0034AA0
2020.01.12 15:02:22 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF60200013E5F0034AA0/0112200000086AA001122AA001122AA001122AAAA001122AA001122AA0011
2020.01.12 15:02:22 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF60200013E5F0034AA00112200000086AA001122AA001122AA001122AAAA001122AA001122AA0011/22AA001122AA001122AA001122AA001122AA001180
2020.01.12 15:02:22 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  004853 A F602 00326012 00 34 AA00112200000086AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2020.01.12 15:02:26 3 : Device HM_356739 added to ActionDetector with 000:10 time
2020-01-12 15:02:26 CUL_HM HM_356739 Activity: alive
2020.01.12 15:02:26 5 : TSCUL_Read cul_TSCULF_LAPTOP: /A
2020.01.12 15:02:26 5 : TSCUL_Read cul_TSCULF_LAPTOP: A/I3567393F00
2020.01.12 15:02:26 4 : TSCUL_Parse: cul_TSCULF_LAPTOP AI3567393F00
2020.01.12 15:02:29 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF601000144FF000F0786103567391212120AA8F50850C4F5
2020.01.12 15:02:29 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  011634 A F601 00332796 00 0F 07 8610 356739 121212 0AA8F50850C4 -79.5dB
2020.01.12 15:02:29 5 : cul_TSCULF_LAPTOP: dispatch A0F0786103567391212120AA8F50850C4::-79.5:cul_TSCULF_LAPTOP:
2020-01-12 15:02:29 CUL_HM HM_356739 actuator: 80
2020-01-12 15:02:29 CUL_HM HM_356739 battery: ok
2020-01-12 15:02:29 CUL_HM HM_356739 batteryLevel: 2.3
2020-01-12 15:02:29 CUL_HM HM_356739 desired-temp: 21.0
2020-01-12 15:02:29 CUL_HM HM_356739 measured-temp: 24.5
2020-01-12 15:02:29 CUL_HM HM_356739 motorErr: ok
2020-01-12 15:02:29 CUL_HM HM_356739_Clima ValvePosition: 80
2020-01-12 15:02:29 CUL_HM HM_356739_Clima boostTime: 4 min
2020-01-12 15:02:29 CUL_HM HM_356739_Clima controlMode: boost
2020-01-12 15:02:29 CUL_HM HM_356739_Clima desired-temp: 21.0
2020-01-12 15:02:29 CUL_HM HM_356739_Clima measured-temp: 24.5
2020-01-12 15:02:29 CUL_HM HM_356739_Clima partyEnd: -
2020-01-12 15:02:29 CUL_HM HM_356739_Clima partyStart: -
2020-01-12 15:02:29 CUL_HM HM_356739_Clima partyTemp: -
2020-01-12 15:02:29 CUL_HM HM_356739_Clima T: 24.5 desired: 21.0 valve: 80
2020-01-12 15:02:29 CUL_HM HM_356739_Weather measured-temp: 24.5
2020-01-12 15:02:29 CUL_HM HM_356739_Weather 24.5
2020.01.12 15:02:29 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF602000145190034AA001122
2020.01.12 15:02:29 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF602000145190034AA001122/00000085AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA001180 AF6010001451C000908A112
2020.01.12 15:02:29 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  011742 A F602 00332900 00 34 AA00112200000085AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2020.01.12 15:02:29 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF6010001451C000908A112/AABBCC35673916 AF60100014521000F608610610C0B0000000A50B50B00
2020.01.12 15:02:29 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  011780 A F601 00332912 00 09 08 A112 AABBCC 356739  -63dB
2020.01.12 15:02:29 5 : cul_TSCULF_LAPTOP: dispatch A0908A112AABBCC356739::-63:cul_TSCULF_LAPTOP:
2020.01.12 15:02:29 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF60100014521000F608610610C0B0000000A50B50B00/0001
2020.01.12 15:02:29 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  011793 A F601 00332932 00 0F 60 8610 610C0B 000000 0A50B50B0000 -73.5dB
2020.01.12 15:02:29 5 : cul_TSCULF_LAPTOP: dispatch A0F608610610C0B0000000A50B50B0000::-73.5:cul_TSCULF_LAPTOP:
2020.01.12 15:02:29 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF6010001455F000908A112AABBCC35673916
2020.01.12 15:02:29 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  012019 A F601 00333180 00 09 08 A112 AABBCC 356739  -63dB
2020.01.12 15:02:29 5 : cul_TSCULF_LAPTOP: dispatch A0908A112AABBCC356739::-63:cul_TSCULF_LAPTOP:
2020.01.12 15:02:29 5 : TSCUL_Read cul_TSCULF_LAPTOP: /A
2020.01.12 15:02:29 5 : TSCUL_Read cul_TSCULF_LAPTOP: A/F601000145A2000908A112AABBCC35673915
2020.01.12 15:02:29 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  012290 A F601 00333448 00 09 08 A112 AABBCC 356739  -63.5dB
2020.01.12 15:02:29 5 : cul_TSCULF_LAPTOP: dispatch A0908A112AABBCC356739::-63.5:cul_TSCULF_LAPTOP:
2020.01.12 15:02:37 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF60200014D950034AA00112
2020.01.12 15:02:37 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF60200014D950034AA00112/200000084AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA001180
2020.01.12 15:02:37 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  020431 A F602 00341588 00 34 AA00112200000084AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2020.01.12 15:02:38 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF60100014E07000F0886103567391212120AA8F5080000
2020.01.12 15:02:38 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF60100014E07000F0886103567391212120AA8F5080000/F0
2020.01.12 15:02:38 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  020897 A F601 00342044 00 0F 08 8610 356739 121212 0AA8F5080000 -82dB
2020.01.12 15:02:38 5 : cul_TSCULF_LAPTOP: dispatch A0F0886103567391212120AA8F5080000::-82:cul_TSCULF_LAPTOP:
2020-01-12 15:02:38 CUL_HM HM_356739 actuator: 0
2020-01-12 15:02:38 CUL_HM HM_356739 battery: ok
2020-01-12 15:02:38 CUL_HM HM_356739 batteryLevel: 2.3
2020-01-12 15:02:38 CUL_HM HM_356739 desired-temp: 21.0
2020-01-12 15:02:38 CUL_HM HM_356739 measured-temp: 24.5
2020-01-12 15:02:38 CUL_HM HM_356739 motorErr: ok
2020-01-12 15:02:38 CUL_HM HM_356739_Clima ValvePosition: 0
2020-01-12 15:02:38 CUL_HM HM_356739_Clima boostTime: -
2020-01-12 15:02:38 CUL_HM HM_356739_Clima controlMode: auto
2020-01-12 15:02:38 CUL_HM HM_356739_Clima desired-temp: 21.0
2020-01-12 15:02:38 CUL_HM HM_356739_Clima measured-temp: 24.5
2020-01-12 15:02:38 CUL_HM HM_356739_Clima partyEnd: -
2020-01-12 15:02:38 CUL_HM HM_356739_Clima partyStart: -
2020-01-12 15:02:38 CUL_HM HM_356739_Clima partyTemp: -
2020-01-12 15:02:38 CUL_HM HM_356739_Clima T: 24.5 desired: 21.0 valve: 0
2020-01-12 15:02:38 CUL_HM HM_356739_Weather measured-temp: 24.5
2020-01-12 15:02:38 CUL_HM HM_356739_Weather 24.5
2020.01.12 15:02:38 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF60100014E250
2020.01.12 15:02:38 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF60100014E250/00909A112AABBCC35673915
2020.01.12 15:02:38 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  021012 A F601 00342164 00 09 09 A112 AABBCC 356739  -63.5dB
2020.01.12 15:02:38 5 : cul_TSCULF_LAPTOP: dispatch A0909A112AABBCC356739::-63.5:cul_TSCULF_LAPTOP:
2020.01.12 15:02:38 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF60100014E68000909A112AABBC
2020.01.12 15:02:38 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF60100014E68000909A112AABBC/C35673916
2020.01.12 15:02:38 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  021283 A F601 00342432 00 09 09 A112 AABBCC 356739  -63dB
2020.01.12 15:02:38 5 : cul_TSCULF_LAPTOP: dispatch A0909A112AABBCC356739::-63:cul_TSCULF_LAPTOP:
2020.01.12 15:02:39 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF60100014EAB000909A112AABBCC35673916
2020.01.12 15:02:39 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  021538 A F601 00342700 00 09 09 A112 AABBCC 356739  -63dB
2020.01.12 15:02:39 5 : cul_TSCULF_LAPTOP: dispatch A0909A112AABBCC356739::-63:cul_TSCULF_LAPTOP:
2020.01.12 15:02:44 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF60100015448000F9A86
2020.01.12 15:02:44 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF60100015448000F9A86/10610BA60000000A4CD10B004022
2020.01.12 15:02:44 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  027291 A F601 00348448 00 0F 9A 8610 610BA6 000000 0A4CD10B0040 -57dB
2020.01.12 15:02:44 5 : cul_TSCULF_LAPTOP: dispatch A0F9A8610610BA60000000A4CD10B0040::-57:cul_TSCULF_LAPTOP:
2020.01.12 15:02:48 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF6020001577F0034AA00112200000083AA001122AA001122AA0
2020.01.12 15:02:48 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF6020001577F0034AA00112200000083AA001122AA001122AA0/01122AAAA001122AA001122AA001122AA001122AA001122AA001122AA0011
2020.01.12 15:02:48 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF6020001577F0034AA00112200000083AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA0011/22AA001180
2020.01.12 15:02:48 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  030589 A F602 00351740 00 34 AA00112200000083AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2020.01.12 15:02:52 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF60100015B74000901A03F35673912121211
2020.01.12 15:02:52 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  034630 A F601 00355792 00 09 01 A03F 356739 121212  -65.5dB
2020.01.12 15:02:52 5 : cul_TSCULF_LAPTOP: dispatch A0901A03F356739121212::-65.5:cul_TSCULF_LAPTOP:
2020.01.12 15:02:52 5 : TSCUL_Write: cul_TSCULF_LAPTOP sending As0F01803F121212356739020425ADD57C
2020.01.12 15:02:52 4 : TSCUL_send:  cul_TSCULF_LAPTOP  034642                 As 0F 01 803F 121212 356739 020425ADD57C
2020-01-12 15:02:52 CUL_HM HM_356739 CMDs_done
2020-01-12 15:02:52 CUL_HM HM_356739 time-request: -
2020.01.12 15:02:52 5 : TSCUL_Read cul_TSCULF_LAPTOP: /A
2020.01.12 15:02:52 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF603
2020.01.12 15:02:52 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF603/00015B8C010A0180021212123567390080
2020.01.12 15:02:52 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  034757 A F603 00355888 01 0A 01 8002 121212 356739 00 _CCAdly:4 _dhmSt:96
2020.01.12 15:02:52 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF6030001
2020.01.12 15:02:52 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF6030001/5BA7010F01803F121212356739020425ADD57C80
2020.01.12 15:02:52 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  034866 A F603 00355996 01 0F 01 803F 121212 356739 020425ADD57C _CCAdly:4 _dhmSt:204
2020.01.12 15:02:54 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF60100015DE6000F0986103567391212120AA8F50
2020.01.12 15:02:54 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF60100015DE6000F0986103567391212120AA8F50/800001C
2020.01.12 15:02:54 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  037146 A F601 00358296 00 0F 09 8610 356739 121212 0AA8F5080000 -60dB
2020.01.12 15:02:54 5 : cul_TSCULF_LAPTOP: dispatch A0F0986103567391212120AA8F5080000::-60:cul_TSCULF_LAPTOP:
2020-01-12 15:02:54 CUL_HM HM_356739 actuator: 0
2020-01-12 15:02:54 CUL_HM HM_356739 battery: ok
2020-01-12 15:02:54 CUL_HM HM_356739 batteryLevel: 2.3
2020-01-12 15:02:54 CUL_HM HM_356739 desired-temp: 21.0
2020-01-12 15:02:54 CUL_HM HM_356739 measured-temp: 24.5
2020-01-12 15:02:54 CUL_HM HM_356739 motorErr: ok
2020-01-12 15:02:54 CUL_HM HM_356739_Clima ValvePosition: 0
2020-01-12 15:02:54 CUL_HM HM_356739_Clima boostTime: -
2020-01-12 15:02:54 CUL_HM HM_356739_Clima controlMode: auto
2020-01-12 15:02:54 CUL_HM HM_356739_Clima desired-temp: 21.0
2020-01-12 15:02:54 CUL_HM HM_356739_Clima measured-temp: 24.5
2020-01-12 15:02:54 CUL_HM HM_356739_Clima partyEnd: -
2020-01-12 15:02:54 CUL_HM HM_356739_Clima partyStart: -
2020-01-12 15:02:54 CUL_HM HM_356739_Clima partyTemp: -
2020-01-12 15:02:54 CUL_HM HM_356739_Clima T: 24.5 desired: 21.0 valve: 0
2020-01-12 15:02:54 CUL_HM HM_356739_Weather measured-temp: 24.5
2020-01-12 15:02:54 CUL_HM HM_356739_Weather 24.5
2020.01.12 15:02:54 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF60100015E
2020.01.12 15:02:54 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF60100015E/0400090AA112AABBCC35673917
2020.01.12 15:02:54 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  037261 A F601 00358416 00 09 0A A112 AABBCC 356739  -62.5dB
2020.01.12 15:02:54 5 : cul_TSCULF_LAPTOP: dispatch A090AA112AABBCC356739::-62.5:cul_TSCULF_LAPTOP:
2020.01.12 15:02:54 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF60100015E4700090AA112AA
2020.01.12 15:02:55 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF60100015E4700090AA112AA/BBCC35673918
2020.01.12 15:02:55 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  037532 A F601 00358684 00 09 0A A112 AABBCC 356739  -62dB
2020.01.12 15:02:55 5 : cul_TSCULF_LAPTOP: dispatch A090AA112AABBCC356739::-62:cul_TSCULF_LAPTOP:
2020.01.12 15:02:55 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF60100015E8A00090AA112AABBCC35673916
2020.01.12 15:02:55 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  037788 A F601 00358952 00 09 0A A112 AABBCC 356739  -63dB
2020.01.12 15:02:55 5 : cul_TSCULF_LAPTOP: dispatch A090AA112AABBCC356739::-63:cul_TSCULF_LAPTOP:
2020.01.12 15:02:56 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF602
2020.01.12 15:02:56 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF602/000160030034AA00112200000082AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA001180
2020.01.12 15:02:56 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  039296 A F602 00360460 00 34 AA00112200000082AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2020.01.12 15:03:00 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF601000163C2000F0A861035673
2020.01.12 15:03:00 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF601000163C2000F0A861035673/91212120A50F508000026
2020.01.12 15:03:00 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  043143 A F601 00364296 00 0F 0A 8610 356739 121212 0A50F5080000 -55dB
2020.01.12 15:03:00 5 : cul_TSCULF_LAPTOP: dispatch A0F0A86103567391212120A50F5080000::-55:cul_TSCULF_LAPTOP:
2020-01-12 15:03:00 CUL_HM HM_356739 actuator: 0
2020-01-12 15:03:00 CUL_HM HM_356739 battery: ok
2020-01-12 15:03:00 CUL_HM HM_356739 batteryLevel: 2.3
2020-01-12 15:03:00 CUL_HM HM_356739 desired-temp: 10.0
2020-01-12 15:03:00 CUL_HM HM_356739 measured-temp: 24.5
2020-01-12 15:03:00 CUL_HM HM_356739 motorErr: ok
2020-01-12 15:03:00 CUL_HM HM_356739_Clima ValvePosition: 0
2020-01-12 15:03:00 CUL_HM HM_356739_Clima boostTime: -
2020-01-12 15:03:00 CUL_HM HM_356739_Clima controlMode: auto
2020-01-12 15:03:00 CUL_HM HM_356739_Clima desired-temp: 10.0
2020-01-12 15:03:00 CUL_HM HM_356739_Clima measured-temp: 24.5
2020-01-12 15:03:00 CUL_HM HM_356739_Clima partyEnd: -
2020-01-12 15:03:00 CUL_HM HM_356739_Clima partyStart: -
2020-01-12 15:03:00 CUL_HM HM_356739_Clima partyTemp: -
2020-01-12 15:03:00 CUL_HM HM_356739_Clima T: 24.5 desired: 10.0 valve: 0
2020-01-12 15:03:00 CUL_HM HM_356739_Weather measured-temp: 24.5
2020-01-12 15:03:00 CUL_HM HM_356739_Weather 24.5
2020.01.12 15:03:01 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF602000164FE0034AA
2020.01.12 15:03:01 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF602000164FE0034AA/00112200000081AA001122AA001122AA001122AAAA001122AA001122AA001
2020.01.12 15:03:01 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF602000164FE0034AA00112200000081AA001122AA001122AA001122AAAA001122AA001122AA001/122AA001122AA001122AA001122AA001122AA001180
2020.01.12 15:03:01 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  044399 A F602 00365560 00 34 AA00112200000081AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2020.01.12 15:03:03 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF601000166
2020.01.12 15:03:03 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF601000166/2900090BA112AABBCC3567391A
2020.01.12 15:03:03 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  045601 A F601 00366756 00 09 0B A112 AABBCC 356739  -61dB
2020.01.12 15:03:03 5 : cul_TSCULF_LAPTOP: dispatch A090BA112AABBCC356739::-61:cul_TSCULF_LAPTOP:
2020.01.12 15:03:03 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF6010001666C00090BA112AABBCC3
2020.01.12 15:03:03 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF6010001666C00090BA112AABBCC3/5673912
2020.01.12 15:03:03 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  045872 A F601 00367024 00 09 0B A112 AABBCC 356739  -65dB
2020.01.12 15:03:03 5 : cul_TSCULF_LAPTOP: dispatch A090BA112AABBCC356739::-65:cul_TSCULF_LAPTOP:
2020.01.12 15:03:03 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF601000166AF00090BA112AABBCC35673917
2020.01.12 15:03:03 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  046127 A F601 00367292 00 09 0B A112 AABBCC 356739  -62.5dB
2020.01.12 15:03:03 5 : cul_TSCULF_LAPTOP: dispatch A090BA112AABBCC356739::-62.5:cul_TSCULF_LAPTOP:
2020.01.12 15:03:10 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF60200016D550034AA00112200000080AA001122AA001122
2020.01.12 15:03:10 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF60200016D550034AA00112200000080AA001122AA001122/AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA0
2020.01.12 15:03:10 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF60200016D550034AA00112200000080AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA0/01122AA001180
2020.01.12 15:03:10 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  052946 A F602 00374100 00 34 AA00112200000080AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2020.01.12 15:03:18 5 : TSCUL_Read cul_TSCULF_LAPTOP: /A
2020.01.12 15:03:18 5 : TSCUL_Read cul_TSCULF_LAPTOP: A/F602000175850034AA00112200000079AA001122AA001122AA001122AAAA0
2020.01.12 15:03:18 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF602000175850034AA00112200000079AA001122AA001122AA001122AAAA0/01122AA001122AA001122AA001122AA001122AA001122AA001122AA001180
2020.01.12 15:03:18 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  061332 A F602 00382484 00 34 AA00112200000079AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2020-01-12 15:03:20 Global global SAVE
2020.01.12 15:03:32 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF602000183050034AA00112200000078AA001122AA001122AA001122AA
2020.01.12 15:03:32 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF602000183050034AA00112200000078AA001122AA001122AA001122AA/AA001122AA001122AA001122AA001122AA001122AA001122AA001122AA001180
2020.01.12 15:03:32 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  075156 A F602 00396308 00 34 AA00112200000078AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2020.01.12 15:03:47 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF602000191140034A
2020.01.12 15:03:47 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF602000191140034A/A00112200000077AA001122AA001122AA001122AAAA001122AA001122AA00
2020.01.12 15:03:47 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF602000191140034AA00112200000077AA001122AA001122AA001122AAAA001122AA001122AA00/1122AA001122AA001122AA001122AA001122AA001180
2020.01.12 15:03:47 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  089540 A F602 00410704 00 34 AA00112200000077AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2020.01.12 15:03:52 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF6
2020.01.12 15:03:52 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF6/02000196E80034AA00112200000076AA001122AA001122AA001122AAAA001
2020.01.12 15:03:53 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF602000196E80034AA00112200000076AA001122AA001122AA001122AAAA001/122AA001122AA001122AA001122AA001122AA001122AA001122AA001180
2020.01.12 15:03:53 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  095504 A F602 00416672 00 34 AA00112200000076AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2020.01.12 15:04:03 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF60200
2020.01.12 15:04:03 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF60200/01A1670034AA00112200000075AA001122AA001122AA001122AAAA001122A
2020.01.12 15:04:03 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF6020001A1670034AA00112200000075AA001122AA001122AA001122AAAA001122A/A001122AA001122AA001122AA001122AA001122AA001122AA001180
2020.01.12 15:04:03 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  106252 A F602 00427420 00 34 AA00112200000075AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2020.01.12 15:04:06 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF6010001A41B000F898610610CF80000000A
2020.01.12 15:04:06 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF6010001A41B000F898610610CF80000000A/4CCD0A00402F
2020.01.12 15:04:06 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  109030 A F601 00430188 00 0F 89 8610 610CF8 000000 0A4CCD0A0040 -50.5dB
2020.01.12 15:04:06 5 : cul_TSCULF_LAPTOP: dispatch A0F898610610CF80000000A4CCD0A0040::-50.5:cul_TSCULF_LAPTOP:
2020.01.12 15:04:08 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF6010001A5D8000D9B86104106C10000000601000025
2020.01.12 15:04:08 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  110801 A F601 00431968 00 0D 9B 8610 4106C1 000000 06010000 -55.5dB
2020.01.12 15:04:08 5 : cul_TSCULF_LAPTOP: dispatch A0D9B86104106C100000006010000::-55.5:cul_TSCULF_LAPTOP:
2020.01.12 15:04:15 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF6020001ACCF0034AA00112200000074AA00
2020.01.12 15:04:15 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF6020001ACCF0034AA00112200000074AA00/1122AA001122AA001122AAAA001122AA001122AA001122AA001122AA00112
2020.01.12 15:04:15 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF6020001ACCF0034AA00112200000074AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA00112/2AA001122AA001122AA001180
2020.01.12 15:04:15 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  117940 A F602 00439100 00 34 AA00112200000074AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2020.01.12 15:04:22 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF6020001B3DD0034AA00112200000073AA001122AA001
2020.01.12 15:04:22 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF6020001B3DD0034AA00112200000073AA001122AA001/122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122
2020.01.12 15:04:22 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF6020001B3DD0034AA00112200000073AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122/AA001122AA001180
2020.01.12 15:04:22 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  125163 A F602 00446324 00 34 AA00112200000073AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2020.01.12 15:04:32 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF6020001BD4B0034
2020.01.12 15:04:32 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF6020001BD4B0034/AA00112200000072AA001122AA001122AA001122AAAA001122AA001122AA0
2020.01.12 15:04:32 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF6020001BD4B0034AA00112200000072AA001122AA001122AA001122AAAA001122AA001122AA0/01122AA001122AA001122AA001122AA001122AA001180
2020.01.12 15:04:32 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  134811 A F602 00455980 00 34 AA00112200000072AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2020.01.12 15:04:44 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF6020001C8DB0034AA00112200000071AA001122AA001
2020.01.12 15:04:44 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF6020001C8DB0034AA00112200000071AA001122AA001/122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122
2020.01.12 15:04:44 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF6020001C8DB0034AA00112200000071AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122/AA001122AA001180
2020.01.12 15:04:44 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  146658 A F602 00467820 00 34 AA00112200000071AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2020.01.12 15:04:48 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF6010001CD44000FA
2020.01.12 15:04:48 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF6010001CD44000FA/786103567CF0000000A94DF0A0040E8
2020.01.12 15:04:48 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  151173 A F601 00472336 00 0F A7 8610 3567CF 000000 0A94DF0A0040 -86dB
2020.01.12 15:04:48 5 : cul_TSCULF_LAPTOP: dispatch A0FA786103567CF0000000A94DF0A0040::-86:cul_TSCULF_LAPTOP:
2020.01.12 15:04:56 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF6020001D47E00
2020.01.12 15:04:56 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF6020001D47E00/34AA00112200000070AA001122AA001122AA001122AAAA001122AA001122A
2020.01.12 15:04:56 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF6020001D47E0034AA00112200000070AA001122AA001122AA001122AAAA001122AA001122A/A001122AA001122AA001122AA001122AA001122AA001180
2020.01.12 15:04:56 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  158567 A F602 00479736 00 34 AA00112200000070AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2020.01.12 15:05:04 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF6010001DCDD000F0B86103567390000000A50F50900
2020.01.12 15:05:04 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF6010001DCDD000F0B86103567390000000A50F50900/0059
2020.01.12 15:05:04 4 : TSCUL_Parse: cul_TSCULF_LAPTOP  167150 A F601 00488308 00 0F 0B 8610 356739 000000 0A50F5090000 -29.5dB
2020.01.12 15:05:04 5 : cul_TSCULF_LAPTOP: dispatch A0F0B86103567390000000A50F5090000::-29.5:cul_TSCULF_LAPTOP:
2020-01-12 15:05:04 CUL_HM HM_356739 actuator: 0
2020-01-12 15:05:04 CUL_HM HM_356739 battery: ok
2020-01-12 15:05:04 CUL_HM HM_356739 batteryLevel: 2.4
2020-01-12 15:05:04 CUL_HM HM_356739 desired-temp: 10.0
2020-01-12 15:05:04 CUL_HM HM_356739 measured-temp: 24.5
2020-01-12 15:05:04 CUL_HM HM_356739 motorErr: ok
2020-01-12 15:05:04 CUL_HM HM_356739_Clima ValvePosition: 0
2020-01-12 15:05:04 CUL_HM HM_356739_Clima boostTime: -
2020-01-12 15:05:04 CUL_HM HM_356739_Clima controlMode: auto
2020-01-12 15:05:04 CUL_HM HM_356739_Clima desired-temp: 10.0
2020-01-12 15:05:04 CUL_HM HM_356739_Clima measured-temp: 24.5
2020-01-12 15:05:04 CUL_HM HM_356739_Clima partyEnd: -
2020-01-12 15:05:04 CUL_HM HM_356739_Clima partyStart: -
2020-01-12 15:05:04 CUL_HM HM_356739_Clima partyTemp: -
2020-01-12 15:05:04 CUL_HM HM_356739_Clima T: 24.5 desired: 10.0 valve: 0
2020-01-12 15:05:04 CUL_HM HM_356739_Weather measured-temp: 24.5
2020-01-12 15:05:04 CUL_HM HM_356739_Weather 24.5
2020.01.12 15:05:08 5 : TSCUL_Read cul_TSCULF_LAPTOP: /AF6020001E0DE0034AA00112200000069AA00
2020.01.12 15:05:08 5 : TSCUL_Read cul_TSCULF_LAPTOP: AF6020001E0DE0034AA00112200000069AA00/1122AA001122AA001122AAAA001122AA001122AA001122AA001122AA00112
2020.01.12 15:05:08 5 : TSCUL_Read cul_TSCULF_LAPTOP:

Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: riker1 am 12 Januar 2020, 15:17:10
Hätte eine Frage.

kann man das reading Paired to auch per TSCULF setzten?

Muss nun das device vom Testsystem zu Prod migrieren....

Oder muss ich die ganze Prozedure mit neu Pairen machen ?

Danke LG T
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: MadMax-FHEM am 12 Januar 2020, 15:36:40
Das Reading ist "nur" eine "Anzeige" es ist beim Gerät im Register (interner Flash) hinterlegt mit WEM (HMID) es gepaired ist!

Wenn du ein Gerät umziehst zu einer Zentralen mit ANDERER HMID, dann musst du ein unpair machen oder Reset des Gerätes und dann dort neu anlernen: neue HMID (als Kennung der neuen Zentrale)

Wenn beide Systeme dieselbe HMID haben, dann musst du nichts umlernen...
...ABER: es gibt Probleme, weil die Geräte ja dann 2 "Master" haben...

Gruß, Joachim
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: frank am 12 Januar 2020, 16:58:36
@riker1

es funktioniert jetzt, weil nun das attr IODev existiert.  ;)
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: noansi am 12 Januar 2020, 17:41:30
Hallo Thomas,

2020-01-12 15:02:21   R-pairCentral   set_0x121212
sagt noch nicht, dass das pairing komplett erfolgreich war. Erst wenn das set_ noch weg ist, dann kannst Du sicher sein. Aber es stehen noch CMDs an.

Eventuell mußt Du nochmal einen getConfig bei dem RT anstoßen, um den aktuellen Status (mit der Zeit) zu bekommen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: MadMax-FHEM am 12 Januar 2020, 20:16:59
Oder wenn cmds_pending sind noch mal das "Anlern-Knöpfchen" drücken...

Ein getConfig "oben drauf" führt evtl. zu weiteren pending Telegrammen... ;)

Oder davor mind. clearMessages...

Gruß, Joachim
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: riker1 am 13 Januar 2020, 14:04:06
Zitat von: frank am 12 Januar 2020, 16:58:36
@riker1

es funktioniert jetzt, weil nun das attr IODev existiert.  ;)

Hallo, ja das IODev attrib ist nun da.

allerdings ist mir immer noch unklar.

Warum steht da nicht die VCCU drinnen?

Wieso weichen IODev Reading und Attribute manmal voneinander ab, bzw warum benötigt man beides?

Danke Thomas
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: rudolfkoenig am 13 Januar 2020, 14:18:36
ZitatWieso weichen IODev Reading und Attribute manmal voneinander ab, bzw warum benötigt man beides?
Das IODev _Internal_ wird ueblicherweise vom Modul durch Aufruf der Funktion AssignIOPort() gesetzt, hier sucht fhem.pl eine "passende" Instanz.
Wenn dem Benutzer das nicht gefaellt, dann modifiziert er das Attribut IODev, was wiederum das Internal ueberschreibt.

Ein IODev _Reading_ sagt mir nichts.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: riker1 am 13 Januar 2020, 14:30:25
Zitat von: rudolfkoenig am 13 Januar 2020, 14:18:36
Das IODev _Internal_ wird ueblicherweise vom Modul durch Aufruf der Funktion AssignIOPort() gesetzt, hier sucht fhem.pl eine "passende" Instanz.
Wenn dem Benutzer das nicht gefaellt, dann modifiziert er das Attribut IODev, was wiederum das Internal ueberschreibt.

Ein IODev _Reading_ sagt mir nichts.

Danke für die Antwort, ...ich meine das Internal sorry.

Nur zur sicherheit, auch wenn ich ein CUL bzw TSCULF als IODev setze, wird abder die VCCU genutzt die ich in IOGrp  angegeben habe, richtig?

Danke
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: noansi am 14 Januar 2020, 20:11:49
Hallo Thomas, hallo Rudolf,

und 10_CUL_HM macht es noch etwas anders, insbesondere im VCCU Betrieb.

Da wird das IODev auch noch nach RSSI gesetzt, sowie dem Attribut IOgrp (HM-device) und IOList (VCCU).

AssignIoPort ist nur der letzte Ausweg, weil es recht langsam ist.

Wenn eine VCCU genutzt wird, dann reicht das Attribut IOgrp VCCU_Name beim HM-device in der Regel.
Das Atrribut IODev hat nur beim Start von FHEM im VCCU Betrieb als erste Wahl oder ohne VCCU wirklich eine Bedeutung.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: frank am 14 Januar 2020, 22:31:09
hallo ansgar,
attr iodev muss immer vorhanden sein, auch wenn attr iogrp genutzt wird, also bei verwendung einer vccu.

ansonnsten macht mindestens aes probleme.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: noansi am 15 Januar 2020, 19:16:07
Hallo Frank,

das Attribut IODev wird an wenigen Stellen in 10_CUL_HM verwendet, um Attribute zu lesen.
In der in meinem zip beigepackten 10_CUL_HM Version funktioniert AES ohne das Attribut IODev unter VCCU Nutzung und Nutzung der tsculfw. IOgrp muss allerdings richtig sitzen.
Und IODev soll unter VCCU Nutzung nicht verwendet werden, damit die das Restore der IO-Zuweisung bei einem FHEM Neustart funktioniert, was insbesondere für Speicherschwache CUL Hardware, wie CUL V3 oder nanoCUL hilft, den Flash Speicher zu schonen. Die letzte Zuweisung wird beim Neustart aus den CULs gelesen.

Ich kann natürlich nicht ausschließen, dass es in der aktuellen Version aus dem Update von Martin zu Problemen kommt, wenn es nicht gesetzt ist. Ein HMLAN habe ich auch nicht zum Testen, ob es damit eventuell noch Nebenwirkungen gibt.

Zum Senden an Devices wird stets $hash->{IODev} von IOWrite verwendet. Schon aus Performance Gründen macht es keinen Sinn überall das Attribut zu verwenden.

Aber eigentlich wollte ich nur ein wenig deutlicher machen, auf welche Attribute der User bei der Konfiguration achten muss, wenn er das nutzt, was hier zur Verfügung gestellt wird.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: noansi am 15 Januar 2020, 21:15:58
Hallo Rudolf,

ich würde gerne die Version 0.33 der TS Firmware hier einstellen und habe auch schon die alte 0.31 und 0.32 gelöscht.
Leider erlaubt mit das Forum nicht, die neue zip mit 9541585 Bytes anzuhängen, ohne Fehlerhinweis. Es erscheint nur die Seite für ein neues Thema.
Ein neues Thema hilft auch nicht, die Dateigröße wird nicht akzeptiert.
Ist das ein Bug beim Server?

Gruß und Danke, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: frank am 15 Januar 2020, 21:22:17
hallo ansgar,

schon damals bei der einführung der vccu musste attr iodev aus "kompatibilitätsgründen" mit fhem existieren.
bis heute gibt es "attr sparfüchse", die durch weglassen des attributes nachweislich in probleme geraten. https://forum.fhem.de/index.php/topic,100911.0.html (https://forum.fhem.de/index.php/topic,100911.0.html)

ich finde es kontraproduktiv, wenn du hier etwas anderes propagierst. gerade weil die vccu nicht nur für cul derivate mit deiner firmware und deiner angepassten und "veralteten" cul_hm version angeblich funktioniert.

ebenso gibt es probleme im vccu betrieb bei devices, die kein zusätzliches attr iogrp benutzen. also mit vccu immer beide attribute nutzen.

gruss frank
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.32
Beitrag von: noansi am 15 Januar 2020, 22:56:43
Hallo Frank,

Hier der code zu IOWrite aus der aktuellen fhem.pl:
#####################################
sub
IOWrite($@)
{
  my ($hash, @a) = @_;

  my $dev = $hash->{NAME};
  return if(IsDummy($dev) || IsIgnored($dev));
  my $iohash = $hash->{IODev};
  if(!$iohash ||
     !$iohash->{TYPE} ||
     !$modules{$iohash->{TYPE}} ||
     !$modules{$iohash->{TYPE}}{WriteFn}) {
    Log 5, "No IO device or WriteFn found for $dev";
    return;
  }

  return if(IsDummy($iohash->{NAME}));

  no strict "refs";
  my $ret = &{$modules{$iohash->{TYPE}}{WriteFn}}($iohash, @a);
  use strict "refs";
  return $ret;
}

Da sehe ich $hash->{IODev} und nicht das Attribut. Schreiben an das IO geht also über $hash->{IODev}. Der Weg des IODev in $hash->{IODev} führt allerdings normalerweise über das Attribut IODev bei FHEM-Start. Und bei neuen devices in der Regel auch über AssignIOPort(), wie Rudolf schon geschrieben hat. Bei CUL_HM gibt es aber Abweichungen von der Regel, weil es da auch noch die RSSI abhängige IO Zuweisung gibt.

Zitatdeiner firmware und deiner angepassten und "veralteten" cul_hm version angeblich funktioniert.
Nun, ich habe hier ein SCC und ein CUNX auf tsculfw an einer VCCU laufen und habe extra nochmal getestet (mit Taste an HM-Dis-EP-WM55), ob geht, was ich geschrieben habe. Und es funktioniert, sogar mit automatischem IO Wechsel nach RSSI. Allerdings ohne HMLAN oder HMUARTLGW und mit der veralteten, angepassten 10_CUL_HM Version. Dazu hatte ich aber auch was geschrieben.

Und wenn ich in meine Änderungen am 10_CUL_HM Code schaue, dann habe ich an diversen Stellen auch eine Abfrage auf die VTS Firmware eingebaut. U.a. auch an der Stelle mit AES. Mit Mischbetrieb mit HMLAN oder HMUARTLGW kann es also durchaus zu Problemen kommen, wenn das Attribut fehlt. Ich kann es nicht testen und hatte wohl damals für andere IOs als TSCULs Kompatibilität zum "Standard" zu halten versucht. Insbesondere in der Hoffnung, dass Martin es übernimmt. Dazu ist es aber leider nicht gekommen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.33
Beitrag von: noansi am 16 Januar 2020, 19:57:47
Hallo Testwillige,

hier eine neue Version 0.33 der Timestamp Firmware und der dazu benötigten FHEM Module.

Diese Version bietet einige Verbesserungen für SlowRF Empfang und RF-Router.
In dem Zusammenhang ist auch das RF-Router Ping Timing geändert, damit also auch nicht kompatibel mit Standard culffw oder a-culfw und auch nicht zur Version 0.32.
Ergänzt ist SlowRf Empfang von Pearl NC7427 Temperatur/Luftfeuchte Sensoren. Entsprechend Kanalwahlschalter können 3 Stück empfangen werden. Zum Anlernen mittels autocreate muss der TEST Taster am Sensor gedrückt werden.

Das EEPROM Layout ist geändert und daher werden nach dem Flashen alle Einstellungen auf default zurück gestellt. Also vor dem Flashen individuelle Einstellungen, z.B. Frequenzoffsets, notieren und nacher neu einstellen.

Auszug aus der Changed:
- FULL_PA_RAMPING bugs corrected
- CCA CS thresholds setable for ASKSIN, MORITZ, HAS_RWE, RFNATIVE and MBUS with XTxy, x=CARRIER_SENSE_REL_THR, y=CARRIER_SENSE_ABS_THR as in AGCCTRL1
- SlowRf receive timing limits corrected
- SlowRf lower filter switched off by define in rf_receive_timing.h
- RFR timing/timeout shortened, FastRF CCA disabled
- auto Ci interrupt counter messages
- XP command extended to switch on auto Ci messages, AP removed as all PLL messages switchable by XP
- improvement and corrections for CUNX RS485 PIG support
- CUNX: PIG RTS controllable by USB Host for serial foward and RS485 serial forward
- CUNX: DMX interupts changed to HI priority and CC1101 interrupts to MED priority
- CUNX: USB interrupts to LO priority
- GPIOR1 used for USB USB_DeviceState
- GPIOR1 used for SERIAL STACKING stacking_ST_state


Ein Peakfilter für SlowRF Empfang ist ergänzt und mit "peakfilter" einstellbar.
In dem Zusammenhang ist auch das RF-Router Ping Timing geändert, damit also auch nicht kompatibel mit Standard culffw oder a-culfw.
Außerdem kann das Senden von RF-Router Daten nach deren Empfang einstellbar verzögert werden (RfRdelay).

CCAMode wirkt nun auch auf IT-Senden und SOMY-Senden, sowie auf das Senden des RF-Router Pings. Mit fRfCCAMode kann auch das CCA Verhalten für RF-Router Senden und FastRF geändert werden.

Auszug aus der Changed:
- IT and SOMYFY use SlowRF EEPROM CCA setting now for sending
- changes in SlowRF reception for reset and sync start. IT V1 reception tested succsessfully.
- SlowRF filter and match adaption
- SlowRF spike filter improved, max. peak lenght settable with Xpxx, xx hex time in 8us units
- IR receive/transmit pause during send of SlowRF changed to not globally switching off all interrupts
- periodic RF-Router ping RSSI display as "Cuxx\r\n" with xx = RSSI Hex
- RF-Router ping timing changed for better distinguish from other protocols
- RF-Router pre silence before send settable with uRxx, xx hex time in 4ms units
- Xrrt commands bits:
   rr:
   report known protocol data                                                      Bit 0
   report repeated data                                                            Bit 1
   report received bits                                                            Bit 2
   report 'r' (rising) or 'f' (falling) edge, '.' (collect) or '?' (sync) timeout  Bit 3
   report edges, bit times and timeouts                                            Bit 4
   report S300 data with valid checksum only                                       Bit 5
   report FHT                                                                      Bit 6
   report 'l' RSSI decimal data continuosly                                        Bit 7
   t:
   report recorded SlowRF timing                                                   Bit 0
- corrections in interrupt flag clearing
- correction in delay function
- fastRF bug corrected, untested
- EEPROM layout changed for the new parameters


TSCUNX kann mit entsprechendem RS485 Modul nun auch DMX.
Auch HM485 ist für TXCUNX angepasst.
In dem Zuge ist auch die DMX Funktionalität bei CUNO2 etwas erweitert.
IR läuft nun auch richtig mit TSCONO2.
Außerdem läuft RF-Router auf der tsculfw, allerdings mit einer Änderung. Das 'U' ist durch '~' ersetzt. 'U' kollidierte mit dem Uniroll Senden.

Kurzer Auszug aus der CHANGED:
- IO optimizations CUNX, especially to/from PIM and Ethernet
- CUNX DHCP non blocking operation
- IO optimizations
- HM485 support for CUNX (like CUNO2) with RS485 PIM.
  HM485 switch off with Hx for CUNX. With CUNX after Hx RS485 PIM again accessible via PIM USB or Ethernet Interface
- CUNX support for DMX and HM485 with RS485 PIM (to be tested), a Dwxxxxyy switches to DMX via CUNX Interface, a Hsxxxxxxxxxxxxxxxxxx switches to HM485 via CUNX Interface
- DMX switch off with Dx. With CUNX after Dx RS485 PIM is again accessible via PIM USB- or Ethernet Interface
  DMX flexible channel usage. Channels are sent out upto the highest channel set (0 sent as default for unset channels). With switching off with Dx the highest channel is reset.
  DMX changed in timing and resting behaviour. Rests on IDLE if less then 24 device, only, to keep 1204µs min. BREAK to BREAK (to be tested)
  DMX Dt command to set/view timing of MarkAfterBreak and BREAK
  DMX less disturbed while sending SlowRF
- W function gives feedback after writing EEPROM
- clock timer unburdened, may impact onewire and fht (to be tested)
- corrections for IRTX
- IR base timings changed to 12500Hz or 20000Hz
- RF-Router working, but 'U' changed to '~' (definable in board.h, but 'U' disables HAS_UNIROLL)

Es ist eine Prüfung auf Stacküberlauf eingebaut. Am Anfang des heap werden zwei Byte mit einem Bitmuster beschrieben. Wird das verändert, dann ist der Speicher wahrscheinlich korrumpiert, was durch einen Stacküberlauf ausgelöst sein sollte. Sofern der CUL dann noch kann sendet er ein "C_M" an TSCUL, was zu einem entsprechenden Log Eintrag führt.
Damit kann man vorsichtig die Speichergrenzen ausloten. Ein langer Testzeitraum ist aber erforderlich, um einigermaßen sicher zu sein, dass der worst case auch mal durchlaufen worden ist.
Außerdem ist ein Kommando mU (je nach Firmware) eingebaut, mit dem man den vom Stack ungenutzen heap in etwa auslesen kann (auch als get unusedstack in TSCUL verfügbar). Auch hier gilt, nur nach langer Laufzeit einigermaßen sinnvoll. Es macht sicher keinen Sinn auf Grund des Wertes den Speicher bis auf das letzte Byte auszuquetschen, denn weiterhin hängt die Stacknutzung vom gewählten Protokoll und Einstellungen ab.

In TSCULflash ist Flashen auch von NanoCULs und MiniCULs ergänzt. Vor dem Flashen wird ein "B00" also Reset für die TSCUL Firmware an den nano/Mini geschickt, 1 Sekunde gewartet und dann versucht mit avrdude zu flashen.
Also erst die Firmware in den FHEM/Firmware Ordner kopieren und dann in FHEM mit
TSCULflash <nanodevicename> TSnanoCUL
bzw.
TSCULflash <minidevicename> TSminiCUL
versuchen zu Flashen. Im Log sollte danach (dauert etwas) die avrdude Ausgabe zu finden sein.

Ebenfalls möglich ist das Flashen eines PIGATOR Moduls an einem CUNX
TSCULflash <pigatordevicename>|<cunxdevicename> TSPIGATOR

AESCommReq wird unterstützt. Die Nutzung ist unverändert zu Standard CUL, sprich, beim gewünschten Gerät/Kanal aesCommReq auf 1 setzen und ggf. noch aesKey passend zum verteilten Key setzen.
Es werden von tsculfw nur die Keys 0 (Default Key) bis 3 unterstützt.

Diese Erweiterung erfordert jedoch auch zusätzliche Empfangspuffer im knappen Speicher des CULs. Ein CUL V3 nutzt bis zu 6 Empfangspuffer. Auch der FlashSpeicherbdarf ist angestiegen, so dass einige Protokolle nicht mehr gleichzeitig in ein Kompilat passen. Das sollte aber weniger tragisch sein, da im ASKSIN Modus ohnehin nur HM empfangen werden kann.

Bei CUL V2 reicht der verfügbare Speicher leider hinten und vorne nicht aus, um diese Version nutzen zu können.

Im Anhang ist in TSCUL_fwcode_00_33_FHEM_Modules_00_44_2.zip wieder die Timestamp Firmware zu finden. Getestet habe ich TSCUNX, TSPIGATOR , TSCUL_V3 , TSCUL_V3_RFR, TSCUNO2, TSCOC und TSSCC. (TSCUL_V3_RFR ist ohne HM Unterstützung, also nur SlowRF)

Die tsculfw Firmware kann für TSCUL_V3, TSCUL_V3_RFR (via USB), TSCUNO2, TSCOC, TSSCC, TSCUNX und TSPIGATOR (an CUNX) mit FHEM mit dem TSCULflash geflashed werden. Die anderen müssen mit dem jeweiligen Flash Programmer geflashed werden. Bei CUNO2 und SCC muss die Bootloadertaste gedrückt werden, bis der Flashvorgang anläuft.
So z.B. https://forum.fhem.de/index.php/topic,24436.msg631743.html#msg631743 kann es mit einem USB CUL Stick gehen, wenn man nicht TSCULflash verwendet.
TSCULflash ist erweitert auf COC, SCC, CCD, rpiaddon, CUNO2 und CUNO. Jedoch ist es nicht ganz so einfach zu handhaben, da zum einen teilweise die Taste zu drücken ist und bei Raspberry PI Modulen die Rechteproblematik für den Zugriff auf die IO-Pins überwunden werden muss. Tips dazu in der Command-Ref auch bei RPI_GPIO.
Bei einem Stapel aus SCC mit aufgesetztem COC, CCD oder (rpiaddon?) ist unbedingt beim SCC Flash darauf zu achten, die Taste am gewünschten Modul zu drücken. Sonst wird das oberste Nicht-SCC Modul mit der SCC Firmware geflashed.
Mit CUNO2 ist das flashen getestet (generell nur über USB!). Wichtig, aber auch hier, die Taste zu drücken.

Es gibt nicht den Luxus des Downloads beim TSCULflash, sondern die Firmware muss händisch in den FHEM/firmware Ordner kopiert werden. Der Typ ist dann z.B. TSCUL_V3.
Beispiel:
TSCULflash MeinCulV3Device TSCUL_V3

Wichtig für SCC Nutzer. TSSTACKED ist entfallen und wird nicht mehr unterstützt.
Statt dessen gibt es das neue Modul STACKABLETS (als Abwandlung von Rudolfs STACKABLE).
Dieses wird sozusagen zwischen die Stackteilnehmer eingebaut.

Beispiel für fhem.cfg:
#erstes SCC Modul als Basis
define SCC_WS868 TSCUL /dev/ttyAMA0@38400 0000
attr SCC_WS868 event-on-change-reading Ints_per_sec,IntCalcStat,MatchStat
attr SCC_WS868 rfmode SlowRF
attr SCC_WS868 room Receiver
attr SCC_WS868 sendpool CUL_HM868,SCC_WS868
attr SCC_WS868 verbose 1

#neues STACKABLETS virtuelles IO device
define STACK_1 STACKABLETS SCC_WS868
attr STACK_1 verbose 1

#zweites SCC Modul
define SCC_HM868 TSCUL FHEM:DEVIO:STACK_1:38400 1034
attr SCC_HM868 event-on-change-reading cond
attr SCC_HM868 hmId F11034


Ergänzender Hinweis zu USB CULs: 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_08\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 1234
bzw.
define CUL_433 TSCUL /dev/CUL433_0@12000000 0000
definiert werden und es gibt keine Probleme mit wechselnder Schnittstelle mehr.
Die Seriennummer kann beim Compilieren der Firmware in der board.h festgelegt werden, so dass damit dann auch /dev/CUL868_1 etc. für mehrere gleiche CULs möglich sind.

Oder für CUNX
define CUNX_868 TSCUL /dev/CUNX868_0@12000000 0000
oder für PIGATOR an CUNX
define PIGATOR_433 TSCUL /dev/CUNXPIM_0@38400 0000
die Seriennummer wird aus der Seriennummer des XMEGA Chips des CUNX gebildet. Unter Linux lsusb nutzen!

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.

Bei nicht nativen USB CULs wie z.B. nanoCUL, miniCUL oder CUNO2, beträgt die Baudrate 38400, dementsprechend muss die Definition beispielsweise so aussehen:
define CUL_868 TSCUL /dev/CUL868@38400 1234
bzw.
define CUL_433 TSCUL /dev/CUL433@38400 0000

Und noch ein Beispiel für eine Definition eines Netzwerk CUNX:
define CUL_868 TSCUL 192.168.178.111:2323 0000
oder für PIGATOR an CUNX
define PIGATOR_433 TSCUL 192.168.178.111:2324 0000
beim PIGATOR sollten zuvor mit Anschluss an USB und öffnen der Schnittstelle mit gewünschten Kommunikationsparametern mit ps oder unter TSCUL mit set PIMstoreBaud die seriellen Kommunikationsparameter zum PIGATOR Modul gespeichert werden, falls sie vom default abweichen.

Oder Netzwerk CUNO2:
define CUNO2_868 TSCUL 192.168.178.110:2323 0000

Die aktuell eingestellte oder per DHCP erhaltene Netzwerkadresse kann mit Lc repektive in TSCUL mit get NetAdresses abgefragt werden. Mit Lp respektive in TSCUL mit get NetPHYlink kann der Linkzustand des Netzwerkanschlusses angezeigt werden.


In der Zip Datei sind ebenfalls die ergänzten Module zu finden, die zur Nutzung der Firmware erforderlich sind.

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
16_TSCUL_RFR.pm -> der 16_CUL_RFR.pm, aus CUL_RFR devices werden damit TSCUL_RFR devices in der fhem.cfg (händisch anzupassen)
16_STACKABLETS.pm -> statt der 16_STACKABLE.pm, aus STACKABLE werden damit STACKABLETS devices in der fhem.cfg (händisch anzupassen)

10_UNIRoll_TS.pm  -> statt der 10_UNIRoll.pm, mit TSCUL 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 IO-devices zu verwenden, aus TSKS300 wird dann TSKS300  in der fhem.cfg (händisch anzupassen). Obsolet, da 14_TSCUL_WS.pm nun KS300 unterstützt.
14_TSCUL_TX.pm    -> statt der 14_CUL_TX.pm, mit TSCUL 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 IO-devices zu verwenden, aus CUL_WS wird dann TSCUL_WS  in der fhem.cfg (händisch anzupassen)
14_TSCUL_NC7427.pm  -> NC7427 Unterstützung
15_TSCUL_EM.pm   -> statt der 15_CUL_EM.pm, mit TSCUL IO-devices zu verwenden, aus CUL_EM wird dann TSCUL_EM  in der fhem.cfg (händisch anzupassen)
CalcUtil.pm               -> Hilfsrechenroutinen für Taupunkt und Windstärkeindex
ReadingUtil.pm          -> Hilfsroutinen für Readings

Da diese Module ergänzt werden (müssen!), überleben sie auch ein Update von FHEM.

10_IT.pm                   -> vermeidet unnötiges busy waiting beim Senden. Wird ohne Schutz von FHEM update überschrieben

Außerdem:

98_TSCULflash.pm     -> Zum Flash von TSCUL_V3, TSPIGATOR (an CUNX) mit Datei in FHEM/firmware

10_CUL_HM.pm         -> angepasste Version zur Nutzung mit TSCUL/tsculfw. Die Nutzung dieses Moduls ist optional. Für CUL_V3, nanoCUL, miniCUL im Multio-HM-IO Betrieb jedoch empfohlen, da sie den EEPROM Verschleiss über das Attribut "rssiSwitchHyst" verringert.
HMConfig.pm             -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden. Einstelllimits für HM-CC-RT-DN Regler P und I Anteil erweitert. Damit kann man mit R-regAdaptive offDeter deutlich mehr an den Regelparametern spielen.
98_HMinfo.pm           -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden. Spaltenbreiten in Tabelle von protoEvents variabel zu verbesserten Übersicht in der Darstellung.
Die 3 Dateien entsprechen einem Stand von Mitte 12/2019. Seither gab es viele Änderungen, so dass entweder diese 3 verwendet werden müssen oder die 3 aus aktuellem Update (meinerseits nicht getestet und der EEPROM-Verschleißhinweis unten ist zu beachten).

10_CULG.pm              -> optional, enthalten, da die Firmware es unterstützt

97_timerTS.pm           -> optional, Austausch-Timerroutinen. Wenn es nicht genutzt werden soll, dann löschen oder umbennen.
98_apptime.pm          -> apptime zur zwingenden Nutzung mit 97_timerTS.pm.
98_apptm.pm            -> apptime zur zwingenden Nutzung mit 97_timerTS.pm, mit geringerem Speicherverbrauch bei weniger Details

98_autocreate.pm       -> autocreate mit TSCUL Unterstützung

98_Cumulate               -> Kumulieren von Zählwerten, wie Strom, Regenmenge etc.
98_SAverage.pm         -> Mittelwertbildung von z.B. Temperaturen. Stunde, Tag, Monat und Jahr, sowie ein gleitender Mittelwert der letzten Stunde sind damit möglich.


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_STACKABLETS.pm DevIoTS.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.pm CalcUtil.pm 97_timerTS.pm 98_TSCULflash.pm 97_timerTS.pm 98_apptime.pm 98_apptm.pm 10_IT.pm 10_CULG.pm 10_CUL_HM.pm HMConfig.pm 98_HMinfo.pm ReadingUtil.pm 98_autocreate.pm 98_Cumulate.pm 98_SAverage.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` }

Noch ein Hinweis: TSCUL fragt auch die Firmwareversion der tsculfw auf 0.33 ab. Eine ältere Version wird also nicht unterstützt!

Frequenzoffset: Für HM ist ein Frequenzoffset von -20.6kHz im EEPROM als default in der tsculfw hinterlegt (das ist ein individuelles Optimum für meinen COC). Dieser Frequenzoffset kann mit set hmFreqOffs umgestellt werden. 0 ist default in der Standard-culfw.
Wenn also keine Antwort von angesprochenen HM devices kommt, dann hmFreqOffs von 0 ausgehend verstellen. CUNX z.B. geht eher in Richtung + mit dem Offset.
Wer das Frequenzspektrum sichtbar machen kann, kann sich die optimale Mitte aller devices ermitteln und mit dem Offset sein CUL dazu passend einstellen.

Noch ein Tip zur Haltbarkeit der CULs mit wenig SRAM (CUL V3, nanoCUL, miniCUL ...). Jedesmal, wenn einem HM-Device das IODev durch Roaming neu zugeordnet wird, führt das zu EEPROM Schreibvorgängen in den beteiligten CULs. Die Lebensdauer des EEPROMs ist begrenzt (100000 Schreibzyklen laut Datenblatt). Daher rate ich zur Nutzung des VorzugsIOs beim Device Attribut IOgrp. Also nicht einfach stumpf
attr HMdeviceName IOgrp VCCU
setzen, sondern
attr HMdeviceName IOgrp VCCU:CUL_mit_gutem_Empfang_fuer_Device
sofern die Roaming Funktionalität entsprechend RSSI für das jeweilige device nicht zwingend benötigt wird. Ein Fallback auf einen anderen CUL bleibt dennoch möglich.
Mit dem Attribut "rssiSwitchHyst", das in der beigefügten 10_CUL_HM.pm verfügbar ist, kann bei den HM-devices die Umschalthysterese für das Roaming von 10 bis auf 2 bei Bedarf für mobile devices verringert werden.

Ergänzt ist auch noch ein set TX3Send.
Damit lassen sich TX3 Sensordatentelegramme auf 433er CULs versenden.
Beispiel:

define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 TX3Send T:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." SID:23 U")}

define NF_HumOut notify Sen_Aussen:humidity.* {fhem("set TSCUL_WS433 TX3Send H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." SID:23 U")}


Ergänzt ist auch noch ein set KSSend.
Damit lassen sich WS Sensordatentelegramme versenden.
Beispiel:

define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 KSSend T:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." Code:2")}


Hier geht es zur vorherigen Version https://forum.fhem.de/index.php/topic,24436.msg984185.html#msg984185 (https://forum.fhem.de/index.php/topic,24436.msg984185.html#msg984185).

Gruß, Ansgar.

Edit: Sourcen im nächsten Beitrag.
Edit: Bug in 14_TCUL_WS.pm bezüglich Regenoffset oder Sonnenscheinoffset behoben.
Edit: hex files für ungetestete CUL-Typen ergänzt, Feedback erwünscht
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.33
Beitrag von: noansi am 16 Januar 2020, 20:00:53
Und die Sourcen kommen später, wenn mich das Forum wieder reguläre Dateigrößen hochladen läßt...
Im Anhang, das, was ich an Sourcen hochladen kann.
Im Wizchip Code für CUNX fehlt noch eine iolibrary.chm Hilfe Datei, die leider sehr groß ist und daher nicht in eine kleinere zip passt.
Ok, die Sourcen sind nun auch komplett.

Gruß, Ansgar.

Yeah, geht wieder. :)
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.33
Beitrag von: noansi am 18 Januar 2020, 12:05:05
Hallo Testwillige,

ich habe noch einen Bug in 14_TCUL_WS.pm bezüglich Regenoffset oder Sonnenscheinoffset behoben.
Daher oben neue Version der zip.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.33
Beitrag von: pantau am 18 Januar 2020, 19:20:28
Hallo Ansgar,

lieferst Du die "fehlenden" HEX Files noch nach, wie z.B. rpiaddon, CUL_V4 etc?

Gruß

Peter
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.33
Beitrag von: noansi am 18 Januar 2020, 19:48:48
Hallo Peter,

welche konkret?

Bisher gab es null Feedback zu anderen aus "untested", daher habe ich sie als hex weg gelassen.
Ein "hallo geht" würde die Motivation schon steigern.  ;)

Compilieren kann sie ohnehin mit dem Quellcode, wer mag. CULV4 ist z.B. ein Fall mit wenig RAM und von daher besser in Wunschfunktionskonfiguration (so weit umsetzbar) zu kompilieren.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.33
Beitrag von: pantau am 18 Januar 2020, 20:52:26
Zitat von: noansi am 18 Januar 2020, 19:48:48
Hallo Peter,

Bisher gab es null Feedback zu anderen aus "untested", daher habe ich sie als hex weg gelassen
Na das Weglassen hat doch schon ein Feedback bewirkt, oder ? :P
Aber ich habe noch andere Baustellen und kann erst mal keine neue Firmware in anderen CULs testen.
Apropos Baustelle:
Ich hatte mich wirklich gefreut:
KS300 original:
T: 1.7 H: 71 W: 0.0 R: 709.2 IR: no Wi: 0 D: -3.0
KS300 mit TSCUL_WS:
T: 1.7 H: 71 W: 0 R: 0 IR: no Wi: 0 D: -3.0
=> Endlich mal ein STATE der gleich ist und ich muss meine ganzen Skripte nicht anpassen! .. Pustekuchen ... :-\
In R: wird nicht mehr die Gesamtmenge geschrieben und IR: wird nicht von den Kontakten genommen, sondern aus der Count-Differenz berechnet....Zumindest interpretiere ich so den Code.
Muss das den sein? Die Idee von ELV zu IR war, das das bei Erkennung sofort gesendet wird und nicht erst wenn die Wippe voll ist.... Ich weiß das das nicht besonders zuverlässig ist, aber dann hätte es auch ein ODER aus Wippe und Count getan?
Bei mir steht dann im Log:
2020-01-09_10:08:08 TSCUL_WS_CUL_0_223 T: 9  H: 83  W: 0  R: 0  IR: no  Wi: 0 D: 6.3
2020-01-09_10:10:40 TSCUL_WS_CUL_0_223 T: 9  H: 82  W: 0.2  R: 7  IR: yes  Wi: 0 D: 6.1
2020-01-09_10:10:41 TSCUL_WS_CUL_0_223 T: 9  H: 82  W: 0.2  R: 0  IR: no  Wi: 0 D: 6.1
R:7 ist die Count-Differenz, aber seit wann? Und eine Sekunde später ist R: 0? Wie ist denn ein R Wert zu interpretieren?

Und dann mal was Positives:
1.) HM ist bei mir stabiler geworden, vor allem ein CUNX (mit Pigator, als HM und SlowRF) hat viel weniger Netzwerk Reconnects. Auch mein RFR läuft deutlich stabiler.
2.) Ich kann Dir jetzt erklären, warum Du wenige SlowRF Tester hast  ;D

Gruß

Peter

Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.33
Beitrag von: noansi am 18 Januar 2020, 22:00:21
Hallo Peter,

ZitatIn R: wird nicht mehr die Gesamtmenge geschrieben
Stimmt, die steht in rainTotal.
R: ist "momentane" Regenmenge in l/h, also Zählerstandsänderung

ZitatIR: wird nicht von den Kontakten genommen, sondern aus der Count-Differenz berechnet....
Du hast wohl beim Regensensor Typ 2 geschaut.
KS300 wird so ausgewertet (Zeile 314):
    my $israining = (($totalCnt!=$lastTotCnt) || ($addrnib & 0x2))?"yes":"no";
Also sowohl, als auch. Die Regensignalisierung im KS300 ist nicht 100% zuverlässig (Schmutz, schräge Aufstellung etc.). Deswegen wird sowohl eine Zählerstandsänderung, als auch eine direkte Regenerkennung als Regen in IR: signalisiert.
Sieht korrekt aus, was Du da geloggt hast, bis auf das D:, das kommt nicht vom TSCUL_WS Code.

ZitatR:7 ist die Count-Differenz, aber seit wann?
Seit ich dieses Modul so geschrieben habe, weil ich es so für sinnvoller hielt.

Du kannst den KS300 auch als TSKS300 definieren. Außerdem muss beim CUL, das ihn empfangen soll, das Attribut "KS300redirect" gesetzt sein.
Dann hast Du den alten Stand in state.

Zitatvor allem ein CUNX (mit Pigator, als HM und SlowRF) hat viel weniger Netzwerk Reconnects
Kannst Du das bitte präzisieren?
Ich kenne nur den Zustand "kein Reconnect". Oder arbeitet CUNX als RF-Router? Nur da gibt es eine mir bewusste Quelle für einen Reconnect, falls eine RF-Router Nachricht wegen erkannter Dauerbelegung des Kanals nicht abgesetzt werden kann, und das auch nur, wenn der Puffer voll ist.
Nebenbei ist CUNX + PIGATOR beide in 868MHz Variante wegen maximaler gegenseitiger Störung nicht unbedingt die beste Kombination. Ich hoffe, Du nutzt wenigstens abgesetzte Antennen mit größerem Abstand.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.33
Beitrag von: noansi am 21 Januar 2020, 21:38:55
Hallo Testwillige,

ich habe mal die aktuelle 10_CUL_HM.pm und die damit verbundenen Module auf TSCUL V0.33 angepasst.

Wer testen mag, im Anhang die zip Datei dazu. Alle 4 Dateien gehören ins FHEM Verzeichnis.

Wichtiger Hinweis vor einem Test (mit Feedback bitte), erst Backup von FHEM erstellen, damit der Rückweg kein Problem darstellt!!!

Da Martin seit meiner letzten Anpassung Modelaliassing eingeführt hat und in dem Zug auch Modelnammen auf Großbuchstaben umgestellt hat, ist der nächste wichtige Hinweis: Keinesfalls das Attribut "model" bei HM-devices händisch ändern!

Um sicher zu gehen, dass die Kleinbuchstaben keinen Ärger machen, habe ich das in FHEM (nach dem ersten Neustart mit neuen Modulen) durch Setzen des Attributs modelForce bei jedem HM device gemacht. Bei modelForce wird eine Auswahlliste der Modelle zur Auswahl geboten, in der das richtige Model in Großbuchstaben auszuwählen ist.
Danach dann ein Save config und FHEM Neustart, damit die damit verbundenen Änderungen auch alle durchlaufen und gesichert werden.
Anschließend habe ich die modelForce Attribute alle wieder gelöscht, wieder abgeschlossen mit Save config und FHEM Neustart.
Bei meiner eingeschränkten Testlandschaft (nur tsculfw mit VCCU und nur eine kleine Auswahl an HM-Devices) habe ich damit bisher keine unangenehmen Nebenwirkungen feststellen können.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.33
Beitrag von: Hotte1195 am 08 Februar 2020, 19:42:29
Hallo zusammen,

ich wollte hier mal mit testen und meine Homematic Geräte wieder in FHEM einbinden, da mir vor einiger Zeit mein HM-MOD-RPI-PCB verstorben ist :-(
Jetzt brauche ich bitte mal Eure Hilfe:

Ich habe einen Nano V3 mit Pegelwandler und CC1101 zusammengefügt und aus dem Beitrag
https://forum.fhem.de/index.php/topic,24436.msg1013844.html#msg1013844
die TSnanoCUL.hex auf den Arduino gespielt. Baue ich jetzt unter meinem Ubuntu mir 38400B8N1 eine Verbindung auf und sende ein großes <V>
erhalte ich als Antwort <VTS 0.33 CSM868\r\n>. Soweit sollte alles funktioniert haben. Dann habe ich noch mit dem Tool von FTDI dem FT232 eine
Seriennummer vergeben. Als nächstes die Moduldateien aus dem Softwarepaket nach /opt/fhem/FHEM auf den Raspi gespielt. Rechte stehen auf 644 wie bei den anderen Modulen, Eigentümer ist fhem mit Gruppe dialout. Ein cat /opt/fhem/FHEM/00_TSCUL.pm funktioniert. Jetzt kommt der Punkt wo ich nicht weiter weiß:
ein <define nanoCUL_868 TSCUL /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_47110815-if00-port0@38400 1234> wird mit
<Cannot load module TSCUL> quittiert. Ein <define nanoCUL_868 CUL /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_47110815-if00-port0@38400 1234> legt ein Device an, unter Clients wird aber nix mit *HM gelistet und ein <get nanoCUL_868 version> funktioniert auch nicht (no Answer).

Könntet Ihr mir kurz den Weg erläutern, wie ich meine Homematic Sensoren mit dem nanoTSCUL wieder in Fhem bringe?

Ich sage schon mal DANKE! im voraus!

Gruß Hotte
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.33
Beitrag von: noansi am 08 Februar 2020, 20:13:34
Hallo Hotte,

Zitatich wollte hier mal mit testen und meine Homematic Geräte wieder in FHEM einbinden,
Sind sie noch eingebunden und vermissen nur ein IO?

ZitatAls nächstes die Moduldateien aus dem Softwarepaket nach /opt/fhem/FHEM auf den Raspi gespielt.
Eventuell musst Du dann mal FHEM neu starten, um die Modulliste zu aktualisieren.

Zitatein <define nanoCUL_868 TSCUL /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_47110815-if00-port0@38400 1234> wird mit
Du kannst es so versuchen, abschließend musst Du aber sicher stellen, dass der nano vor allen HM devices und VCCU in der fhem.cfg definiert wird. Außerdem Attribut rfmode HomeMatic nicht vergessen.
Wenn Du alle HM devices neu anlernen willst/musst, dann sollte es vermutlich auch so gehen. Und wenn Du schon alles neu machst, dann gleich mit VCCU.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.33
Beitrag von: Hotte1195 am 09 Februar 2020, 00:09:39
Hallo Ansgar,

Danke, daß Du versuchst mir zu helfen! Die HM Geräte sind noch da, IO ist natürlich weg weil kaputt.
Fhem Service ist angehalten, Dateien neu nach /opt/fhem/FHEM/ kopiert, Eigentümer gesetzt und Service danach neu gestartet.
Ich hab auch extra nochmal das Paket runtergeladen und neu entpackt, falls da was schief gelaufen ist.
Nun stehe ich vor dem gleichen Problem:ein

<define nanoCUL_868 TSCUL /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_47110815-if00-port0@38400 1234>

wird mit

<Cannot load module TSCUL>

quittiert. Verwende ich anstatt TSCUL nur das Modul CUL wird ein Device angelegt das IMHO nicht richtig funktioniert und auch die HM Vorteile vom tsculfw nicht nutzen kann. Oder sehe ich da was falsch? Ich bin völlig ratlos!

BG Hotte
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.33
Beitrag von: Hotte1195 am 09 Februar 2020, 00:30:51
Och nö. Ich könnte vor Scham im Boden versinken. Warum bin ich nicht auf die Idee gekommen das fhem-2020-02.log anzuschauen? Beim Kopieren muss die Datei ReadingUtil.pm verloren gegangen sein. Ist ein blöder Bedienfehler. Ich hab zum Kopieren den MC auf dem Raspi benutzt. ReadingUtil ist die letzte Datei und die wurde immer nicht mit markiert. :'(
Jetzt kann ich ein TSCUL anlegen und es antwortet auch   ::)

BG Hotte
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.33
Beitrag von: RaspiLED am 09 Februar 2020, 18:16:12
Spoiler:

Im MC nutzt man * um alle Dateien zu markieren ;-)

Gruß Arnd


Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: noansi am 09 Februar 2020, 19:02:53
Hallo Testwillige,

hier eine neue Version 0.34 der Timestamp Firmware und der dazu benötigten FHEM Module.

Diese Version bietet wakup support und keep awake Support. Für CULs mit wenig Speicher kann dies mit dem Attribut "hmForceLzyCfg" aktiviert werden, siehe auch der Hinweis zum EEPROM Verschleiß weiter unten.

Das RF-Router Ping Timing ist geändert, damit also auch nicht kompatibel mit Standard culffw oder a-culfw und auch nicht zur Version 0.32.
Ergänzt ist SlowRf Empfang von Pearl NC7427 Temperatur/Luftfeuchte Sensoren. Entsprechend Kanalwahlschalter können 3 Stück empfangen werden. Zum Anlernen mittels autocreate muss der TEST Taster am Sensor gedrückt werden.

Das EEPROM Layout ist geändert und daher werden nach dem Flashen alle Einstellungen auf default zurück gestellt. Also vor dem Flashen individuelle Einstellungen, z.B. Frequenzoffsets, notieren und nacher neu einstellen.

Auszug aus der Changed:
- FULL_PA_RAMPING bugs corrected
- CCA CS thresholds setable for ASKSIN, MORITZ, HAS_RWE, RFNATIVE and MBUS with XTxy, x=CARRIER_SENSE_REL_THR, y=CARRIER_SENSE_ABS_THR as in AGCCTRL1
- SlowRf receive timing limits corrected
- SlowRf lower filter switched off by define in rf_receive_timing.h
- RFR timing/timeout shortened, FastRF CCA disabled
- auto Ci interrupt counter messages
- XP command extended to switch on auto Ci messages, AP removed as all PLL messages switchable by XP
- improvement and corrections for CUNX RS485 PIG support
- CUNX: PIG RTS controllable by USB Host for serial foward and RS485 serial forward
- CUNX: DMX interupts changed to HI priority and CC1101 interrupts to MED priority
- CUNX: USB interrupts to LO priority
- GPIOR1 used for USB USB_DeviceState
- GPIOR1 used for SERIAL STACKING stacking_ST_state


Ein Peakfilter für SlowRF Empfang ist ergänzt und mit "peakfilter" einstellbar.
In dem Zusammenhang ist auch das RF-Router Ping Timing geändert, damit also auch nicht kompatibel mit Standard culffw oder a-culfw.
Außerdem kann das Senden von RF-Router Daten nach deren Empfang einstellbar verzögert werden (RfRdelay).

CCAMode wirkt nun auch auf IT-Senden und SOMY-Senden, sowie auf das Senden des RF-Router Pings. Mit fRfCCAMode kann auch das CCA Verhalten für RF-Router Senden und FastRF geändert werden.

Auszug aus der Changed:
- IT and SOMYFY use SlowRF EEPROM CCA setting now for sending
- changes in SlowRF reception for reset and sync start. IT V1 reception tested succsessfully.
- SlowRF filter and match adaption
- SlowRF spike filter improved, max. peak lenght settable with Xpxx, xx hex time in 8us units
- IR receive/transmit pause during send of SlowRF changed to not globally switching off all interrupts
- periodic RF-Router ping RSSI display as "Cuxx\r\n" with xx = RSSI Hex
- RF-Router ping timing changed for better distinguish from other protocols
- RF-Router pre silence before send settable with uRxx, xx hex time in 4ms units
- Xrrt commands bits:
   rr:
   report known protocol data                                                      Bit 0
   report repeated data                                                            Bit 1
   report received bits                                                            Bit 2
   report 'r' (rising) or 'f' (falling) edge, '.' (collect) or '?' (sync) timeout  Bit 3
   report edges, bit times and timeouts                                            Bit 4
   report S300 data with valid checksum only                                       Bit 5
   report FHT                                                                      Bit 6
   report 'l' RSSI decimal data continuosly                                        Bit 7
   t:
   report recorded SlowRF timing                                                   Bit 0
- corrections in interrupt flag clearing
- correction in delay function
- fastRF bug corrected, untested
- EEPROM layout changed for the new parameters


TSCUNX kann mit entsprechendem RS485 Modul nun auch DMX.
Auch HM485 ist für TXCUNX angepasst.
In dem Zuge ist auch die DMX Funktionalität bei CUNO2 etwas erweitert.
IR läuft nun auch richtig mit TSCONO2.
Außerdem läuft RF-Router auf der tsculfw, allerdings mit einer Änderung. Das 'U' ist durch '~' ersetzt. 'U' kollidierte mit dem Uniroll Senden.

Kurzer Auszug aus der CHANGED:
- IO optimizations CUNX, especially to/from PIM and Ethernet
- CUNX DHCP non blocking operation
- IO optimizations
- HM485 support for CUNX (like CUNO2) with RS485 PIM.
  HM485 switch off with Hx for CUNX. With CUNX after Hx RS485 PIM again accessible via PIM USB or Ethernet Interface
- CUNX support for DMX and HM485 with RS485 PIM (to be tested), a Dwxxxxyy switches to DMX via CUNX Interface, a Hsxxxxxxxxxxxxxxxxxx switches to HM485 via CUNX Interface
- DMX switch off with Dx. With CUNX after Dx RS485 PIM is again accessible via PIM USB- or Ethernet Interface
  DMX flexible channel usage. Channels are sent out upto the highest channel set (0 sent as default for unset channels). With switching off with Dx the highest channel is reset.
  DMX changed in timing and resting behaviour. Rests on IDLE if less then 24 device, only, to keep 1204µs min. BREAK to BREAK (to be tested)
  DMX Dt command to set/view timing of MarkAfterBreak and BREAK
  DMX less disturbed while sending SlowRF
- W function gives feedback after writing EEPROM
- clock timer unburdened, may impact onewire and fht (to be tested)
- corrections for IRTX
- IR base timings changed to 12500Hz or 20000Hz
- RF-Router working, but 'U' changed to '~' (definable in board.h, but 'U' disables HAS_UNIROLL)

Es ist eine Prüfung auf Stacküberlauf eingebaut. Am Anfang des heap werden zwei Byte mit einem Bitmuster beschrieben. Wird das verändert, dann ist der Speicher wahrscheinlich korrumpiert, was durch einen Stacküberlauf ausgelöst sein sollte. Sofern der CUL dann noch kann sendet er ein "C_M" an TSCUL, was zu einem entsprechenden Log Eintrag führt.
Damit kann man vorsichtig die Speichergrenzen ausloten. Ein langer Testzeitraum ist aber erforderlich, um einigermaßen sicher zu sein, dass der worst case auch mal durchlaufen worden ist.
Außerdem ist ein Kommando mU (je nach Firmware) eingebaut, mit dem man den vom Stack ungenutzen heap in etwa auslesen kann (auch als get unusedstack in TSCUL verfügbar). Auch hier gilt, nur nach langer Laufzeit einigermaßen sinnvoll. Es macht sicher keinen Sinn auf Grund des Wertes den Speicher bis auf das letzte Byte auszuquetschen, denn weiterhin hängt die Stacknutzung vom gewählten Protokoll und Einstellungen ab.

In TSCULflash ist Flashen auch von NanoCULs und MiniCULs ergänzt. Vor dem Flashen wird ein "B00" also Reset für die TSCUL Firmware an den nano/Mini geschickt, 1 Sekunde gewartet und dann versucht mit avrdude zu flashen.
Also erst die Firmware in den FHEM/Firmware Ordner kopieren und dann in FHEM mit
TSCULflash <nanodevicename> TSnanoCUL
bzw.
TSCULflash <minidevicename> TSminiCUL
versuchen zu Flashen. Im Log sollte danach (dauert etwas) die avrdude Ausgabe zu finden sein.

Ebenfalls möglich ist das Flashen eines PIGATOR Moduls an einem CUNX
TSCULflash <pigatordevicename>|<cunxdevicename> TSPIGATOR

AESCommReq wird unterstützt. Die Nutzung ist unverändert zu Standard CUL, sprich, beim gewünschten Gerät/Kanal aesCommReq auf 1 setzen und ggf. noch aesKey passend zum verteilten Key setzen.
Es werden von tsculfw nur die Keys 0 (Default Key) bis 3 unterstützt.

Diese Erweiterung erfordert jedoch auch zusätzliche Empfangspuffer im knappen Speicher des CULs. Ein CUL V3 nutzt bis zu 6 Empfangspuffer. Auch der FlashSpeicherbdarf ist angestiegen, so dass einige Protokolle nicht mehr gleichzeitig in ein Kompilat passen. Das sollte aber weniger tragisch sein, da im ASKSIN Modus ohnehin nur HM empfangen werden kann.

Bei CUL V2 reicht der verfügbare Speicher leider hinten und vorne nicht aus, um diese Version nutzen zu können.

Im Anhang ist in TSCUL_fwcode_00_34_FHEM_Modules_00_47.zip wieder die Timestamp Firmware zu finden. Getestet habe ich TSCUNX, TSPIGATOR , TSCUL_V3 , TSCUL_V3_RFR, TSCUNO2, TSCOC und TSSCC. (TSCUL_V3_RFR ist ohne HM Unterstützung, also nur SlowRF)

Die tsculfw Firmware kann für TSCUL_V3, TSCUL_V3_RFR (via USB), TSCUNO2, TSCOC, TSSCC, TSCUNX und TSPIGATOR (an CUNX) mit FHEM mit dem TSCULflash geflashed werden. Die anderen müssen mit dem jeweiligen Flash Programmer geflashed werden. Bei CUNO2 und SCC muss die Bootloadertaste gedrückt werden, bis der Flashvorgang anläuft.
So z.B. https://forum.fhem.de/index.php/topic,24436.msg631743.html#msg631743 kann es mit einem USB CUL Stick gehen, wenn man nicht TSCULflash verwendet.
TSCULflash ist erweitert auf COC, SCC, CCD, rpiaddon, CUNO2 und CUNO. Jedoch ist es nicht ganz so einfach zu handhaben, da zum einen teilweise die Taste zu drücken ist und bei Raspberry PI Modulen die Rechteproblematik für den Zugriff auf die IO-Pins überwunden werden muss. Tips dazu in der Command-Ref auch bei RPI_GPIO.
Bei einem Stapel aus SCC mit aufgesetztem COC, CCD oder (rpiaddon?) ist unbedingt beim SCC Flash darauf zu achten, die Taste am gewünschten Modul zu drücken. Sonst wird das oberste Nicht-SCC Modul mit der SCC Firmware geflashed.
Mit CUNO2 ist das flashen getestet (generell nur über USB!). Wichtig, aber auch hier, die Taste zu drücken.

Es gibt nicht den Luxus des Downloads beim TSCULflash, sondern die Firmware muss händisch in den FHEM/firmware Ordner kopiert werden. Der Typ ist dann z.B. TSCUL_V3.
Beispiel:
TSCULflash MeinCulV3Device TSCUL_V3

Wichtig für SCC Nutzer. TSSTACKED ist entfallen und wird nicht mehr unterstützt.
Statt dessen gibt es das neue Modul STACKABLETS (als Abwandlung von Rudolfs STACKABLE).
Dieses wird sozusagen zwischen die Stackteilnehmer eingebaut.

Beispiel für fhem.cfg:
#erstes SCC Modul als Basis
define SCC_WS868 TSCUL /dev/ttyAMA0@38400 0000
attr SCC_WS868 event-on-change-reading Ints_per_sec,IntCalcStat,MatchStat
attr SCC_WS868 rfmode SlowRF
attr SCC_WS868 room Receiver
attr SCC_WS868 sendpool CUL_HM868,SCC_WS868
attr SCC_WS868 verbose 1

#neues STACKABLETS virtuelles IO device
define STACK_1 STACKABLETS SCC_WS868
attr STACK_1 verbose 1

#zweites SCC Modul
define SCC_HM868 TSCUL FHEM:DEVIO:STACK_1:38400 1034
attr SCC_HM868 event-on-change-reading cond
attr SCC_HM868 hmId F11034


Ergänzender Hinweis zu USB CULs: 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_08\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 1234
bzw.
define CUL_433 TSCUL /dev/CUL433_0@12000000 0000
definiert werden und es gibt keine Probleme mit wechselnder Schnittstelle mehr.
Die Seriennummer kann beim Compilieren der Firmware in der board.h festgelegt werden, so dass damit dann auch /dev/CUL868_1 etc. für mehrere gleiche CULs möglich sind.

Oder für CUNX
define CUNX_868 TSCUL /dev/CUNX868_0@12000000 0000
oder für PIGATOR an CUNX
define PIGATOR_433 TSCUL /dev/CUNXPIM_0@38400 0000
die Seriennummer wird aus der Seriennummer des XMEGA Chips des CUNX gebildet. Unter Linux lsusb nutzen!

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.

Bei nicht nativen USB CULs wie z.B. nanoCUL, miniCUL oder CUNO2, beträgt die Baudrate 38400, dementsprechend muss die Definition beispielsweise so aussehen:
define CUL_868 TSCUL /dev/CUL868@38400 1234
bzw.
define CUL_433 TSCUL /dev/CUL433@38400 0000

Und noch ein Beispiel für eine Definition eines Netzwerk CUNX:
define CUL_868 TSCUL 192.168.178.111:2323 0000
oder für PIGATOR an CUNX
define PIGATOR_433 TSCUL 192.168.178.111:2324 0000
beim PIGATOR sollten zuvor mit Anschluss an USB und öffnen der Schnittstelle mit gewünschten Kommunikationsparametern mit ps oder unter TSCUL mit set PIMstoreBaud die seriellen Kommunikationsparameter zum PIGATOR Modul gespeichert werden, falls sie vom default abweichen.

Oder Netzwerk CUNO2:
define CUNO2_868 TSCUL 192.168.178.110:2323 0000

Die aktuell eingestellte oder per DHCP erhaltene Netzwerkadresse kann mit Lc repektive in TSCUL mit get NetAdresses abgefragt werden. Mit Lp respektive in TSCUL mit get NetPHYlink kann der Linkzustand des Netzwerkanschlusses angezeigt werden.


In der Zip Datei sind ebenfalls die ergänzten Module zu finden, die zur Nutzung der Firmware erforderlich sind.

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
16_TSCUL_RFR.pm -> der 16_CUL_RFR.pm, aus CUL_RFR devices werden damit TSCUL_RFR devices in der fhem.cfg (händisch anzupassen)
16_STACKABLETS.pm -> statt der 16_STACKABLE.pm, aus STACKABLE werden damit STACKABLETS devices in der fhem.cfg (händisch anzupassen)
97_timerTS.pm           -> Austausch-Timerroutinen und fhemFork()

10_UNIRoll_TS.pm  -> statt der 10_UNIRoll.pm, mit TSCUL 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 IO-devices zu verwenden, aus TSKS300 wird dann TSKS300  in der fhem.cfg (händisch anzupassen). Obsolet, da 14_TSCUL_WS.pm nun KS300 unterstützt.
14_TSCUL_TX.pm    -> statt der 14_CUL_TX.pm, mit TSCUL 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 IO-devices zu verwenden, aus CUL_WS wird dann TSCUL_WS  in der fhem.cfg (händisch anzupassen)
14_TSCUL_NC7427.pm  -> NC7427 Unterstützung
15_TSCUL_EM.pm   -> statt der 15_CUL_EM.pm, mit TSCUL IO-devices zu verwenden, aus CUL_EM wird dann TSCUL_EM  in der fhem.cfg (händisch anzupassen)
CalcUtil.pm               -> Hilfsrechenroutinen für Taupunkt und Windstärkeindex
ReadingUtil.pm          -> Hilfsroutinen für Readings

Da diese Module ergänzt werden (müssen!), überleben sie auch ein Update von FHEM.

98_fhemdebug.pm     -> fhemdebug zur zwingenden Nutzung mit 97_timerTS.pm.
98_apptime.pm          -> apptime zur zwingenden Nutzung mit 97_timerTS.pm.
98_apptm.pm            -> apptime zur zwingenden Nutzung mit 97_timerTS.pm, mit geringerem Speicherverbrauch bei weniger Details
10_IT.pm                   -> vermeidet unnötiges busy waiting beim Senden. Wird ohne Schutz von FHEM update überschrieben

Außerdem:

98_TSCULflash.pm     -> Zum Flash von TSCUL_V3, TSPIGATOR (an CUNX) mit Datei in FHEM/firmware

10_CUL_HM.pm         -> angepasste Version zur Nutzung mit TSCUL/tsculfw. Die Nutzung dieses Moduls ist optional. Für CUL_V3, nanoCUL, miniCUL im Multio-HM-IO Betrieb jedoch empfohlen, da sie den EEPROM Verschleiss über das Attribut "rssiSwitchHyst" verringert. Nur diese Version bietet derzeit vollständige TSCUL/tsculfw Unterstützung.
HMConfig.pm             -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden. Einstelllimits für HM-CC-RT-DN Regler P und I Anteil erweitert. Damit kann man mit R-regAdaptive offDeter deutlich mehr an den Regelparametern spielen.
98_HMinfo.pm           -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden. Spaltenbreiten in Tabelle von protoEvents variabel zu verbesserten Übersicht in der Darstellung.
98_HMtemplate.pm   -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden.
Die 4 Dateien entsprechen einem Stand von Mitte 02/2020. Derzeit sollten diese verwendet werden.

10_CULG.pm              -> optional, enthalten, da die Firmware es unterstützt

98_autocreate.pm       -> autocreate mit TSCUL Unterstützung

98_Cumulate               -> Kumulieren von Zählwerten, wie Strom, Regenmenge etc.
98_SAverage.pm         -> Mittelwertbildung von z.B. Temperaturen. Stunde, Tag, Monat und Jahr, sowie ein gleitender Mittelwert der letzten Stunde sind damit möglich.


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_STACKABLETS.pm DevIoTS.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.pm CalcUtil.pm 14_TSCUL_NC7427.pm ReadingUtil.pm 97_timerTS.pm 98_TSCULflash.pm 98_apptime.pm 98_apptm.pm 10_IT.pm 10_CULG.pm 10_CUL_HM.pm HMConfig.pm 98_HMinfo.pm 98_HMtemplate.pm ReadingUtil.pm 98_autocreate.pm 98_Cumulate.pm 98_SAverage.pm 98_fhemdebug.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` }

Noch ein Hinweis: TSCUL fragt auch die Firmwareversion der tsculfw auf 0.34 ab. Eine ältere Version wird also nicht unterstützt!

Frequenzoffset: Für HM ist ein Frequenzoffset von -20.6kHz im EEPROM als default in der tsculfw hinterlegt (das ist ein individuelles Optimum für meinen COC). Dieser Frequenzoffset kann mit set hmFreqOffs umgestellt werden. 0 ist default in der Standard-culfw.
Wenn also keine Antwort von angesprochenen HM devices kommt, dann hmFreqOffs von 0 ausgehend verstellen. CUNX z.B. geht eher in Richtung + mit dem Offset.
Wer das Frequenzspektrum sichtbar machen kann, kann sich die optimale Mitte aller devices ermitteln und mit dem Offset sein CUL dazu passend einstellen.

Noch ein Tip zur Haltbarkeit der CULs mit wenig SRAM (CUL V3, nanoCUL, miniCUL ...). Jedesmal, wenn einem HM-Device das IODev durch Roaming neu zugeordnet wird, führt das zu EEPROM Schreibvorgängen in den beteiligten CULs. Die Lebensdauer des EEPROMs ist begrenzt (100000 Schreibzyklen laut Datenblatt). Daher rate ich zur Nutzung des VorzugsIOs beim Device Attribut IOgrp. Also nicht einfach stumpf
attr HMdeviceName IOgrp VCCU
setzen, sondern
attr HMdeviceName IOgrp VCCU:CUL_mit_gutem_Empfang_fuer_Device
sofern die Roaming Funktionalität entsprechend RSSI für das jeweilige device nicht zwingend benötigt wird. Ein Fallback auf einen anderen CUL bleibt dennoch möglich.
Mit dem Attribut "rssiSwitchHyst", das in der beigefügten 10_CUL_HM.pm verfügbar ist, kann bei den HM-devices die Umschalthysterese für das Roaming von 10 bis auf 2 bei Bedarf für mobile devices verringert werden.
Mit dem Attribut "hmForceLzyCfg" kann wakeup und keep awake support bei solchen CULs aktiviert werden. Das erhöht den EEPROM Verschleiß beim Lesen oder Verändern von Registerwerten bei wakup und lazy config devices.

Ergänzt ist auch noch ein set TX3Send.
Damit lassen sich TX3 Sensordatentelegramme auf 433er CULs versenden.
Beispiel:

define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 TX3Send T:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." SID:23 U")}

define NF_HumOut notify Sen_Aussen:humidity.* {fhem("set TSCUL_WS433 TX3Send H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." SID:23 U")}


Ergänzt ist auch noch ein set KSSend.
Damit lassen sich WS Sensordatentelegramme versenden.
Beispiel:

define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 KSSend T:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." Code:2")}


Hier geht es zur vorherigen Version https://forum.fhem.de/index.php/topic,24436.msg1013844.html#msg1013844 (https://forum.fhem.de/index.php/topic,24436.msg1013844.html#msg1013844).

Gruß, Ansgar.

EDIT: zip nochmal aktualisiert, da mir noch ein Fehler bei wakeup aufgefallen ist.
EDIT2: zip nochmal aktualisiert. Kleinere Änderungen an den FHEM Modulen.
EDIT3: zip nochmal aktualisiert. Änderungen an den FHEM Modulen.
EDIT4: zip nochmal aktualisiert. Änderungen an den FHEM Modulen. 97_timerTS.pm ist jetzt erforderlich zu nutzen, da damit fhemFork() ersetzt wird. timerTS, apptime, apptm aktualisiert. fhemdebug ergänzt.
EDIT5: zip nochmal aktualisiert. Änderungen an den FHEM Modulen.
EDIT6: zip nochmal aktualisiert. Änderungen an den FHEM Modulen.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: noansi am 09 Februar 2020, 21:10:29
Hallo zusammen,

ich habe das obige zip nochmal aktualisiert auf TSCUL_fwcode_00_34_FHEM_Modules_00_45_1.zip, weil mir noch ein Fehler in der Firmware beim wakup aufgefallen ist.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: fredje am 13 Februar 2020, 06:54:24
Hallo,
Ich benutze einen CUL mit der original Firmware V1.66 und habe immer wieder Verbindungsprobleme.
Nun habe ich von  Beta-User erfahren das es für den CUL eine alternative Firmware gibt die das
beheben könnte.

Meine Fragen.
1.) Kann ich die hier beschrieben Firmware in meinen CUL Stick installieren.
2.) Muss ich nach der Installation alle HM Devices neu anlernen.
3.) Gibt es eine Installationsbeschreibung
4.) Wo kann ich die älteren Versionen dieser Firmware Downloaden, möchte nicht gerne auf eine ganz neue Firmware wechseln

Vielen Dank

Internals:
   CMDS       BbCFiAZNkGMKUYRTVWXefmLltux
   CUL_0_MSGCNT 38807
   CUL_0_TIME 2020-02-13 06:19:46
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        /dev/ttyACM0@9600 1034
   DeviceName /dev/ttyACM0@9600
   FD         11
   FHTID      1034
   FUUID      5c9374e9-f33f-2f85-c01f-aab9dd0c79d66a67
   NAME       CUL_0
   NR         55
   NR_CMD_LAST_H 7
   PARTIAL   
   RAWMSG     A0D9180414E71F146AE070732008004
   RSSI       -72
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.66 CUL868
   initString X21
Ar
   MatchList:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2020-02-07 15:31:40   cmds             B b C F i A Z N k G M K U Y R T V W X e f m L l t u x
     2016-11-01 14:26:06   raw             V 1.66 CUL868
     2020-02-13 06:19:46   state           Initialized
   XMIT_TIME:
     1581567609.75294
     1581567746.65337
     1581567911.04719
     1581568297.22579
     1581568422.47627
     1581568568.127
     1581569225.17211
   helper:
     000000:
       QUEUE:
     410247:
       QUEUE:
     46AE07:
       QUEUE:
     48C747:
       QUEUE:
     4AB3E0:
       QUEUE:
     4DA3E0:
       QUEUE:
     4DB039:
       QUEUE:
     4DE7DA:
       QUEUE:
     4E4901:
       QUEUE:
     4E71F1:
       QUEUE:
     5E5701:
       QUEUE:
     5E6553:
       QUEUE:
     5F7EB8:
       QUEUE:
     5F7ECE:
       QUEUE:
     609DB7:
       QUEUE:
     609DBE:
       QUEUE:
     60A7CD:
       QUEUE:
     63E118:
       QUEUE:
     669C1F:
       QUEUE:
     669C21:
       QUEUE:
     669C42:
       QUEUE:
     669C9F:
       QUEUE:
     669CB4:
       QUEUE:
Attributes:
   group      CUL,
   rfmode     HomeMatic
   room       System
   verbose    2


Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: MadMax-FHEM am 13 Februar 2020, 07:30:04
1) sollte gehen (bzw. müsstest du genauer schreiben was für ein CUL: Controller)

2) wenn du es nach Anleitung machst, also "bestehenden" CUL "abändern" (und du eine HMID vergeben hast/diese kennst): nein!!!

EDIT: ok keine HMID gesetzt, sollte sich aber durch die FW nicht ändern. Besser wäre eine gesetzt zu haben (falls du den CUL mal tauschen musst). Und auch besser eine vccu zu haben (wurde aber glaub ich im andern Thread auch schon erwähnt)...

3) im ersten Post sollte alles stehen...

4) weiß nicht, ob wo ältere sind. Aber: wozu!!!?

Gruß, Joachim
Titel: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: RaspiLED am 14 Februar 2020, 20:00:00
Hi,

OT: hier ist die Source für die a-culfw

https://github.com/heliflieger/a-culfw

Hier die Firmware als Download:

https://www.mediafire.com/folder/iuf7lue8r578c/a-culfw

Nimm die neueste! Haben wir zu Hunderten hier Forum ;-)

EDIT: Ich war im falschen Thread! Sorry. Die TS CUL FW ist viel besser für Homematic! Also vergesst die Links von mir, die sind nur bei Themen wie IT oder anderen Sonderwünschen, aber nicht für Homematic! Danke noansi für Deine coole Arbeit!

Gruß Arnd


Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: noansi am 14 Februar 2020, 21:24:47
Hallo Arnd,

wärst Du so nett, wenn Du schon links auf die a-culfw in diesen Thread verteilst, darauf aufmerksam zu machen, dass die keinesfalls was mit der tsculfw zu tun hat und für HM ebenso ungünstig, wie die culfw ist. Danke!
Darauf aufmerksam machen, das erst Lesen und dann möglichst konkret Fragen die bessere Methode ist, um im FHEM Forum Antworten zu bekommen, bitte nicht mit solchen Fehlleitungen bitte auch nicht mit solchen versehentlichen Fehlleitungen.

@fredje: Wenn Du ein bischen nach oben scrollst, dann findest Du auch den link auf die Vorgängerversion der tsculfw und der zugehörigen FHEM Module, wenn Du was älteres willst. Zu Deinem CUL, scheint per USB angebunden zu sein und vermutlich ein CUL V3 zu sein? Was Du hast, kannst Du auf der CUL Platine ablesen, wenn sie von Busware stammt. Das wäre das erste, was Du sicher raus bekommen musst, bevor Du ans Flashen der Firmware denkst (und fragst, wie Du die Firmware wohl flashen könntest). Wie im Zweifel ein zur Hardware passendes Firmware .hex file auf die jeweilige Busware Hardware zu flashen ist, findest Du auf der Busware Seite.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: Thargor am 11 März 2020, 14:21:38
Leider konnte ich die Info nicht finden.
Auf einem (Max) Cube ist die Firmware nicht einsetzbar. Ist das korrekt?
Vielen Dank!
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: noansi am 11 März 2020, 19:10:52
Hallo Thargor,

ZitatAuf einem (Max) Cube ist die Firmware nicht einsetzbar. Ist das korrekt?
Das ist im derzeitigen Stand korrekt.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: noansi am 13 April 2020, 20:01:49
Hallo Zusammen,

ich habe oben https://forum.fhem.de/index.php/topic,24436.msg1022651.html#msg1022651 (https://forum.fhem.de/index.php/topic,24436.msg1022651.html#msg1022651) nochmal die zip Datei aktualisiert, weil sich FHEM Module (nicht die Firmware) darin geändert haben.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: noansi am 14 April 2020, 10:53:27
Hallo Zusammen,

ich habe oben https://forum.fhem.de/index.php/topic,24436.msg1022651.html#msg1022651 (https://forum.fhem.de/index.php/topic,24436.msg1022651.html#msg1022651) nochmal die zip Datei aktualisiert, weil sich FHEM Module (nicht die Firmware) darin geändert haben.

In DevIoTS.pm sind die Hinweise aus https://forum.fhem.de/index.php/topic,110125.msg1041356.html#msg1041356 (https://forum.fhem.de/index.php/topic,110125.msg1041356.html#msg1041356) eingeflossen, inklusive der Behebung der darin im Verlauf aufgefallenen Probleme, insbesondere auch mit strict "refs".

97_timerTS.pm enthält jetzt auch einen Ersatz für fhemFork() und ist damit nicht mehr optional, sondern erforderlich zu nutzen.
fhemFork() hat DevIoTS beim Schließen geöffneter Verbindungen nicht berücksichtigt. Das habe ich ergänzt. Bei mir haben sich damit keine Veränderungen im Verhalten ergeben, aber vielleicht macht es in anderen Betriebssystemumgebungen einen Unterschied, weshalb ich es ergänzt habe.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: pantau am 18 April 2020, 22:50:31
Hallo Ansgar,
ich habe jetzt mit der neusten Version der FHEM Module einen Nebeneffekt der vorher nicht auftrat. Aus Reichweitegründen betreibe ich noch einen CUBe mit a-culfw. Selbstverständlich mit der jeweiligen passenden Definition. Bisher wurden die WS und EM Sensoren sowohl von den TSCUL Devices als auch vom CUBe empfangen. Jetzt nur noch vom TSCUL. Als erstes ist mir das bei dem KS300 aufgefallen, scheint aber bei allen WS und EM so zu sein.
Ist das ein von Dir gewünschtes Verhalten?

Gruß

Peter
P.S: Es sieht so aus, als ob auch keine HMS Sensoren mehr empfangen werden, z.B. auch nicht meine (alten) RM100 Rauchmelder.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: noansi am 19 April 2020, 00:24:21
Hallo Peter,

die Lists von den CULs und den Sensoren würden jetzt helfen.

Es hängt davon ab, wie sie jeweils definiert sind.

Bei den KS300, WS und EM (und TX, NC7427) gibt es inzwischen das Attribut "dupTimeout", was per default 10 Sekunden ist.
Damit wird Mehrfachempfang der gleichen Nachricht weggefiltert.
Wenn die Sensoren nun nur jeweils einmal ohne Attribut IODev definiert sind, dann "gewinnt" die erste Nachricht und folgende gleiche (von anderen IOs) werden verworfen. Wenn TSCUL immer empfängt und schneller ist, dann siehst Du nicht, falls auch was vom CUBe kommt. Oder nur ab und zu mal was vom CUBe, wenn CUL nicht empfängt.
Du kannst das Attribut beim Sensor auf 0 setzen und damit die Filterung abschalten, dann solltest Du wieder sehen, von welchen IOs der Sensor empfangen wird.
Bringt halt nur nichts, da redundante Sensordaten, die auch verarbeitet werden müssen.

Du kannst auch zu einem Sensor zwei Sensordevices anlegen und bei denen jeweils ein anderes IODev via Attribut einstellen. Dann kommt am jeweiligen Sensordevice nur die Nachricht von seinem IODev an. Das ist aber eigentlich dafür Gedacht in zwei nicht überlappenden Empfangsbereichen unter den gleichen Sensoradressen verschiedene Sensoren (also mehr, als die eigentlich möglichen) nutzen zu können.

ZitatEs sieht so aus, als ob auch keine HMS Sensoren mehr empfangen werden, z.B. auch nicht meine (alten) RM100 Rauchmelder.
Via tsculfw? Hat das mal funktioniert? Mit welcher Firmwareversion? (Ich habe selbst keine HMS Testkandidaten)
Via CUBe aber über TSCUL definiert?

Mehr Details für die Glaskugel bitte. Bewußt habe ich HMS jedenfalls nicht den Hahn abgedreht.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: pantau am 19 April 2020, 22:21:17
Zitat von: noansi am 19 April 2020, 00:24:21
Mehr Details für die Glaskugel bitte. Bewußt habe ich HMS jedenfalls nicht den Hahn abgedreht.
Danke für die ausführliche Antwort und die Bestätigung das sich für HMS nichts geändert hat. Hatte ich zwar beim Versionsvergleich auch schon vermutet, aber nach dem Einspielen der letzten Version hatte ich das beschriebene Verhalten.
Nun habe ich den Server noch einmal neu gestartet und alles geht wieder wie zuvor. Anscheinend hatte sich der CUBe "verschluckt".
Was mir jetzt auffällt: Alle HMS (ca. 10 Stück) werden nur vom CUBe empfangen (LASTInputDev CUBe868SL).
Ich habe pro Sensor ein IODev definiert, welches dem Sensor am nächsten liegt. Da sind auch TSCUL dabei. Aber außer dem CUBe empfängt keines der TSCUL HMS Sensoren. WS und EM werden dagegen empfangen.
Zusammen mit der Tatsache das bei "verschlucktem" CUBe gar nichts empfangen wurde, vermute ich jetzt mal das die TSCUL keine HMS Sensoren empfangen, vor allem nicht meine Rauchmelder, aber auch die HMS 100T /TF nicht.
Das ist doch nicht das erwartete Verhalten?
Was kann ich probieren / testen?

Gruß

Peter 
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: noansi am 19 April 2020, 23:26:39
Hallo Peter,

ZitatWas kann ich probieren / testen?

Du kannst mir erst mal verraten, mit welchem Versionstand Du meinst noch HMS mit tsculfw und TSCUL empfangen zu haben. Gerne auch nochmal im Versionsstand zurück gehen, um das auch zu verifizieren.

Hast Du den CUBe als TSCUL oder als CUL definiert?

Die Lists, um die ich gebeten hatte, stehen noch aus.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: pantau am 20 April 2020, 21:42:47
Zitat von: noansi am 19 April 2020, 23:26:39
Du kannst mir erst mal verraten, mit welchem Versionstand Du meinst noch HMS mit tsculfw und TSCUL empfangen zu haben. Gerne auch nochmal im Versionsstand zurück gehen, um das auch zu verifizieren.
Du updatest schneller als ich testen kann, dann überschreibst Du die Zipfiles im Forum und ein Changelog zwischen den Versionen habe ich nicht gefunden. Das macht es ganz schön schwer, etwas nachzuvollziehen ...
Nur eine kleine Anregung :)
Die Tests waren mit FW 0.34 und FHEM 0.46.x. Alles unten gesagte bezieht sich darauf.
Heute Abend probiere ich mal 0.47.
Zitat von: noansi am 19 April 2020, 23:26:39
Hast Du den CUBe als TSCUL oder als CUL definiert?
DANKE. Ich wusste nicht das das geht, da da ja a-culfw drauf läuft... Habe ich jetzt gemacht, alles folgende bezieht sich auf folgende CUBe Definition:
(Mein CUBe hat 4 Empfänger eingebaut und per STACKABLE konfiguriert).
define CUBe868SL TSCUL 192.168.99.52:2323 1234 <= Das geht, siehe 2.)
define CUBeStack2 STACKABLE CUBe868SL
define CUBe433SL TSCUL FHEM:DEVIO:CUBeStack2:9600 0000
define CUBeStack3 STACKABLE CUBe433SL
define CUBe868HM TSCUL FHEM:DEVIO:CUBeStack3:9600 0000 <= Das funktioniert nicht, s.u.
define CUBeStack4 STACKABLE CUBe868HM
define CUBe868N CUL FHEM:DEVIO:CUBeStack4:9600 0000


1.) CUBEe868HM:
Als TSCUL empfängt er nichts:
TSCUL_Parse: CUBe868HM unknown message 072E2E0DE9CAFF0C
2020.04.20 19:48:46 2: TSCUL_Parse: CUBe868HM unknown message 450000060021656A
2020.04.20 19:48:46 2: TSCUL_Parse: CUBe868HM unknown message C8930322F8340733
2020.04.20 19:48:46 2: TSCUL_Parse: CUBe868HM unknown message 18166C434091876B
2020.04.20 19:48:46 2: TSCUL_Parse: CUBe868HM unknown message 00597F3E81350B00
2020.04.20 19:48:50 2: TSCUL_ReceiveDelayed: CUBe868HM Timeout reading answer for get RDl

(Die 10_CUL_HM.pm und bezogene Dateien habe ich nicht ausgetauscht)
Umdefiniert TSCUL => CUL geht: list CUBe868HM
Internals:
   CFGFN      ./hm.cfg
   CMDS       bCAZNELYVXfz*
   CUBe868HM_MSGCNT 622
   CUBe868HM_TIME 2020-04-20 21:05:45
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:TSSTACKED:STACKABLE:
   DEF        FHEM:DEVIO:CUBeStack3:9600 0000
   DeviceName FHEM:DEVIO:CUBeStack3:9600
   FD         8
   FHTID      0000
   FUUID      5c48e3ef-f33f-d5a5-a502-3a70ce813b76e8b4
   IODev      CUBeStack3
   IODevPort  9600
   IODevRxBuffer
   IOReadFn   STACKABLE_IOReadFn
   NAME       CUBe868HM
   NR         125
   NR_CMD_LAST_H 15
   PARTIAL   
   RAWMSG     A0692CEB08A5497EB
   RSSI       -84.5
   STACKED    CUBeStack4
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.26.01 a-culfw Build: PAN (06.11.2017) CUBEx4_8F (F-Band: 868MHz)
   initString X21
Ar
   owner_CCU  vccu
   MatchList:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
     M:TSSTACKED ^\*
     N:STACKABLE ^\*
   READINGS:
     2020-04-20 19:18:41   Xmit-Events     disconnected:1 init:5
     2019-09-01 00:15:15   ccconf          freq:868.300MHz bWidth:101KHz rAmpl:33dB sens:8dB
     2020-04-20 20:06:42   cmds             b C A Z N E L Y V X f z *
     2020-04-20 19:18:41   cond            init
     2019-01-28 20:53:09   fhtbuf          A0E228410633B5D0000000B9CCE0B401D
     2020-04-20 15:19:33   prot_disconnected last
     2020-04-20 19:18:41   prot_init       last
     2020-04-20 21:05:45   state           Initialized
     2019-09-13 10:49:14   uptime          No answer
     2020-04-20 16:54:40   version         V 1.26.01 a-culfw Build: PAN (06.11.2017) CUBEx4_8F (F-Band: 868MHz)
   XMIT_TIME:
     1587406035.63347
     1587406036.33538
     1587406036.98396
     1587406037.31849
     1587406038.1398
     1587406038.71764
     1587406039.44816
     1587406039.60656
     1587406040.62904
     1587406040.9966
     1587407109.26098
     1587407915.57911
     1587407916.18162
     1587408282.67929
     1587408290.93364
   helper:
     5172D5:
       QUEUE:
     5A5159:
       QUEUE:
     648562:
       QUEUE:
     q:
Attributes:
   group      Gateways
   hmId       F11122
   hmProtocolEvents 0_off
   icon       cul_cul
   rfmode     HomeMatic
   room       AZ,CUL_HM,Server
   sendpool   CUBe868SL,rcul,CUL_0,CUBe868HM
   verbose    2


Das funktioniert.

2.) CUBe868SL geht als TSCUL:
list CUBe868SL
CFGFN      ./interfaces.cfg
   CMDS       BbCFiAZNEkGMKLUYRTVWXefhltuxz*
   CUBe868SL_MSGCNT 436
   CUBe868SL_TIME 2020-04-20 21:12:27
   Clients    STACKABLETS:STACKABLE:TSCUL_WS:TSCUL_NC7427:IT:CUL_FHTTK:CUL_HOERMANN:TSCUL_TX:CUL_IR:SOMFY:Revolt:ESA2000:TSCUL_RFR:TSCUL_EM:BS:USF1000:FS20:FHT.*:TSKS300:HMS:FS20V:CUL_TCM97001:CUL_REDIRECT
   DEF        192.168.99.52:2323 1234
   DeviceName 192.168.99.52:2323
   FD         8
   FHTID      1234
   FUUID      5c48e3ea-f33f-d5a5-1d33-0691fdfa09f7b2ea
   NAME       CUBe868SL
   NR         44
   PARTIAL   
   RAWMSG     810c04xx0909a00116310000b000
   RSSI       -73
   STACKED    CUBeStack2
   STATE      Initialized
   TYPE       TSCUL
   VERSION    V 1.26.01 a-culfw Build: PAN (06.11.2017) CUBEx4_8F (F-Band: 868MHz)
   VERSION_TS no
   XmitOpen   0
   initString XP1C
X21
   MatchList:
     1:STACKABLETS ^\*
     2:STACKABLE ^\*
     A:TSCUL_WS ^K[\dA-F]....
     B:TSCUL_NC7427 ^n..........
     C:IT       ^i.(?::.|.....)
     D:CUL_FHTTK ^T[\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F]
     E:CUL_HOERMANN ^R..........
     F:TSCUL_TX ^TXA.........
     G:CUL_IR   ^I............
     H:SOMFY    ^Y[r|t|s]:?[\dA-F]+
     I:Revolt   ^r......................$
     J:ESA2000  ^S................................$
     K:TSCUL_RFR ^[\dA-F][\dA-F][\dA-F][\dA-F]~.
     L:TSCUL_EM ^E0.0[\dA-F]..............
     M:FS20V    ^81..(?:04|0c)..0101a001......00[89a-f]...
     N:BS       ^81..(?:04|0c)..0101a001a5cf
     O:USF1000  ^81..(?:04|0c)..0101a001a5ceaa00....
     P:FS20     ^81..(?:04|0c)..0101a001
     Q:FHT      ^81..(?:04|09|0d)..(?:0909a001|83098301|c409c401)..
     R:TSKS300  ^810d04..4027a001
     T:HMS      ^810e04......a001
     U:CUL_TCM97001 ^s[\dA-F]+
     V:CUL_REDIRECT ^o
   QUEUE:
   READINGS:
     2020-04-20 20:06:41   Xmit-Events     non-HM:2 disconnected:1
     2020-04-20 20:06:40   cmds             B b C F i A Z N E k G M K L U Y R T V W X e f h l t u x z *
     2020-04-20 20:06:41   cond            non-HM
     2020-04-20 20:06:11   prot_disconnected last
     2020-04-20 20:06:41   prot_non-HM     last
     2020-04-20 20:06:41   state           Initialized
     2019-09-13 10:49:30   uptime          0 22:02:48
   helper:
     ChkPart    0
     RA_Timeout 0
     nRec       0
     recAlive   1
     recd       1
     DEVIOTS:
       RXfailTO   
     HM:
       HMactive   0
       hmCrdts    9
     cnd:
       250        2
       253        1
     q:
       HMcndN     250
       hmLanQlen  1
     ref:
       ioBR       3840
       lHMt       4294967295
       lSys       1673805971.12738
       pngLm      80
       scF        1
     sendpool:
       HASH(0x55611011bb98)
       HASH(0x55610f5e8400)
       HASH(0x556112fe8f30)
Attributes:
   group      Gateways
   model      CUN
   rfmode     SlowRF
   room       Server,AZ
   sendpool   CUBe868SL,rcul,CUL_0,CUBe868HM


Ein anderes slowRF CUL:
Internals:
   CFGFN      ./interfaces.cfg
   CMDS       BCFGJKMRTUVWXYeilmtux
   CUL_0_MSGCNT 53
   CUL_0_TIME 2020-04-20 21:14:21
   Clients    STACKABLETS:STACKABLE:TSCUL_WS:TSCUL_NC7427:IT:CUL_FHTTK:CUL_HOERMANN:TSCUL_TX:CUL_IR:SOMFY:Revolt:ESA2000:TSCUL_RFR:TSCUL_EM:BS:USF1000:FS20:FHT.*:TSKS300:HMS:FS20V:CUL_TCM97001:CUL_REDIRECT
   DEF        192.168.99.111:2002 1034
   DeviceName 192.168.99.111:2002
   FD         7
   FHTID      1034
   FUUID      5c48e3ea-f33f-d5a5-6c48-a0271bcd55cbf5c2
   NAME       CUL_0
   NR         40
   PARTIAL   
   RAWMSG     K21617162
   RFR_CULID  01
   RFR_REC_RSSI -80
   RSSI       -66
   STATE      Initialized
   SlowRF_IntCalcStat Last: 15.0  Min: 5.0  Mean: 10.5  Max: 56.0
   TYPE       TSCUL
   VERSION    VTS 0.34 CUL868
   VERSION_HW CUL_V3.4_0004
   VERSION_TS no ASKSIN
   XmitOpen   0
   initString XP1C
X21
   MatchList:
     1:STACKABLETS ^\*
     2:STACKABLE ^\*
     A:TSCUL_WS ^K[\dA-F]....
     B:TSCUL_NC7427 ^n..........
     C:IT       ^i.(?::.|.....)
     D:CUL_FHTTK ^T[\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F]
     E:CUL_HOERMANN ^R..........
     F:TSCUL_TX ^TXA.........
     G:CUL_IR   ^I............
     H:SOMFY    ^Y[r|t|s]:?[\dA-F]+
     I:Revolt   ^r......................$
     J:ESA2000  ^S................................$
     K:TSCUL_RFR ^[\dA-F][\dA-F][\dA-F][\dA-F]~.
     L:TSCUL_EM ^E0.0[\dA-F]..............
     M:FS20V    ^81..(?:04|0c)..0101a001......00[89a-f]...
     N:BS       ^81..(?:04|0c)..0101a001a5cf
     O:USF1000  ^81..(?:04|0c)..0101a001a5ceaa00....
     P:FS20     ^81..(?:04|0c)..0101a001
     Q:FHT      ^81..(?:04|09|0d)..(?:0909a001|83098301|c409c401)..
     R:TSKS300  ^810d04..4027a001
     T:HMS      ^810e04......a001
     U:CUL_TCM97001 ^s[\dA-F]+
     V:CUL_REDIRECT ^o
   QUEUE:
   READINGS:
     2020-04-20 21:13:49   Ints_per_sec    SI: 9.38892  TI: 0.24612  S: 0.47889  L: 0.11448  F: 0.13737  M: 0.01336
     2020-04-20 11:25:38   SlowRFSndFreq   868.300MHz +0.000kHz
     2020-04-20 20:06:10   Xmit-Events     disconnected:1 non-HM:1
     2019-12-30 00:33:07   ccconf          freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB
     2020-04-20 20:06:10   cmds             B C F G J K M R T U V W X Y e i l m t u x
     2020-04-20 20:06:10   cond            non-HM
     2019-08-19 21:02:21   fhtbuf          AE
     2020-04-20 20:06:09   prot_disconnected last
     2020-04-20 20:06:10   prot_non-HM     last
     2019-08-17 01:23:10   raw             0100
     2020-04-20 20:06:11   state           Initialized
     2020-04-20 20:28:57   uptime          5 21:23:32
     2020-04-20 20:28:52   version         VTS 0.34 CUL868
   helper:
     ChkPart    0
     RA_Timeout 0
     SVTS       1
     nRec       0
     recAlive   1
     recd       1
     DEVIOTS:
       RXfailTO   
     HM:
       hmCrdts    9
     RFR_RSSI_STAT:
       N          7
       RSSILast   -80
       RSSIMax    -80
       RSSIMean   -80
       RSSIMin    -80
     SRf:
       lastIntC   52856592
       lastIntCTime 1587410029.70956
       lastIntTOC 4589819
       lastSyncC  10299272
       lastloFltC 1389261
       lastmtchErrC 326983
       lastupFltC 2042253
       IntStat:
         Max        56
         Mean       10.5
         Min        5
         N          8
     cnd:
       250        1
       253        1
     ids:
     q:
       HMcndN     250
       hmLanQlen  1
     ref:
       ioBR       3840
       lHMt       4294967295
       lSys       1673805969.86989
       pngLm      80
       scF        1
     sendpool:
       HASH(0x55611002e548)
       HASH(0x55611011bb98)
       HASH(0x556112fe8f30)
     zCStat:
Attributes:
   group      Gateways
   room       Keller,Server
   sendpool   CUBe868SL,rcul,CUL_0,CUBe868HM


Jetzt zum Problem der HMS:
Hier eines der Devices:
Internals:
   CFGFN      ./sensor.cfg
   CODE       1001
   CUBe868SL_MSGCNT 65
   CUBe868SL_RAWMSG 810e04xx0511a0014352000001480200
   CUBe868SL_RSSI -74.5
   CUBe868SL_TIME 2020-04-20 21:16:42
   DEF        1001
   FUUID      5c48e3f6-f33f-d5a5-db97-e66b5ddfc9750ef4
   IODev      CUL_0
   LASTInputDev CUBe868SL
   MSGCNT     65
   NAME       hms100t
   NR         887
   STATE      T: 24.8  Bat: ok
   TYPE       HMS
   READINGS:
     2020-04-20 21:16:42   ExactId         4352
     2020-04-20 21:16:42   battery         ok
     2020-04-20 21:16:42   batteryState    ok
     2020-04-20 21:16:42   state           T: 24.8  Bat: ok
     2020-04-20 21:16:42   temperature     24.8
     2020-04-20 21:16:42   type            HMS100T
Attributes:
   IODev      CUL_0
   alias      Vorratskeller
   comment    Keller_Vorrat
   model      hms100-t
   room       Keller
   timeout    0

Vor der Umstellung des CUBe868SL hat mich gestört, dass bei allen 10 HMS die ich habe bei LastInputDev immer der CUBe868SL steht. Das hat sich auch nicht geändert als ich das Device auf TSCUL umgestellt habe. Meine Empfangssituation erklärt das nicht, da sollten auch andere Devices stehen. Durch die Umstellung ist allerdings bewiesen das TSCUL (in Kombination mit a-culfw) HMS empfängt. Es gibt für SlowRF jetzt nur noch TSCUL Definitionen. Außerdem ist mir aufgefallen das der MSGCNT pro Sendung bei einigen HMS um mehr als 1 hochzählt. Daraus schliesse ich, das der HMS von mehreren TSCUL empfangen wird?!
Insofern sehe ich in meiner jetzigen Konfiguration erst mal kein Problem mit HMS Empfang (mehr)?!

3.) Der Wechsel der CUBe[433,868]SL von CUL nach TSCUL hat mich "Clients" gekostet. Zuvor konnte ich z.B HIDEKI empfangen, da habe ich in der a-culfw einiges "einkompiliert". Das scheint TSCUL nicht abzufragen, nicht zu "verstehen"?

Zusätzliche Fragen:
- Sollte ich den CUBe besser als STACKABLETS definieren?
- Siehst Du eine Chance Deine TSCUL Firmware Änderungen in a-culfw einzubauen, damit ich meinenCUBe damit flashen kann?
- Ich könnte mich daran versuchen, könntest Du als Unterstützung einen Diff zw Deiner und der culfw zur Verfügung stellen?
- Oder ist das in meinem Fall aussichtslos, da das STACKTABLETS mit dem CUBe nicht laufen kann?

Vielen Dank schon mal für's durchlesen.  ;)
Gruß

Peter

Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: noansi am 20 April 2020, 23:54:12
Hallo Peter,

ZitatDANKE. Ich wusste nicht das das geht, da da ja a-culfw drauf läuft...
Wie Du festgestellt hast, mit HM geht da gar nichts mit TSCUL, weil die a-culfw mit timestamps nichts am Hut hat und weder mit dem gesendeten was richtig anfangen kann, noch das empfangene passend schickt.
SlowRf geht, so weit sich die von der a-culfw kommenden Daten mit dem von tsculfw kommenden Daten der jeweiligen Protokolle deckt (KS, EM und TX Empfang geht). Aber da Du nicht weißt, wo Unterschiede sind, lass es bitte bei a-culfw und CUL in Verbindung mit STACKABLE. Insbesondere auch Veränderung von CUBe Einstellungen via TSCUL geht in die Hose. Senden wird auch nicht glücklich machen.
Mir ging es primär darum, zu wissen, was Du in FHEM definierst und einstellst.
ZitatEs gibt für SlowRF jetzt nur noch TSCUL Definitionen.
Der einzige Vorteil, den Du damit für KS, EM und TX Sensoren hättest (unter Nutzung auch der TS Module mit den Sensoren), wäre die Empfangsstatistik -> get dispSRFStat bei einem TSCUL CUL.

Wenn gestackte devices genutzt werden gilt:
CUL mit culfw/a-culfw  -> STACKABLE -> CUL mit culfw/a-culfw
TSCUL mit tsculfw -> STACKABLETS -> TSCUL mit tsculfw
Es gibt dabei wesentliche Unterschiede. Somit ist das bei Deinem Test schon mal schief gelaufen.
Außerdem mit TSCUL betreffende Sensordevices ebenfalls auf TS Variante umstellen.

2019-12-30 00:33:07   ccconf          freq:868.300MHz bWidth:325KHz rAmpl:42dB sens:4dB
Beim CUL_0 kannst Du mal mit einem get ccconf die altuellen Einstellungen neu lesen.

ZitatDurch die Umstellung ist allerdings bewiesen das TSCUL (in Kombination mit a-culfw) HMS empfängt.
oder genauer, würde die tsculfw ein HMS Telegramm empfangen, dann würde es mit TSCUL richtig weiter verarbeitet.

ZitatVor der Umstellung des CUBe868SL hat mich gestört, dass bei allen 10 HMS die ich habe bei LastInputDev immer der CUBe868SL steht.
Was darauf hindeutet, dass tsculfw die HMS Telegramme nicht empfängt/dekodiert.

ZitatAußerdem ist mir aufgefallen das der MSGCNT pro Sendung bei einigen HMS um mehr als 1 hochzählt. Daraus schliesse ich, das der HMS von mehreren TSCUL empfangen wird?!
Eher nicht denke ich. Wiederholt HMS?
Schalt den CUBe mal ab und schau, ob dann noch was von HMS reinkommt.

ZitatDas scheint TSCUL nicht abzufragen, nicht zu "verstehen"?
Kann gut sein, siehe oben. Ich bemühe mich nicht, die a-culfw mit TSCUL voll zu unterstützen.

Zitat- Siehst Du eine Chance Deine TSCUL Firmware Änderungen in a-culfw einzubauen, damit ich meinenCUBe damit flashen kann?
Also, ich habe einen CUBe mit einem 433er Zusatz-Modul mit a-culfw laufen. Von daher besteht eine gewisse Motivation die tsculfw mal auf den CUBe zu portieren.
Aber jetzt schon begeistert mich der 433er Empfang via CUBe schon nicht wirklich. Entweder ein bescheidenes Modul oder zu viele Störungen durch die CUBe Elektronik oder die Interruptauswertung zweier SlowRF Empfänger ist einfach schon zu störend untereinander. Das senkt die Motivation massiv, da auch ein sehr erheblicher Zeitaufwand dahinter steht.
Den ts Anteil in die a-culfw einzubauen tut es so auch nicht wirklich, weil das Timer/Delay Handling in a-culfw erst mal umgestellt werden müßte, was der Portierung von der tsculfw schon wieder recht nahe kommt.

Zitat- Ich könnte mich daran versuchen, könntest Du als Unterstützung einen Diff zw Deiner und der culfw zur Verfügung stellen?
Der Quelltext der tsculfw ist doch im zip dabei!

Zitat- Oder ist das in meinem Fall aussichtslos, da das STACKTABLETS mit dem CUBe nicht laufen kann?
In meiner Testumgebung mit besagtem CUBe läuft 16_STACKABLETS.pm wunderbar mit 00_TSCUL.pm.  :)
STACKABLE und STACKABLETS sind jeweils Aufsätze, um die mit '*' Protokoll versehen Nachrichten vom CUL innerhalb von FHEM durchzureichen, respektive richtg ans CUL über die Stackebenen zu senden.

Und verstehe ich es richtig, dass Du noch mit keiner tsculfw Version in der Vergangenheit HMS Telegramme zweifelsfrei empfangen hast? Sondern eher die HMS Nachrichten von der culfw Nutzung her vermisst?
Dann brauche ich nicht danach zu schauen, ob ich in jüngerer Vergangenheit HMS mit einer Nebenwirkung in der Firmware ausgehebelt habe. Sondern dann brauche ich erst mal einen zuverlässigen Sender für HMS Telegramme und/oder vernünftige Rohdatenmitschnitte.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: pantau am 21 April 2020, 13:15:21
Zitat von: noansi am 20 April 2020, 23:54:12
SlowRf geht, so weit sich die von der a-culfw kommenden Daten mit dem von tsculfw kommenden Daten der jeweiligen Protokolle deckt (KS, EM und TX Empfang geht). Aber da Du nicht weißt, wo Unterschiede sind, lass es bitte bei a-culfw und CUL in Verbindung mit STACKABLE. Insbesondere auch Veränderung von CUBe Einstellungen via TSCUL geht in die Hose. Senden wird auch nicht glücklich machen.
Danke für die Hinweise, ich war/bin aber zufrieden das jetzt nicht alle EM und WS Devices doppelt definiert sind. Das zusammenführen von CUL und TSCUL EM und WS ist ein Problem für mich.
Zitat von: noansi am 20 April 2020, 23:54:12
Was darauf hindeutet, dass tsculfw die HMS Telegramme nicht empfängt/dekodiert.
Ja kann ich jetzt bestätigen, die Beobachtung gestern beruhte auf 2 Sensoren die versehentlich den gleiche Code nutzten... tsculfw empfängt HMS nicht.
Zitat von: noansi am 20 April 2020, 23:54:12
Und verstehe ich es richtig, dass Du noch mit keiner tsculfw Version in der Vergangenheit HMS Telegramme zweifelsfrei empfangen hast? Sondern eher die HMS Nachrichten von der culfw Nutzung her vermisst?
Dann brauche ich nicht danach zu schauen, ob ich in jüngerer Vergangenheit HMS mit einer Nebenwirkung in der Firmware ausgehebelt habe. Sondern dann brauche ich erst mal einen zuverlässigen Sender für HMS Telegramme und/oder vernünftige Rohdatenmitschnitte.
Was in der Vergangenheit war, ist schwer nachzuvollziehen. Momentan würde ich behaupten, das ich den nicht funktionierenden tsculfw HMS Empfang übersehen habe, da die Daten immer über den CUBe mit a-culfw geliefert wurden/werden.

Wie sehen denn vernünftige Rohdatenmitschnitte aus und wie kann ich die erzeugen, so das Du die nutzen kannst?

Gruß

Peter
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: noansi am 21 April 2020, 21:11:35
Hallo Peter,

ZitatWie sehen denn vernünftige Rohdatenmitschnitte aus und wie kann ich die erzeugen, so das Du die nutzen kannst?
Mit einem nicht RFR CUL, aber SlowRF nutzend und im Empfangsbereich eines regelmäßig sendenen HMS Sensors positioniert, brauchst Du nur set X39 setzen und den verbose level für den CUL auf 4 via Attribut. Auch den CUBe auf verbose 4.
Dann landen die Empfangsrohdaten im Log und die Datentelgramme vom CUBe.
Bei dem Sensor beobachten, wann via CUBe was empfangen wird. Dann wieder set X21 beim CUL und verbose wieder auf 1, und auch beim CUBe.

So was ist dann im Log, hier z.B. von einem KS Sensor.
2020.04.21 20:56:33.958 3: set CUNX2_WS868 raw X39
2020.04.21 20:56:48.844 4: TSCUL_Parse: CUNX2_WS868 raw SlowRf:
H15432 L1496 s00
H5536 L48 s00
H944 L352 s00
H864 L344 s02
H824 L352 s02
H888 L360 s02
H840 L360 s02
H848 L352 s02
H848 L360 s02
H848 L360 s02
H848 L352 s02
H856 L360 s02
H400 L784 s02
H400 L792 s20
H912 L304 s20
H872 L352 s20
H856 L360 s20
H408 L784 s20
H400 L792 s20
H904 L312 s20
H416 L792 s20
H912 L304 s20
H408 L792 s20
H904 L304 s20
H912 L312 s20
H400 L792 s20
H912 L304 s20
H408 L792 s20
H400 L792 s20
H912 L312 s20
H864 L352 s20
H856 L360 s20
H400 L784 s20
H912 L304 s20
H408 L792 s20
H912 L304 s20
H864 L360 s20
H400 L784 s20
H408 L792 s20
H408 L792 s20
H408 L792 s20
H912 L312 s20
H416 L792 s20
H904 L312 s20
H408 L800 s20
H400 L792 s20
H912 L312 s20
H408 L800 s20
H904 L312 s20
H856 L360 s20
H400 L784 s20
H912 L304 s20
H408 L792 s20
H912 L304 s20
H416 L784 s20
H408 L792 s20
H912 L304 s20
H416 L792 s20
H408 L784 s20
H912 L312 s20
H864 L360 s20
H408 L784 s20.
2020.04.21 20:56:48.846 4: TSCUL_Parse: CUNX2_WS868 K51147246EA -85

Das brauche ich dann alles, um daraus mit der Information der zeitlichen Nähe zum Ende der Daten hin, das betreffende darin auch zu finden. Das jeweilige H Telegramm vom CUBe sollte dann auch da drin stehen.

Mehrere Telgramme so aufzunehmen verbessert deutlich die Datenlage für mich.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: pantau am 21 April 2020, 22:07:53
Im Anhang ein erstes Log.
Folgende HMS Devices habe ich definiert:
define hms100w HMS f7aa
define hms100wd HMS 2e41
define hms100co HMS 1008
define hms100mg HMS 1006
define hms100fit HMS 100e
define hms100tf HMS eb90
define hms100t HMS 1001
define WZ_T HMS 4321
define Test_T HMS 4314
define Temp_Kiz2_Pati HMS 4305
define rm100_wz HMS 55b0
define rm100_fl HMS 4391
define rm100_ke HMS 0a5b
define rm100_dg HMS 2a73
define rm100_az HMS bc78

Den Sensor Test_T (CODE 4314) habe ich neben das CUL_0 (im Keller) gestellt. Einen Empfang habe ich bei diesem Sensor um 21:39:37 registriert.
list Test_T:
Internals:
   CFGFN      ./sensor.cfg
   CODE       4314
   CUBe868SL_MSGCNT 266
   CUBe868SL_RAWMSG 810e04xx0510a0014314000000760138
   CUBe868SL_RSSI -74.5
   CUBe868SL_TIME 2020-04-21 22:04:25
   DEF        4314
   FUUID      5c48e3f6-f33f-d5a5-d426-2862dbf855dccf95
   IODev      CUBe868N
   LASTInputDev CUBe868SL
   MSGCNT     266
   NAME       Test_T
   NR         897
   STATE      T: 17.6  H: 38  Bat: ok
   TYPE       HMS
   Helper:
     DBLOG:
       data:
         logdb:
           TIME       1587496468.66686
           VALUE      T: 17.6  H: 38  Bat: ok D: 3.1
       dewpoint:
         logdb:
           TIME       1587496468.66686
           VALUE      3.1
       humidity:
         logdb:
           TIME       1587496468.66686
           VALUE      38
       temperature:
         logdb:
           TIME       1587484465.43338
           VALUE      17.6
   READINGS:
     2020-04-21 22:04:25   battery         ok
     2020-04-21 22:04:25   batteryState    ok
     2020-04-21 21:14:28   dewpoint        3.1
     2020-04-21 22:04:25   humidity        38
     2020-04-21 22:04:25   state           T: 17.6  H: 38  Bat: ok
     2020-04-21 22:04:25   temperature     17.6
     2020-04-21 22:04:25   type            HMS100TF
Attributes:
   DbLogInclude .*
   IODev      CUBe868N
   event-on-change-reading .*
   room       AZ,HMS
   timeout    0

Der CUBe steht im 1. Stock. Ich kann nur bei dem Sensor garantieren das er von beiden CUL empfangen wird.
Aber vom CUBe sind einige HMS Empfänge im Log. Die raw Daten vom anderen CUL kann  ich leider nicht interpretieren.
Sollte das nicht reichen, zeichne ich gerne noch mal länger auf. Ich war nur nicht sicher wie groß die Anhänge sein können.

Danke

Peter
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: noansi am 21 April 2020, 23:16:21
Hallo Peter,

zur genannten Uhrzeit kommen vom CUBe868SL 3 HMS messages:
2020.04.21 21:39:37 4: TSCUL_Parse: CUBe868SL H431400760138FF -74.5
2020.04.21 21:39:37 4: TSCUL_Parse: CUBe868SL H430520200252FF -74.5
2020.04.21 21:39:38 4: TSCUL_Parse: CUBe868SL H432120140241FF -74.5
2020.04.21 21:39:38 4: TSCUL_Parse: CUL_0 raw SlowRf: 


vom CUL_0 leider nichts dazu.

Eventuell liegt es an den Einstellungen.
Mach bitte bei beiden mal ein get ccconf und schick bitte das aktualisierte Ergebnis dazu.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: pantau am 21 April 2020, 23:46:26
CUBe868SL:
Internals:
   CFGFN      ./interfaces.cfg
   CMDS       BbCFiAZNEkGMKLUYRTVWXefhltuxz*
   CUBe868SL_MSGCNT 8188
   CUBe868SL_TIME 2020-04-21 23:39:39
   Clients    STACKABLETS:STACKABLE:TSCUL_WS:TSCUL_NC7427:IT:CUL_FHTTK:CUL_HOERMANN:TSCUL_TX:CUL_IR:SOMFY:Revolt:ESA2000:TSCUL_RFR:TSCUL_EM:BS:USF1000:FS20:FHT.*:TSKS300:HMS:FS20V:CUL_TCM97001:CUL_REDIRECT
   DEF        192.168.99.52:2323 1234
   DeviceName 192.168.99.52:2323
   FD         8
   FHTID      1234
   FUUID      5c48e3ea-f33f-d5a5-1d33-0691fdfa09f7b2ea
   NAME       CUBe868SL
   NR         44
   PARTIAL   
   RAWMSG     810e04xx0510a0014323000000400233
   RSSI       -74.5
   STACKED    CUBeStack2
   STATE      Initialized
   TYPE       TSCUL
   VERSION    V 1.26.01 a-culfw Build: PAN (06.11.2017) CUBEx4_8F (F-Band: 868MHz)
   VERSION_TS no
   XmitOpen   0
   initString XP1C
X21
   MatchList:
     1:STACKABLETS ^\*
     2:STACKABLE ^\*
     A:TSCUL_WS ^K[\dA-F]....
     B:TSCUL_NC7427 ^n..........
     C:Hideki   ^P12#75[A-F0-9]{17,30}
     C:IT       ^i.(?::.|.....)
     C:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     D:CUL_FHTTK ^T[\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F]
     E:CUL_HOERMANN ^R..........
     F:TSCUL_TX ^TXA.........
     G:CUL_IR   ^I............
     H:SOMFY    ^Y[r|t|s]:?[\dA-F]+
     I:Revolt   ^r......................$
     J:ESA2000  ^S................................$
     K:TSCUL_RFR ^[\dA-F][\dA-F][\dA-F][\dA-F]~.
     L:TSCUL_EM ^E0.0[\dA-F]..............
     M:FS20V    ^81..(?:04|0c)..0101a001......00[89a-f]...
     N:BS       ^81..(?:04|0c)..0101a001a5cf
     O:USF1000  ^81..(?:04|0c)..0101a001a5ceaa00....
     P:FS20     ^81..(?:04|0c)..0101a001
     Q:FHT      ^81..(?:04|09|0d)..(?:0909a001|83098301|c409c401)..
     R:TSKS300  ^810d04..4027a001
     T:HMS      ^810e04......a001
     U:CUL_TCM97001 ^s[\dA-F]+
     V:CUL_REDIRECT ^o
   QUEUE:
   READINGS:
     2020-04-21 08:54:36   Xmit-Events     disconnected:1 non-HM:2
     2020-04-21 23:39:19   ccconf          freq:868.300MHz freqOffs:0.000kHz bWidth:325kHz freqIF:152.34kHz rAmpl:42dB sens:4dB dRate:5.604kBit/s
agcPrio:0 agcWait:16 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:0 AGC_FREEZE:0
CCAmode:0 csRelThr:dis csAbsThr:0dB
     2020-04-21 08:54:35   cmds             B b C F i A Z N E k G M K L U Y R T V W X e f h l t u x z *
     2020-04-21 08:54:36   cond            non-HM
     2020-04-21 08:54:00   prot_disconnected last
     2020-04-21 08:54:36   prot_non-HM     last
     2020-04-21 08:54:36   state           Initialized
     2019-09-13 10:49:30   uptime          0 22:02:48
   helper:
     ChkPart    0
     RA_Timeout 0
     nRec       0
     recAlive   1
     recd       1
     DEVIOTS:
       RXfailTO   
     HM:
       HMactive   0
       hmCrdts    9
     cnd:
       250        2
       253        1
     q:
       HMcndN     250
       hmLanQlen  1
     ref:
       ioBR       3840
       lHMt       4294967295
       lSys       1673852040.05568
       pngLm      80
       scF        1
     sendpool:
       HASH(0x558e6ddf4f30)
       HASH(0x558e6d301e30)
       HASH(0x558e70ce0ab0)
Attributes:
   group      Gateways
   model      CUN
   rfmode     SlowRF
   room       Server,AZ
   sendpool   CUBe868SL,rcul,CUL_0,CUBe868HM
   verbose    0

CUL_0:
Internals:
   CFGFN      ./interfaces.cfg
   CMDS       BCFGJKMRTUVWXYeilmtux
   CUL_0_MSGCNT 6525
   CUL_0_TIME 2020-04-21 23:42:32
   Clients    STACKABLETS:STACKABLE:TSCUL_WS:TSCUL_NC7427:IT:CUL_FHTTK:CUL_HOERMANN:TSCUL_TX:CUL_IR:SOMFY:Revolt:ESA2000:TSCUL_RFR:TSCUL_EM:BS:USF1000:FS20:FHT.*:TSKS300:HMS:FS20V:CUL_TCM97001:CUL_REDIRECT
   DEF        192.168.99.111:2002 1034
   DeviceName 192.168.99.111:2002
   FD         7
   FHTID      1034
   FUUID      5c48e3ea-f33f-d5a5-6c48-a0271bcd55cbf5c2
   NAME       CUL_0
   NR         40
   PARTIAL   
   RAWMSG     K51520100
   RFR_CULID  01
   RFR_REC_RSSI -70
   RSSI       -96.5
   STATE      Initialized
   SlowRF_IntCalcStat Last: 40.0  Min: 5.0  Mean: 20.8  Max: 63.0
   TYPE       TSCUL
   VERSION    VTS 0.34 CUL868
   VERSION_HW CUL_V3.4_0004
   VERSION_TS no ASKSIN
   XmitOpen   0
   initString XP1C
X21
   MatchList:
     1:STACKABLETS ^\*
     2:STACKABLE ^\*
     A:TSCUL_WS ^K[\dA-F]....
     B:TSCUL_NC7427 ^n..........
     C:Hideki   ^P12#75[A-F0-9]{17,30}
     C:IT       ^i.(?::.|.....)
     C:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     D:CUL_FHTTK ^T[\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F]
     E:CUL_HOERMANN ^R..........
     F:TSCUL_TX ^TXA.........
     G:CUL_IR   ^I............
     H:SOMFY    ^Y[r|t|s]:?[\dA-F]+
     I:Revolt   ^r......................$
     J:ESA2000  ^S................................$
     K:TSCUL_RFR ^[\dA-F][\dA-F][\dA-F][\dA-F]~.
     L:TSCUL_EM ^E0.0[\dA-F]..............
     M:FS20V    ^81..(?:04|0c)..0101a001......00[89a-f]...
     N:BS       ^81..(?:04|0c)..0101a001a5cf
     O:USF1000  ^81..(?:04|0c)..0101a001a5ceaa00....
     P:FS20     ^81..(?:04|0c)..0101a001
     Q:FHT      ^81..(?:04|09|0d)..(?:0909a001|83098301|c409c401)..
     R:TSKS300  ^810d04..4027a001
     T:HMS      ^810e04......a001
     U:CUL_TCM97001 ^s[\dA-F]+
     V:CUL_REDIRECT ^o
   QUEUE:
   READINGS:
     2020-04-21 23:42:12   ITSndFreq       433.920MHz +0.000kHz
     2020-04-21 23:35:22   Ints_per_sec    SI: 96.22930  TI: 6.81521  S: 16.80436  L: 2.81154  F: 4.15245  M: 0.97278
     2020-04-21 23:41:59   SlowRFSndFreq   868.300MHz +0.000kHz
     2020-04-21 23:41:14   SlowRfconf      freq:868.300MHz freqOffs:0.000kHz bWidth:325kHz freqIF:330.08kHz rAmpl:42dB sens:12dB dRate:2.461kBit/s
agcPrio:0 agcWait:16 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:0 AGC_FREEZE:0
CCAmode:1 csRelThr:10dB csAbsThr:7dB
     2020-04-21 08:53:59   Xmit-Events     disconnected:1 non-HM:1
     2020-04-21 23:41:01   ccconf          freq:868.300MHz freqOffs:0.000kHz bWidth:325kHz freqIF:330.08kHz rAmpl:42dB sens:12dB dRate:2.461kBit/s
agcPrio:0 agcWait:16 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:0 AGC_FREEZE:0
CCAmode:1 csRelThr:10dB csAbsThr:7dB
     2020-04-21 23:41:07   cmds             B C F G J K M R T U V W X Y e i l m t u x
     2020-04-21 08:53:59   cond            non-HM
     2020-04-21 23:41:31   fRfconf         freq:868.300MHz freqOffs:0.000kHz bWidth:541kHz freqIF:304.69kHz rAmpl:42dB sens:4dB dRate:249.939kBit/s
agcPrio:0 agcWait:32 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:3 AGC_FREEZE:0
CCAmode:0 csRelThr:dis csAbsThr:0dB
     2019-08-19 21:02:21   fhtbuf          AE
     2020-04-21 08:53:58   prot_disconnected last
     2020-04-21 08:53:59   prot_non-HM     last
     2019-08-17 01:23:10   raw             0100
     2020-04-21 08:54:00   state           Initialized
     2020-04-20 20:28:57   uptime          5 21:23:32
     2020-04-21 23:41:39   version         VTS 0.34 CUL868
   helper:
     ChkPart    0
     RA_Timeout 0
     SVTS       1
     nRec       0
     recAlive   1
     recd       1
     DEVIOTS:
       RXfailTO   
     HM:
       hmCrdts    9
     RFR_RSSI_STAT:
       N          100
       RSSILast   -70
       RSSIMax    -68
       RSSIMean   -73.4949999999999
       RSSIMin    -87.5
     SRf:
       lastIntC   61485654
       lastIntCTime 1587504922.30442
       lastIntTOC 5399010
       lastSyncC  12274797
       lastloFltC 1674746
       lastmtchErrC 384136
       lastupFltC 2472853
       IntStat:
         Max        63
         Mean       20.7745098039216
         Min        5
         N          102
     cnd:
       250        1
       253        1
     q:
       HMcndN     250
       hmLanQlen  1
     ref:
       ioBR       3840
       lHMt       4294967295
       lSys       1673852038.79709
       pngLm      80
       scF        1
     sendpool:
       HASH(0x558e6dd02370)
       HASH(0x558e6ddf4f30)
       HASH(0x558e70ce0ab0)
Attributes:
   group      Gateways
   room       Keller,Server
   sendpool   CUBe868SL,rcul,CUL_0,CUBe868HM
   verbose    0
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: noansi am 22 April 2020, 07:20:04
Hallo Peter,

- stell den Sensor in mindestens 2m Abstand vom CUL_0, dann neuer Aufzeichnungsversuch, wie zuvor

- dann set sens 8 beim CUL_0 und neuer Aufzeichnungsversuch, wie zuvor

- dann set sens 4 beim CUL_0 und neuer Aufzeichnungsversuch, wie zuvor

Dann wieder set sens 12 beim CUL_0, sonst ist meine Erfahrung, dass die KS, EM, TX Sensoren schlechter empfangen werden.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: pantau am 22 April 2020, 18:18:23
So im Anhang jetzt der neue Versuch.
17:18:23  X39 + vorher sens 8
17:28 sens 4
Ich habe glaube ich gestern einen Fehler gemacht. Ich habe auch Sensoren die nur über HMS Emulation empfangen werden. Einen davon habe ich wohl gestern "getrackt"/verwendet. Dies sind alle mit Code 43xx. Ignoriere die bitte. Der mit 2e67 ist ein Original ELV HMS100T, suche mal nur nach dem, der ist auch ca.  2m weg vom CUL_0. 77e1 ist ein HMS CO sensor auch im Log.

Zur Info: Der CUL_0 ist mit der V3_RFR tsculfw geflasht, da hängt auch ein RFR dran.
Gestern habe ich mal in der 0.34_0.47 Firmwaresource geschmöckert. In der CUL board.h sind die FHT Sachen per #undef bei V3 rausgenommen, bei V3_RFR drin. Ich bin nun verwirrt da ich auch einen anderen CUL (CUL_2) mit V3 geflasht habe und da wird als Client FHT unterstützt angezeigt. Bist Du sicher das du die Firmware im zip genau so kompiliert hast oder mache ich einen Denkfehler? FHT habe ich auch im Einsatz, der CUL_2 ist aber eine 433MHz Version so dass ich nicht erwarte das er FHT Empfänge anzeigt.
list CUL_2:
Internals:
   CMDS       ABCFGJKRUVWXYeiltx
   Clients    STACKABLETS:STACKABLE:TSCUL_WS:TSCUL_NC7427:IT:CUL_FHTTK:CUL_HOERMANN:TSCUL_TX:CUL_IR:SOMFY:Revolt:ESA2000:TSCUL_RFR:TSCUL_EM:BS:USF1000:FS20:FHT.*:TSKS300:HMS:FS20V:CUL_TCM97001:CUL_REDIRECT
   DEF        192.168.99.111:2004 0000
   DeviceName 192.168.99.111:2004
   FD         252
   FHTID      0000
   FUUID      5d3b2745-f33f-d5a5-f9c7-e87e8c111256c756
   NAME       CUL_2
   NR         1831
   PARTIAL   
   RAWMSG     
   STATE      Initialized
   SlowRF_IntCalcStat Last: 14.0  Min: 4.0  Mean: 11.2  Max: 36.0
   TYPE       TSCUL
   VERSION    VTS 0.34 CUL433
   VERSION_HW CUL_V3.4_0004
   VERSION_TS yes AES ChTblSize:219
   XmitOpen   0
   initString XP1C
X21
AM5
AHF10000
   msgLoadCurrent 0
   MatchList:
     1:STACKABLETS ^\*
     2:STACKABLE ^\*
     A:TSCUL_WS ^K[\dA-F]....
     B:TSCUL_NC7427 ^n..........
     C:Hideki   ^P12#75[A-F0-9]{17,30}
     C:IT       ^i.(?::.|.....)
     C:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     D:CUL_FHTTK ^T[\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F]
     E:CUL_HOERMANN ^R..........
     F:TSCUL_TX ^TXA.........
     G:CUL_IR   ^I............
     H:SOMFY    ^Y[r|t|s]:?[\dA-F]+
     I:Revolt   ^r......................$
     J:ESA2000  ^S................................$
     K:TSCUL_RFR ^[\dA-F][\dA-F][\dA-F][\dA-F]~.
     L:TSCUL_EM ^E0.0[\dA-F]..............
     M:FS20V    ^81..(?:04|0c)..0101a001......00[89a-f]...
     N:BS       ^81..(?:04|0c)..0101a001a5cf
     O:USF1000  ^81..(?:04|0c)..0101a001a5ceaa00....
     P:FS20     ^81..(?:04|0c)..0101a001
     Q:FHT      ^81..(?:04|09|0d)..(?:0909a001|83098301|c409c401)..
     R:TSKS300  ^810d04..4027a001
     T:HMS      ^810e04......a001
     U:CUL_TCM97001 ^s[\dA-F]+
     V:CUL_REDIRECT ^o
   READINGS:
     2020-04-22 18:06:14   Ints_per_sec    SI: 2.47684  TI: 0.32821  S: 0.37019  L: 0.08587  F: 0.13167  M: 0.00000
     2020-01-10 14:00:01   SlowRFSndFreq   433.920MHz +0.000kHz
     2020-04-21 08:55:14   Xmit-Events     disconnected:1 non-HM:2
     2020-04-21 13:19:11   ccconf          freq:433.920MHz freqOffs:0.000kHz bWidth:325kHz freqIF:330.08kHz rAmpl:42dB sens:12dB dRate:2.461kBit/s
agcPrio:0 agcWait:16 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:0 AGC_FREEZE:0
CCAmode:1 csRelThr:10dB csAbsThr:7dB
     2020-04-21 08:54:20   cmds             A B C F G J K R U V W X Y e i l t x
     2020-04-21 08:55:14   cond            non-HM
     2020-03-04 09:53:48   credit10ms      2700
     2020-03-04 09:53:41   peakfilter      88 µs
     2020-04-21 08:54:20   prot_disconnected last
     2020-04-21 08:55:14   prot_non-HM     last
     2020-04-21 08:54:22   state           Initialized
     2020-04-21 13:19:21   uptime          6 14:21:33
     2020-04-21 13:19:26   version         VTS 0.34 CUL433
   helper:
     CUrun      1
     ChkPart    0
     RA_Timeout 0
     SVTS       1
     VTS        1
     VTS_ACK    1
     VTS_AES    1
     nRec       0
     recAlive   1
     recd       0
     DEVIOTS:
       RXfailTO   
     HM:
       ChTblSize  219
       FUP        0
       hmCrdts    0
       ChTbl:
       msgCNT:
         0x02       3874
     SRf:
       lastIntC   2537699
       lastIntCTime 1587571574.34518
       lastIntTOC 392329
       lastSyncC  443340
       lastloFltC 84016
       lastmtchErrC 0
       lastupFltC 136891
       IntStat:
         Max        36
         Mean       11.1842105263158
         Min        4
         N          228
     cnd:
       250        2
       253        1
     q:
       HMcndN     250
       hmLanQlen  1
     ref:
       Sdly       0
       ioBR       3840
       lHMt       673722536
       lSys       581170922
       pndCUAp    0
       pngLm      80
       scF        1
Attributes:
   group      Gateways
   room       Server


Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: noansi am 22 April 2020, 20:23:03
Hallo Peter,

mit sens 8 kam schon mal was rein und wurde zumindest als HMS Timing erkannt und es wurde was eingesammelt. Das Problem steckt also später im Firmware Code.

Jetzt also bitte noch eine Aufzeichnung mit sens 8, aber diesmal set X3D.


ZitatBist Du sicher das du die Firmware im zip genau so kompiliert hast
aber sowas von sicher!  :)

ZitatGestern habe ich mal in der 0.34_0.47 Firmwaresource geschmöckert. In der CUL board.h sind die FHT Sachen per #undef bei V3 rausgenommen, bei V3_RFR drin. Ich bin nun verwirrt da ich auch einen anderen CUL (CUL_2) mit V3 geflasht habe und da wird als Client FHT unterstützt angezeigt.
CMDS       ABCFGJKRUVWXYeiltx
zeigt an, was der CUL in Firmware unterstützt (genauer, welche Befehle er kennt).

Clients    STACKABLETS:STACKABLE:TSCUL_WS:TSCUL_NC7427:IT:CUL_FHTTK:CUL_HOERMANN:TSCUL_TX:CUL_IR:SOMFY:Revolt:ESA2000:TSCUL_RFR:TSCUL_EM:BS:USF1000:FS20:FHT.*:TSKS300:HMS:FS20V:CUL_TCM97001:CUL_REDIRECT
zeigt an, welche Module 00_TSCUL.pm unterstützt, das hat mit der Firmware nichts zu tun.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: pantau am 22 April 2020, 22:46:23
Diesmal wollte der Sensor einfach nicht senden..
Aber ein EB90 ist drin, auch "authentisch" ELV HMS100TF, siehe Anhang
Danke
Peter
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: noansi am 24 April 2020, 19:09:13
Hallo Peter,

ein Problem habe ich bezüglich HMS identifiziert. Vermutlich war es das noch nicht allein.

Kannst Du bitte mit der Firmware im Anhang den Test mit sens 8 und set X3D wiederholen?!
Das würde mir zeigen, ob ich auf dem richtigen Weg bin.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: pantau am 24 April 2020, 20:56:49
Hallo Ansgar,
ich habe den CUL_0 mit der V3_RFR geflasht.
Internals:
   CFGFN      ./interfaces.cfg
   CMDS       BCFGJKMRTUVWXYeilmtux
   CUL_0_MSGCNT 4684
   CUL_0_TIME 2020-04-24 20:55:54
   Clients    STACKABLETS:STACKABLE:TSCUL_WS:TSCUL_NC7427:IT:CUL_FHTTK:CUL_HOERMANN:TSCUL_TX:CUL_IR:SOMFY:Revolt:ESA2000:TSCUL_RFR:TSCUL_EM:BS:USF1000:FS20:FHT.*:TSKS300:HMS:FS20V:CUL_TCM97001:CUL_REDIRECT
   DEF        192.168.99.111:2002 1034
   DeviceName 192.168.99.111:2002
   FD         400
   FHTID      1034
   FUUID      5c48e3ea-f33f-d5a5-6c48-a0271bcd55cbf5c2
   NAME       CUL_0
   NR         40
   PARTIAL   
   RAWBITS    p20  904  320  392  824 10  9 7 -90 EC7A38E4B1886A3D9EBE  416
   RAWBITS_UNKNOWN P07  224  288  368  472 21 13 4 -40 000010081298094095234E2798C0  472
   RAWMSG     810c04xx0909a001254b0000a000
   RFR_CULID  01
   RFR_REC_RSSI -76.5
   RSSI       -88
   STATE      Initialized
   SlowRF_IntCalcStat Last: 40.0  Min: 5.0  Mean: 34.3  Max: 55.0
   TYPE       TSCUL
   VERSION    VTS 0.35 CUL868
   VERSION_HW CUL_V3.4_0004
   VERSION_TS no ASKSIN
   XmitOpen   0
   initString XP1C
X21
   MatchList:
     1:STACKABLETS ^\*
     2:STACKABLE ^\*
     A:TSCUL_WS ^K[\dA-F]....
     B:TSCUL_NC7427 ^n..........
     C:IT       ^i.(?::.|.....)
     D:CUL_FHTTK ^T[\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F]
     E:CUL_HOERMANN ^R..........
     F:TSCUL_TX ^TXA.........
     G:CUL_IR   ^I............
     H:SOMFY    ^Y[r|t|s]:?[\dA-F]+
     I:Revolt   ^r......................$
     J:ESA2000  ^S................................$
     K:TSCUL_RFR ^[\dA-F][\dA-F][\dA-F][\dA-F]~.
     L:TSCUL_EM ^E0.0[\dA-F]..............
     M:FS20V    ^81..(?:04|0c)..0101a001......00[89a-f]...
     N:BS       ^81..(?:04|0c)..0101a001a5cf
     O:USF1000  ^81..(?:04|0c)..0101a001a5ceaa00....
     P:FS20     ^81..(?:04|0c)..0101a001
     Q:FHT      ^81..(?:04|09|0d)..(?:0909a001|83098301|c409c401)..
     R:TSKS300  ^810d04..4027a001
     T:HMS      ^810e04......a001
     U:CUL_TCM97001 ^s[\dA-F]+
     V:CUL_REDIRECT ^o
   QUEUE:
   READINGS:
     2020-04-21 23:42:12   ITSndFreq       433.920MHz +0.000kHz
     2020-04-24 20:49:03   Ints_per_sec    SI: 88.81061  TI: 4.48804  S: 13.32102  L: 2.70008  F: 3.97284  M: 0.89494
     2020-04-21 23:41:59   SlowRFSndFreq   868.300MHz +0.000kHz
     2020-04-24 20:29:43   SlowRfconf      freq:868.300MHz freqOffs:0.000kHz bWidth:325kHz freqIF:330.08kHz rAmpl:42dB sens:8dB dRate:2.461kBit/s
agcPrio:0 agcWait:16 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:0 AGC_FREEZE:0
CCAmode:1 csRelThr:10dB csAbsThr:7dB
     2020-04-24 20:29:43   Xmit-Events     disconnected:4 non-HM:3
     2020-04-24 20:55:46   ccconf          freq:868.300MHz freqOffs:0.000kHz bWidth:325kHz freqIF:330.08kHz rAmpl:42dB sens:8dB dRate:2.461kBit/s
agcPrio:0 agcWait:16 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:0 AGC_FREEZE:0
CCAmode:1 csRelThr:10dB csAbsThr:7dB
     2020-04-24 20:24:18   cmds             B C F G J K M R T U V W X Y e i l m t u x
     2020-04-24 20:29:43   cond            non-HM
     2020-04-21 23:41:31   fRfconf         freq:868.300MHz freqOffs:0.000kHz bWidth:541kHz freqIF:304.69kHz rAmpl:42dB sens:4dB dRate:249.939kBit/s
agcPrio:0 agcWait:32 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:3 AGC_FREEZE:0
CCAmode:0 csRelThr:dis csAbsThr:0dB
     2020-04-22 00:19:32   fhtbuf          AE
     2020-04-24 20:22:46   prot_disconnected last
     2020-04-24 20:29:43   prot_non-HM     last
     2019-08-17 01:23:10   raw             0100
     2020-04-24 20:23:18   state           Initialized
     2020-04-20 20:28:57   uptime          5 21:23:32
     2020-04-24 20:24:11   version         VTS 0.35 CUL868
   helper:
     ChkPart    0
     RA_Timeout 0
     SVTS       1
     nRec       0
     recAlive   1
     recd       1
     DEVIOTS:
       RXfailTO   
     HM:
       hmCrdts    9
     RFR_RSSI_STAT:
       N          2
       RSSILast   -76.5
       RSSIMax    -76.5
       RSSIMean   -77.5
       RSSIMin    -78.5
     SRf:
       lastIntC   304696
       lastIntCTime 1587754143.848
       lastIntTOC 35003
       lastSyncC  87586
       lastloFltC 12750
       lastmtchErrC 965
       lastupFltC 20692
       IntStat:
         Max        55
         Mean       34.3333333333333
         Min        5
         N          3
     cnd:
       250        3
       253        4
     q:
       HMcndN     250
       hmLanQlen  1
     ref:
       ioBR       3840
       lHMt       4294967295
       lSys       1674115344.79767
       pngLm      80
       scF        1
     sendpool:
       HASH(0x5597990ea4e8)
       HASH(0x5597991dbf98)
       HASH(0x55979c0c38f8)
Attributes:
   group      Gateways
   room       Keller,Server
   sendpool   CUBe868SL,rcul,CUL_0,CUBe868HM
   verbose    0

Deine Vermutung stimmt, bisher kein HMS Empfang zu sehen.
Log im Anhang, habe aus Versehen zuerst X39 gesetzt, danach X3D, beides im Log.
Diesmal wieder der Sensor 2E6F, ab 20:41:47 dann mit X3D. Noch mal um 20:47:09.
Danke schonmal.

Gruß

Peter
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: noansi am 24 April 2020, 21:23:52
Hallo Peter,

immerhin eine Veränderung. Diesmal hat mich der Timeout nach dem Sync rausgehauen.

Kannst Du bitte mit der Firmware im Anhang den Test mit sens 8 und set X3D wiederholen?!

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: pantau am 24 April 2020, 22:03:59
A watched sensor never sends... :-)
Evtl. muss ich mal die Batterien raus und wieder rein machen, dann senden die glaube ich sofort....
21:46:01 2E6F
21:50:26 ist ein 77E1 "vorbeigehuscht (CO Sensor)
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: noansi am 24 April 2020, 22:13:01
Hallo Peter,

einer war drin und es ist auch was eingesammelt worden (21:47:51). Doch nicht...
Da drüber muss ich dann mal grübeln.

Wär nicht schlecht, wenn Du noch etwas mehr einfangen könntest.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: pantau am 24 April 2020, 22:31:08
Aber was war hiermit:
2020.04.24 21:46:01 4: TSCUL_Parse: CUBe868SL H2E6F01750100E6 -87
2020.04.24 21:46:01 4: TSCUL_Parse: CUL_0 raw SlowRf:
Der Sensor wurde vom CUBe empfangen und steht 2m vom CUL_0, sagst Du der CUL_0 hat nichts empfangen?
Kann es an der letzten Firmware liegen?
Ich hatte an der Konstellation nichts geändert und es war mit sens 8.
Ich kann es gerne wiederholen, aber gib mir mal einen Tipp woran ich erkenne das der CUL_0 was für Dich hilfreiches empfängt, dann sparen wir uns das erstellen von Logs ohne hilfreichen Inhalt.
Gruß

Peter
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: noansi am 24 April 2020, 22:44:21
Hallo Peter,

ZitatAber was war hiermit:
2020.04.24 21:46:01 4: TSCUL_Parse: CUBe868SL H2E6F01750100E6 -87
2020.04.24 21:46:01 4: TSCUL_Parse: CUL_0 raw SlowRf:
CUL_0 hat den aber nicht empfangen.
Das ist ein weiteres Thema, bessere Einstellungen zu finden. Z.B. ist sens 12 für KS, EM und TX3 mit der Datenrate beim die beste Einstellung.
Das ist aber anscheinend nicht so für HMS.

Aber erst mal soll das, was empfangen werden kann, was mit dem zu tun bekommen, was der CUBe empfängt.

21:47:54 ist noch was. Wieder zu früh mit Timeout ausgestiegen.

Kannst Du bitte mit der Firmware im Anhang den Test mit sens 8 und set X3D wiederholen?!

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: pantau am 24 April 2020, 23:11:33
Weder erwärmen, noch Batterie rein raus bringt die Sensoren spontan zum senden - mühsam ...
22:54:21 EB90
22:55:32 2E6F (da sieht es so aus, als ob der CUL_0 nichts hat, komisch beide Sensoren stehen nebeneinander)
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: pantau am 24 April 2020, 23:15:44
Zitat von: noansi am 24 April 2020, 22:44:21

21:47:54 ist noch was. Wieder zu früh mit Timeout ausgestiegen.


Das scheint aber ein H43xx zu sein, denk dran das sind keine echten HMS, das sind welche die über eine Emulation beim 868SL reinkommen, die kann deine FW so nicht empfangen - denke ich.
Deshalb gebe ich Dir immer die CODE an.
Im CUBe steckt noch ein CUL (CUBe868N) den ich alle 5min per set raw Nr1 auf LaCrosse Empfang umschalte. Ich habe nie verstanden warum da als IO der CUBe868SL kommt, aber hat ja funktioniert ...
43xx sind die Code dieser Sensoren.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: noansi am 24 April 2020, 23:22:43
Hallo Peter,

hier ist was:
2020.04.24 22:54:21 4: TSCUL_Parse: CUL_0 P80  952 1056 1008  488 19  8 4 -68 940240029080800800  984
2020.04.24 22:54:21 4: TSCUL_Parse: CUBe868SL HEB9000650100E3 -88.5

2020.04.24 22:55:32 4: TSCUL_Parse: CUL_0 P80 1000 1024 1032  512 19  8 4 -46 4421080AA280800280 1000
2020.04.24 22:55:32 4: TSCUL_Parse: CUBe868SL H2E6F01750100E5 -87.5

und noch welche mehr, die aber der CUBe nicht empfangen hat. Immerhin hat mich der Timeout nicht mehr raus gekegelt.

Setz bitte mal attr global mseclog 1
Dann gibt es auch ms bei den Uhrzeiten und man kann viel besser sehen, ob die was miteinander zu tun haben.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: pantau am 25 April 2020, 00:09:20
23:59:44
00:02:18
00:05:06
habe ich was gesehen von beiden Sensoren
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: noansi am 25 April 2020, 12:00:59
Hallo Peter,

kannst Du bitte mit der Firmware im Anhang den Test mit sens 8 und set X3D wiederholen?!

Außerdem dabei bitte den CUBe mit set X25 und auch auf verbose 4. (anschließend wieder zurück auf X21).

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: pantau am 25 April 2020, 12:41:45
Sieht gut aus!
Internals:
   CFGFN      ./sensor.cfg
   CODE       2e6f
   CUBe868SL_MSGCNT 162
   CUBe868SL_RAWMSG 810e04xx0511a0012e6f000001740100
   CUBe868SL_RSSI -89
   CUBe868SL_TIME 2020-04-25 12:39:28
   CUL_0_MSGCNT 1
   CUL_0_RAWMSG 810e04xx0511a0012e6f000001740100
   CUL_0_RSSI -46.5
   CUL_0_TIME 2020-04-25 12:39:28
   DEF        2e6f
   FUUID      5c48e3f6-f33f-d5a5-db97-e66b5ddfc9750ef4
   IODev      CUL_0
   LASTInputDev CUL_0
   MSGCNT     162
   NAME       hms100t
   NR         887
   STATE      T: 17.4  Bat: ok
   TYPE       HMS
   READINGS:
     2020-04-22 18:29:36   ExactId         2e6f
     2020-04-25 12:39:28   battery         ok
     2020-04-25 12:39:28   batteryState    ok
     2020-04-25 12:39:28   state           T: 17.4  Bat: ok
     2020-04-25 12:39:28   temperature     17.4
     2020-04-25 12:39:28   type            HMS100T
Attributes:
   IODev      CUL_0
   alias      Vorratskeller
   comment    Keller_Vorrat
   model      hms100-t
   room       Keller
   timeout    0

LOG folgt ...
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: pantau am 25 April 2020, 13:16:54
Hallo Ansgar,

wie schon erwähnt hat der CUL_0 nun HMS empfangen. Jetzt sieht man auch das die Sensoren öfters senden, nur der Empfang vom CUBe868SL schlechter ist. Liegt überwiegend an der Anordnung. Ich hatte dann am CUBe868SL mal mit sens und datarate gespielt. Sollte im Log sein. Auch gleichzeitiger Empfang ist im Log, wenn auch weniger. EB90 steht etwas günstiger zw. beiden CUL.
Wenn Du denkst es macht Sinn, kann  ich dann auch noch den CUNX und Pigator testen, die habe ich auch noch im Einsatz, vermute aber das Problem ist/war nicht HW abhängig?
Ich hatte auch gesehen das Du im CUL_V3.hex FHT disabled hattest, deshalb wäre ich auch an der Source interessiert, dann kann ich meine Protokolle selber einschalten.
Hat aber keine Eile. Vielen Dank!
Gruß

Peter
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: noansi am 25 April 2020, 16:36:29
Hallo Peter,

Zitatvermute aber das Problem ist/war nicht HW abhängig?
Richtig, das Problem saß (vor langer Zeit) vor der Tastatur.  ;)

Leider hat die Behebung das Kompilat etwas vergrößert, so dass ich bei CUL_V3 HAS_HOERMANN aus dem Standardkompilat entfernen musste, um Platz zu bekommen. Flash- und Speichergröße sind leider hardwareabhängig.

ZitatCUL_V3.hex FHT disabled hattest, deshalb wäre ich auch an der Source interessiert
Funktioniert denn FHT bei Dir? Das ist auch noch ein mangles Testobjekt ungetesteter Bereich. Im CULV3RFR ist es aus eben Flashmangel nicht drin. Dafür muss man auf andere Protokolle verzichten.
Sourcen kommen, wenn der nächste Test auch noch erfolgreich ist. Negatives, wie positives Feedback sind erwünscht.

Kannst Du bitte mit der Firmware im Anhang den Test mit sens 8 und set X3D wiederholen?!
Und dabei bitte den CUBe mit set X25 und auch auf verbose 4.

Ich habe noch bei ESA die Sync Prüfung etwas verschärft und HMS über HAS_HMS ebenfalls für's kompilieren konfigurierbar gemacht.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: pantau am 25 April 2020, 17:47:00
Zitat von: noansi am 25 April 2020, 16:36:29
Funktioniert denn FHT bei Dir? Das ist auch noch ein mangles Testobjekt ungetesteter Bereich. Im CULV3RFR ist es aus eben Flashmangel nicht drin. Dafür muss man auf andere Protokolle verzichten.
Das verstehe ich nicht. Laut der board.h vom CUL aus der FW 0.34 ist FHT in V3 nicht drin, in V3_RFR aber sehr wohl. Deshalb hatte ich neulich gefragt, ob die Sourcen zu den HEX passen... Der nakte CUL hat ja mehr Platz als der RFR und wenn FHT in RFR passt, war meine Frage, warum Du es im normalen disabled hast .
Bei FHT ist mir nichts negatives aufgefallen:
Internals:
   CFGFN      ./fht.cfg
   CODE       1e08
   CUBe868SL_MSGCNT 805
   CUBe868SL_RAWMSG 810c04xx0909a0011e080000b000
   CUBe868SL_RSSI -77
   CUBe868SL_TIME 2020-04-25 17:31:54
   CUL_0_MSGCNT 957
   CUL_0_RAWMSG 810c04xx0909a0011e080000b000
   CUL_0_RSSI -80
   CUL_0_TIME 2020-04-25 17:31:54
   DEF        1e08
   FUUID      5c48e3f7-f33f-d5a5-164e-ea42b7f65b280413
   IODev      CUBe868SL
   LASTInputDev rcul
   MSGCNT     1083
   MyRFR_MSGCNT 876
   MyRFR_RAWMSG 810c04xx0909a0011e080000b000
   MyRFR_RSSI -50.5
   MyRFR_TIME 2020-04-25 17:31:55
   NAME       wz
   NR         960
   STATE      measured-temp: 21.1
   TYPE       FHT
   rcul_MSGCNT 951
   rcul_RAWMSG 810c04xx0909a0011e080000b000
   rcul_RSSI  -76
   rcul_TIME  2020-04-25 17:31:54
   Helper:
     DBLOG:
       actuator:
         logdb:
           TIME       1587828714.05239
           VALUE      0
   READINGS:
     2020-04-25 17:31:54   actuator        0%
     2020-02-17 09:02:56   battery         ok
     2020-02-17 09:02:56   batteryState    ok
     2020-04-19 20:14:32   desired-temp    off
     2020-02-17 09:02:56   lowtemp         ok
     2020-02-17 12:43:26   measured-temp   21.1
     2019-12-20 15:14:50   mode            manual
     2020-02-17 12:43:26   state           measured-temp: 21.1
     2020-02-17 12:43:26   temperature     21.1
     2020-02-17 09:02:56   warnings        none
     2020-02-17 09:02:56   window          closed
     2020-02-17 09:02:56   windowsensor    ok
Attributes:
   DbLogInclude .*
   IODev      CUBe868SL
   fp_Erdgeschoss 350,630,2,
   minfhtbuffer 5
   retrycount 3
   room       WohnZ
   timeout    0

CUBe868SL  a-culfw, CUL_0: V3_RFR (0.35), MyRFR: V3_RFR (V0.34), rcul: CUNX (tscul V0.34)
Also für mich sieht das ok aus. FHTTK gehen auch.

Hast recht ESA ging bisher noch nicht mit TSCUL, hatte ich übersehen:
Internals:
   CFGFN      ./em.cfg
   CODE       0178
   CUBe868SL_MSGCNT 756
   CUBe868SL_RAWMSG S800178011E0029D7D1000057B56803E9
   CUBe868SL_RSSI -80
   CUBe868SL_TIME 2020-04-25 17:42:08
   DEF        0178
   FUUID      5c48e3f6-f33f-d5a5-718f-c32e2955db410456
   IODev      CUL_0
   LASTInputDev CUBe868SL
   MSGCNT     756
   NAME       EM_Total
   NR         738
   STATE      CNT: 0+ CUM: 867.228 CUR: 0.000 TICKS: 1000 LR
   TYPE       ESA2000
   Helper:
     DBLOG:
       actual:
         logdb:
           TIME       1587829328.95649
           VALUE      0
       actual_ticks:
         logdb:
           TIME       1587829328.95649
           VALUE      0
       battery:
         logdb:
           TIME       1587829328.95649
           VALUE      ok
       day:
         logdb:
           TIME       1587829328.95649
           VALUE      0
       day_hr:
         logdb:
           TIME       1587751019.46024
           VALUE      0
       day_last:
         logdb:
           TIME       1587765746.28486
           VALUE      0
       day_lr:
         logdb:
           TIME       1587829328.95649
           VALUE      0
       diff:
         logdb:
           TIME       1587829328.95649
           VALUE      0.0000
       diff_sec:
         logdb:
           TIME       1587829328.95649
           VALUE      156.460736989975
       diff_ticks:
         logdb:
           TIME       1587829328.95649
           VALUE      0
       hour:
         logdb:
           TIME       1587829328.95649
           VALUE      0
       hour_last:
         logdb:
           TIME       1587826887.20166
           VALUE      0
       last_sec:
         logdb:
           TIME       1587829328.95649
           VALUE      1587829328.91685
       month:
         logdb:
           TIME       1587829328.95649
           VALUE      0
       month_hr:
         logdb:
           TIME       1587751019.46024
           VALUE      0
       month_lr:
         logdb:
           TIME       1587829328.95649
           VALUE      0
       rate:
         logdb:
           TIME       1587829328.95649
           VALUE      LR
       raw:
         logdb:
           TIME       1587829328.95649
           VALUE      CNT: 0+ CUM: 2742225 CUR: 0  TICKS: 1000 LR
       raw_total:
         logdb:
           TIME       1587829328.95649
           VALUE      2742.225
       repeat:
         logdb:
           TIME       1587829328.95649
           VALUE      +
       sequence:
         logdb:
           TIME       1587829328.95649
           VALUE      0
       state:
         logdb:
           TIME       1587829328.95649
           VALUE      CNT: 0+ CUM: 867.228 CUR: 0.000 TICKS: 1000 LR
       ticks:
         logdb:
           TIME       1587829328.95649
           VALUE      1000
       total:
         logdb:
           TIME       1587829328.95649
           VALUE      867.22799999998
       total_ticks:
         logdb:
           TIME       1587829328.95649
           VALUE      2742225
       type:
         logdb:
           TIME       1587829328.95649
           VALUE      ESAx000WZ
       year:
         logdb:
           TIME       1587829328.95649
           VALUE      0
       year_hr:
         logdb:
           TIME       1587751019.46024
           VALUE      0
       year_lr:
         logdb:
           TIME       1587829328.95649
           VALUE      0
   READINGS:
     2020-04-25 17:42:08   actual          0
     2020-04-25 17:42:08   actual_ticks    0
     2020-04-25 17:42:08   battery         ok
     2020-04-25 17:42:08   day             0
     2020-04-24 19:56:59   day_hr          0
     2020-04-25 00:02:26   day_last        0
     2020-04-25 17:42:08   day_lr          0
     2020-04-25 17:42:08   diff            0.0000
     2020-04-25 17:42:08   diff_sec        156.460736989975
     2020-04-25 17:42:08   diff_ticks      0
     2020-04-25 17:42:08   hour            0
     2020-04-25 17:01:27   hour_last       0
     2020-04-25 17:42:08   last_sec        1587829328.91685
     2019-01-24 19:37:19   max             13.7806930802237
     2020-04-25 17:42:08   month           0
     2020-04-24 19:56:59   month_hr        0
     2020-04-01 01:35:24   month_last      0
     2020-04-25 17:42:08   month_lr        0
     2020-04-25 17:42:08   rate            LR
     2020-04-25 17:42:08   raw             CNT: 0+ CUM: 2742225 CUR: 0  TICKS: 1000 LR
     2020-04-25 17:42:08   raw_total       2742.225
     2020-04-25 17:42:08   repeat          +
     2020-04-25 17:42:08   sequence        0
     2020-04-25 17:42:08   state           CNT: 0+ CUM: 867.228 CUR: 0.000 TICKS: 1000 LR
     2020-04-25 17:42:08   ticks           1000
     2020-04-25 17:42:08   total           867.22799999998
     2020-04-25 17:42:08   total_ticks     2742225
     2020-04-25 17:42:08   type            ESAx000WZ
     2020-04-25 17:42:08   year            0
     2020-04-24 19:56:59   year_hr         0
     2020-01-01 00:02:21   year_last       377.947999999991
     2020-04-25 17:42:08   year_lr         0
Attributes:
   DbLogInclude .*
   IODev      CUL_0
   room       ESA2000,Strom

Test folgt heute Abend.
Gruß

Peter
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: noansi am 25 April 2020, 18:21:38
Hallo Peter,

ZitatDer nakte CUL hat ja mehr Platz als der RFR
Leider falsch gedacht.
Der RFR kann kein ASKSIN und kein Moritz und kein RWE. Die machen wenig Sinn, denn RFR benötigt SlowRF. Somit hat die Variante RFR mehr Platz.

ZitatBei FHT ist mir nichts negatives aufgefallen:
Sehr schön.  :)

ZitatHast recht ESA ging bisher noch nicht mit TSCUL, hatte ich übersehen:
Was hast Du eigentlich nicht im Zoo?  ;) Schön.  :)
Mir ist im Log 5 nur was aufgefallen, was der CUL_0 mit ESA verwechselt hat. Aber dann ist da mit ESA wohl noch eine offene Baustelle.
Kann der CUL_0 von seiner Position her einen ESA überhaupt empfangen?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: noansi am 25 April 2020, 19:35:34
Hallo Peter,

noch eine neue Version im Anhang zum Test.
Ich bin optimistisch, dass mit der nun auch ESA klappt. Im Protokoll habe ich ESA Beispiele gefunden.
Wenn man ESA nicht braucht, ist es aber besser, es nicht rein zu komplieren, weil die Trennschärfe beim SlowRF Sync damit doch deutlich mehr gefordert wird, somit andere Protokolle eventuell schlechter empfangen werden, insbesondere, wenn die Sender ohnehin kein sauberes Timing haben oder der CC1101 wackelig empfängt.

Kannst Du bitte mit der Firmware im Anhang den Test mit sens 8 und set X3D wiederholen?!
Und dabei bitte den CUBe mit set X25 und auch auf verbose 4.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.34
Beitrag von: pantau am 25 April 2020, 22:08:55
Hallo Ansgar,
Zitat von: noansi am 25 April 2020, 19:35:34
Was hast Du eigentlich nicht im Zoo?  ;) Schön.  :)
Mein Zoo ist einfach über 15 Jahre gewachsen und umfasst alle ELV Generationen. Die haben leider alle 3-5 Jahre was Neues erfunden... Die alten Sache laufen meist ganz gut, also kein Grund es wegzuschmeißen.
Zitat von: noansi am 25 April 2020, 19:35:34
Mir ist im Log 5 nur was aufgefallen, was der CUL_0 mit ESA verwechselt hat. Aber dann ist da mit ESA wohl noch eine offene Baustelle.
Kann der CUL_0 von seiner Position her einen ESA überhaupt empfangen?
Kann er, siehe auch Log, das sind ca. 2m zum CUL_0, 2 Stockwerke zum CUBe868SL.

Zitat von: noansi am 25 April 2020, 19:35:34
noch eine neue Version im Anhang zum Test.
Ich bin optimistisch, dass mit der nun auch ESA klappt. Im Protokoll habe ich ESA Beispiele gefunden.
Wenn man ESA nicht braucht, ist es aber besser, es nicht rein zu komplieren, weil die Trennschärfe beim SlowRF Sync damit doch deutlich mehr gefordert wird, somit andere Protokolle eventuell schlechter empfangen werden, insbesondere, wenn die Sender ohnehin kein sauberes Timing haben oder der CC1101 wackelig empfängt.
ESA geht. Der CUBe868SL hatte vor allem mit dem ESA nie Probleme, mit den HMS schon. Danke für die Erklärung.
Log im Anhang, jetzt ist mir aufgefallen, das tatsächlich der CUL_0 die HMS nicht immer empfing wenn es der CUBe868SL tat. ESA war bei beiden immer gleich. Zumindest auf den ersten Blick.
Ich hab ja ein paar CUL im Einsatz, da werde ich dann mal besser planen, welcher was empfangen soll.

Gruß

Peter
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.35
Beitrag von: noansi am 26 April 2020, 09:43:24
Hallo Testwillige,

hier eine neue Version 0.35 der Timestamp Firmware und der dazu benötigten FHEM Module.

Diese Version korrigiert Fehler die HMS und ESA Empfang verhindert haben. Vielen Dank an Peter für's Testen. Noch als Hinweis, für HMS und ESA scheint sens 12 eine ungünstige Einstellung für den Empfang  dieser Protokolle zu sein.

Diese Version bietet wakup support und keep awake Support. Für CULs mit wenig Speicher kann dies mit dem Attribut "hmForceLzyCfg" aktiviert werden, siehe auch der Hinweis zum EEPROM Verschleiß weiter unten.

Das RF-Router Ping Timing ist geändert, damit also auch nicht kompatibel mit Standard culffw oder a-culfw und auch nicht zur Version 0.32.
Ergänzt ist SlowRf Empfang von Pearl NC7427 Temperatur/Luftfeuchte Sensoren. Entsprechend Kanalwahlschalter können 3 Stück empfangen werden. Zum Anlernen mittels autocreate muss der TEST Taster am Sensor gedrückt werden.

Das EEPROM Layout ist geändert und daher werden nach dem Flashen alle Einstellungen auf default zurück gestellt. Also vor dem Flashen individuelle Einstellungen, z.B. Frequenzoffsets, notieren und nacher neu einstellen.

Auszug aus der Changed:
- FULL_PA_RAMPING bugs corrected
- CCA CS thresholds setable for ASKSIN, MORITZ, HAS_RWE, RFNATIVE and MBUS with XTxy, x=CARRIER_SENSE_REL_THR, y=CARRIER_SENSE_ABS_THR as in AGCCTRL1
- SlowRf receive timing limits corrected
- SlowRf lower filter switched off by define in rf_receive_timing.h
- RFR timing/timeout shortened, FastRF CCA disabled
- auto Ci interrupt counter messages
- XP command extended to switch on auto Ci messages, AP removed as all PLL messages switchable by XP
- improvement and corrections for CUNX RS485 PIG support
- CUNX: PIG RTS controllable by USB Host for serial foward and RS485 serial forward
- CUNX: DMX interupts changed to HI priority and CC1101 interrupts to MED priority
- CUNX: USB interrupts to LO priority
- GPIOR1 used for USB USB_DeviceState
- GPIOR1 used for SERIAL STACKING stacking_ST_state


Ein Peakfilter für SlowRF Empfang ist ergänzt und mit "peakfilter" einstellbar.
In dem Zusammenhang ist auch das RF-Router Ping Timing geändert, damit also auch nicht kompatibel mit Standard culffw oder a-culfw.
Außerdem kann das Senden von RF-Router Daten nach deren Empfang einstellbar verzögert werden (RfRdelay).

CCAMode wirkt nun auch auf IT-Senden und SOMY-Senden, sowie auf das Senden des RF-Router Pings. Mit fRfCCAMode kann auch das CCA Verhalten für RF-Router Senden und FastRF geändert werden.

Auszug aus der Changed:
- IT and SOMYFY use SlowRF EEPROM CCA setting now for sending
- changes in SlowRF reception for reset and sync start. IT V1 reception tested succsessfully.
- SlowRF filter and match adaption
- SlowRF spike filter improved, max. peak lenght settable with Xpxx, xx hex time in 8us units
- IR receive/transmit pause during send of SlowRF changed to not globally switching off all interrupts
- periodic RF-Router ping RSSI display as "Cuxx\r\n" with xx = RSSI Hex
- RF-Router ping timing changed for better distinguish from other protocols
- RF-Router pre silence before send settable with uRxx, xx hex time in 4ms units
- Xrrt commands bits:
   rr:
   report known protocol data                                                      Bit 0
   report repeated data                                                            Bit 1
   report received bits                                                            Bit 2
   report 'r' (rising) or 'f' (falling) edge, '.' (collect) or '?' (sync) timeout  Bit 3
   report edges, bit times and timeouts                                            Bit 4
   report S300 data with valid checksum only                                       Bit 5
   report FHT                                                                      Bit 6
   report 'l' RSSI decimal data continuosly                                        Bit 7
   t:
   report recorded SlowRF timing                                                   Bit 0
- corrections in interrupt flag clearing
- correction in delay function
- fastRF bug corrected, untested
- EEPROM layout changed for the new parameters


TSCUNX kann mit entsprechendem RS485 Modul nun auch DMX.
Auch HM485 ist für TXCUNX angepasst.
In dem Zuge ist auch die DMX Funktionalität bei CUNO2 etwas erweitert.
IR läuft nun auch richtig mit TSCONO2.
Außerdem läuft RF-Router auf der tsculfw, allerdings mit einer Änderung. Das 'U' ist durch '~' ersetzt. 'U' kollidierte mit dem Uniroll Senden.

Kurzer Auszug aus der CHANGED:
- IO optimizations CUNX, especially to/from PIM and Ethernet
- CUNX DHCP non blocking operation
- IO optimizations
- HM485 support for CUNX (like CUNO2) with RS485 PIM.
  HM485 switch off with Hx for CUNX. With CUNX after Hx RS485 PIM again accessible via PIM USB or Ethernet Interface
- CUNX support for DMX and HM485 with RS485 PIM (to be tested), a Dwxxxxyy switches to DMX via CUNX Interface, a Hsxxxxxxxxxxxxxxxxxx switches to HM485 via CUNX Interface
- DMX switch off with Dx. With CUNX after Dx RS485 PIM is again accessible via PIM USB- or Ethernet Interface
  DMX flexible channel usage. Channels are sent out upto the highest channel set (0 sent as default for unset channels). With switching off with Dx the highest channel is reset.
  DMX changed in timing and resting behaviour. Rests on IDLE if less then 24 device, only, to keep 1204µs min. BREAK to BREAK (to be tested)
  DMX Dt command to set/view timing of MarkAfterBreak and BREAK
  DMX less disturbed while sending SlowRF
- W function gives feedback after writing EEPROM
- clock timer unburdened, may impact onewire and fht (to be tested)
- corrections for IRTX
- IR base timings changed to 12500Hz or 20000Hz
- RF-Router working, but 'U' changed to '~' (definable in board.h, but 'U' disables HAS_UNIROLL)

Es ist eine Prüfung auf Stacküberlauf eingebaut. Am Anfang des heap werden zwei Byte mit einem Bitmuster beschrieben. Wird das verändert, dann ist der Speicher wahrscheinlich korrumpiert, was durch einen Stacküberlauf ausgelöst sein sollte. Sofern der CUL dann noch kann sendet er ein "C_M" an TSCUL, was zu einem entsprechenden Log Eintrag führt.
Damit kann man vorsichtig die Speichergrenzen ausloten. Ein langer Testzeitraum ist aber erforderlich, um einigermaßen sicher zu sein, dass der worst case auch mal durchlaufen worden ist.
Außerdem ist ein Kommando mU (je nach Firmware) eingebaut, mit dem man den vom Stack ungenutzen heap in etwa auslesen kann (auch als get unusedstack in TSCUL verfügbar). Auch hier gilt, nur nach langer Laufzeit einigermaßen sinnvoll. Es macht sicher keinen Sinn auf Grund des Wertes den Speicher bis auf das letzte Byte auszuquetschen, denn weiterhin hängt die Stacknutzung vom gewählten Protokoll und Einstellungen ab.

In TSCULflash ist Flashen auch von NanoCULs und MiniCULs ergänzt. Vor dem Flashen wird ein "B00" also Reset für die TSCUL Firmware an den nano/Mini geschickt, 1 Sekunde gewartet und dann versucht mit avrdude zu flashen.
Also erst die Firmware in den FHEM/Firmware Ordner kopieren und dann in FHEM mit
TSCULflash <nanodevicename> TSnanoCUL
bzw.
TSCULflash <minidevicename> TSminiCUL
versuchen zu Flashen. Im Log sollte danach (dauert etwas) die avrdude Ausgabe zu finden sein.

Ebenfalls möglich ist das Flashen eines PIGATOR Moduls an einem CUNX
TSCULflash <pigatordevicename>|<cunxdevicename> TSPIGATOR

AESCommReq wird unterstützt. Die Nutzung ist unverändert zu Standard CUL, sprich, beim gewünschten Gerät/Kanal aesCommReq auf 1 setzen und ggf. noch aesKey passend zum verteilten Key setzen.
Es werden von tsculfw nur die Keys 0 (Default Key) bis 3 unterstützt.

Diese Erweiterung erfordert jedoch auch zusätzliche Empfangspuffer im knappen Speicher des CULs. Ein CUL V3 nutzt bis zu 6 Empfangspuffer. Auch der FlashSpeicherbdarf ist angestiegen, so dass einige Protokolle nicht mehr gleichzeitig in ein Kompilat passen. Das sollte aber weniger tragisch sein, da im ASKSIN Modus ohnehin nur HM empfangen werden kann.

Bei CUL V2 reicht der verfügbare Speicher leider hinten und vorne nicht aus, um diese Version nutzen zu können.

Im Anhang ist in TSCUL_fwcode_00_35_FHEM_Modules_00_48.zip wieder die Timestamp Firmware zu finden. Getestet habe ich TSCUNX, TSPIGATOR , TSCUL_V3 , TSCUL_V3_RFR, TSCUNO2, TSCOC und TSSCC. (TSCUL_V3_RFR ist ohne HM Unterstützung, also nur SlowRF)

Die tsculfw Firmware kann für TSCUL_V3, TSCUL_V3_RFR (via USB), TSCUNO2, TSCOC, TSSCC, TSCUNX und TSPIGATOR (an CUNX) mit FHEM mit dem TSCULflash geflashed werden. Die anderen müssen mit dem jeweiligen Flash Programmer geflashed werden. Bei CUNO2 und SCC muss die Bootloadertaste gedrückt werden, bis der Flashvorgang anläuft.
So z.B. https://forum.fhem.de/index.php/topic,24436.msg631743.html#msg631743 kann es mit einem USB CUL Stick gehen, wenn man nicht TSCULflash verwendet.
TSCULflash ist erweitert auf COC, SCC, CCD, rpiaddon, CUNO2 und CUNO. Jedoch ist es nicht ganz so einfach zu handhaben, da zum einen teilweise die Taste zu drücken ist und bei Raspberry PI Modulen die Rechteproblematik für den Zugriff auf die IO-Pins überwunden werden muss. Tips dazu in der Command-Ref auch bei RPI_GPIO.
Bei einem Stapel aus SCC mit aufgesetztem COC, CCD oder (rpiaddon?) ist unbedingt beim SCC Flash darauf zu achten, die Taste am gewünschten Modul zu drücken. Sonst wird das oberste Nicht-SCC Modul mit der SCC Firmware geflashed.
Mit CUNO2 ist das flashen getestet (generell nur über USB!). Wichtig, aber auch hier, die Taste zu drücken.

Es gibt nicht den Luxus des Downloads beim TSCULflash, sondern die Firmware muss händisch in den FHEM/firmware Ordner kopiert werden. Der Typ ist dann z.B. TSCUL_V3.
Beispiel:
TSCULflash MeinCulV3Device TSCUL_V3

Wichtig für SCC Nutzer. TSSTACKED ist entfallen und wird nicht mehr unterstützt.
Statt dessen gibt es das neue Modul STACKABLETS (als Abwandlung von Rudolfs STACKABLE).
Dieses wird sozusagen zwischen die Stackteilnehmer eingebaut.

Beispiel für fhem.cfg:
#erstes SCC Modul als Basis
define SCC_WS868 TSCUL /dev/ttyAMA0@38400 0000
attr SCC_WS868 event-on-change-reading Ints_per_sec,IntCalcStat,MatchStat
attr SCC_WS868 rfmode SlowRF
attr SCC_WS868 room Receiver
attr SCC_WS868 sendpool CUL_HM868,SCC_WS868
attr SCC_WS868 verbose 1

#neues STACKABLETS virtuelles IO device
define STACK_1 STACKABLETS SCC_WS868
attr STACK_1 verbose 1

#zweites SCC Modul
define SCC_HM868 TSCUL FHEM:DEVIO:STACK_1:38400 1034
attr SCC_HM868 event-on-change-reading cond
attr SCC_HM868 hmId F11034


Ergänzender Hinweis zu USB CULs: 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_08\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 1234
bzw.
define CUL_433 TSCUL /dev/CUL433_0@12000000 0000
definiert werden und es gibt keine Probleme mit wechselnder Schnittstelle mehr.
Die Seriennummer kann beim Compilieren der Firmware in der board.h festgelegt werden, so dass damit dann auch /dev/CUL868_1 etc. für mehrere gleiche CULs möglich sind.

Oder für CUNX
define CUNX_868 TSCUL /dev/CUNX868_0@12000000 0000
oder für PIGATOR an CUNX
define PIGATOR_433 TSCUL /dev/CUNXPIM_0@38400 0000
die Seriennummer wird aus der Seriennummer des XMEGA Chips des CUNX gebildet. Unter Linux lsusb nutzen!

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.

Bei nicht nativen USB CULs wie z.B. nanoCUL, miniCUL oder CUNO2, beträgt die Baudrate 38400, dementsprechend muss die Definition beispielsweise so aussehen:
define CUL_868 TSCUL /dev/CUL868@38400 1234
bzw.
define CUL_433 TSCUL /dev/CUL433@38400 0000

Und noch ein Beispiel für eine Definition eines Netzwerk CUNX:
define CUL_868 TSCUL 192.168.178.111:2323 0000
oder für PIGATOR an CUNX
define PIGATOR_433 TSCUL 192.168.178.111:2324 0000
beim PIGATOR sollten zuvor mit Anschluss an USB und öffnen der Schnittstelle mit gewünschten Kommunikationsparametern mit ps oder unter TSCUL mit set PIMstoreBaud die seriellen Kommunikationsparameter zum PIGATOR Modul gespeichert werden, falls sie vom default abweichen.

Oder Netzwerk CUNO2:
define CUNO2_868 TSCUL 192.168.178.110:2323 0000

Die aktuell eingestellte oder per DHCP erhaltene Netzwerkadresse kann mit Lc repektive in TSCUL mit get NetAdresses abgefragt werden. Mit Lp respektive in TSCUL mit get NetPHYlink kann der Linkzustand des Netzwerkanschlusses angezeigt werden.


In der Zip Datei sind ebenfalls die ergänzten Module zu finden, die zur Nutzung der Firmware erforderlich sind.

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
16_TSCUL_RFR.pm -> der 16_CUL_RFR.pm, aus CUL_RFR devices werden damit TSCUL_RFR devices in der fhem.cfg (händisch anzupassen)
16_STACKABLETS.pm -> statt der 16_STACKABLE.pm, aus STACKABLE werden damit STACKABLETS devices in der fhem.cfg (händisch anzupassen)
97_timerTS.pm           -> Austausch-Timerroutinen und fhemFork()

10_UNIRoll_TS.pm  -> statt der 10_UNIRoll.pm, mit TSCUL 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 IO-devices zu verwenden, aus TSKS300 wird dann TSKS300  in der fhem.cfg (händisch anzupassen). Obsolet, da 14_TSCUL_WS.pm nun KS300 unterstützt.
14_TSCUL_TX.pm    -> statt der 14_CUL_TX.pm, mit TSCUL 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 IO-devices zu verwenden, aus CUL_WS wird dann TSCUL_WS  in der fhem.cfg (händisch anzupassen)
14_TSCUL_NC7427.pm  -> NC7427 Unterstützung
15_TSCUL_EM.pm   -> statt der 15_CUL_EM.pm, mit TSCUL IO-devices zu verwenden, aus CUL_EM wird dann TSCUL_EM  in der fhem.cfg (händisch anzupassen)
CalcUtil.pm               -> Hilfsrechenroutinen für Taupunkt und Windstärkeindex
ReadingUtil.pm          -> Hilfsroutinen für Readings

Da diese Module ergänzt werden (müssen!), überleben sie auch ein Update von FHEM.

98_fhemdebug.pm     -> fhemdebug zur zwingenden Nutzung mit 97_timerTS.pm.
98_apptime.pm          -> apptime zur zwingenden Nutzung mit 97_timerTS.pm.
98_apptm.pm            -> apptime zur zwingenden Nutzung mit 97_timerTS.pm, mit geringerem Speicherverbrauch bei weniger Details
10_IT.pm                   -> vermeidet unnötiges busy waiting beim Senden. Wird ohne Schutz von FHEM update überschrieben

Außerdem:

98_TSCULflash.pm     -> Zum Flash von TSCUL_V3, TSPIGATOR (an CUNX) mit Datei in FHEM/firmware

10_CUL_HM.pm         -> angepasste Version zur Nutzung mit TSCUL/tsculfw. Die Nutzung dieses Moduls ist optional. Für CUL_V3, nanoCUL, miniCUL im Multio-HM-IO Betrieb jedoch empfohlen, da sie den EEPROM Verschleiss über das Attribut "rssiSwitchHyst" verringert. Nur diese Version bietet derzeit vollständige TSCUL/tsculfw Unterstützung.
HMConfig.pm             -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden. Einstelllimits für HM-CC-RT-DN Regler P und I Anteil erweitert. Damit kann man mit R-regAdaptive offDeter deutlich mehr an den Regelparametern spielen.
98_HMinfo.pm           -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden. Spaltenbreiten in Tabelle von protoEvents variabel zu verbesserten Übersicht in der Darstellung.
98_HMtemplate.pm   -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden.
Die 4 Dateien entsprechen einem Stand von Mitte 02/2020. Derzeit sollten diese verwendet werden.

10_CULG.pm              -> optional, enthalten, da die Firmware es unterstützt

98_autocreate.pm       -> autocreate mit TSCUL Unterstützung

98_Cumulate               -> Kumulieren von Zählwerten, wie Strom, Regenmenge etc.
98_SAverage.pm         -> Mittelwertbildung von z.B. Temperaturen. Stunde, Tag, Monat und Jahr, sowie ein gleitender Mittelwert der letzten Stunde sind damit möglich.


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_STACKABLETS.pm DevIoTS.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.pm CalcUtil.pm 14_TSCUL_NC7427.pm ReadingUtil.pm 97_timerTS.pm 98_TSCULflash.pm 98_apptime.pm 98_apptm.pm 10_IT.pm 10_CULG.pm 10_CUL_HM.pm HMConfig.pm 98_HMinfo.pm 98_HMtemplate.pm ReadingUtil.pm 98_autocreate.pm 98_Cumulate.pm 98_SAverage.pm 98_fhemdebug.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` }

Noch ein Hinweis: TSCUL fragt auch die Firmwareversion der tsculfw auf 0.34 ab. Eine ältere Version wird also nicht unterstützt!

Frequenzoffset: Für HM ist ein Frequenzoffset von -20.6kHz im EEPROM als default in der tsculfw hinterlegt (das ist ein individuelles Optimum für meinen COC). Dieser Frequenzoffset kann mit set hmFreqOffs umgestellt werden. 0 ist default in der Standard-culfw.
Wenn also keine Antwort von angesprochenen HM devices kommt, dann hmFreqOffs von 0 ausgehend verstellen. CUNX z.B. geht eher in Richtung + mit dem Offset.
Wer das Frequenzspektrum sichtbar machen kann, kann sich die optimale Mitte aller devices ermitteln und mit dem Offset sein CUL dazu passend einstellen.

Noch ein Tip zur Haltbarkeit der CULs mit wenig SRAM (CUL V3, nanoCUL, miniCUL ...). Jedesmal, wenn einem HM-Device das IODev durch Roaming neu zugeordnet wird, führt das zu EEPROM Schreibvorgängen in den beteiligten CULs. Die Lebensdauer des EEPROMs ist begrenzt (100000 Schreibzyklen laut Datenblatt). Daher rate ich zur Nutzung des VorzugsIOs beim Device Attribut IOgrp. Also nicht einfach stumpf
attr HMdeviceName IOgrp VCCU
setzen, sondern
attr HMdeviceName IOgrp VCCU:CUL_mit_gutem_Empfang_fuer_Device
sofern die Roaming Funktionalität entsprechend RSSI für das jeweilige device nicht zwingend benötigt wird. Ein Fallback auf einen anderen CUL bleibt dennoch möglich.
Mit dem Attribut "rssiSwitchHyst", das in der beigefügten 10_CUL_HM.pm verfügbar ist, kann bei den HM-devices die Umschalthysterese für das Roaming von 10 bis auf 2 bei Bedarf für mobile devices verringert werden.
Mit dem Attribut "hmForceLzyCfg" kann wakeup und keep awake support bei solchen CULs aktiviert werden. Das erhöht den EEPROM Verschleiß beim Lesen oder Verändern von Registerwerten bei wakup und lazy config devices.

Ergänzt ist auch noch ein set TX3Send.
Damit lassen sich TX3 Sensordatentelegramme auf 433er CULs versenden.
Beispiel:

define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 TX3Send T:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." SID:23 U")}

define NF_HumOut notify Sen_Aussen:humidity.* {fhem("set TSCUL_WS433 TX3Send H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." SID:23 U")}


Ergänzt ist auch noch ein set KSSend.
Damit lassen sich WS Sensordatentelegramme versenden.
Beispiel:

define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 KSSend T:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." Code:2")}


Hier geht es zur vorherigen Version https://forum.fhem.de/index.php/topic,24436.msg1022651.html#msg1022651 (https://forum.fhem.de/index.php/topic,24436.msg1022651.html#msg1022651).

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.35
Beitrag von: pantau am 28 April 2020, 23:29:40
Hallo Ansgar,

ich sehe noch folgendes im LOG:
2020.04.28 20:59:16 2: TSCUL_ReceiveDelayed: CUL_2  C 00=0D 01=2E 02=2D 03=47 04=D3 05=91 06=FF 07=00 08=32 09=00 0A=00 0B=0D 0C=00 0D=10 0E=B0 0F=71 10=56 11=8D 12=30 13=03 14=FF 15=00 16=07 17=10 18=18 19=14 1A=6C 1B=07 1C=27 1D=92 1E=FF 1F=FF 20=FB 21=B6 22=11 23=EF 24=29 25=19 26=1F 27=41 28=00 29=59 2A=7F 2B=2F 2C=81 2D=35 2E=09 2F=00 30=00 31=04 32=00 33=80 34=EA 35=0D 36=00 37=00 38=B4 39=FE 3A=00 3B=00 3C=00 3D=00
2020.04.28 21:14:16 2: TSCUL_ReceiveDelayed: CUL_2  C 00=0D 01=2E 02=2D 03=47 04=D3 05=91 06=FF 07=00 08=32 09=00 0A=00 0B=0D 0C=00 0D=10 0E=B0 0F=71 10=56 11=8D 12=30 13=03 14=FF 15=00 16=07 17=10 18=18 19=14 1A=6C 1B=07 1C=27 1D=92 1E=FF 1F=FF 20=FB 21=B6 22=11 23=EF 24=2A 25=1A 26=1F 27=41 28=00 29=59 2A=7F 2B=2F 2C=81 2D=35 2E=09 2F=00 30=00 31=04 32=00 33=80 34=E9 35=0D 36=00 37=00 38=B4 39=FC 3A=00 3B=00 3C=00 3D=00
2020.04.28 21:29:17 2: TSCUL_ReceiveDelayed: CUL_2  C 00=0D 01=2E 02=2D 03=47 04=D3 05=91 06=FF 07=00 08=32 09=00 0A=00 0B=0D 0C=00 0D=10 0E=B0 0F=71 10=56 11=8D 12=30 13=03 14=FF 15=00 16=07 17=10 18=18 19=14 1A=6C 1B=07 1C=27 1D=92 1E=FF 1F=FF 20=FB 21=B6 22=11 23=EF 24=29 25=19 26=1F 27=41 28=00 29=59 2A=7F 2B=2F 2C=81 2D=35 2E=09 2F=00 30=00 31=04 32=00 33=80 34=E9 35=0D 36=00 37=00 38=B4 39=FE 3A=00 3B=00 3C=00 3D=00
2020.04.28 21:44:17 2: TSCUL_ReceiveDelayed: CUL_2  C 00=0D 01=2E 02=2D 03=47 04=D3 05=91 06=FF 07=00 08=32 09=00 0A=00 0B=0D 0C=00 0D=10 0E=B0 0F=71 10=56 11=8D 12=30 13=03 14=FF 15=00 16=07 17=10 18=18 19=14 1A=6C 1B=07 1C=27 1D=92 1E=FF 1F=FF 20=FB 21=B6 22=11 23=EF 24=29 25=19 26=1F 27=41 28=00 29=59 2A=7F 2B=2F 2C=81 2D=35 2E=09 2F=00 30=00 31=04 32=00 33=80 34=E9 35=0D 36=00 37=00 38=B4 39=FE 3A=00 3B=00 3C=00 3D=00
2020.04.28 21:59:17 2: TSCUL_ReceiveDelayed: CUL_2  C 00=0D 01=2E 02=2D 03=47 04=D3 05=91 06=FF 07=00 08=32 09=00 0A=00 0B=0D 0C=00 0D=10 0E=B0 0F=71 10=56 11=8D 12=30 13=03 14=FF 15=00 16=07 17=10 18=18 19=14 1A=6C 1B=07 1C=27 1D=92 1E=FF 1F=FF 20=FB 21=B6 22=11 23=EF 24=29 25=19 26=1F 27=41 28=00 29=59 2A=7F 2B=2F 2C=81 2D=35 2E=09 2F=00 30=00 31=04 32=00 33=80 34=E9 35=0D 36=00 37=00 38=B4 39=FD 3A=00 3B=00 3C=00 3D=00
2020.04.28 22:14:17 2: TSCUL_ReceiveDelayed: CUL_2  C 00=0D 01=2E 02=2D 03=47 04=D3 05=91 06=FF 07=00 08=32 09=00 0A=00 0B=0D 0C=00 0D=10 0E=B0 0F=71 10=56 11=8D 12=30 13=03 14=FF 15=00 16=07 17=10 18=18 19=14 1A=6C 1B=07 1C=27 1D=92 1E=FF 1F=FF 20=FB 21=B6 22=11 23=EF 24=29 25=1A 26=1F 27=41 28=00 29=59 2A=7F 2B=2F 2C=81 2D=35 2E=09 2F=00 30=00 31=04 32=00 33=80 34=E9 35=0D 36=00 37=00 38=B4 39=FC 3A=00 3B=00 3C=00 3D=00
2020.04.28 22:29:17 2: TSCUL_ReceiveDelayed: CUL_2  C 00=0D 01=2E 02=2D 03=47 04=D3 05=91 06=FF 07=00 08=32 09=00 0A=00 0B=0D 0C=00 0D=10 0E=B0 0F=71 10=56 11=8D 12=30 13=03 14=FF 15=00 16=07 17=10 18=18 19=14 1A=6C 1B=07 1C=27 1D=92 1E=FF 1F=FF 20=FB 21=B6 22=11 23=EF 24=29 25=19 26=1F 27=41 28=00 29=59 2A=7F 2B=2F 2C=81 2D=35 2E=09 2F=00 30=00 31=04 32=00 33=80 34=E9 35=0D 36=00 37=00 38=B4 39=FE 3A=00 3B=00 3C=00 3D=00
2020.04.28 22:44:17 2: TSCUL_ReceiveDelayed: CUL_2  C 00=0D 01=2E 02=2D 03=47 04=D3 05=91 06=FF 07=00 08=32 09=00 0A=00 0B=0D 0C=00 0D=10 0E=B0 0F=71 10=56 11=8D 12=30 13=03 14=FF 15=00 16=07 17=10 18=18 19=14 1A=6C 1B=07 1C=27 1D=92 1E=FF 1F=FF 20=FB 21=B6 22=11 23=EF 24=29 25=1A 26=1F 27=41 28=00 29=59 2A=7F 2B=2F 2C=81 2D=35 2E=09 2F=00 30=00 31=04 32=00 33=80 34=E9 35=0D 36=00 37=00 38=B4 39=FC 3A=00 3B=00 3C=00 3D=00
2020.04.28 22:59:17 2: TSCUL_ReceiveDelayed: CUL_2  C 00=0D 01=2E 02=2D 03=47 04=D3 05=91 06=FF 07=00 08=32 09=00 0A=00 0B=0D 0C=00 0D=10 0E=B0 0F=71 10=56 11=8D 12=30 13=03 14=FF 15=00 16=07 17=10 18=18 19=14 1A=6C 1B=07 1C=27 1D=92 1E=FF 1F=FF 20=FB 21=B6 22=11 23=EF 24=29 25=1A 26=1F 27=41 28=00 29=59 2A=7F 2B=2F 2C=81 2D=35 2E=09 2F=00 30=00 31=04 32=00 33=80 34=EA 35=0D 36=00 37=00 38=B4 39=FC 3A=00 3B=00 3C=00 3D=00
2020.04.28 23:14:17 2: TSCUL_ReceiveDelayed: CUL_2  C 00=0D 01=2E 02=2D 03=47 04=D3 05=91 06=FF 07=00 08=32 09=00 0A=00 0B=0D 0C=00 0D=10 0E=B0 0F=71 10=56 11=8D 12=30 13=03 14=FF 15=00 16=07 17=10 18=18 19=14 1A=6C 1B=07 1C=27 1D=92 1E=FF 1F=FF 20=FB 21=B6 22=11 23=EF 24=29 25=19 26=1F 27=41 28=00 29=59 2A=7F 2B=2F 2C=81 2D=35 2E=09 2F=00 30=00 31=04 32=00 33=80 34=E9 35=0D 36=00 37=00 38=B4 39=FE 3A=00 3B=00 3C=00 3D=00

An irgendwas verschluckt sich der CUL_2?
list CUL_2 (433MHz, CUL_V3_RFR geflasht):
Internals:
   CMDS       BCFGJKMRTUVWXYeilmtux
   Clients    STACKABLETS:STACKABLE:TSCUL_WS:TSCUL_NC7427:IT:CUL_FHTTK:CUL_HOERMANN:TSCUL_TX:CUL_IR:SOMFY:Revolt:ESA2000:TSCUL_RFR:TSCUL_EM:BS:USF1000:FS20:FHT.*:TSKS300:HMS:FS20V:CUL_TCM97001:CUL_REDIRECT
   DEF        192.168.99.111:2004 0000
   DeviceName 192.168.99.111:2004
   FD         252
   FHTID      0000
   FUUID      5d3b2745-f33f-d5a5-f9c7-e87e8c111256c756
   NAME       CUL_2
   NR         1831
   PARTIAL   
   RAWMSG     
   STATE      Initialized
   SlowRF_IntCalcStat Last: 10.0  Min: 5.0  Mean: 11.8  Max: 49.0
   TYPE       TSCUL
   VERSION    VTS 0.35 CUL433
   VERSION_HW CUL_V3.4_0004
   VERSION_TS no ASKSIN
   XmitOpen   0
   initString XP1C
X21
   MatchList:
     1:STACKABLETS ^\*
     2:STACKABLE ^\*
     A:TSCUL_WS ^K[\dA-F]....
     B:TSCUL_NC7427 ^n..........
     C:Hideki   ^P12#75[A-F0-9]{17,30}
     C:IT       ^i.(?::.|.....)
     C:OREGON   ^(3[8-9A-F]|[4-6][0-9A-F]|7[0-8]).*
     D:CUL_FHTTK ^T[\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F]
     E:CUL_HOERMANN ^R..........
     F:TSCUL_TX ^TXA.........
     G:CUL_IR   ^I............
     H:SOMFY    ^Y[r|t|s]:?[\dA-F]+
     I:Revolt   ^r......................$
     J:ESA2000  ^S................................$
     K:TSCUL_RFR ^[\dA-F][\dA-F][\dA-F][\dA-F]~.
     L:TSCUL_EM ^E0.0[\dA-F]..............
     M:FS20V    ^81..(?:04|0c)..0101a001......00[89a-f]...
     N:BS       ^81..(?:04|0c)..0101a001a5cf
     O:USF1000  ^81..(?:04|0c)..0101a001a5ceaa00....
     P:FS20     ^81..(?:04|0c)..0101a001
     Q:FHT      ^81..(?:04|09|0d)..(?:0909a001|83098301|c409c401)..
     R:TSKS300  ^810d04..4027a001
     T:HMS      ^810e04......a001
     U:CUL_TCM97001 ^s[\dA-F]+
     V:CUL_REDIRECT ^o
   READINGS:
     2020-04-28 23:24:07   ITSndFreq       433.920MHz +0.000kHz
     2020-04-28 23:20:48   Ints_per_sec    SI: 3.30636  TI: 0.51513  S: 0.60480  L: 0.11638  F: 0.18697  M: 0.00000
     2020-01-10 14:00:01   SlowRFSndFreq   433.920MHz +0.000kHz
     2020-04-28 23:23:22   SlowRfconf      freq:433.920MHz freqOffs:0.000kHz bWidth:325kHz freqIF:330.08kHz rAmpl:42dB sens:12dB dRate:2.461kBit/s
agcPrio:0 agcWait:16 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:0 AGC_FREEZE:0
CCAmode:1 csRelThr:10dB csAbsThr:7dB
     2020-04-26 17:43:59   Xmit-Events     non-HM:1 disconnected:1
     2020-04-28 23:23:07   ccconf          freq:433.920MHz freqOffs:0.000kHz bWidth:325kHz freqIF:330.08kHz rAmpl:42dB sens:12dB dRate:2.461kBit/s
agcPrio:0 agcWait:16 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:0 AGC_FREEZE:0
CCAmode:1 csRelThr:10dB csAbsThr:7dB
     2020-04-28 23:24:24   cmds             B C F G J K M R T U V W X Y e i l m t u x
     2020-04-26 17:43:59   cond            non-HM
     2020-03-04 09:53:48   credit10ms      2700
     2020-03-04 09:53:41   peakfilter      88 µs
     2020-04-26 17:43:58   prot_disconnected last
     2020-04-26 17:43:59   prot_non-HM     last
     2020-04-26 17:43:59   state           Initialized
     2020-04-21 13:19:21   uptime          6 14:21:33
     2020-04-28 23:23:54   version         VTS 0.35 CUL433
   helper:
     ChkPart    0
     RA_Timeout 0
     SVTS       1
     nRec       0
     recAlive   1
     recd       0
     DEVIOTS:
       RXfailTO   
     HM:
       hmCrdts    9
     SRf:
       lastIntC   741663
       lastIntCTime 1588108848.4171
       lastIntTOC 115284
       lastSyncC  132801
       lastloFltC 27022
       lastmtchErrC 0
       lastupFltC 41940
       IntStat:
         Max        49
         Mean       11.7554347826087
         Min        5
         N          368
     cnd:
       250        1
       253        1
     q:
       HMcndN     250
       hmLanQlen  1
     ref:
       ioBR       3840
       lHMt       4294967295
       lSys       1674315838.40547
       pngLm      80
       scF        1
     zCStat:
Attributes:
   group      Gateways
   room       Server

Ich "vermisse" gerade keinen Sender, weiß also spontan nicht, was da alle 15min empfangen wird.
Ist es sinnvoll zu debuggen oder gibt es eine Möglichkeit das "abzuschalten"?

Danke!

Peter
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.35
Beitrag von: noansi am 29 April 2020, 07:21:30
Hallo Peter,

der CUL empfängt nichts verwertbares auf 433.92MHz.
Deswegen werden regelmäßig die Registerwerte des CC1101 ausgelesen und bei verbose 2 ins log geschrieben -> verbose 1.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.35
Beitrag von: noansi am 01 Mai 2020, 21:07:39
Hallo Peter,

kannst Du bitte die angehängte Firmware nochmal bezüglich Native mit Lacrosse Emulation testen. Ich habe die Lacrosse Emulation nach meinem Verständnis vom ursprünglichen Code umgeschrieben.
Kommt noch was rein?
Stimmen die Werte?

Danke und Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.35
Beitrag von: pantau am 02 Mai 2020, 13:33:14
Zitat von: noansi am 01 Mai 2020, 21:07:39
Hallo Peter,

kannst Du bitte die angehängte Firmware nochmal bezüglich Native mit Lacrosse Emulation testen. Ich habe die Lacrosse Emulation nach meinem Verständnis vom ursprünglichen Code umgeschrieben.
Kommt noch was rein?
Stimmen die Werte?
Hallo Ansgar,

flashen und Server neu starten hat geklappt. Der CUNX ist ansprechbar.Er empfängt auch noch im Normalmode.
Nach einem set raw Nr1 passiert das:
2020.05.02 13:24:03 3: set rcul raw Nr1
2020.05.02 13:24:09 3: rcul: Unknown code N01984598B2EFAAAA00009A894A, help me!
2020.05.02 13:24:09 3: rcul: Unknown code H43212098150, help me!
2020.05.02 13:24:16 3: rcul: Unknown code N0191451617D0AAAA0000240E6B, help me!
2020.05.02 13:24:16 3: rcul: Unknown code N019506242E3FAAAA0000DCA04F, help me!
2020.05.02 13:24:16 3: rcul: Unknown code H43140024246, help me!
2020.05.02 13:24:18 3: rcul: Unknown code N01984598B2EFAAAA0000B38675, help me!
2020.05.02 13:24:18 3: rcul: Unknown code H43212098150, help me!
2020.05.02 13:24:18 3: rcul: Unknown code N013421668513AAC770994D4563, help me!
2020.05.02 13:24:24 3: rcul: Unknown code N01914596B7F0AAAA00009EBE7B, help me!
2020.05.02 13:24:24 3: rcul: Unknown code H43052096155, help me!
2020.05.02 13:24:24 3: rcul: Unknown code N019506242E3FAAAA00010703C3, help me!
2020.05.02 13:24:24 3: rcul: Unknown code H43140024246, help me!
2020.05.02 13:24:26 3: rcul: Unknown code N01984598B2EFAAAA0000DE5185, help me!
2020.05.02 13:24:26 3: rcul: Unknown code H43212098150, help me!
2020.05.02 13:24:33 3: rcul: Unknown code N0189800248EF24D53D08D28564, help me!
2020.05.02 13:24:33 3: rcul: Unknown code N019506242E3FAAAA000014C963, help me!
2020.05.02 13:24:33 3: rcul: Unknown code H43140024246, help me!
2020.05.02 13:24:35 3: rcul: Unknown code N01984598B2EFAAAA0001013E37, help me!
2020.05.02 13:24:35 3: rcul: Unknown code H43212098150, help me!
2020.05.02 13:24:35 3: rcul: Unknown code N0104486047A0FFC6C43A1A07D8, help me!
2020.05.02 13:24:39 1: dewpoint_notify: humidity device hms100tf (humidity) invalid: 0
2020.05.02 13:24:39 1: dewpoint_notify: humidity device hms100tf (H) invalid: 0
2020.05.02 13:24:39 3: rcul: Unknown code N01984597B276AAAA00000CEA65, help me!
2020.05.02 13:24:39 3: rcul: Unknown code H43212097150, help me!
2020.05.02 13:24:40 3: rcul: Unknown code N01914596B7F0AAAA00017E2055, help me!
2020.05.02 13:24:40 3: rcul: Unknown code H43052096155, help me!
2020.05.02 13:24:41 3: rcul: Unknown code N019506242E3FAAAA0000EA04CE, help me!
2020.05.02 13:24:41 3: rcul: Unknown code H43140024246, help me!
2020.05.02 13:24:41 3: rcul: Unknown code N01689985BB19AFBF3001963720, help me!
2020.05.02 13:24:43 3: rcul: Unknown code N01984597B276AAAA00013FFCFE, help me!
2020.05.02 13:24:43 3: rcul: Unknown code H43212097150, help me!
2020.05.02 13:24:48 3: rcul: Unknown code N01984597B276AAAA0000FC2A2A, help me!
2020.05.02 13:24:48 3: rcul: Unknown code H43212097150, help me!
2020.05.02 13:24:48 3: rcul: Unknown code N01914596B7F0AAAA0000D48F77, help me!
2020.05.02 13:24:48 3: rcul: Unknown code H43052096155, help me!
2020.05.02 13:24:49 3: rcul: Unknown code N019506242E3FAAAA000050CFD6, help me!
2020.05.02 13:24:49 3: rcul: Unknown code H43140024246, help me!
2020.05.02 13:24:52 3: rcul: Unknown code N01984598B2EFAAAA0000A95743, help me!
2020.05.02 13:24:52 3: rcul: Unknown code H43212098150, help me!
2020.05.02 13:24:56 3: rcul: Unknown code N01984598B2EFAAAA0001115882, help me!
2020.05.02 13:24:56 3: rcul: Unknown code H43212098150, help me!
2020.05.02 13:24:56 3: rcul: Unknown code N01914596B7F0AAAA0000813204, help me!
2020.05.02 13:24:56 3: rcul: Unknown code H43052096155, help me!
2020.05.02 13:24:58 3: rcul: Unknown code N019506242E3FAAAA0000542553, help me!
2020.05.02 13:24:58 3: rcul: Unknown code H43140024246, help me!
2020.05.02 13:24:59 3: rcul: Unknown code N01F9190DA78989F3DE4BC0039E, help me!
2020.05.02 13:25:01 3: rcul: Unknown code N01984598B2EFAAAA00008AC00B, help me!
2020.05.02 13:25:01 3: rcul: Unknown code H43212098150, help me!
2020.05.02 13:25:05 3: rcul: Unknown code N01B69C1421CB4A01847A6704D6, help me!
2020.05.02 13:25:06 3: rcul: Unknown code N019506242E3FAAAA000065DEC5, help me!
2020.05.02 13:25:06 3: rcul: Unknown code H43140024246, help me!
2020.05.02 13:25:08 1: Timeout: 17442.6 ks1
2020.05.02 13:25:08 1: Timeout: 10842.6 Wildcard_T
2020.05.02 13:25:08 1: Timeout: 3155.88333333333 SZ_T
2020.05.02 13:25:08 1: Timeout: 748106.466666667 bad_alt
2020.05.02 13:25:11 3: rcul: Unknown code N01984597B276AAAA00006DC7FE, help me!
2020.05.02 13:25:11 3: rcul: Unknown code H43212097150, help me!
2020.05.02 13:25:11 3: rcul: Unknown code N017D2E6C7C90339BBAEB132CA3, help me!
2020.05.02 13:25:11 3: rcul: Unknown code N019506232E91AAAA00003212CF, help me!
2020.05.02 13:25:11 3: rcul: Unknown code H43140023246, help me!
2020.05.02 13:25:12 3: FS20 set Heizung off
2020.05.02 13:25:12 3: FS20 set HZ_S2 on
2020.05.02 13:25:12 3: rcul: Unknown code N01914596B7F0AAAA0001F548ED, help me!
2020.05.02 13:25:12 3: rcul: Unknown code H43052096155, help me!
2020.05.02 13:25:13 3: rcul: Unknown code N01984597B276AAAA00009F7189, help me!
2020.05.02 13:25:13 3: rcul: Unknown code H43212097150, help me!
2020.05.02 13:25:17 3: rcul: Unknown code N01984598B2EFAAAA000003DCCB, help me!
2020.05.02 13:25:17 3: rcul: Unknown code H43212098150, help me!
2020.05.02 13:25:18 3: rcul: Unknown code N019506242E3FAAAA00003B0623, help me!
2020.05.02 13:25:18 3: rcul: Unknown code H43140024246, help me!
2020.05.02 13:25:21 3: rcul: Unknown code N01914596B7F0AAAA00013F636C, help me!
2020.05.02 13:25:21 3: rcul: Unknown code H43052096155, help me!
2020.05.02 13:25:22 3: rcul: Unknown code N01984597B276AAAA00009A794C, help me!
2020.05.02 13:25:22 3: rcul: Unknown code H43212097150, help me!
2020.05.02 13:25:23 3: rcul: Unknown code N019506242E3FAAAA0001E9C180, help me!
2020.05.02 13:25:23 3: rcul: Unknown code H43140024246, help me!
2020.05.02 13:25:26 3: rcul: Unknown code N0103AF9B498C3A9D312D856C20, help me!
2020.05.02 13:25:26 3: rcul: Unknown code N01984598B2EFAAAA00009C96F8, help me!
2020.05.02 13:25:26 3: rcul: Unknown code H43212098150, help me!
2020.05.02 13:25:29 3: rcul: Unknown code N01914596B7F0AAAA00000AFDDC, help me!
2020.05.02 13:25:29 3: rcul: Unknown code H43052096155, help me!
2020.05.02 13:25:30 3: rcul: Unknown code N01984598B2EFAAAA000079AEC9, help me!
2020.05.02 13:25:30 3: rcul: Unknown code H43212098150, help me!
2020.05.02 13:25:31 3: rcul: Unknown code N019506242E3FAAAA0000463886, help me!
2020.05.02 13:25:31 3: rcul: Unknown code H43140024246, help me!
2020.05.02 13:25:34 3: rcul: Unknown code N01984598B2EFAAAA00002C3006, help me!
2020.05.02 13:25:34 3: rcul: Unknown code H43212098150, help me!
2020.05.02 13:25:36 3: rcul: Unknown code N011B5F015E05645B120B0E460C, help me!
2020.05.02 13:25:37 3: rcul: Unknown code N01914596B7F0AAAA0001A4E8E8, help me!
2020.05.02 13:25:37 3: rcul: Unknown code H43052096155, help me!
2020.05.02 13:25:39 3: rcul: Unknown code N019506242E3FAAAA00017110E0, help me!
2020.05.02 13:25:39 3: rcul: Unknown code H43140024246, help me!
2020.05.02 13:25:43 3: rcul: Unknown code N01984597B276AAAA00006124E8, help me!
2020.05.02 13:25:43 3: rcul: Unknown code H43212097150, help me!
2020.05.02 13:25:45 3: rcul: Unknown code N01914596B7F0AAAA0000F610AE, help me!
2020.05.02 13:25:45 3: rcul: Unknown code H43052096155, help me!
2020.05.02 13:25:47 3: rcul: Unknown code N01984598B2EFAAAA0000DC0168, help me!
2020.05.02 13:25:47 3: rcul: Unknown code H43212098150, help me!
2020.05.02 13:25:48 3: rcul: Unknown code N019506242E3FAAAA000008504B, help me!
2020.05.02 13:25:48 3: rcul: Unknown code H43140024246, help me!
2020.05.02 13:25:51 3: rcul: Unknown code N01704240AACFD510E0DAA8B7C3, help me!
2020.05.02 13:25:51 3: rcul: Unknown code N01984598B2EFAAAA000076204A, help me!
2020.05.02 13:25:51 3: rcul: Unknown code H43212098150, help me!
2020.05.02 13:25:53 3: rcul: Unknown code N01914596B7F0AAAA0001C2D946, help me!
2020.05.02 13:25:53 3: rcul: Unknown code H43052096155, help me!
2020.05.02 13:25:56 3: rcul: Unknown code N01984598B2EFAAAA000098AF0C, help me!
2020.05.02 13:25:56 3: rcul: Unknown code H43212098150, help me!
2020.05.02 13:25:56 3: rcul: Unknown code N019506242E3FAAAA000060604E, help me!
2020.05.02 13:25:56 3: rcul: Unknown code H43140024246, help me!
2020.05.02 13:26:01 3: rcul: Unknown code N01914596B7F0AAAA0001CE0CA9, help me!
2020.05.02 13:26:01 3: rcul: Unknown code H43052096155, help me!
2020.05.02 13:26:04 3: rcul: Unknown code N01984598B2EFAAAA00001D60B4, help me!
2020.05.02 13:26:04 3: rcul: Unknown code H43212098150, help me!
2020.05.02 13:26:06 3: rcul: Unknown code N019A5EA8E89F7B0236361DEABD, help me!
2020.05.02 13:26:08 3: rcul: Unknown code N01287B28D81CB996E058FB144F, help me!
2020.05.02 13:26:09 3: rcul: Unknown code N01914596B7F0AAAA000164544E, help me!
2020.05.02 13:26:09 3: rcul: Unknown code H43052096155, help me!
2020.05.02 13:26:11 3: rcul: Unknown code N01B1A015F388C8DBA75660E2A6, help me!
2020.05.02 13:26:13 3: rcul: Unknown code N019506242E3FAAAA0001E9CD87, help me!
2020.05.02 13:26:13 3: rcul: Unknown code H43140024246, help me!
2020.05.02 13:26:13 3: rcul: Unknown code N01984597B276AAAA0001D3483C, help me!
2020.05.02 13:26:13 3: rcul: Unknown code H43212097150, help me!
2020.05.02 13:26:17 3: rcul: Unknown code N01984597B276AAAA0000F0BBE7, help me!
2020.05.02 13:26:17 3: rcul: Unknown code H43212097150, help me!
2020.05.02 13:26:17 3: rcul: Unknown code N01914596B7F0AAAA00010A9B21, help me!
2020.05.02 13:26:17 3: rcul: Unknown code H43052096155, help me!
2020.05.02 13:26:21 3: rcul: Unknown code N01984598B2EFAAAA000002E339, help me!
2020.05.02 13:26:21 3: rcul: Unknown code H43212098150, help me!
2020.05.02 13:26:26 3: rcul: Unknown code N01914596B7F0AAAA0000C70A8C, help me!
2020.05.02 13:26:26 3: rcul: Unknown code H43052096155, help me!
2020.05.02 13:26:26 3: rcul: Unknown code N01984597B276AAAA000074A135, help me!
2020.05.02 13:26:26 3: rcul: Unknown code H43212097150, help me!
2020.05.02 13:26:29 3: rcul: Unknown code N019506242E3FAAAA0000558E9B, help me!
2020.05.02 13:26:29 3: rcul: Unknown code H43140024246, help me!
2020.05.02 13:26:30 3: rcul: Unknown code N01984598B2EFAAAA0000D96AA4, help me!
2020.05.02 13:26:30 3: rcul: Unknown code H43212098150, help me!
2020.05.02 13:26:34 3: rcul: Unknown code N01984597B276AAAA00000ED3E3, help me!
2020.05.02 13:26:34 3: rcul: Unknown code H43212097150, help me!
2020.05.02 13:26:38 3: rcul: Unknown code N01984597B276AAAA00001AF673, help me!
2020.05.02 13:26:38 3: rcul: Unknown code H43212097150, help me!
2020.05.02 13:26:42 3: rcul: Unknown code N01914596B7F0AAAA00000CD996, help me!
2020.05.02 13:26:42 3: rcul: Unknown code H43052096155, help me!
2020.05.02 13:26:42 3: rcul: Unknown code N01AA54D626BDE69E4694CFDA39, help me!
2020.05.02 13:26:47 1: 192.168.99.181:2323 disconnected, waiting to reappear rcul
2020.05.02 13:26:47 2: TSCUL_condUpdateHM: rcul new condition disconnected
2020.05.02 13:26:48 3: rcul: Unknown code N01984598B2EFAAAA00018264D5, help me!
2020.05.02 13:26:48 3: rcul: Unknown code H43212098150, help me!
2020.05.02 13:26:50 1: rcul is VERSION_TS, VTS 0.36 CUL868, CUNX_V1.0_0014
2020.05.02 13:26:50 2: TSCUL_condUpdateHM: rcul new condition non-HM
2020.05.02 13:26:51 1: 192.168.99.181:2323 reappeared (rcul)
2020.05.02 13:26:55 3: set rcul raw Nx

=> sieht für mich nicht erfolgreich aus, bei den Lacrosse Sensoren sehe ich auch keine Werte vom CUNX.
Soll ich was loggen und wenn ja mit welchen Einstellungen?

Gruß

Peter
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.35
Beitrag von: noansi am 02 Mai 2020, 13:49:10
Hallo Peter,

danke, mir scheint da noch eine Ziffer bei Lacrosse durch die Lappen gegangen zu sein.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.35
Beitrag von: noansi am 02 Mai 2020, 14:30:29
Hallo Peter,

neue Version mit der Bitte um neuen Native Test.

Wenn der N log Output nervt, dann kann der beim CUL mit dem neuen Attribut SuppressNative = 1 unterdrückt werden. Es gibt kein verarbeitendes Modul dafür.
Außerdem habe ich den rfmode um Native1 bis Native3 erweitert und den RSSI mal versucht aufzunehmen.

Danke, Ansgar
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.35
Beitrag von: pantau am 03 Mai 2020, 14:17:34
Zitat von: noansi am 02 Mai 2020, 14:30:29
Hallo Peter,

neue Version mit der Bitte um neuen Native Test.

Wenn der N log Output nervt, dann kann der beim CUL mit dem neuen Attribut SuppressNative = 1 unterdrückt werden. Es gibt kein verarbeitendes Modul dafür.
Außerdem habe ich den rfmode um Native1 bis Native3 erweitert und den RSSI mal versucht aufzunehmen.

Danke, Ansgar
Besser!
Erschreit zwar noch um Hilfe:
20.05.03 13:39:54 3: rcul: Unknown code N0199C6322C5CAAAA00000868D4, help me!
2020.05.03 13:39:55 3: rcul: Unknown code N01984597B276AAAA0000ABFEC6, help me!
2020.05.03 13:39:56 3: rcul: Unknown code N01F5D5BDC79C3398B429DA112A, help me!
2020.05.03 13:40:04 3: rcul: Unknown code N01984597B276AAAA0000CB8071, help me!
2020.05.03 13:40:08 3: rcul: Unknown code N019B945FA11210002C83145047, help me!
2020.05.03 13:40:09 1: dewpoint_notify: humidity device hms100tf (humidity) invalid: 0
2020.05.03 13:40:09 1: dewpoint_notify: humidity device hms100tf (H) invalid: 0
2020.05.03 13:40:09 3: rcul: Unknown code N01914595B6ECAAAA00014C9257, help me!
2020.05.03 13:40:11 3: rcul: Unknown code N0199C6322C5CAAAA200480E6F6, help me!
2020.05.03 13:40:12 3: rcul: Unknown code N01984597B276AAAA00008008C9, help me!
2020.05.03 13:40:21 3: rcul: Unknown code N01984597B276AAAA0000115231, help me!
2020.05.03 13:40:24 3: rcul: Unknown code N019506242C5DAAAA0000FDF0C4, help me!
2020.05.03 13:40:25 3: rcul: Unknown code N0146F0B432608BA7C29AD5FFC9, help me!
2020.05.03 13:40:25 3: rcul: Unknown code N01914595B6ECAAAA0000760077, help me!
2020.05.03 13:40:28 1: Timeout: 360.916666666667 rm100_dg
2020.05.03 13:40:28 1: Timeout: 749561.8 bad_alt
2020.05.03 13:40:28 1: Timeout: 18897.9333333333 ks1
2020.05.03 13:40:28 1: Timeout: 12297.9333333333 Wildcard_T
2020.05.03 13:40:29 3: rcul: Unknown code N0199C6322C5CAAAA0080A51413, help me!
2020.05.03 13:40:29 3: rcul: Unknown code N01984597B276AAAA00001EC841, help me!
2020.05.03 13:40:33 3: FS20 set Heizung off
2020.05.03 13:40:33 3: FS20 set HZ_S2 on
2020.05.03 13:40:39 3: rcul: Unknown code N01984597B276AAAA00002C1131, help me!
2020.05.03 13:40:41 3: rcul: Unknown code N019506242C5DAAAA00000FF1D4, help me!
2020.05.03 13:40:41 3: rcul: Unknown code N01914595B6ECAAAA00009923B2, help me!
2020.05.03 13:40:46 3: rcul: Unknown code N0199C6322D7C2AAA000077AAE1, help me!
2020.05.03 13:40:46 3: rcul: Unknown code N01984597B276AAAA00000F0C28, help me!
2020.05.03 13:40:55 3: rcul: Unknown code N01984597B276AAAA00001F4E7B, help me!
2020.05.03 13:40:57 3: rcul: Unknown code N019506242C5DAAAA0001C2DA3A, help me!
2020.05.03 13:40:58 3: rcul: Unknown code N01914595B6ECAAAA0001991404, help me!
2020.05.03 13:41:00 3: rcul: Unknown code N010924642B6DF378B68AA9CAB7, help me!
2020.05.03 13:41:02 3: rcul: Unknown code N01914595B6ECAAAA0000AB8482, help me!
2020.05.03 13:41:03 3: rcul: Unknown code N0199C6322C5CAAAE0002485819, help me!
2020.05.03 13:41:03 3: rcul: Unknown code N01984597B276AAAA000058086D, help me!
2020.05.03 13:41:06 3: rcul: Unknown code N019506242C5DAAAA0000032E6C, help me!
2020.05.03 13:41:07 3: rcul: Unknown code N012C24F09BC107BB8A11791AF0, help me!
2020.05.03 13:41:12 3: rcul: Unknown code N01984597B276AAAA0000E7F402, help me!
2020.05.03 13:41:14 3: rcul: Unknown code N019506242C5DAAAA0001123DC9, help me!
2020.05.03 13:41:18 3: rcul: Unknown code N01914595B6ECAAAA000004E565, help me!
2020.05.03 13:41:19 3: rcul: Unknown code N0127766696376B5AADD2D67D90, help me!
2020.05.03 13:41:20 3: rcul: Unknown code N0199C6322C5C2AAA0000C9F899, help me!
2020.05.03 13:41:21 3: rcul: Unknown code N01984597B276AAAA0000AA0BD4, help me!
2020.05.03 13:41:22 3: rcul: Unknown code N019506242C5DAAAA000057A2FB, help me!
2020.05.03 13:41:29 3: rcul: Unknown code N0199C6F27F5CAEA7E007C77F27, help me!
2020.05.03 13:41:30 3: rcul: Unknown code N01984597B276AAAA0001F94EFF, help me!
2020.05.03 13:41:31 3: rcul: Unknown code N019506242C5DAAAA0001EB95D2, help me!
2020.05.03 13:41:37 3: rcul: Unknown code N01984597B276AAAA0000E14506, help me!
2020.05.03 13:41:37 3: rcul: Unknown code N0199C6322C5CAAAA0000C60E2B, help me!
2020.05.03 13:41:38 3: rcul: Unknown code N01A788881F307C79CB2D5A5E7A, help me!
2020.05.03 13:41:39 3: rcul: Unknown code N019506242C5DAAAA000009947B, help me!
2020.05.03 13:41:42 3: rcul: Unknown code N01914595B6ECAAAA0000FC8FE7, help me!
2020.05.03 13:41:46 3: rcul: Unknown code N01984597B276AAAA0001445360, help me!
2020.05.03 13:41:46 3: rcul: Unknown code N0199C6322C54A2AA00004809C3, help me!
2020.05.03 13:41:47 3: rcul: Unknown code N019506242C5DAAAA0000F8D4EE, help me!
2020.05.03 13:41:50 3: rcul: Unknown code N01914594B618AAAA0000BF21FF, help me!
2020.05.03 13:41:51 3: rcul: Unknown code N010CC80954BFB6DA2BDBA19936, help me!
2020.05.03 13:41:53 3: rcul: Unknown code N01490374C22367B3FE176151AF, help me!
2020.05.03 13:41:54 3: rcul: Unknown code N01914594B618AAAA00012C991D, help me!
2020.05.03 13:41:54 3: rcul: Unknown code N01984597B276AAAA0000844BC8, help me!
2020.05.03 13:41:55 3: rcul: Unknown code N0199C6322C1CAAAA00003A3DA9, help me!
2020.05.03 13:41:56 3: rcul: Unknown code N019506242C5DAAAA0000EBAC70, help me!
2020.05.03 13:41:58 3: rcul: Unknown code N01914594B729AAAA000034474A, help me!
2020.05.03 13:42:00 3: rcul: Unknown code N019506232CF3AAAA000149E927, help me!
2020.05.03 13:42:03 3: rcul: Unknown code N01984597B276AAAA0000A96A60, help me!
2020.05.03 13:42:03 3: rcul: Unknown code N0199C6322C5CAAAA000008FA79, help me!
2020.05.03 13:42:04 3: rcul: Unknown code N019506242C5DAAAA0001D0FC7E, help me!
2020.05.03 13:42:06 3: rcul: Unknown code N01914594B618AAAA0001E65B97, help me!
2020.05.03 13:42:08 3: rcul: Unknown code N019506242C5DAAAA00005BDE04, help me!
2020.05.03 13:42:10 3: rcul: Unknown code N01914594B618AAAA000089AC00, help me!
2020.05.03 13:42:12 3: rcul: Unknown code N01984597B276AAAA000144C18C, help me!
2020.05.03 13:42:12 3: rcul: Unknown code N0199C6322C5CAABA8000781B4D, help me!
2020.05.03 13:42:12 3: rcul: Unknown code N019506242C5DAAAA0000DE992F, help me!
2020.05.03 13:42:14 3: rcul: Unknown code N01914595B7DDAAAA00012040C3, help me!
2020.05.03 13:42:19 3: rcul: Unknown code N0105748F4870C1ED481313CA58, help me!
2020.05.03 13:42:21 3: rcul: Unknown code N01984597B276AAAA000078953A, help me!
2020.05.03 13:42:21 3: rcul: Unknown code N0199C6322C5CAAAA80003368FE, help me!
2020.05.03 13:42:21 3: rcul: Unknown code N019506242C5DAAAA000197C66F, help me!
2020.05.03 13:42:22 3: rcul: Unknown code N0153D4CB84F44BB1B2E25072B7, help me!
2020.05.03 13:42:22 3: rcul: Unknown code N01914594B618AAAA0001CD96D1, help me!
2020.05.03 13:42:26 3: rcul: Unknown code N01914594B729AAAA00008B9206, help me!
2020.05.03 13:42:29 3: rcul: Unknown code N01984597B276AAAA0000894080, help me!
2020.05.03 13:42:29 3: rcul: Unknown code N019506242C5DAAAA000061B344, help me!
2020.05.03 13:42:29 3: rcul: Unknown code N0199C6322C5CAAAA0000FB0604, help me!
2020.05.03 13:42:30 3: rcul: Unknown code N01543C50C22B7C9566822C6075, help me!
2020.05.03 13:42:30 3: rcul: Unknown code N01914594B618AAAA00001E081A, help me!
2020.05.03 13:42:34 3: rcul: Unknown code N01914594B618AAAA00002561AA, help me!
2020.05.03 13:42:37 3: rcul: Unknown code N01984597B276AAAA0000BDB3DD, help me!
2020.05.03 13:42:37 3: rcul: Unknown code N019506242C5DAAAA00000CC297, help me!
2020.05.03 13:42:38 3: rcul: Unknown code N0199C6322C54AAAA00009F5403, help me!
2020.05.03 13:42:38 3: rcul: Unknown code N01914594B729AAAA0001362FCA, help me!
2020.05.03 13:42:46 3: rcul: Unknown code N01984597B276AAAA0001EAB783, help me!
2020.05.03 13:42:46 3: rcul: Unknown code N0199C6322C5DAAAB0000CFB864, help me!
2020.05.03 13:42:47 3: rcul: Unknown code N01914594B618AAAA0000EDC24F, help me!
2020.05.03 13:42:49 3: rcul: Unknown code N0133F03AD0220AC4A9BE7D26E4, help me!
2020.05.03 13:42:51 3: rcul: Unknown code N01914594B729AAAA000117AC0E, help me!
2020.05.03 13:42:54 3: rcul: Unknown code N019506242C5DAAAA0000E90908, help me!
2020.05.03 13:42:54 3: rcul: Unknown code N01984597B276AAAA0001B35B45, help me!
2020.05.03 13:42:55 3: rcul: Unknown code N01914594B418AAAA00005C235A, help me!
2020.05.03 13:42:55 3: rcul: Unknown code N0199C6323C5CAAAA000054806E, help me!
2020.05.03 13:42:55 3: rcul: Unknown code N015DFBBDBEB8F208A0D5361B4C, help me!
2020.05.03 13:42:57 3: rcul: Unknown code N019385DA63C9ECD63E95751E04, help me!
2020.05.03 13:43:02 3: rcul: Unknown code N019506242C5DAAAA0001385C1F, help me!
2020.05.03 13:43:03 3: rcul: Unknown code N01984597B276AAAA0001B84B4A, help me!
2020.05.03 13:43:03 3: rcul: Unknown code N01914594B729AAAA000050A089, help me!
2020.05.03 13:43:04 3: rcul: Unknown code N0198C4322C5CAAAA0000BD5363, help me!
2020.05.03 13:43:07 3: rcul: Unknown code N01914594B618AAAA000147864E, help me!
2020.05.03 13:43:08 3: rcul: Unknown code N014EAED9C127858C2E609C98E5, help me!
2020.05.03 13:43:10 3: rcul: Unknown code N019506242C5DAAAA000031E992, help me!
2020.05.03 13:43:11 3: rcul: Unknown code N01914594B618AAAA0000EA3D15, help me!
2020.05.03 13:43:11 3: rcul: Unknown code N01984597B276AAAA0000CF2A55, help me!
2020.05.03 13:43:12 3: rcul: Unknown code N0199C6322C5CAAAA000006D193, help me!
2020.05.03 13:43:15 3: rcul: Unknown code N01914594B729AAAA000066444F, help me!
2020.05.03 13:43:15 3: rcul: Unknown code N01B16CA690A05943AA9AAE80E7, help me!
2020.05.03 13:43:15 3: rcul: Unknown code N01984598B2EFAAAA00003A82A0, help me!
2020.05.03 13:43:20 3: rcul: Unknown code N01984597B276AAAA0000BF7484, help me!
2020.05.03 13:43:21 3: rcul: Unknown code N0191C6322C5CAAAA000055429B, help me!
2020.05.03 13:43:23 3: rcul: Unknown code N01914594B618AAAA0000AE8895, help me!
2020.05.03 13:43:24 3: rcul: Unknown code N01984598B2EFAAAA0000C70766, help me!
2020.05.03 13:43:27 3: rcul: Unknown code N01914594B729AAAA000016B591, help me!
2020.05.03 13:43:27 3: rcul: Unknown code N019506242C5DAAAA0001A42997, help me!
2020.05.03 13:43:28 3: rcul: Unknown code N01B263C3DC0B9199C9DEE51A7F, help me!
2020.05.03 13:43:28 3: rcul: Unknown code N01984597B276AAAA000005929E, help me!
2020.05.03 13:43:29 3: rcul: Unknown code N0199C6322C5CAAAA0000AAAE32, help me!
2020.05.03 13:43:31 3: rcul: Unknown code N01914594B729AAAA00000C0C16, help me!
2020.05.03 13:43:32 3: rcul: Unknown code N01984598B2EFAAAA0000011A3C, help me!
2020.05.03 13:43:35 3: rcul: Unknown code N01914594B618AAAA000173C9C2, help me!
2020.05.03 13:43:35 3: rcul: Unknown code N019506242C5DAAAA0001B1BC4C, help me!
2020.05.03 13:43:36 3: rcul: Unknown code N017A3C5739F3834338358E03B1, help me!
2020.05.03 13:43:37 3: rcul: Unknown code N01B924EBE8E16EA4377A928F54, help me!
2020.05.03 13:43:37 3: rcul: Unknown code N01984598B2EFAAAA0000F7E88C, help me!
2020.05.03 13:43:38 3: rcul: Unknown code N019986322C5CAAAA0000EA70C7, help me!
2020.05.03 13:43:39 3: rcul: Unknown code N01914594B729AAAA000160D3CA, help me!
2020.05.03 13:43:41 3: rcul: Unknown code N0135005802FFC0BFD1A46F682E, help me!
2020.05.03 13:43:41 3: rcul: Unknown code N01984598B2EFAAAA0000620A44, help me!
2020.05.03 13:43:42 3: rcul: Unknown code N01854AA0FD420C7722264F7B11, help me!
2020.05.03 13:43:43 3: rcul: Unknown code N01914594B729AAAA0000B2A484, help me!
2020.05.03 13:43:44 3: rcul: Unknown code N019506242C5DAAAA0000F89153, help me!
2020.05.03 13:43:45 3: rcul: Unknown code N01984597B276AAAA00002E7107, help me!
2020.05.03 13:43:46 3: rcul: Unknown code N01CF565B906697A5CCEE8B10D9, help me!
2020.05.03 13:43:47 3: rcul: Unknown code N0199C6322C5CAAAA00002C8D5A, help me!
2020.05.03 13:43:47 3: rcul: Unknown code N01914594B729AAAA000105C409, help me!
2020.05.03 13:43:49 3: rcul: Unknown code N01984598B2EFAAAA0000DA0A4E, help me!
2020.05.03 13:43:54 3: rcul: Unknown code N01984597B276AAAA00006BFA09, help me!
2020.05.03 13:43:55 3: rcul: Unknown code N01914594B618AAAA0000194D4F, help me!
2020.05.03 13:43:55 3: rcul: Unknown code N0199C6322C5CAAAA0000C62D36, help me!
2020.05.03 13:43:58 3: rcul: Unknown code N01984597B276AAAA0000A76B5A, help me!
2020.05.03 13:43:59 3: rcul: Unknown code N01914594B729AAAA000029D950, help me!
2020.05.03 13:44:00 3: rcul: Unknown code N019506242C5DAAAA0000BE6676, help me!
2020.05.03 13:44:02 3: rcul: Unknown code N01984597B276AAAA0000E2887F, help me!
2020.05.03 13:44:03 3: rcul: Unknown code N01914594B729AAAA00011C818A, help me!
2020.05.03 13:44:05 3: rcul: Unknown code N019946322C5CAAAA0000215C6A, help me!
2020.05.03 13:44:07 3: rcul: Unknown code N01914594B729AAAA0000D00B66, help me!
2020.05.03 13:44:09 3: rcul: Unknown code N019506242C5DAAAA00000AB5EE, help me!
2020.05.03 13:44:10 3: rcul: Unknown code N01CAD247D505612158F0A439B1, help me!
2020.05.03 13:44:11 3: rcul: Unknown code N01984597B276AAAA0000835ED1, help me!
2020.05.03 13:44:11 3: rcul: Unknown code N01220119357AD3B11C0F1CB652, help me!
2020.05.03 13:44:12 3: rcul: Unknown code N0119C6322C5CAAAA0000FD75EE, help me!
2020.05.03 13:44:15 3: rcul: Unknown code N01984598B2EFAAAA0001039651, help me!
2020.05.03 13:44:15 3: rcul: Unknown code N01914594B618AAAA0000F1D477, help me!
2020.05.03 13:44:17 3: rcul: Unknown code N019506242C5DAAAA000000393C, help me!
2020.05.03 13:44:19 3: rcul: Unknown code N01984597B276AAAA0001D51D6F, help me!
2020.05.03 13:44:19 3: rcul: Unknown code N01914594B729AAAA0001F9BE54, help me!
2020.05.03 13:44:21 3: rcul: Unknown code N0199C6322C54AAAA000001D617, help me!
2020.05.03 13:44:23 3: rcul: Unknown code N01914594B729AAAA000197A697, help me!
2020.05.03 13:44:24 3: rcul: Unknown code N01984597B276AAAA0000338C8F, help me!
2020.05.03 13:44:25 3: rcul: Unknown code N019506242C5DAAAA00008B79A0, help me!
2020.05.03 13:44:28 3: rcul: Unknown code N01914594B729AAAA0000D1AC7B, help me!
2020.05.03 13:44:29 3: rcul: Unknown code N01984597B276AAAA0001A402B2, help me!
2020.05.03 13:44:33 3: rcul: Unknown code N012194462B234637C9309339D0, help me!
2020.05.03 13:44:34 3: rcul: Unknown code N019506242C5DAAAA0000B9CC28, help me!
2020.05.03 13:44:36 3: rcul: Unknown code N01914594B729AAAA0000772BA9, help me!
2020.05.03 13:44:36 3: rcul: Unknown code N01984597B276AAAA00011C3D2A, help me!
2020.05.03 13:44:45 3: rcul: Unknown code N01984597B276AAAA00004A1650, help me!
2020.05.03 13:44:47 3: rcul: Unknown code N0199C6322C5CAAAA000270F4C8, help me!
2020.05.03 13:44:48 3: rcul: Unknown code N01914594B618AAAA0001E15AFF, help me!
2020.05.03 13:44:49 3: rcul: Unknown code N01984598B2EFAAAA00003926CC, help me!
2020.05.03 13:44:50 3: rcul: Unknown code N019506252CA9AAAA000096787C, help me!
2020.05.03 13:44:52 3: rcul: Unknown code N01914594B729AAAA0000A8F9F1, help me!
2020.05.03 13:44:53 3: rcul: Unknown code N01984597B276AAAA00000D79B4, help me!
2020.05.03 13:44:54 3: rcul: Unknown code N019506252CA9AAAA0000AD563B, help me!
2020.05.03 13:44:55 3: rcul: Unknown code N0199C6322C5CAAAA00005EA51B, help me!
2020.05.03 13:44:56 3: rcul: Unknown code N01914594B729AAAA0001E696B3, help me!
2020.05.03 13:44:57 3: rcul: Unknown code N0129E09428630C8F42761766F0, help me!
2020.05.03 13:44:58 3: rcul: Unknown code N01984597B276AAAA0000BE2765, help me!
2020.05.03 13:44:58 3: rcul: Unknown code N019506242C5DAAAA000046CFA3, help me!
2020.05.03 13:45:00 3: rcul: Unknown code N01914594B618AAAA0001FCAF80, help me!
2020.05.03 13:45:02 3: rcul: Unknown code N01984598B2EFAAAA0000174D61, help me!
2020.05.03 13:45:03 3: rcul: Unknown code N019506242C5DAAAA000010A80C, help me!
2020.05.03 13:45:04 3: rcul: Unknown code N01914594B618AAAA0001977A8B, help me!
2020.05.03 13:45:06 3: rcul: Unknown code N01984597B276AAAA0001309A74, help me!
2020.05.03 13:45:07 3: rcul: Unknown code N019506242C5DAAAA000093F5C8, help me!
2020.05.03 13:45:08 3: rcul: Unknown code N01914594B729AAAA0001CD9F30, help me!
2020.05.03 13:45:10 3: rcul: Unknown code N01984598B2EFAAAA000007889A, help me!
2020.05.03 13:45:11 3: rcul: Unknown code N019506252CA9AAAA000016E2AC, help me!
2020.05.03 13:45:12 3: rcul: Unknown code N01914594B729AAAA0001F40916, help me!
2020.05.03 13:45:13 3: rcul: Unknown code N0199C6322C5CAAA2000019C7E9, help me!
2020.05.03 13:45:15 3: rcul: Unknown code N01984597B276AAAA00000A3080, help me!
2020.05.03 13:45:15 3: rcul: Unknown code N019506242C5DAAAA000081564B, help me!
2020.05.03 13:45:16 3: rcul: Unknown code N01914594B729AAAA00017E5A1C, help me!
2020.05.03 13:45:19 3: rcul: Unknown code N01984598B2EFAAAA0000C97E12, help me!
2020.05.03 13:45:19 3: rcul: Unknown code N019506252CA9AAAA00004ED762, help me!
2020.05.03 13:45:21 3: rcul: Unknown code N0199C6322C5CA8AA0000BC2901, help me!
2020.05.03 13:45:22 1: dewpoint_notify: humidity device hms100tf (humidity) invalid: 0
2020.05.03 13:45:22 1: dewpoint_notify: humidity device hms100tf (H) invalid: 0
2020.05.03 13:45:23 3: rcul: Unknown code N01984598B2EFAAAA0001C286F6, help me!
2020.05.03 13:45:23 3: rcul: Unknown code N019506252CA9AAAA0001938712, help me!
2020.05.03 13:45:24 3: Batteriewarnung von HausTuer
2020.05.03 13:45:24 3: rcul: Unknown code N01914594B729AAAA0000E39E33, help me!
2020.05.03 13:45:25 3: Batterie wieder ok von HausTuer
2020.05.03 13:45:27 3: rcul: Unknown code N01984597B276AAAA000034A06D, help me!
2020.05.03 13:45:28 3: rcul: Unknown code N019506242C5DAAAA0000D7B45C, help me!
2020.05.03 13:45:28 1: Timeout: 12302.9333333333 Wildcard_T
2020.05.03 13:45:28 1: Timeout: 18902.9333333333 ks1
2020.05.03 13:45:28 1: Timeout: 365.916666666667 rm100_dg
2020.05.03 13:45:28 1: Timeout: 749566.8 bad_alt
2020.05.03 13:45:32 3: rcul: Unknown code N01984598B2EFAAAA0000846B02, help me!
2020.05.03 13:45:32 3: rcul: Unknown code N019506252CA9AAAA0001037132, help me!
2020.05.03 13:45:33 3: rcul: Unknown code N01E09190FDC8832A7469A2241C, help me!
2020.05.03 13:45:33 3: rcul: Unknown code N01914594B729AAAA00012AC804, help me!
2020.05.03 13:45:33 3: FS20 set Heizung off
2020.05.03 13:45:33 3: FS20 set HZ_S2 on
2020.05.03 13:45:36 3: rcul: Unknown code N01984598B2EFAAAA0000FF5500, help me!
2020.05.03 13:45:40 3: rcul: Unknown code N019506242C5DAAAA00006E3A46, help me!
2020.05.03 13:45:41 3: rcul: Unknown code N01984597B276AAAA0000676EB1, help me!
2020.05.03 13:45:41 3: rcul: Unknown code N01914594B729AAAA0001DB1412, help me!
2020.05.03 13:45:43 3: rcul: Unknown code N01D2CB47E2F17CD1E44FB1FC0D, help me!
2020.05.03 13:45:44 3: rcul: Unknown code N019506252CA9AAAA0001A56DAE, help me!
2020.05.03 13:45:45 3: rcul: Unknown code N01984597B276AAAA0000BB1069, help me!
2020.05.03 13:45:48 3: rcul: Unknown code N01914594B729AAAA00010A7FE2, help me!
2020.05.03 13:45:48 3: rcul: Unknown code N019506252CA9AAAA00000DE73C, help me!
2020.05.03 13:45:49 3: rcul: Unknown code N01984598B2EFAAAA000001AB96, help me!
2020.05.03 13:45:53 3: rcul: Unknown code N01984598B2EFAAAA000166464D, help me!
2020.05.03 13:45:55 3: rcul: Unknown code N017E92A8F08D0C5C5C4E41E8F9, help me!
2020.05.03 13:45:56 3: rcul: Unknown code N0199C632A45CAAAE00004E4B83, help me!
2020.05.03 13:45:56 3: rcul: Unknown code N01914594B729AAAA000166E9A5, help me!
2020.05.03 13:45:57 3: rcul: Unknown code N019506252CA9AAAA00019A1BF2, help me!
2020.05.03 13:45:57 3: rcul: Unknown code N01984597B276AAAA0000C73E3C, help me!
2020.05.03 13:45:59 3: rcul: Unknown code N01EA0A529B513635C9541D5488, help me!
2020.05.03 13:46:01 3: rcul: Unknown code N019506252CA9AAAA000185734C, help me!
2020.05.03 13:46:02 3: rcul: Unknown code N01984597B276AAAA00008D948D, help me!
2020.05.03 13:46:04 3: rcul: Unknown code N01E66035051756F322798B966F, help me!
2020.05.03 13:46:04 3: rcul: Unknown code N0199C6322E5CAA2A000035B200, help me!
2020.05.03 13:46:04 3: rcul: Unknown code N01914594B729AAAA0000AA460A, help me!
2020.05.03 13:46:05 3: rcul: Unknown code N019506252CA9AAAA0000BAE257, help me!
2020.05.03 13:46:06 3: rcul: Unknown code N01984598B2EFAAAA00004DF40A, help me!
2020.05.03 13:46:10 3: rcul: Unknown code N01984597B276AAAA0000BD79F0, help me!
2020.05.03 13:46:12 3: rcul: Unknown code N0162A275A8C1AC1A2439890F37, help me!
2020.05.03 13:46:13 3: rcul: Unknown code N01914594B729AAAA000071EE12, help me!
2020.05.03 13:46:13 3: rcul: Unknown code N0199C6322C5CAAAA0000457BB0, help me!
2020.05.03 13:46:13 3: rcul: Unknown code N019506252CA9AAAA000072478A, help me!
2020.05.03 13:46:14 3: rcul: Unknown code N01984597B276AAAA00003D6321, help me!
2020.05.03 13:46:15 3: rcul: Unknown code N01420696A59E01024505650570, help me!
2020.05.03 13:46:17 3: rcul: Unknown code N01914594B709AAAA0000D54DDC, help me!
2020.05.03 13:46:17 3: rcul: Unknown code N019506252CA9AAAA0000F00C74, help me!
2020.05.03 13:46:18 3: rcul: Unknown code N01984598B2EFAAAA00018CC4CF, help me!
2020.05.03 13:46:21 3: rcul: Unknown code N01914594B729AAAA00019A1865, help me!

attr SuppressNative 1 unterdrückt diesen Output direkt.
Ein attr SuppressNative 0 schaltet ihn wieder ein.
Aber es wird was Empfangen:
Internals:
   CFGFN      ./sensor.cfg
   CODE       4314
   CUBe868SL_MSGCNT 47
   CUBe868SL_RAWMSG 810e04xx0510a0014314000000240244
   CUBe868SL_RSSI -74.5
   CUBe868SL_TIME 2020-05-03 13:40:41
   DEF        4314
   FUUID      5c48e3f6-f33f-d5a5-d426-2862dbf855dccf95
   IODev      CUBe868N
   LASTInputDev rcul
   MSGCNT     53
   NAME       Test_T
   NR         897
   STATE      T: 22.4  H: 44  Bat: ok D: 9.5
   TYPE       HMS
   rcul_MSGCNT 7
   rcul_RAWMSG 810e04xx0510a0014314000000240244
   rcul_RSSI  -74.5
   rcul_TIME  2020-05-03 13:41:31
   Helper:
     DBLOG:
       battery:
         logdb:
           TIME       1588506091.2299
           VALUE      1
       batteryState:
         logdb:
           TIME       1588506091.2299
           VALUE      ok
       data:
         logdb:
           TIME       1588506091.2299
           VALUE      T: 22.4  H: 44  Bat: ok D: 9.5
       dewpoint:
         logdb:
           TIME       1588506091.2299
           VALUE      9.5
       humidity:
         logdb:
           TIME       1588506091.2299
           VALUE      44
       temperature:
         logdb:
           TIME       1588506091.2299
           VALUE      22.4
       type:
         logdb:
           TIME       1588506091.2299
           VALUE      HMS100TF
   READINGS:
     2020-05-03 13:41:31   battery         ok
     2020-05-03 13:41:31   batteryState    ok
     2020-05-03 13:41:31   dewpoint        9.5
     2020-05-03 13:41:31   humidity        44
     2020-05-03 13:41:31   state           T: 22.4  H: 44  Bat: ok
     2020-05-03 13:41:31   temperature     22.4
     2020-05-03 13:41:31   type            HMS100TF
Attributes:
   DbLogInclude .*
   IODev      CUBe868N
   room       AZ,HMS
   timeout    0

Internals:
   CFGFN      ./sensor.cfg
   CODE       4321
   CUBe868SL_MSGCNT 56
   CUBe868SL_RAWMSG 810e04xx0510a0014321000020970150
   CUBe868SL_RSSI -74.5
   CUBe868SL_TIME 2020-05-03 13:40:47
   DEF        4321
   FUUID      5d9b78e8-f33f-d5a5-1b4d-c4d22d6a012a6f65
   IODev      CUBe868N
   LASTInputDev rcul
   MSGCNT     89
   NAME       WZ_T
   NR         893
   STATE      T: 19.7  H: 50  Bat: empty
   TYPE       HMS
   rcul_MSGCNT 36
   rcul_RAWMSG 810e04xx0510a0014321000020970150
   rcul_RSSI  -59
   rcul_TIME  2020-05-03 13:44:02
   Helper:
     DBLOG:
       data:
         logdb:
           TIME       1588506234.19949
           VALUE      T: 19.7  H: 50  Bat: empty D: 9.0
       dewpoint:
         logdb:
           TIME       1588506234.19949
           VALUE      9.0
       humidity:
         logdb:
           TIME       1588504852.59793
           VALUE      50
       temperature:
         logdb:
           TIME       1588506234.19949
           VALUE      19.7
   READINGS:
     2020-05-03 13:44:02   battery         empty
     2020-05-03 13:44:02   batteryState    low
     2020-05-03 13:43:54   dewpoint        9.0
     2020-05-03 13:44:02   humidity        50
     2020-05-03 13:44:02   state           T: 19.7  H: 50  Bat: empty
     2020-05-03 13:44:02   temperature     19.7
     2020-05-03 13:44:02   type            HMS100TF
Attributes:
   DbLogInclude .*
   IODev      CUBe868N
   event-on-change-reading .*
   room       HMS,WohnZ
   timeout    0

Internals:
   CODE       4327
   CUBe868SL_MSGCNT 49
   CUBe868SL_RAWMSG 810e04xx0510a0014327000000320244
   CUBe868SL_RSSI -74.5
   CUBe868SL_TIME 2020-05-03 13:40:46
   DEF        4327
   FUUID      5e9db559-f33f-d5a5-0a1f-ae88837a11a5eaa4
   IODev      CUBe868N
   LASTInputDev rcul
   MSGCNT     62
   NAME       SZ_T
   NR         2170
   STATE      T: 23.2  H: 44  Bat: ok D: 10.3
   TYPE       HMS
   rcul_MSGCNT 14
   rcul_RAWMSG 810e04xx0510a0014327000000320244
   rcul_RSSI  -82
   rcul_TIME  2020-05-03 13:43:55
   READINGS:
     2020-05-03 13:43:55   battery         ok
     2020-05-03 13:43:55   batteryState    ok
     2020-05-03 13:43:55   dewpoint        10.3
     2020-05-03 13:43:55   humidity        44
     2020-05-03 13:43:55   state           T: 23.2  H: 44  Bat: ok
     2020-05-03 13:43:55   temperature     23.2
     2020-05-03 13:43:55   type            HMS100TF
Attributes:
   IODev      CUBe868N
   room       HMS
   timeout    0

RSSI sieht für mich plausibel aus. Werte auch.
Warum dann die vielen Unknown code?
Was noch Probleme macht ist ein set raw Nx. Ich glaube da schaltet er nicht wieder in den normalen Empfang um.
Zumindest sieht es so aus, als ob er danach gar nichts mehr empfängt. Es kommt kein Unknown code mehr, aber auch keine Daten anderer Sender
Test:
set raw Nr1
Lacrosse wird empfangen, Unknown code im Log
set raw Nx
Unknown code hört sofort auf. Aber auch kein Empfang mehr von EM, WS, echtem HMS. Und Lacrosse kommen auch nicht, wie erwartet.
Ein set rcul reopen, resettet den rcul und alles geht wieder im "Normalmode". (Allerdings auch nur wenn ich den Befehl 2x schicke (oder bin ich zu ungedultig, hatte 10s gewartet).


Gruß

Peter
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.35
Beitrag von: pantau am 03 Mai 2020, 14:26:18
Nachtrag:

Laut culfw Referenz:
   x
        disables reception

Just "N" returns active mode.

disable reception: Die a-culfw geht da wieder in Normalmode, aber evtl. muss ich eher ein X21 oder so schicken?
"N" returns active mode: set raw N macht gar nichts, get raw N liefert verschiedene Dinge, aber nicht den active mode: i1AA53BEE, i6DE5C3EE, E0309AF902B0000902BF6
Scheint eher der Empfangspuffer zu sein?
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.35
Beitrag von: noansi am 03 Mai 2020, 15:23:15
Hallo Peter,

Zitatdisable reception: Die a-culfw geht da wieder in Normalmode,
OK, mit Nx Rücksprung nach SlowRf Empfang im Anhang (gerne mit Feedback).
Außerdem ein Kompensationsversuch für das engere ESA Timing, damit andere zappelige Protokolle bessere Chance haben durch zu kommen, wenn ESA einkompiliert ist.

Zitatset raw N macht gar nichts
Habe ich raus geschmissen. In den empfangen N daten ist der N-Mode ohnehin in den ersten 2 Ziffern zu sehen.
Und was man beim Testen mit Nr einstellt kann an sich auch merken...
01, 02 oder 03 ohne Kennung etc. ist auch keine gute Wahl für ein Feedback.

Sinn und Zweck der Umschreiberei ist, Flash Speicher zu sparen.

Ob N in der Firmware unterstützt wird, kann man aus den ausgelesenen CMDs ersehen.

Zitatget raw N
Bekommt keine spezifische Antwort und liefert daher, was gerade empfangen wird.

ZitatRSSI sieht für mich plausibel aus. Werte auch.
Schön, dann lass ich das drin.

ZitatWarum dann die vielen Unknown code?
Weil die N Daten (auch schon bei a-culfw) immer geliefert werden und H Gedöns, nur wenn was über Lacrosse Emulation daraus aus den 5 ersten Datenbytes interpretiert werden konnte.

Kein derzeitiges Modul kann mit N... irgendwas anfangen. Deswegen die Filtermöglichkeit über das Attribut. SuppressNative = 1 ist jetzt default in 00_TSCUL.pm. Damit muss man Nxx jetzt über das Attribut bewusst durchlassen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.35
Beitrag von: pantau am 05 Mai 2020, 21:13:22
Zitat von: noansi am 03 Mai 2020, 15:23:15
OK, mit Nx Rücksprung nach SlowRf Empfang im Anhang (gerne mit Feedback).
Außerdem ein Kompensationsversuch für das engere ESA Timing, damit andere zappelige Protokolle bessere Chance haben durch zu kommen, wenn ESA einkompiliert ist.
Hall Ansgar,

uneindeutig würde ich sagen:
set raw Nr und zurück set raw Nx geht. Inklusive empfang von LaCrosse.
Danach ist mir (erst) aufgefallen, das der CUNX kein ESA mehr empfängt.
Deshalb habe ich versucht durch ein set reopen den neu zu initialisieren. Danach blieb er im disconnect. Mehrere Minuten. und reopen Versuche.
Das angesteckte Pigator Modul war aber noch ansprechbar, also ist der CUNX nicht ganz abgeschmiert.
Dann Spannungsversorgung getrennt und mit reopen wieder verbunden.
Jetzt empfängt er auch (wieder) ESA.
Nächster Test nach dem Neustart:
set CUNX ropen => disconnect, bei einem 2. set CUNX reopen ist er wieder da, das mit dem 2x reopen ist mir schon früher aufgefallen, diesmal habe ich (handgestoppt) 10s gewartet vor dem 2.
Jetzt ein set Nx (ohne vorher Nr1) => ESA geht noch
Test von oben (Nr1 => Nx) wiederholt, jetzt geht ESA auch danach, hm..
set reopen, nach ca 30s kommt er wieder, scheint mir lang, geht aber.

Ich teste mal länger.
16_TSCUL_RFR.pm habe ich mit reingenommen, aber das hängt nicht am CUNX, also nicht getestet.

Vielen Dank!

Peter
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.35
Beitrag von: noansi am 05 Mai 2020, 22:05:19
Hallo Peter,

danke für den Test.

ZitatDanach ist mir (erst) aufgefallen, das der CUNX kein ESA mehr empfängt.
Was sagt ccconf? Welcher sens?

ZitatDeshalb habe ich versucht durch ein set reopen den neu zu initialisieren. Danach blieb er im disconnect. Mehrere Minuten. und reopen Versuche.
Das angesteckte Pigator Modul war aber noch ansprechbar, also ist der CUNX nicht ganz abgeschmiert.
Hmm, kann ich nicht nachvollziehen. Wenn es nochmal auftritt, bitte mal Deine Versuche mit verbose 5 beim CUNX mitloggen.
Sollte der CUNX wirklich abschmieren, würde er nach etwa 8s via Watchdog wiederbelebt.

Zitatset CUNX ropen => disconnect, bei einem 2. set CUNX reopen ist er wieder da, das mit dem 2x reopen ist mir schon früher aufgefallen, diesmal habe ich (handgestoppt) 10s gewartet vor dem 2.
Jetzt ein set Nx (ohne vorher Nr1) => ESA geht noch
Test von oben (Nr1 => Nx) wiederholt, jetzt geht ESA auch danach, hm..
set reopen, nach ca 30s kommt er wieder, scheint mir lang, geht aber.
Kann ich auch nicht nachvollziehen, weder per USB, noch per Netzwerk angeschlossen. Ca. 5s nach reopen ist er wieder Initialized.
Welche ping Zeiten hast Du zum CUNX? Exotische Netzwerkanbindung?

Allerdings muss ich gelegentlich im Browser mal einen reload der Seite ausführen, weil FHEM oder der Browser nicht immer den state Wechsel automatisch zur Anzeige bringt (auch bei anderen FHEM devices). Das ist dann aber ein anderes Problem.

Im Anhang auch mal die Version in CUL_V3_RFR. N ist da auch mit drin. Allerdings weigert er sich Nr auszuführen, wenn RFR aktiviert ist (eine ID gesetzt ist). Macht auch der CUNX ebenso.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.35
Beitrag von: pantau am 14 Mai 2020, 16:17:11
Hallo Ansgar,

sorry für die Funkstille, ich war/bin gerade mit anderen Dingen beschäftigt.
Der CUNX verrichtet unauffällig seinen Dienst, auch das periodische Umschalten von Nr1 und Nx funktioniert.
Die beschriebenen Probleme konnte ich bisher nicht wieder nachvollziehen, liegt aber vielleicht auch daran, das ich gerade nicht daran "rumspiele".
Die FW CUL_V3_RFR kann ich gerade nicht mit N testen, da ich die nur auf einen CUL mit aktiviertem RFR Mode habe. Der andere ist eine 433MHz Version.

Gruß

Peter
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.35
Beitrag von: noansi am 14 Mai 2020, 16:42:05
Hallo Peter,

ZitatDer CUNX verrichtet unauffällig seinen Dienst, auch das periodische Umschalten von Nr1 und Nx funktioniert.
Ist doch auch beruhigender "Funk".  ;)

ZitatDie FW CUL_V3_RFR kann ich gerade nicht mit N testen
Macht nichts, ich spiele selber noch am Code rum, weil ich mit dem ersten Verbesserungversuch zu ESA mit anderen Protokollen noch nicht glücklich bin.
Dann kommt auch noch eine board.h Definition hinzu, mit der man, entsprechend kompiliert, bei nicht gesetztem RFR Target auf andere Protokoll umschalten darf. Werde ich selber aber nicht so kompilieren, weil ich meine RFR Basis immer auf Empfang halten möchte und von zwischendurch mal auf Native umschalten nicht wirklich viel halte. (Und führt nur zur Frage, warum andere Protokolle schlecht empfangen werden...)

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.35
Beitrag von: billiloumez am 21 August 2020, 15:38:37
Hallo Ansgar,

ich habe heute FHEM neu aufgesetzt und mir die TSCUL Module von Version 0.35 reingeladen, bekomme aber beim Start von FHEM folgende Fehler im Log:

2020.08.21 15:36:54 1: reload: Error:Modul 00_TSCUL deactivated:
Global symbol "$haveInet6" requires explicit package name (did you forget to declare "my $haveInet6"?) at FHEM/DevIoTS.pm line 617, <$fh> line 48.
Compilation failed in require at ./FHEM/00_TSCUL.pm line 13, <$fh> line 48.
BEGIN failed--compilation aborted at ./FHEM/00_TSCUL.pm line 13, <$fh> line 48.

2020.08.21 15:36:54 0: Global symbol "$haveInet6" requires explicit package name (did you forget to declare "my $haveInet6"?) at FHEM/DevIoTS.pm line 617, <$fh> line 48.
Compilation failed in require at ./FHEM/00_TSCUL.pm line 13, <$fh> line 48.
BEGIN failed--compilation aborted at ./FHEM/00_TSCUL.pm line 13, <$fh> line 48.


Hatte früher eine Uralt Version auf meinem alten FHEM laufen, das auch immer noch funktioniert, wenn ich meinen CUL da anstecke, aber soll natürlich auf dem neuen FHEM auch laufen. Fällt dir dazu spontan was ein?

Gruß, Stefan
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.35
Beitrag von: noansi am 21 August 2020, 22:03:46
Hallo Stefan,

dann hast Du wohl mit einem älteren FHEM gestartet und vorher kein FHEM Update gefahren.

$haveInet6 ist in der fhem.pl definiert. Wann es rein gekommen ist, kann ich Dir nicht mehr sagen. Gefühlt irgendwann Anfang des Jahres.

Wenn Du aber erst mal TSCUL weg lässt, dann FHEM aktualisierst und es dann nochmal probierts, wird es wohl besser laufen. Ich nehme an, Du hast zuerst diealten Dateien gesichert, bevor Du die aus der zip übernommen hast?!

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.35
Beitrag von: billiloumez am 22 August 2020, 17:56:31
Hallo Ansgar,

hey super, das war auch schon der entscheidende Hinweis. Ich hab mir wohl selber ein Ei gelegt und erst ein Update gemacht und danach mein Backup wiederhergestellt und dabei hat er mir natürlich die Module wieder überbügelt. Also noch mal update gemacht, deine Module eingespielt, CUL neu geflasht (auch nicht ganz trivial wenn man das alle Herrenjahre mal macht..) und nun läuft wieder alles!

Vielen Dank und beste Grüße,
Stefan
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.35
Beitrag von: billiloumez am 23 August 2020, 16:00:44
Hallo Ansgar,

meine ganzen HM Komponenten funktionieren eigentlich, aber ich sehe im Log noch haufenweise folgende Meldungen:

2020.08.23 15:39:49 3: CUL1: Unknown code A1E10008E850B4EBB95E0000047B17C4BCF9F3ACCB3A498215AB2BDE8C23C0D::-100:CUL1:, help me!
2020.08.23 15:39:49 3: CUL1: Unknown code A1E10008E850B4EBB95E0000047B17C4BCF9F3ACCB3A498215AB2BDE8C23C0D::-100.5:CUL1:, help me!
2020.08.23 15:39:49 3: CUL1: Unknown code A2110088E850B4EE00002000047B23E1F1844DE50B1F7EB937BD6CC32EDD934508CA1::-100.5:CUL1:, help me!
2020.08.23 15:39:50 3: CUL1: Unknown code A1E10008E850B4EBB95E0000047B344B53C97846AA87C07BB6B810A06C182A9::-102:CUL1:, help me!
2020.08.23 15:39:50 3: CUL1: Unknown code A2110088E850B4EE00002000047B459B5EC36DC1D9B25BE9F1CEEF2C7BDC03475C8AA::-102.5:CUL1:, help me!
2020.08.23 15:39:51 3: CUL1: Unknown code A1E10008E850B4EBB95E0000047B53DD98F4446D78BE4521699B3B884E8F622::-101.5:CUL1:, help me!
2020.08.23 15:39:52 3: CUL1: Unknown code A2110088E850B4EE00002000047B64CBA55D8F0B61B0EB6F5B67140486DD80174BB61::-101:CUL1:, help me!


Ist das irgendwas, das mich beunruhigen sollte?

Gruß,
Stefan
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.35
Beitrag von: frank am 23 August 2020, 16:23:39
das ist sicher vom nachbarn.
definiere eine vccu.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.35
Beitrag von: billiloumez am 03 September 2020, 12:45:13
Mir ist gerade aufgefallen, dass ich seit dem Update hin und wieder lange "Hänger" am CUL habem wo er einfach nichts von meinen Wandthermostaten empfängt, gerade heute wieder ist das letzte Reading von den Thermostaten von halb 4 Morgens. Am CUL seh ich auch "CUL1_TIME 2020-09-03 03:29:51". Woran könnte das liegen?

Im Anhang die Internals und Readings vom CUL
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.35
Beitrag von: noansi am 03 September 2020, 19:39:50
Hallo Stefan,

die Informationsbasis ist nicht sehr aussagekräftig.

Ein List vom CUL wäre hilfreicher, nach einem "get CUL1 ccconf", außerdem je ein list von den devices, die nicht empfangen werden.

Was steht im Log im Bezug zum CUL1.

Möglich wäre ein unpassender Frequenzoffset bezogen auf die devices.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.35
Beitrag von: billiloumez am 04 September 2020, 08:15:39
Hallo Ansgar,

was mir noch aufgefallen ist: cmds senden tut der CUL einwandfrei und sobald er was gesendet hat, empfängt er nun auch wieder die readings von meinen Wandthermostaten.

get CUL1 ccconf:
CUL1 ccconf => freq:868.300MHz freqOffs:0.000kHz bWidth:101kHz freqIF:152.34kHz rAmpl:33dB sens:8dB dRate:9.993kBit/s
agcPrio:1 agcWait:16 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:1 AGC_FREEZE:0
CCAmode:3 csRelThr:10dB csAbsThr:7dB


Hier der Auszug aus dem Log zu dem Zeitpunkt als nix mehr ankam:
2020.09.03 03:16:45 3: CUL1: Unknown code A1A10008EBF333B978B1D17F3BC59FF7F8F98D27060286F56A14025::-105:CUL1:, help me!
2020.09.03 03:18:59 3: CUL1: Unknown code A1410008EBF333BA30D5A17F3BC68864088E8EA667A::-104:CUL1:, help me!
2020.09.03 03:22:19 3: CUL1: Unknown code A1410008EBF333B978B1D17F3BC6D10B6858B4B1ACA::-105.5:CUL1:, help me!
2020.09.03 03:25:12 3: CUL1: Unknown code A1410008EBF333B4CA9C617F3BC70E26A46057CF876::-106.5:CUL1:, help me!
2020.09.03 03:25:13 3: CUL1: Unknown code A1410008EBF333B4CA9C617F3BC72B1C25F3F7A40CD::-104:CUL1:, help me!
2020.09.03 03:26:45 3: CUL1: Unknown code A1410008EBF333B9F7DDB17F3BC777DA3F7FDE97AAA::-104.5:CUL1:, help me!
2020.09.03 03:26:46 3: CUL1: Unknown code A1410008EBF333B9F7DDB17F3BC7A2DABF9D4A62D71::-106.5:CUL1:, help me!
2020.09.03 03:46:53 2: TSCUL_ReceiveDelayed: CUL1  C 00=07 01=2E 02=01 03=42 04=E9 05=CA 06=31 07=0C 08=45 09=00 0A=00 0B=06 0C=00 0D=21 0E=65 0F=6A 10=C8 11=93 12=03 13=22 14=F8 15=34 16=07 17=3C 18=18 19=16 1A=6C 1B=43 1C=67 1D=91 1E=87 1F=6B 20=F8 21=56 22=10 23=EF 24=2A 25=1A 26=1F 27=41 28=00 29=59 2A=7F 2B=3E 2C=81 2D=35 2E=09 2F=00 30=00 31=14 32=F0 33=3A 34=BC 35=0D 36=00 37=00 38=2B 39=FD 3A=00 3B=41 3C=00 3D=00
2020.09.03 04:01:53 2: TSCUL_ReceiveDelayed: CUL1  C 00=07 01=2E 02=01 03=42 04=E9 05=CA 06=31 07=0C 08=45 09=00 0A=00 0B=06 0C=00 0D=21 0E=65 0F=6A 10=C8 11=93 12=03 13=22 14=F8 15=34 16=07 17=3C 18=18 19=16 1A=6C 1B=43 1C=67 1D=91 1E=87 1F=6B 20=F8 21=56 22=10 23=EF 24=2A 25=1A 26=1F 27=41 28=00 29=59 2A=7F 2B=3E 2C=81 2D=35 2E=09 2F=00 30=00 31=14 32=F0 33=3A 34=BC 35=0D 36=00 37=00 38=2B 39=FD 3A=00 3B=41 3C=00 3D=00
2020.09.03 04:16:53 2: TSCUL_ReceiveDelayed: CUL1  C 00=07 01=2E 02=01 03=42 04=E9 05=CA 06=31 07=0C 08=45 09=00 0A=00 0B=06 0C=00 0D=21 0E=65 0F=6A 10=C8 11=93 12=03 13=22 14=F8 15=34 16=07 17=3C 18=18 19=16 1A=6C 1B=43 1C=67 1D=91 1E=87 1F=6B 20=F8 21=56 22=10 23=EF 24=2A 25=1A 26=1F 27=41 28=00 29=59 2A=7F 2B=3E 2C=81 2D=35 2E=09 2F=00 30=00 31=14 32=F0 33=3A 34=BC 35=0D 36=00 37=00 38=2B 39=FD 3A=00 3B=41 3C=00 3D=00
2020.09.03 04:31:53 2: TSCUL_ReceiveDelayed: CUL1  C 00=07 01=2E 02=01 03=42 04=E9 05=CA 06=31 07=0C 08=45 09=00 0A=00 0B=06 0C=00 0D=21 0E=65 0F=6A 10=C8 11=93 12=03 13=22 14=F8 15=34 16=07 17=3C 18=18 19=16 1A=6C 1B=43 1C=67 1D=91 1E=87 1F=6B 20=F8 21=56 22=10 23=EF 24=2A 25=1A 26=1F 27=41 28=00 29=59 2A=7F 2B=3E 2C=81 2D=35 2E=09 2F=00 30=00 31=14 32=F0 33=3A 34=BC 35=0D 36=00 37=00 38=2B 39=FD 3A=00 3B=41 3C=00 3D=00
2020.09.03 04:46:53 2: TSCUL_ReceiveDelayed: CUL1  C 00=07 01=2E 02=01 03=42 04=E9 05=CA 06=31 07=0C 08=45 09=00 0A=00 0B=06 0C=00 0D=21 0E=65 0F=6A 10=C8 11=93 12=03 13=22 14=F8 15=34 16=07 17=3C 18=18 19=16 1A=6C 1B=43 1C=67 1D=91 1E=87 1F=6B 20=F8 21=56 22=10 23=EF 24=2A 25=1A 26=1F 27=41 28=00 29=59 2A=7F 2B=3E 2C=81 2D=35 2E=09 2F=00 30=00 31=14 32=F0 33=3A 34=BC 35=0D 36=00 37=00 38=2B 39=FD 3A=00 3B=41 3C=00 3D=00
2020.09.03 05:01:53 2: TSCUL_ReceiveDelayed: CUL1  C 00=07 01=2E 02=01 03=42 04=E9 05=CA 06=31 07=0C 08=45 09=00 0A=00 0B=06 0C=00 0D=21 0E=65 0F=6A 10=C8 11=93 12=03 13=22 14=F8 15=34 16=07 17=3C 18=18 19=16 1A=6C 1B=43 1C=67 1D=91 1E=87 1F=6B 20=F8 21=56 22=10 23=EF 24=2A 25=1A 26=1F 27=41 28=00 29=59 2A=7F 2B=3E 2C=81 2D=35 2E=09 2F=00 30=00 31=14 32=F0 33=3A 34=BC 35=0D 36=00 37=00 38=2B 39=FD 3A=00 3B=41 3C=00 3D=00
2020.09.03 05:16:53 2: TSCUL_ReceiveDelayed: CUL1  C 00=07 01=2E 02=01 03=42 04=E9 05=CA 06=31 07=0C 08=45 09=00 0A=00 0B=06 0C=00 0D=21 0E=65 0F=6A 10=C8 11=93 12=03 13=22 14=F8 15=34 16=07 17=3C 18=18 19=16 1A=6C 1B=43 1C=67 1D=91 1E=87 1F=6B 20=F8 21=56 22=10 23=EF 24=2A 25=1A 26=1F 27=41 28=00 29=59 2A=7F 2B=3E 2C=81 2D=35 2E=09 2F=00 30=00 31=14 32=F0 33=3A 34=BC 35=0D 36=00 37=00 38=2B 39=FD 3A=00 3B=41 3C=00 3D=00
2020.09.03 05:31:53 2: TSCUL_ReceiveDelayed: CUL1  C 00=07 01=2E 02=01 03=42 04=E9 05=CA 06=31 07=0C 08=45 09=00 0A=00 0B=06 0C=00 0D=21 0E=65 0F=6A 10=C8 11=93 12=03 13=22 14=F8 15=34 16=07 17=3C 18=18 19=16 1A=6C 1B=43 1C=67 1D=91 1E=87 1F=6B 20=F8 21=56 22=10 23=EF 24=2A 25=1A 26=1F 27=41 28=00 29=59 2A=7F 2B=3E 2C=81 2D=35 2E=09 2F=00 30=00 31=14 32=F1 33=3A 34=BC 35=0D 36=00 37=00 38=2B 39=FD 3A=00 3B=41 3C=00 3D=00
2020.09.03 05:46:53 2: TSCUL_ReceiveDelayed: CUL1  C 00=07 01=2E 02=01 03=42 04=E9 05=CA 06=31 07=0C 08=45 09=00 0A=00 0B=06 0C=00 0D=21 0E=65 0F=6A 10=C8 11=93 12=03 13=22 14=F8 15=34 16=07 17=3C 18=18 19=16 1A=6C 1B=43 1C=67 1D=91 1E=87 1F=6B 20=F8 21=56 22=10 23=EF 24=2A 25=1A 26=1F 27=41 28=00 29=59 2A=7F 2B=3E 2C=81 2D=35 2E=09 2F=00 30=00 31=14 32=F1 33=3A 34=BC 35=0D 36=00 37=00 38=2B 39=FD 3A=00 3B=41 3C=00 3D=00


Hier sieht man den Gap bei einem Wandthermostat:
2020-09-03_01:20:09 HM_34D2D9 battery: ok
2020-09-03_01:20:09 HM_34D2D9 batteryLevel: 3.4
2020-09-03_01:20:09 HM_34D2D9 desired-temp: 17.0
2020-09-03_01:20:09 HM_34D2D9 measured-temp: 24.9
2020-09-03_02:23:27 HM_34D2D9 battery: ok
2020-09-03_02:23:27 HM_34D2D9 batteryLevel: 3.4
2020-09-03_02:23:27 HM_34D2D9 desired-temp: 17.0
2020-09-03_02:23:27 HM_34D2D9 measured-temp: 24.8
2020-09-03_03:21:36 HM_34D2D9 battery: ok
2020-09-03_03:21:36 HM_34D2D9 batteryLevel: 3.4
2020-09-03_03:21:36 HM_34D2D9 desired-temp: 17.0
2020-09-03_03:21:36 HM_34D2D9 measured-temp: 24.7
2020-09-03_14:36:33 HM_34D2D9 CMDs_done
2020-09-03_14:36:33 HM_34D2D9 time-request: -
2020-09-03_14:36:47 HM_34D2D9 battery: ok
2020-09-03_14:36:47 HM_34D2D9 batteryLevel: 3.4
2020-09-03_14:36:47 HM_34D2D9 desired-temp: 21.0
2020-09-03_14:36:47 HM_34D2D9 measured-temp: 25.0
2020-09-03_14:36:48 HM_34D2D9 CMDs_done
2020-09-03_14:36:48 HM_34D2D9 time-request: -
2020-09-03_14:39:31 HM_34D2D9 battery: ok
2020-09-03_14:39:31 HM_34D2D9 batteryLevel: 3.4
2020-09-03_14:39:31 HM_34D2D9 desired-temp: 21.0
2020-09-03_14:39:31 HM_34D2D9 measured-temp: 25.1
2020-09-03_14:54:37 HM_34D2D9 battery: ok
2020-09-03_14:54:37 HM_34D2D9 batteryLevel: 3.4
2020-09-03_14:54:37 HM_34D2D9 desired-temp: 21.0
2020-09-03_14:54:37 HM_34D2D9 measured-temp: 25.2
2020-09-03_15:07:53 HM_34D2D9 battery: ok
2020-09-03_15:07:53 HM_34D2D9 batteryLevel: 3.4
2020-09-03_15:07:53 HM_34D2D9 desired-temp: 21.0
2020-09-03_15:07:53 HM_34D2D9 measured-temp: 25.3


deviceInfo des Wandthermostats:
Device name:HM_34D2D9
   org ID    :00AD  Model=HM-TC-IT-WM-W-EU
   alias ID :00AD  Model=HM-TC-IT-WM-W-EU
   mode    :config,burst - activity:alive
   protState : CMDs_done pending: none

   HM_34D2D9_Weather state:T: 24.4 H: 44
   HM_34D2D9_Climate state:T: 24.4 desired: 21.0
   HM_34D2D9_WindowRec state:last:HM_4E2047:closed
   HM_34D2D9_remote state:unpeered
   HM_34D2D9_SwitchTr state:unpeered


Benötigst du noch mehr Infos?

Gruß,
Stefan
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.35
Beitrag von: noansi am 06 September 2020, 12:59:11
Hallo Stefan,

mal as Feedback, die Log Einträge sind der entscheidende Hinweis.
Irgendwie gelingt es dem Transceiver Chip doch (trotz all meiner bisherigen Maßnahmen) seinen Empfangs-FIFO zum Überlauf zu bringen und dann nicht den RX-OverFlow Zustand einzunehmen, sondern im RX Zustand zu bleiben.
Damit kommen dann keine Daten mehr an.

Wenn mal was gesendet wird, dann wird der Chip aus diesem unseligen Zustand erlöst.

Ich arbeite an einer Lösung dazu.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.35
Beitrag von: billiloumez am 07 September 2020, 15:40:39
Hallo Ansgar,

na Hauptsache du kannst mit den Infos was anfangen ;) Danke für's Feedback, ich teste dann gerne, wenn es was neues von dir gibt.

Gruß,
Stefan
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.36
Beitrag von: noansi am 08 September 2020, 21:55:03
Hallo Testwillige,

hier eine neue Version 0.36 der Timestamp Firmware und der dazu benötigten FHEM Module.

Diese Version behebt ein Überlaufproblem des RX-FIFOs des Transceivers, der zum Empfangsausfall führen konnte (fiel nur beim reinen Empfangsbetrieb ohne regelmäßiges Senden auf). Danke Stefan für den Hinweis.

Auszug aus der Changed:
- little correction in rf_native, if slowrf monitoring is active
- lacrosse emu reworked
- SlowRf reception adapted for better ESA reception with still well E and HMS reception
- generic Manchester raw send added with Gm command
- ESA send added with 'S' command
- HMS send added with 'Q' command
- IT reception corrected
- RfRouter with repeat in FastRF packet, better send timing and reduced receive timeout
- for pure USB CULs blinking while waiting on watchdog reboot and during boot/bootloader reboot with different frequencies
- message finalization with \n on PIM receive buffer full
- ASKSIN, fastRF, RF-Router, moritz, rwe, RX-FIFO Overflow detection improved

Noch als Hinweis, für HMS und ESA scheint sens 12 eine ungünstige Einstellung für den Empfang  dieser Protokolle zu sein.

Diese Version bietet wakup support und keep awake Support. Für CULs mit wenig Speicher kann dies mit dem Attribut "hmForceLzyCfg" aktiviert werden, siehe auch der Hinweis zum EEPROM Verschleiß weiter unten.

Das RF-Router Ping Timing ist geändert, damit also auch nicht kompatibel mit Standard culffw oder a-culfw und auch nicht zur Version 0.32.
Ergänzt ist SlowRf Empfang von Pearl NC7427 Temperatur/Luftfeuchte Sensoren. Entsprechend Kanalwahlschalter können 3 Stück empfangen werden. Zum Anlernen mittels autocreate muss der TEST Taster am Sensor gedrückt werden.

Das EEPROM Layout ist geändert und daher werden nach dem Flashen alle Einstellungen auf default zurück gestellt. Also vor dem Flashen individuelle Einstellungen, z.B. Frequenzoffsets, notieren und nacher neu einstellen.

Auszug aus der Changed:
- FULL_PA_RAMPING bugs corrected
- CCA CS thresholds setable for ASKSIN, MORITZ, HAS_RWE, RFNATIVE and MBUS with XTxy, x=CARRIER_SENSE_REL_THR, y=CARRIER_SENSE_ABS_THR as in AGCCTRL1
- SlowRf receive timing limits corrected
- SlowRf lower filter switched off by define in rf_receive_timing.h
- RFR timing/timeout shortened, FastRF CCA disabled
- auto Ci interrupt counter messages
- XP command extended to switch on auto Ci messages, AP removed as all PLL messages switchable by XP
- improvement and corrections for CUNX RS485 PIG support
- CUNX: PIG RTS controllable by USB Host for serial foward and RS485 serial forward
- CUNX: DMX interupts changed to HI priority and CC1101 interrupts to MED priority
- CUNX: USB interrupts to LO priority
- GPIOR1 used for USB USB_DeviceState
- GPIOR1 used for SERIAL STACKING stacking_ST_state


Ein Peakfilter für SlowRF Empfang ist ergänzt und mit "peakfilter" einstellbar.
In dem Zusammenhang ist auch das RF-Router Ping Timing geändert, damit also auch nicht kompatibel mit Standard culffw oder a-culfw.
Außerdem kann das Senden von RF-Router Daten nach deren Empfang einstellbar verzögert werden (RfRdelay).

CCAMode wirkt nun auch auf IT-Senden und SOMY-Senden, sowie auf das Senden des RF-Router Pings. Mit fRfCCAMode kann auch das CCA Verhalten für RF-Router Senden und FastRF geändert werden.

Auszug aus der Changed:
- IT and SOMYFY use SlowRF EEPROM CCA setting now for sending
- changes in SlowRF reception for reset and sync start. IT V1 reception tested succsessfully.
- SlowRF filter and match adaption
- SlowRF spike filter improved, max. peak lenght settable with Xpxx, xx hex time in 8us units
- IR receive/transmit pause during send of SlowRF changed to not globally switching off all interrupts
- periodic RF-Router ping RSSI display as "Cuxx\r\n" with xx = RSSI Hex
- RF-Router ping timing changed for better distinguish from other protocols
- RF-Router pre silence before send settable with uRxx, xx hex time in 4ms units
- Xrrt commands bits:
   rr:
   report known protocol data                                                      Bit 0
   report repeated data                                                            Bit 1
   report received bits                                                            Bit 2
   report 'r' (rising) or 'f' (falling) edge, '.' (collect) or '?' (sync) timeout  Bit 3
   report edges, bit times and timeouts                                            Bit 4
   report S300 data with valid checksum only                                       Bit 5
   report FHT                                                                      Bit 6
   report 'l' RSSI decimal data continuosly                                        Bit 7
   t:
   report recorded SlowRF timing                                                   Bit 0
- corrections in interrupt flag clearing
- correction in delay function
- fastRF bug corrected, untested
- EEPROM layout changed for the new parameters


TSCUNX kann mit entsprechendem RS485 Modul nun auch DMX.
Auch HM485 ist für TXCUNX angepasst.
In dem Zuge ist auch die DMX Funktionalität bei CUNO2 etwas erweitert.
IR läuft nun auch richtig mit TSCONO2.
Außerdem läuft RF-Router auf der tsculfw, allerdings mit einer Änderung. Das 'U' ist durch '~' ersetzt. 'U' kollidierte mit dem Uniroll Senden.

Kurzer Auszug aus der CHANGED:
- IO optimizations CUNX, especially to/from PIM and Ethernet
- CUNX DHCP non blocking operation
- IO optimizations
- HM485 support for CUNX (like CUNO2) with RS485 PIM.
  HM485 switch off with Hx for CUNX. With CUNX after Hx RS485 PIM again accessible via PIM USB or Ethernet Interface
- CUNX support for DMX and HM485 with RS485 PIM (to be tested), a Dwxxxxyy switches to DMX via CUNX Interface, a Hsxxxxxxxxxxxxxxxxxx switches to HM485 via CUNX Interface
- DMX switch off with Dx. With CUNX after Dx RS485 PIM is again accessible via PIM USB- or Ethernet Interface
  DMX flexible channel usage. Channels are sent out upto the highest channel set (0 sent as default for unset channels). With switching off with Dx the highest channel is reset.
  DMX changed in timing and resting behaviour. Rests on IDLE if less then 24 device, only, to keep 1204µs min. BREAK to BREAK (to be tested)
  DMX Dt command to set/view timing of MarkAfterBreak and BREAK
  DMX less disturbed while sending SlowRF
- W function gives feedback after writing EEPROM
- clock timer unburdened, may impact onewire and fht (to be tested)
- corrections for IRTX
- IR base timings changed to 12500Hz or 20000Hz
- RF-Router working, but 'U' changed to '~' (definable in board.h, but 'U' disables HAS_UNIROLL)

Es ist eine Prüfung auf Stacküberlauf eingebaut. Am Anfang des heap werden zwei Byte mit einem Bitmuster beschrieben. Wird das verändert, dann ist der Speicher wahrscheinlich korrumpiert, was durch einen Stacküberlauf ausgelöst sein sollte. Sofern der CUL dann noch kann sendet er ein "C_M" an TSCUL, was zu einem entsprechenden Log Eintrag führt.
Damit kann man vorsichtig die Speichergrenzen ausloten. Ein langer Testzeitraum ist aber erforderlich, um einigermaßen sicher zu sein, dass der worst case auch mal durchlaufen worden ist.
Außerdem ist ein Kommando mU (je nach Firmware) eingebaut, mit dem man den vom Stack ungenutzen heap in etwa auslesen kann (auch als get unusedstack in TSCUL verfügbar). Auch hier gilt, nur nach langer Laufzeit einigermaßen sinnvoll. Es macht sicher keinen Sinn auf Grund des Wertes den Speicher bis auf das letzte Byte auszuquetschen, denn weiterhin hängt die Stacknutzung vom gewählten Protokoll und Einstellungen ab.

In TSCULflash ist Flashen auch von NanoCULs und MiniCULs ergänzt. Vor dem Flashen wird ein "B00" also Reset für die TSCUL Firmware an den nano/Mini geschickt, 1 Sekunde gewartet und dann versucht mit avrdude zu flashen.
Also erst die Firmware in den FHEM/Firmware Ordner kopieren und dann in FHEM mit
TSCULflash <nanodevicename> TSnanoCUL
bzw.
TSCULflash <minidevicename> TSminiCUL
versuchen zu Flashen. Im Log sollte danach (dauert etwas) die avrdude Ausgabe zu finden sein.

Ebenfalls möglich ist das Flashen eines PIGATOR Moduls an einem CUNX
TSCULflash <pigatordevicename>|<cunxdevicename> TSPIGATOR

AESCommReq wird unterstützt. Die Nutzung ist unverändert zu Standard CUL, sprich, beim gewünschten Gerät/Kanal aesCommReq auf 1 setzen und ggf. noch aesKey passend zum verteilten Key setzen.
Es werden von tsculfw nur die Keys 0 (Default Key) bis 3 unterstützt.

Diese Erweiterung erfordert jedoch auch zusätzliche Empfangspuffer im knappen Speicher des CULs. Ein CUL V3 nutzt bis zu 6 Empfangspuffer. Auch der FlashSpeicherbdarf ist angestiegen, so dass einige Protokolle nicht mehr gleichzeitig in ein Kompilat passen. Das sollte aber weniger tragisch sein, da im ASKSIN Modus ohnehin nur HM empfangen werden kann.

Bei CUL V2 reicht der verfügbare Speicher leider hinten und vorne nicht aus, um diese Version nutzen zu können.

Im Anhang ist in TSCUL_fwcode_00_xx_FHEM_Modules_00_xx.zip wieder die Timestamp Firmware zu finden. Getestet habe ich TSCUNX, TSPIGATOR , TSCUL_V3 , TSCUL_V3_RFR, TSCUNO2, TSCOC und TSSCC. (TSCUL_V3_RFR ist ohne HM Unterstützung, also nur SlowRF)

Die tsculfw Firmware kann für TSCUL_V3, TSCUL_V3_RFR (via USB), TSCUNO2, TSCOC, TSSCC, TSCUNX und TSPIGATOR (an CUNX) mit FHEM mit dem TSCULflash geflashed werden. Die anderen müssen mit dem jeweiligen Flash Programmer geflashed werden. Bei CUNO2 und SCC muss die Bootloadertaste gedrückt werden, bis der Flashvorgang anläuft.
So z.B. https://forum.fhem.de/index.php/topic,24436.msg631743.html#msg631743 kann es mit einem USB CUL Stick gehen, wenn man nicht TSCULflash verwendet.
TSCULflash ist erweitert auf COC, SCC, CCD, rpiaddon, CUNO2 und CUNO. Jedoch ist es nicht ganz so einfach zu handhaben, da zum einen teilweise die Taste zu drücken ist und bei Raspberry PI Modulen die Rechteproblematik für den Zugriff auf die IO-Pins überwunden werden muss. Tips dazu in der Command-Ref auch bei RPI_GPIO.
Bei einem Stapel aus SCC mit aufgesetztem COC, CCD oder (rpiaddon?) ist unbedingt beim SCC Flash darauf zu achten, die Taste am gewünschten Modul zu drücken. Sonst wird das oberste Nicht-SCC Modul mit der SCC Firmware geflashed.
Mit CUNO2 ist das flashen getestet (generell nur über USB!). Wichtig, aber auch hier, die Taste zu drücken.

Es gibt nicht den Luxus des Downloads beim TSCULflash, sondern die Firmware muss händisch in den FHEM/firmware Ordner kopiert werden. Der Typ ist dann z.B. TSCUL_V3.
Beispiel:
TSCULflash MeinCulV3Device TSCUL_V3

Wichtig für SCC Nutzer. TSSTACKED ist entfallen und wird nicht mehr unterstützt.
Statt dessen gibt es das neue Modul STACKABLETS (als Abwandlung von Rudolfs STACKABLE).
Dieses wird sozusagen zwischen die Stackteilnehmer eingebaut.

Beispiel für fhem.cfg:
#erstes SCC Modul als Basis
define SCC_WS868 TSCUL /dev/ttyAMA0@38400 0000
attr SCC_WS868 event-on-change-reading Ints_per_sec,IntCalcStat,MatchStat
attr SCC_WS868 rfmode SlowRF
attr SCC_WS868 room Receiver
attr SCC_WS868 sendpool CUL_HM868,SCC_WS868
attr SCC_WS868 verbose 1

#neues STACKABLETS virtuelles IO device
define STACK_1 STACKABLETS SCC_WS868
attr STACK_1 verbose 1

#zweites SCC Modul
define SCC_HM868 TSCUL FHEM:DEVIO:STACK_1:38400 1034
attr SCC_HM868 event-on-change-reading cond
attr SCC_HM868 hmId F11034


Ergänzender Hinweis zu USB CULs: 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_08\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 1234
bzw.
define CUL_433 TSCUL /dev/CUL433_0@12000000 0000
definiert werden und es gibt keine Probleme mit wechselnder Schnittstelle mehr.
Die Seriennummer kann beim Compilieren der Firmware in der board.h festgelegt werden, so dass damit dann auch /dev/CUL868_1 etc. für mehrere gleiche CULs möglich sind.

Oder für CUNX
define CUNX_868 TSCUL /dev/CUNX868_0@12000000 0000
oder für PIGATOR an CUNX
define PIGATOR_433 TSCUL /dev/CUNXPIM_0@38400 0000
die Seriennummer wird aus der Seriennummer des XMEGA Chips des CUNX gebildet. Unter Linux lsusb nutzen!

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.

Bei nicht nativen USB CULs wie z.B. nanoCUL, miniCUL oder CUNO2, beträgt die Baudrate 38400, dementsprechend muss die Definition beispielsweise so aussehen:
define CUL_868 TSCUL /dev/CUL868@38400 1234
bzw.
define CUL_433 TSCUL /dev/CUL433@38400 0000

Und noch ein Beispiel für eine Definition eines Netzwerk CUNX:
define CUL_868 TSCUL 192.168.178.111:2323 0000
oder für PIGATOR an CUNX
define PIGATOR_433 TSCUL 192.168.178.111:2324 0000
beim PIGATOR sollten zuvor mit Anschluss an USB und öffnen der Schnittstelle mit gewünschten Kommunikationsparametern mit ps oder unter TSCUL mit set PIMstoreBaud die seriellen Kommunikationsparameter zum PIGATOR Modul gespeichert werden, falls sie vom default abweichen.

Oder Netzwerk CUNO2:
define CUNO2_868 TSCUL 192.168.178.110:2323 0000

Die aktuell eingestellte oder per DHCP erhaltene Netzwerkadresse kann mit Lc repektive in TSCUL mit get NetAdresses abgefragt werden. Mit Lp respektive in TSCUL mit get NetPHYlink kann der Linkzustand des Netzwerkanschlusses angezeigt werden.


In der Zip Datei sind ebenfalls die ergänzten Module zu finden, die zur Nutzung der Firmware erforderlich sind.

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
16_TSCUL_RFR.pm -> der 16_CUL_RFR.pm, aus CUL_RFR devices werden damit TSCUL_RFR devices in der fhem.cfg (händisch anzupassen)
16_STACKABLETS.pm -> statt der 16_STACKABLE.pm, aus STACKABLE werden damit STACKABLETS devices in der fhem.cfg (händisch anzupassen)
97_timerTS.pm           -> Austausch-Timerroutinen und fhemFork()

10_UNIRoll_TS.pm  -> statt der 10_UNIRoll.pm, mit TSCUL 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 IO-devices zu verwenden, aus TSKS300 wird dann TSKS300  in der fhem.cfg (händisch anzupassen). Obsolet, da 14_TSCUL_WS.pm nun KS300 unterstützt.
14_TSCUL_TX.pm    -> statt der 14_CUL_TX.pm, mit TSCUL 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 IO-devices zu verwenden, aus CUL_WS wird dann TSCUL_WS  in der fhem.cfg (händisch anzupassen)
14_TSCUL_NC7427.pm  -> NC7427 Unterstützung
15_TSCUL_EM.pm   -> statt der 15_CUL_EM.pm, mit TSCUL IO-devices zu verwenden, aus CUL_EM wird dann TSCUL_EM  in der fhem.cfg (händisch anzupassen)
12_TSHMS.pm        -> statt der 12_HMS.pm zu verwenden
CalcUtil.pm               -> Hilfsrechenroutinen für Taupunkt und Windstärkeindex
ReadingUtil.pm          -> Hilfsroutinen für Readings

Da diese Module ergänzt werden (müssen!), überleben sie auch ein Update von FHEM.

98_fhemdebug.pm     -> fhemdebug zur zwingenden Nutzung mit 97_timerTS.pm.
98_apptime.pm          -> apptime zur zwingenden Nutzung mit 97_timerTS.pm.
98_apptm.pm            -> apptime zur zwingenden Nutzung mit 97_timerTS.pm, mit geringerem Speicherverbrauch bei weniger Details
10_IT.pm                   -> vermeidet unnötiges busy waiting beim Senden. Wird ohne Schutz von FHEM update überschrieben

Außerdem:

98_TSCULflash.pm     -> Zum Flash von TSCUL_V3, TSPIGATOR (an CUNX) mit Datei in FHEM/firmware

10_CUL_HM.pm         -> angepasste Version zur Nutzung mit TSCUL/tsculfw. Die Nutzung dieses Moduls ist optional. Für CUL_V3, nanoCUL, miniCUL im Multio-HM-IO Betrieb jedoch empfohlen, da sie den EEPROM Verschleiss über das Attribut "rssiSwitchHyst" verringert. Nur diese Version bietet derzeit vollständige TSCUL/tsculfw Unterstützung.
HMConfig.pm             -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden. Einstelllimits für HM-CC-RT-DN Regler P und I Anteil erweitert. Damit kann man mit R-regAdaptive offDeter deutlich mehr an den Regelparametern spielen.
98_HMinfo.pm           -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden. Spaltenbreiten in Tabelle von protoEvents variabel zu verbesserten Übersicht in der Darstellung.
98_HMtemplate.pm   -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden.
Die 4 Dateien entsprechen einem Stand von Anfang 09/2020. Derzeit sollten diese verwendet werden.

10_CULG.pm              -> optional, enthalten, da die Firmware es unterstützt

98_autocreate.pm       -> autocreate mit TSCUL Unterstützung

98_Cumulate               -> Kumulieren von Zählwerten, wie Strom, Regenmenge etc.
98_SAverage.pm         -> Mittelwertbildung von z.B. Temperaturen. Stunde, Tag, Monat und Jahr, sowie ein gleitender Mittelwert der letzten Stunde sind damit möglich.


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_STACKABLETS.pm DevIoTS.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.pm CalcUtil.pm 14_TSCUL_NC7427.pm ReadingUtil.pm 97_timerTS.pm 98_TSCULflash.pm 98_apptime.pm 98_apptm.pm 10_IT.pm 10_CULG.pm 10_CUL_HM.pm HMConfig.pm 98_HMinfo.pm 98_HMtemplate.pm ReadingUtil.pm 98_autocreate.pm 98_Cumulate.pm 98_SAverage.pm 98_fhemdebug.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 zwingend auszuführender 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` }

Noch ein Hinweis: TSCUL fragt auch die Firmwareversion der tsculfw auf 0.36 ab. Eine ältere Version wird also nicht unterstützt!

Frequenzoffset: Für HM ist ein Frequenzoffset von -20.6kHz im EEPROM als default in der tsculfw hinterlegt (das ist ein individuelles Optimum für meinen COC). Dieser Frequenzoffset kann mit set hmFreqOffs umgestellt werden. 0 ist default in der Standard-culfw.
Wenn also keine Antwort von angesprochenen HM devices kommt, dann hmFreqOffs von 0 ausgehend verstellen. CUNX z.B. geht eher in Richtung + mit dem Offset.
Wer das Frequenzspektrum sichtbar machen kann, kann sich die optimale Mitte aller devices ermitteln und mit dem Offset sein CUL dazu passend einstellen.

Noch ein Tip zur Haltbarkeit der CULs mit wenig SRAM (CUL V3, nanoCUL, miniCUL ...). Jedesmal, wenn einem HM-Device das IODev durch Roaming neu zugeordnet wird, führt das zu EEPROM Schreibvorgängen in den beteiligten CULs. Die Lebensdauer des EEPROMs ist begrenzt (100000 Schreibzyklen laut Datenblatt). Daher rate ich zur Nutzung des VorzugsIOs beim Device Attribut IOgrp. Also nicht einfach stumpf
attr HMdeviceName IOgrp VCCU
setzen, sondern
attr HMdeviceName IOgrp VCCU:CUL_mit_gutem_Empfang_fuer_Device
sofern die Roaming Funktionalität entsprechend RSSI für das jeweilige device nicht zwingend benötigt wird. Ein Fallback auf einen anderen CUL bleibt dennoch möglich.
Mit dem Attribut "rssiSwitchHyst", das in der beigefügten 10_CUL_HM.pm verfügbar ist, kann bei den HM-devices die Umschalthysterese für das Roaming von 10 bis auf 2 bei Bedarf für mobile devices verringert werden.
Mit dem Attribut "hmForceLzyCfg" kann wakeup und keep awake support bei solchen CULs aktiviert werden. Das erhöht den EEPROM Verschleiß beim Lesen oder Verändern von Registerwerten bei wakup und lazy config devices.

Ergänzt ist auch noch ein set TX3Send.
Damit lassen sich TX3 Sensordatentelegramme auf 433er CULs versenden.
Beispiel:

define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 TX3Send T:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." SID:23 U")}

define NF_HumOut notify Sen_Aussen:humidity.* {fhem("set TSCUL_WS433 TX3Send H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." SID:23 U")}


Ergänzt ist auch noch ein set KSSend.
Damit lassen sich WS Sensordatentelegramme versenden.
Beispiel:

define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 KSSend T:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." Code:2")}


Hier geht es zur vorherigen Version https://forum.fhem.de/index.php/topic,24436.msg1047116.html#msg1047116 (https://forum.fhem.de/index.php/topic,24436.msg1047116.html#msg1047116).

Gruß, Ansgar.

Edit: 00_TSCUL.pm minimale Anpassung für Listendarstellung
Edit2: kleine Korrekturen an 00_TSCUL.pm, 98_HMinfo.pm und HMConfig.pm
Edit3: Korrekturen zur IO Zuweisung in 10_CUL_HM.pm und kleine Korrektur in 98_HMinfo.pm
Edit4: Korrektur 10_CULHM.pm bzgl. negativer Temperaturen RT
Edit5: kleiner Modulupdate bezüglich Anzeigen
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.36
Beitrag von: noansi am 08 September 2020, 22:00:53
Hallo Stefan,

Zitat, ich teste dann gerne, wenn es was neues von dir gibt.
Ich bitte darum, gerne mit Feedback.  :)

@Peter: gerne auch von Dir, ob der Native Empfang noch funktioniert.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.36
Beitrag von: billiloumez am 10 September 2020, 09:04:49
Hallo Ansgar,

Danke, hab gerade alles aktualisiert, bisher läuft alles. Ich beobachte es jedenfalls weiter.

Gruß,
Stefan
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.36
Beitrag von: noansi am 10 September 2020, 10:41:38
Hallo Stefan,

ich habe oben nochmal Module (nicht die Firmware) in der zip ein klein wenig korrigiert., siehe Edit2.

Sendest Du weiterhin nur selten an die devices?
Wenn Du nun häufiger sendest würde weniger wahrscheinlich auffallen, wenn das Problem noch nicht behoben wäre.

Gruß, Ansgar
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.36
Beitrag von: billiloumez am 10 September 2020, 11:47:17
Hallo Ansgar,

alles klar, hab die drei Dateien noch ausgetauscht und FHEM neu gestartet.
An meinem Szenario hat sich eigentlich nichts geändert, ich hatte allerdings seit dem letzten "Hänger" bisher keine weiteren mehr.

Gruß,
Stefan
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.36
Beitrag von: noansi am 10 September 2020, 12:06:44
Hallo Stefan,

Zitat, ich hatte allerdings seit dem letzten "Hänger" bisher keine weiteren mehr.
Deswegen ist es mir bisher auch nicht selbst aufgefallen. Zum einen sende ich in meinem Testszenario regelmäßig und zum anderen tritt das Problem selten auf.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.36
Beitrag von: noansi am 10 September 2020, 15:28:37
Hallo Zusammen,

ich habe oben nochmal Module (nicht die Firmware) in der zip korrigiert., siehe Edit3.

Gruß, Ansgar
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.36
Beitrag von: billiloumez am 10 September 2020, 15:47:50
Hallo Ansgar,

alles klar, hab noch mal bei mir aktualisiert ;)

Gruß,
Stefan
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.36
Beitrag von: noansi am 10 September 2020, 20:45:09
Hallo Zusammen,

... Edit4.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.36
Beitrag von: surfi am 21 September 2020, 20:27:39
Hallo zusammen,

ich habe nun mal alles auf die in der TSCUL_fwcode_00_36_FHEM_Modules_00_54.zip enthaltenen Dateien upgedatet.
Seit dem sind alle Seiten von Homematic Geräten extrem breit. Benutze ich wieder eine "alte" 10_CUL_HM ist alles wieder so wie es immer war.

Der "Fehler" ist auch schon bei der 00_53 vorhanden.

Gruß Thomas
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.36
Beitrag von: noansi am 21 September 2020, 21:32:25
Hallo Thomas,

kannst das mal mit screenshots erklären, was Du meinst?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.36
Beitrag von: surfi am 21 September 2020, 22:03:32
Hi Ansgar,

hier ein HM Device mit der neuen CUL_HM und der alten. Bei der neuen ist die Device Seite extrem breit.
Ich hoffe mal, dass du nun eine Vorstellung hast was ich meine. Die alte war vom 17.12.2018.
Zwischen den Screenshots habe ich nur die 10_CUL_HM ausgetauscht.

Gruß Thomas
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.36
Beitrag von: noansi am 22 September 2020, 07:19:49
Hallo Thomas,

es fehlt jeweils der Rest der Seite.

CUL_HM liefert nur Inhalte von Variablen und Attributen.
Die Darstellung macht fhemweb. Es muss also an Inhalten liegen, wenn es länger wird.
Eventuell auch an versteckten, die Du mit
attr global showInternalValues 1
Sichtbar machen kannst.

Du kannst auch auf die f18 Darstellung wechseln. Die macht es eher schmaler.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.36
Beitrag von: surfi am 22 September 2020, 17:17:59
Hallo Ansgar,

deinen Rat befolgt, Attribut gesetzt, f18 Style..
Das macht die Sache leider nicht besser...
Man bekommt keinen Screenshot, auch nur ansatzweise lesbar, in voller Breite hin.
Kein Wert geht über die gesamte Seitenbreite

Ich habe da vermutlich etwas gefunden! In dem Dropdownfeld hinter der attr Schaltfläche tauchen unter .stc und über IODev die Namen sämtlicher Homematic Geräte auf...das ergibt eine endlos lange Zeile.

Kopiere ich die alten Module wieder in das fhem Verzeichnis taucht die Liste nicht auf.
Hast du eine Idee woran das liegen kann?

Gruß Thomas
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.36
Beitrag von: noansi am 22 September 2020, 21:07:07
Hallo Thomas,

was hast Du denn in attr global userattr alles stehen?

Haben sich die Namen da eingeschlichen?

Zeig mal ein List von einem device. Vielleicht gibt das noch Aufschlüsse.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.36
Beitrag von: noansi am 22 September 2020, 21:43:37
Hallo Thomas,

ich tippe nun auf das Attribut logIDs. Das gab es in 2018 noch nicht. Und es enthält die Namen der IOList und der CUL_HM devices.
Bei mir wird daraus aber eine Auswahlliste, wenn ich es einstellen will.

Daher nehme ich an, dass Dein FHEM insgesamt veraltet ist und daher die Liste bei der Anzeige nicht richtig verarbeitet wird.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.36
Beitrag von: surfi am 22 September 2020, 22:05:37
Hallo Ansgar,

ich bin nun erstmal zurück auf die 0.32, da sich auch noch andere Fehler gezeigt haben.
Ich konnte z.Bsp auch kein valveMaxPos bei den HM-RTs setzen.
Mein Fhem ist aktuell, bis auf die Dateien, die in der 0.32 excluded werden mussten.
Ich mache regelmäßig updates (14tägig).

Gruß Thomas
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.36
Beitrag von: surfi am 23 September 2020, 19:30:39
Hallo Ansgar,

ich kann den Fehler nun auch auf meiner Testinstallation nachstellen und provozieren. Sobald eine VCCU definiert ist mit mehr als einem Gerät in der IOList tritt der Fehler reproduzierbar auf.


Error: Syntax error, unrecognized expression: a[name=CUL_HMCube,....

CUL_HM Cube.. dazwischen fehlt wohl ein Trennzeichen

Gruß Thomas
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.36
Beitrag von: noansi am 23 September 2020, 21:33:40
Hallo Thomas,

was kommt bei
{$modules{CUL_HM}{AttrList}}
oben in der fhem Befehlzeile eingeben, wenn Du ein HM device betrachtest?

Hast Du im Attribut IOList Leerzeichen nach dem Komma eingebaut? Die sind nicht erlaubt! Und würden Dein Problem erklären.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.36
Beitrag von: surfi am 23 September 2020, 22:49:44
Hallo Ansgar,

nein, ich habe da kein Leerzeichen eingebaut. Wollte damit nur deutlich machen, dass es 2 Devices sind, aber ohne Trennzeichen aneinander aufgelistet werden. Meines Erachtens müsste ein Kommata oder etwas anderes dazwischen sein.
Es passiert NUR, wenn in der VCCU mehr als ein Device in der IOList aufgeführt ist.

IOList      TSCUL_868,Cube 
in der VCCU gesetzt.


do_not_notify:1,0 showtime:1,0 rawToReadable unit expert:multiple,defReg,allReg,rawReg,templ,none param readOnly:0,1 actAutoTry:0_off,1_on aesCommReq:1,0 model ignore:1,0 dummy:1,0 IODev IOList IOgrp hmKey hmKey2 hmKey3 actCycle readingOnDead:multiple,noChange,state,periodValues,periodString,channels rssiSwitchHyst:10,9.5,9,8.5,8,7.5,7,6.5,6,5.5,5,4.5,4,3.5,3,2.5,2 subType:AlarmControl,KFM100,THSensor,blindActuator,blindActuatorSol,dimmer,display,keyMatic,motionAndBtn,motionDetector,no,outputUnit,powerMeter,powerSensor,pushButton,remote,repeater,rgb,senBright,sensRain,sensor,singleButton,siren,smokeDetector,swi,switch,thermostat,threeStateSensor,timer,tipTronic,virtual,winMatic modelForce:ACTIONDETECTOR,ACTIONDETECTOR,ASH550,ASH550I,CCU-FHEM,CMM,DORMA_ATENT,DORMA_BRC-H,DORMA_RC-H,HM-CC-RT-DN,HM-CC-RT-DN-BOM,HM-CC-SCD,HM-CC-TC,HM-CC-VD,HM-DIS-EP-WM55,HM-DIS-TD-T,HM-DIS-WM55,HM-DW-WM,HM-ES-PMSW1-DR,HM-ES-PMSW1-PL,HM-ES-PMSW1-PL-DN-R1,HM-ES-PMSW1-PL-DN-R2,HM-ES-PMSW1-PL-DN-R3,HM-ES-PMSW1-PL-DN-R4,HM-ES-PMSW1-PL-DN-R5,HM-ES-PMSW1-SM,HM-ES-TX-WM,HM-HM-LC-DW-WM,HM-LC-AO-SM,HM-LC-BL1-FM,HM-LC-BL1-FM-2,HM-LC-BL1-PB-FM,HM-LC-BL1-SM,HM-LC-BL1-SM-2,HM-LC-BL1PBU-FM,HM-LC-DDC1-PCB,HM-LC-DIM1L-CV,HM-LC-DIM1L-CV-2,HM-LC-DIM1L-CV-644,HM-LC-DIM1L-PL,HM-LC-DIM1L-PL-2,HM-LC-DIM1L-PL-3,HM-LC-DIM1L-PL-644,HM-LC-DIM1PWM-CV,HM-LC-DIM1PWM-CV-2,HM-LC-DIM1T-CV,HM-LC-DIM1T-CV-2,HM-LC-DIM1T-CV-644,HM-LC-DIM1T-DR,HM-LC-DIM1T-FM,HM-LC-DIM1T-FM-2,HM-LC-DIM1T-FM-644,HM-LC-DIM1T-FM-LF,HM-LC-DIM1T-PL,HM-LC-DIM1T-PL-2,HM-LC-DIM1T-PL-3,HM-LC-DIM1T-PL-644,HM-LC-DIM1TPBU-FM,HM-LC-DIM1TPBU-FM-2,HM-LC-DIM2L-CV,HM-LC-DIM2L-SM,HM-LC-DIM2L-SM-2,HM-LC-DIM2L-SM-644,HM-LC-DIM2T-SM,HM-LC-DIM2T-SM,HM-LC-DIM2T-SM-2,HM-LC-JA1PBU-FM,HM-LC-RGBW-WM,HM-LC-SW1-BA-PCB,HM-LC-SW1-DR,HM-LC-SW1-FM,HM-LC-SW1-FM-2,HM-LC-SW1-PB-FM,HM-LC-SW1-PCB,HM-LC-SW1-PL,HM-LC-SW1-PL-3,HM-LC-SW1-PL-CT-R1,HM-LC-SW1-PL-CT-R2,HM-LC-SW1-PL-CT-R3,HM-LC-SW1-PL-CT-R4,HM-LC-SW1-PL-CT-R5,HM-LC-SW1-PL-DN-R1,HM-LC-SW1-PL-DN-R2,HM-LC-SW1-PL-DN-R3,HM-LC-SW1-PL-DN-R4,HM-LC-SW1-PL-DN-R5,HM-LC-SW1-PL-OM54,HM-LC-SW1-PL2,HM-LC-SW1-SM,HM-LC-SW1-SM-2,HM-LC-SW1-SM-ATMEGA168,HM-LC-SW1PBU-FM,HM-LC-SW2-DR,HM-LC-SW2-DR-2,HM-LC-SW2-FM,HM-LC-SW2-FM-2,HM-LC-SW2-PB-FM,HM-LC-SW2-SM,HM-LC-SW2PBU-FM,HM-LC-SW4-BA-PCB,HM-LC-SW4-DR,HM-LC-SW4-DR-2,HM-LC-SW4-PCB,HM-LC-SW4-PCB-2,HM-LC-SW4-SM,HM-LC-SW4-SM-2,HM-LC-SW4-SM-ATMEGA168,HM-LC-SW4-WM,HM-LC-SW4-WM-2,HM-MOD-EM-8,HM-MOD-EM-8BIT,HM-MOD-RE-8,HM-OU-CF-PL,HM-OU-CFM-PL,HM-OU-CFM-TW,HM-OU-CM-PCB,HM-OU-LED16,HM-PB-2-FM,HM-PB-2-WM,HM-PB-2-WM55,HM-PB-2-WM55-2,HM-PB-4-WM,HM-PB-4DIS-WM,HM-PB-4DIS-WM-2,HM-PB-6-WM55,HM-PBI-4-FM,HM-RC-12,HM-RC-12-B,HM-RC-12-SW,HM-RC-19,HM-RC-19-B,HM-RC-19-SW,HM-RC-2-PBU-FM,HM-RC-2-PBU-FM-2,HM-RC-4,HM-RC-4-2,HM-RC-4-3,HM-RC-4-3-D,HM-RC-4-B,HM-RC-8,HM-RC-DIS-H-X-EU,HM-RC-KEY3,HM-RC-KEY3-B,HM-RC-KEY4-2,HM-RC-KEY4-3,HM-RC-P1,HM-RC-SEC3,HM-RC-SEC3-B,HM-RC-SEC4-2,HM-RC-SEC4-3,HM-SCI-3-FM,HM-SEC-CEN,HM-SEC-KEY,HM-SEC-KEY-O,HM-SEC-KEY-S,HM-SEC-MDIR,HM-SEC-MDIR-2,HM-SEC-MDIR-3,HM-SEC-RHS,HM-SEC-RHS-2,HM-SEC-SC,HM-SEC-SC-2,HM-SEC-SCO,HM-SEC-SD,HM-SEC-SD-2,HM-SEC-SFA-SM,HM-SEC-SIR-WM,HM-SEC-TIS,HM-SEC-WDS,HM-SEC-WDS-2,HM-SEC-WIN,HM-SEN-DB-PCB,HM-SEN-EP,HM-SEN-LI-O,HM-SEN-MDIR-O,HM-SEN-MDIR-O-2,HM-SEN-MDIR-O-3,HM-SEN-MDIR-SM,HM-SEN-MDIR-WM55,HM-SEN-RD-O,HM-SEN-WA-OD,HM-SWI-3-FM,HM-SYS-SRP-PL,HM-TC-IT-WM-W-EU,HM-WDC7000,HM-WDS10-TH-O,HM-WDS100-C6-O,HM-WDS100-C6-O-2,HM-WDS20-TH-O,HM-WDS30-OT2-SM,HM-WDS30-OT2-SM-2,HM-WDS30-T-O,HM-WDS40-TH-I,HM-WDS40-TH-I-2,HM-WS550,HM-WS550LCB,HM-WS550LCW,HM-WS550TECH,IS-WDS-TH-OD-S-R3,KFM-DISPLAY,KFM-SENSOR,KS550,KS550LC,KS550TECH,KS888,OLIGO-SMART-IQ-HM,PS-SWITCH,PS-TH-SENS,ROTO_ZEL-STG-RM-DWT-10,ROTO_ZEL-STG-RM-FDK,ROTO_ZEL-STG-RM-FEP-230V,ROTO_ZEL-STG-RM-FFK,ROTO_ZEL-STG-RM-FSA,ROTO_ZEL-STG-RM-FSS-UP3,ROTO_ZEL-STG-RM-FST-UP4,ROTO_ZEL-STG-RM-FWT,ROTO_ZEL-STG-RM-FZS,ROTO_ZEL-STG-RM-FZS-2,ROTO_ZEL-STG-RM-HS-4,ROTO_ZEL-STG-RM-WT-2,S550IA,SCHUECO_263-130,SCHUECO_263-131,SCHUECO_263-132,SCHUECO_263-133,SCHUECO_263-134,SCHUECO_263-135,SCHUECO_263-144,SCHUECO_263-145,SCHUECO_263-146,SCHUECO_263-147,SCHUECO_263-155,SCHUECO_263-157,SCHUECO_263-158,SCHUECO_263-160,SCHUECO_263-162,SCHUECO_263-167,SCHUECO_263-XXX,SENSOTIMER-ST-6,VIRTUAL,WDF-SOLAR,WS888 .mId logIDs:multiple,none,sys,all,broadcast,IO:TSCUL_868,IO:Cube,BM1_EG_Kueche,Dim1_EG_Kueche,HM_00AC02,HM_00AC03,HM_00AC04,HM_00AC05,HM_00AC06,HM_111201,HM_111248,HM_111249,HM_111301,HM_120900,HM_345608,HM_492901,HM_4929D3,HM_567890,HM_6461DA,HM_6A0C7C,HM_6A0C85,HM_901234,HM_F1D002,RT_EG_Buero,RT_EG_Kueche,RT_EG_WC,RT_OG_Bad,RT_OG_Lukas,RT_OG_SZ,RT_OG_T,SW_Easyvdr,SW_Trockner,TFK_DG_Ost,TFK_DG_West,TFK_EG_Buero_gr,TFK_EG_Buero_kl,TFK_EG_HWR,TFK_EG_Kueche,TFK_EG_WC,TFK_EG_WZ_Links,TFK_EG_WZ_Rechts,TFK_OG_Bad,TFK_OG_L,TFK_OG_SZ,TFK_OG_T,TH_DG,TH_EG_Buero,TH_EG_HWR,TH_EG_Kueche,TH_OG_Bad,TH_OG_L,TH_OG_SZ,TH_OG_T serialNr firmware .stc .devInfo actStatus rssiLog:1,0 autoReadReg:0_off,1_restart,2_pon-restart,3_onChange,4_reqStatus,5_readMissing,8_stateOnly burstAccess:0_off,1_auto msgRepeat hmProtocolEvents:0_off,1_dump,2_dumpFull,3_dumpTrigger aesKey:5,4,3,2,1,0 repPeers peerIDs tempListTmpl:none,defaultWeekplan,HM_6461DA_Climate,HM_6A0C7C_Clima,HM_6A0C85_Clima,RT_EG_Buero_Clima,RT_EG_Kueche_Clima,RT_EG_WC_Clima,RT_OG_Bad_Clima,RT_OG_L_Clima,RT_OG_SZ_Clima,RT_OG_T_Clima levelRange levelMap cyclicMsgOffset event-aggregator event-min-interval event-on-change-reading event-on-update-reading oldreadings stateFormat:textField-long timestamp-on-change-reading


Gruß Thomas
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.36
Beitrag von: noansi am 24 September 2020, 21:00:01
Hallo Thomas,

die Attributliste sieht erst mal gut aus, wie der Code sie (ohne Trennzeichen, siehe oben) erzeugen sollte.

Jetzt bitte doch mal ein List von einem "breiten" device.

Und welches Atrribut wird beim device zur Anpassung nach dem Öffnen der Seite angezeigt? Bei mir ist es room.

ZitatError: Syntax error, unrecognized expression: a[name=CUL_HMCube,....
Stand das exakt irgendwo so?
Wenn nicht, dann bitte exakt.

Die Vermutung wäre derzeit, dass etwas mit den Hilftexten nicht passt, oder Du einen unglücklichen Namen verwendet hast, der die automatische Hilfeanzeige aus dem Tritt bringt.
Ich habe auch eine VCCU mit 2 IOs und kann Dein Problem nicht nachvollziehen.

Hast Du eigentlich die CommandRef mit den neuen Modulen aktualisiert?

Mit einem mir noch nicht bekannten Mechanismus werden die Hilfetexte aus dem Text für die CommandRef erzeugt.

Da Du der mir bisher einzige mit dem Problem bekannte Nutzer bist, vermute ich einen Daten-/Einstellungszusammenhang.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.36
Beitrag von: surfi am 24 September 2020, 22:09:30
Hallo Ansgar,

das war das "breite" Device. Bei mir wurde auch room beim öffnen der Seite angezeigt.
Sobald man auf die Attribut Schaltfläche geklickt hat, kam exakt diese Meldung. Es standen halt nur alle HM Devices Komma separiert dahinter.

Deine Vermutung passte.. es waren die Hilfetexte. Bei den Namen habe ich bewusst auf alle Sonderzeichen außer "_" verzichtet.
Ich habe die Commandref nochmals aktualisiert und nun läufts.. merkwürdig.. aber Hauptsache es funktioniert nun.
Besten Dank für deine Geduld.

Gruß Thomas
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.36
Beitrag von: noansi am 24 September 2020, 22:19:28
Hallo Thomas,

:o :o :o :o :o

Ich habe den Rudolfs Commandref Tip jetzt fett zwingend hervorgehoben.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 04 November 2020, 20:18:44
Hallo Testwillige,

hier eine neue Version 0.37 der Timestamp Firmware und der dazu benötigten FHEM Module.

In dieser Version 0.37 ist der Readout des Tranceiver RX Fifos insbesondere für ASKSIN verändert. Beim Reboot nach dem Flashen werden alle EEPROM Einstellungen auf Default gesetzt. Also alle am CUL vorgenommenen Einstellungen notieren, um sie wieder einstellen zu können.
RF_Router und fast_rf sind verändert und nicht kompatibel zu vorherigen Versionen.

Version 0.36 behebt ein Überlaufproblem des RX-FIFOs des Transceivers, der zum Empfangsausfall führen konnte (fiel nur beim reinen Empfangsbetrieb ohne regelmäßiges Senden auf). Danke Stefan für den Hinweis.

Auszug aus der Changed:
- little correction in rf_native, if slowrf monitoring is active
- lacrosse emu reworked
- SlowRf reception adapted for better ESA reception with still well E and HMS reception
- generic Manchester raw send added with Gm command
- ESA send added with 'S' command
- HMS send added with 'Q' command
- IT reception corrected
- RfRouter with repeat in FastRF packet, better send timing and reduced receive timeout
- for pure USB CULs blinking while waiting on watchdog reboot and during boot/bootloader reboot with different frequencies
- message finalization with \n on PIM receive buffer full
- ASKSIN, fastRF, RF-Router, moritz, rwe, RX-FIFO Overflow detection improved

Noch als Hinweis, für HMS und ESA scheint sens 12 eine ungünstige Einstellung für den Empfang  dieser Protokolle zu sein.

Diese Version bietet wakup support und keep awake Support. Für CULs mit wenig Speicher kann dies mit dem Attribut "hmForceLzyCfg" aktiviert werden, siehe auch der Hinweis zum EEPROM Verschleiß weiter unten.

Das RF-Router Ping Timing ist geändert, damit also auch nicht kompatibel mit Standard culffw oder a-culfw und auch nicht zur Version 0.32.
Ergänzt ist SlowRf Empfang von Pearl NC7427 Temperatur/Luftfeuchte Sensoren. Entsprechend Kanalwahlschalter können 3 Stück empfangen werden. Zum Anlernen mittels autocreate muss der TEST Taster am Sensor gedrückt werden.

Das EEPROM Layout ist geändert und daher werden nach dem Flashen alle Einstellungen auf default zurück gestellt. Also vor dem Flashen individuelle Einstellungen, z.B. Frequenzoffsets, notieren und nacher neu einstellen.

Auszug aus der Changed:
- FULL_PA_RAMPING bugs corrected
- CCA CS thresholds setable for ASKSIN, MORITZ, HAS_RWE, RFNATIVE and MBUS with XTxy, x=CARRIER_SENSE_REL_THR, y=CARRIER_SENSE_ABS_THR as in AGCCTRL1
- SlowRf receive timing limits corrected
- SlowRf lower filter switched off by define in rf_receive_timing.h
- RFR timing/timeout shortened, FastRF CCA disabled
- auto Ci interrupt counter messages
- XP command extended to switch on auto Ci messages, AP removed as all PLL messages switchable by XP
- improvement and corrections for CUNX RS485 PIG support
- CUNX: PIG RTS controllable by USB Host for serial foward and RS485 serial forward
- CUNX: DMX interupts changed to HI priority and CC1101 interrupts to MED priority
- CUNX: USB interrupts to LO priority
- GPIOR1 used for USB USB_DeviceState
- GPIOR1 used for SERIAL STACKING stacking_ST_state


Ein Peakfilter für SlowRF Empfang ist ergänzt und mit "peakfilter" einstellbar.
In dem Zusammenhang ist auch das RF-Router Ping Timing geändert, damit also auch nicht kompatibel mit Standard culffw oder a-culfw.
Außerdem kann das Senden von RF-Router Daten nach deren Empfang einstellbar verzögert werden (RfRdelay).

CCAMode wirkt nun auch auf IT-Senden und SOMY-Senden, sowie auf das Senden des RF-Router Pings. Mit fRfCCAMode kann auch das CCA Verhalten für RF-Router Senden und FastRF geändert werden.

Auszug aus der Changed:
- IT and SOMYFY use SlowRF EEPROM CCA setting now for sending
- changes in SlowRF reception for reset and sync start. IT V1 reception tested succsessfully.
- SlowRF filter and match adaption
- SlowRF spike filter improved, max. peak lenght settable with Xpxx, xx hex time in 8us units
- IR receive/transmit pause during send of SlowRF changed to not globally switching off all interrupts
- periodic RF-Router ping RSSI display as "Cuxx\r\n" with xx = RSSI Hex
- RF-Router ping timing changed for better distinguish from other protocols
- RF-Router pre silence before send settable with uRxx, xx hex time in 4ms units
- Xrrt commands bits:
   rr:
   report known protocol data                                                      Bit 0
   report repeated data                                                            Bit 1
   report received bits                                                            Bit 2
   report 'r' (rising) or 'f' (falling) edge, '.' (collect) or '?' (sync) timeout  Bit 3
   report edges, bit times and timeouts                                            Bit 4
   report S300 data with valid checksum only                                       Bit 5
   report FHT                                                                      Bit 6
   report 'l' RSSI decimal data continuosly                                        Bit 7
   t:
   report recorded SlowRF timing                                                   Bit 0
- corrections in interrupt flag clearing
- correction in delay function
- fastRF bug corrected, untested
- EEPROM layout changed for the new parameters


TSCUNX kann mit entsprechendem RS485 Modul nun auch DMX.
Auch HM485 ist für TXCUNX angepasst.
In dem Zuge ist auch die DMX Funktionalität bei CUNO2 etwas erweitert.
IR läuft nun auch richtig mit TSCONO2.
Außerdem läuft RF-Router auf der tsculfw, allerdings mit einer Änderung. Das 'U' ist durch '~' ersetzt. 'U' kollidierte mit dem Uniroll Senden.

Kurzer Auszug aus der CHANGED:
- IO optimizations CUNX, especially to/from PIM and Ethernet
- CUNX DHCP non blocking operation
- IO optimizations
- HM485 support for CUNX (like CUNO2) with RS485 PIM.
  HM485 switch off with Hx for CUNX. With CUNX after Hx RS485 PIM again accessible via PIM USB or Ethernet Interface
- CUNX support for DMX and HM485 with RS485 PIM (to be tested), a Dwxxxxyy switches to DMX via CUNX Interface, a Hsxxxxxxxxxxxxxxxxxx switches to HM485 via CUNX Interface
- DMX switch off with Dx. With CUNX after Dx RS485 PIM is again accessible via PIM USB- or Ethernet Interface
  DMX flexible channel usage. Channels are sent out upto the highest channel set (0 sent as default for unset channels). With switching off with Dx the highest channel is reset.
  DMX changed in timing and resting behaviour. Rests on IDLE if less then 24 device, only, to keep 1204µs min. BREAK to BREAK (to be tested)
  DMX Dt command to set/view timing of MarkAfterBreak and BREAK
  DMX less disturbed while sending SlowRF
- W function gives feedback after writing EEPROM
- clock timer unburdened, may impact onewire and fht (to be tested)
- corrections for IRTX
- IR base timings changed to 12500Hz or 20000Hz
- RF-Router working, but 'U' changed to '~' (definable in board.h, but 'U' disables HAS_UNIROLL)

Es ist eine Prüfung auf Stacküberlauf eingebaut. Am Anfang des heap werden zwei Byte mit einem Bitmuster beschrieben. Wird das verändert, dann ist der Speicher wahrscheinlich korrumpiert, was durch einen Stacküberlauf ausgelöst sein sollte. Sofern der CUL dann noch kann sendet er ein "C_M" an TSCUL, was zu einem entsprechenden Log Eintrag führt.
Damit kann man vorsichtig die Speichergrenzen ausloten. Ein langer Testzeitraum ist aber erforderlich, um einigermaßen sicher zu sein, dass der worst case auch mal durchlaufen worden ist.
Außerdem ist ein Kommando mU (je nach Firmware) eingebaut, mit dem man den vom Stack ungenutzen heap in etwa auslesen kann (auch als get unusedstack in TSCUL verfügbar). Auch hier gilt, nur nach langer Laufzeit einigermaßen sinnvoll. Es macht sicher keinen Sinn auf Grund des Wertes den Speicher bis auf das letzte Byte auszuquetschen, denn weiterhin hängt die Stacknutzung vom gewählten Protokoll und Einstellungen ab.

In TSCULflash ist Flashen auch von NanoCULs und MiniCULs ergänzt. Vor dem Flashen wird ein "B00" also Reset für die TSCUL Firmware an den nano/Mini geschickt, 1 Sekunde gewartet und dann versucht mit avrdude zu flashen.
Also erst die Firmware in den FHEM/Firmware Ordner kopieren und dann in FHEM mit
TSCULflash <nanodevicename> TSnanoCUL
bzw.
TSCULflash <minidevicename> TSminiCUL
versuchen zu Flashen. Im Log sollte danach (dauert etwas) die avrdude Ausgabe zu finden sein.

Ebenfalls möglich ist das Flashen eines PIGATOR Moduls an einem CUNX
TSCULflash <pigatordevicename>|<cunxdevicename> TSPIGATOR

AESCommReq wird unterstützt. Die Nutzung ist unverändert zu Standard CUL, sprich, beim gewünschten Gerät/Kanal aesCommReq auf 1 setzen und ggf. noch aesKey passend zum verteilten Key setzen.
Es werden von tsculfw nur die Keys 0 (Default Key) bis 3 unterstützt.

Diese Erweiterung erfordert jedoch auch zusätzliche Empfangspuffer im knappen Speicher des CULs. Ein CUL V3 nutzt bis zu 6 Empfangspuffer. Auch der FlashSpeicherbdarf ist angestiegen, so dass einige Protokolle nicht mehr gleichzeitig in ein Kompilat passen. Das sollte aber weniger tragisch sein, da im ASKSIN Modus ohnehin nur HM empfangen werden kann.

Bei CUL V2 reicht der verfügbare Speicher leider hinten und vorne nicht aus, um diese Version nutzen zu können.

Im Anhang ist in TSCUL_fwcode_00_xx_FHEM_Modules_00_xx.zip wieder die Timestamp Firmware zu finden. Getestet habe ich TSCUNX, TSPIGATOR , TSCUL_V3 , TSCUL_V3_RFR, TSCUNO2, TSCOC und TSSCC. (TSCUL_V3_RFR ist ohne HM Unterstützung, also nur SlowRF)

Die tsculfw Firmware kann für TSCUL_V3, TSCUL_V3_RFR (via USB), TSCUNO2, TSCOC, TSSCC, TSCUNX und TSPIGATOR (an CUNX) mit FHEM mit dem TSCULflash geflashed werden. Die anderen müssen mit dem jeweiligen Flash Programmer geflashed werden. Bei CUNO2 und SCC muss die Bootloadertaste gedrückt werden, bis der Flashvorgang anläuft.
So z.B. https://forum.fhem.de/index.php/topic,24436.msg631743.html#msg631743 kann es mit einem USB CUL Stick gehen, wenn man nicht TSCULflash verwendet.
TSCULflash ist erweitert auf COC, SCC, CCD, rpiaddon, CUNO2 und CUNO. Jedoch ist es nicht ganz so einfach zu handhaben, da zum einen teilweise die Taste zu drücken ist und bei Raspberry PI Modulen die Rechteproblematik für den Zugriff auf die IO-Pins überwunden werden muss. Tips dazu in der Command-Ref auch bei RPI_GPIO.
Bei einem Stapel aus SCC mit aufgesetztem COC, CCD oder (rpiaddon?) ist unbedingt beim SCC Flash darauf zu achten, die Taste am gewünschten Modul zu drücken. Sonst wird das oberste Nicht-SCC Modul mit der SCC Firmware geflashed.
Mit CUNO2 ist das flashen getestet (generell nur über USB!). Wichtig, aber auch hier, die Taste zu drücken.

Es gibt nicht den Luxus des Downloads beim TSCULflash, sondern die Firmware muss händisch in den FHEM/firmware Ordner kopiert werden. Der Typ ist dann z.B. TSCUL_V3.
Beispiel:
TSCULflash MeinCulV3Device TSCUL_V3

Wichtig für SCC Nutzer. TSSTACKED ist entfallen und wird nicht mehr unterstützt.
Statt dessen gibt es das neue Modul STACKABLETS (als Abwandlung von Rudolfs STACKABLE).
Dieses wird sozusagen zwischen die Stackteilnehmer eingebaut.

Beispiel für fhem.cfg:
#erstes SCC Modul als Basis
define SCC_WS868 TSCUL /dev/ttyAMA0@38400 0000
attr SCC_WS868 event-on-change-reading Ints_per_sec,IntCalcStat,MatchStat
attr SCC_WS868 rfmode SlowRF
attr SCC_WS868 room Receiver
attr SCC_WS868 sendpool CUL_HM868,SCC_WS868
attr SCC_WS868 verbose 1

#neues STACKABLETS virtuelles IO device
define STACK_1 STACKABLETS SCC_WS868
attr STACK_1 verbose 1

#zweites SCC Modul
define SCC_HM868 TSCUL FHEM:DEVIO:STACK_1:38400 1034
attr SCC_HM868 event-on-change-reading cond
attr SCC_HM868 hmId F11034


Ergänzender Hinweis zu USB CULs: 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_08\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 1234
bzw.
define CUL_433 TSCUL /dev/CUL433_0@12000000 0000
definiert werden und es gibt keine Probleme mit wechselnder Schnittstelle mehr.
Die Seriennummer kann beim Compilieren der Firmware in der board.h festgelegt werden, so dass damit dann auch /dev/CUL868_1 etc. für mehrere gleiche CULs möglich sind.

Oder für CUNX
define CUNX_868 TSCUL /dev/CUNX868_0@12000000 0000
oder für PIGATOR an CUNX
define PIGATOR_433 TSCUL /dev/CUNXPIM_0@38400 0000
die Seriennummer wird aus der Seriennummer des XMEGA Chips des CUNX gebildet. Unter Linux lsusb nutzen!

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.

Bei nicht nativen USB CULs wie z.B. nanoCUL, miniCUL oder CUNO2, beträgt die Baudrate 38400, dementsprechend muss die Definition beispielsweise so aussehen:
define CUL_868 TSCUL /dev/CUL868@38400 1234
bzw.
define CUL_433 TSCUL /dev/CUL433@38400 0000

Und noch ein Beispiel für eine Definition eines Netzwerk CUNX:
define CUL_868 TSCUL 192.168.178.111:2323 0000
oder für PIGATOR an CUNX
define PIGATOR_433 TSCUL 192.168.178.111:2324 0000
beim PIGATOR sollten zuvor mit Anschluss an USB und öffnen der Schnittstelle mit gewünschten Kommunikationsparametern mit ps oder unter TSCUL mit set PIMstoreBaud die seriellen Kommunikationsparameter zum PIGATOR Modul gespeichert werden, falls sie vom default abweichen.

Oder Netzwerk CUNO2:
define CUNO2_868 TSCUL 192.168.178.110:2323 0000

Die aktuell eingestellte oder per DHCP erhaltene Netzwerkadresse kann mit Lc repektive in TSCUL mit get NetAdresses abgefragt werden. Mit Lp respektive in TSCUL mit get NetPHYlink kann der Linkzustand des Netzwerkanschlusses angezeigt werden.


In der Zip Datei sind ebenfalls die ergänzten Module zu finden, die zur Nutzung der Firmware erforderlich sind.

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
16_TSCUL_RFR.pm -> der 16_CUL_RFR.pm, aus CUL_RFR devices werden damit TSCUL_RFR devices in der fhem.cfg (händisch anzupassen)
16_STACKABLETS.pm -> statt der 16_STACKABLE.pm, aus STACKABLE werden damit STACKABLETS devices in der fhem.cfg (händisch anzupassen)
97_timerTS.pm           -> Austausch-Timerroutinen und fhemFork()

10_UNIRoll_TS.pm  -> statt der 10_UNIRoll.pm, mit TSCUL 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 IO-devices zu verwenden, aus TSKS300 wird dann TSKS300  in der fhem.cfg (händisch anzupassen). Obsolet, da 14_TSCUL_WS.pm nun KS300 unterstützt.
14_TSCUL_TX.pm    -> statt der 14_CUL_TX.pm, mit TSCUL 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 IO-devices zu verwenden, aus CUL_WS wird dann TSCUL_WS  in der fhem.cfg (händisch anzupassen)
14_TSCUL_NC7427.pm  -> NC7427 Unterstützung
15_TSCUL_EM.pm   -> statt der 15_CUL_EM.pm, mit TSCUL IO-devices zu verwenden, aus CUL_EM wird dann TSCUL_EM  in der fhem.cfg (händisch anzupassen)
12_TSHMS.pm        -> statt der 12_HMS.pm zu verwenden
CalcUtil.pm               -> Hilfsrechenroutinen für Taupunkt und Windstärkeindex
ReadingUtil.pm          -> Hilfsroutinen für Readings

Da diese Module ergänzt werden (müssen!), überleben sie auch ein Update von FHEM.

98_fhemdebug.pm     -> fhemdebug zur zwingenden Nutzung mit 97_timerTS.pm.
98_apptime.pm          -> apptime zur zwingenden Nutzung mit 97_timerTS.pm.
98_apptm.pm            -> apptime zur zwingenden Nutzung mit 97_timerTS.pm, mit geringerem Speicherverbrauch bei weniger Details
10_IT.pm                   -> vermeidet unnötiges busy waiting beim Senden. Wird ohne Schutz von FHEM update überschrieben

Außerdem:

98_TSCULflash.pm     -> Zum Flash von TSCUL_V3, TSPIGATOR (an CUNX) mit Datei in FHEM/firmware

10_CUL_HM.pm         -> angepasste Version zur Nutzung mit TSCUL/tsculfw. Die Nutzung dieses Moduls ist optional. Für CUL_V3, nanoCUL, miniCUL im Multio-HM-IO Betrieb jedoch empfohlen, da sie den EEPROM Verschleiss über das Attribut "rssiSwitchHyst" verringert. Nur diese Version bietet derzeit vollständige TSCUL/tsculfw Unterstützung.
HMConfig.pm             -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden. Einstelllimits für HM-CC-RT-DN Regler P und I Anteil erweitert. Damit kann man mit R-regAdaptive offDeter deutlich mehr an den Regelparametern spielen.
98_HMinfo.pm           -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden. Spaltenbreiten in Tabelle von protoEvents variabel zu verbesserten Übersicht in der Darstellung.
98_HMtemplate.pm   -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden.
Die 4 Dateien entsprechen einem Stand von Anfang 09/2020. Derzeit sollten diese verwendet werden.

10_CULG.pm              -> optional, enthalten, da die Firmware es unterstützt

98_autocreate.pm       -> autocreate mit TSCUL Unterstützung

98_Cumulate               -> Kumulieren von Zählwerten, wie Strom, Regenmenge etc.
98_SAverage.pm         -> Mittelwertbildung von z.B. Temperaturen. Stunde, Tag, Monat und Jahr, sowie ein gleitender Mittelwert der letzten Stunde sind damit möglich.
98_IntervalTimer.pm   -> optional, Intervalltimer um FEHM-Timerbasiert Kommandos in möglichst konstanten Intervallen absetzen zu können.

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_STACKABLETS.pm DevIoTS.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.pm CalcUtil.pm 14_TSCUL_NC7427.pm ReadingUtil.pm 97_timerTS.pm 98_TSCULflash.pm 98_apptime.pm 98_apptm.pm 10_IT.pm 10_CULG.pm 10_CUL_HM.pm HMConfig.pm 98_HMinfo.pm 98_HMtemplate.pm ReadingUtil.pm 98_autocreate.pm 98_Cumulate.pm 98_SAverage.pm 98_fhemdebug.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 zwingend auszuführender 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` }

Noch ein Hinweis: TSCUL fragt auch die Firmwareversion der tsculfw auf 0.36 ab. Eine ältere Version wird also nicht unterstützt!

Frequenzoffset: Für HM ist ein Frequenzoffset von -20.6kHz im EEPROM als default in der tsculfw hinterlegt (das ist ein individuelles Optimum für meinen COC). Dieser Frequenzoffset kann mit set hmFreqOffs umgestellt werden. 0 ist default in der Standard-culfw.
Wenn also keine Antwort von angesprochenen HM devices kommt, dann hmFreqOffs von 0 ausgehend verstellen. CUNX z.B. geht eher in Richtung + mit dem Offset.
Wer das Frequenzspektrum sichtbar machen kann, kann sich die optimale Mitte aller devices ermitteln und mit dem Offset sein CUL dazu passend einstellen.

Noch ein Tip zur Haltbarkeit der CULs mit wenig SRAM (CUL V3, nanoCUL, miniCUL ...). Jedesmal, wenn einem HM-Device das IODev durch Roaming neu zugeordnet wird, führt das zu EEPROM Schreibvorgängen in den beteiligten CULs. Die Lebensdauer des EEPROMs ist begrenzt (100000 Schreibzyklen laut Datenblatt). Daher rate ich zur Nutzung des VorzugsIOs beim Device Attribut IOgrp. Also nicht einfach stumpf
attr HMdeviceName IOgrp VCCU
setzen, sondern
attr HMdeviceName IOgrp VCCU:CUL_mit_gutem_Empfang_fuer_Device
sofern die Roaming Funktionalität entsprechend RSSI für das jeweilige device nicht zwingend benötigt wird. Ein Fallback auf einen anderen CUL bleibt dennoch möglich.
Mit dem Attribut "rssiSwitchHyst", das in der beigefügten 10_CUL_HM.pm verfügbar ist, kann bei den HM-devices die Umschalthysterese für das Roaming von 10 bis auf 2 bei Bedarf für mobile devices verringert werden.
Mit dem Attribut "hmForceLzyCfg" kann wakeup und keep awake support bei solchen CULs aktiviert werden. Das erhöht den EEPROM Verschleiß beim Lesen oder Verändern von Registerwerten bei wakup und lazy config devices.

Ergänzt ist auch noch ein set TX3Send.
Damit lassen sich TX3 Sensordatentelegramme auf 433er CULs versenden.
Beispiel:

define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 TX3Send T:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." SID:23 U")}

define NF_HumOut notify Sen_Aussen:humidity.* {fhem("set TSCUL_WS433 TX3Send H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." SID:23 U")}


Ergänzt ist auch noch ein set KSSend.
Damit lassen sich WS Sensordatentelegramme versenden.
Beispiel:

define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 KSSend T:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." Code:2")}


Zum regelmäßigen Senden von Sensordaten kann der IntervalTimer genutzt werden.
Beispiel:
define AussenSend_WS11 IntervalTimer CUNO2_WS868 176.5
attr AussenSend_WS11 offCmd {fhem("set @ KSSend T: ".ReadingsVal("C_Aussen","temperature",0.0)." H: ".ReadingsVal("C_Aussen","humidity",0.0)." Code:21")}
attr AussenSend_WS11 onCmd {fhem("set @ KSSend T: ".ReadingsVal("C_Aussen","temperature",0.0)." H: ".ReadingsVal("C_Aussen","humidity",0.0)." Code:21")}


Hier geht es zur vorherigen Version https://forum.fhem.de/index.php/topic,24436.msg1083931.html#msg1083931 (https://forum.fhem.de/index.php/topic,24436.msg1083931.html#msg1083931).

Gruß, Ansgar.

Edit: Module, insbesondere 10_CUL_HM.pm aktualisiert.
Edit2: Module, insbesondere 10_CUL_HM.pm wegen Bug bei set Paramterparsing aktualisiert.
Edit3: Firmware Source angepasst, um den WS Protokoll 1.1 Support besser zu unterstützen, sofern er in der jeweiligen board.h vor dem Compilieren aktiviert wird.
Edit4: Module, insbesondere 10_CUL_HM.pm wegen Bug in CUL_HM_ID2PeerList aktualisiert. Bitte beachten, beim HM-CC-RT-DN werden Ist-Temperatur und Ventilstellung nur noch im Clima Channel aktualisiert.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: surfi am 15 November 2020, 11:53:30
Hallo zusammen,

ich habe die 0.37 ausprobiert. Seit dem kann ich keine Wochenprofile mehr mit dem Modul weekplan an die HM-CC-RT-DN übertragen.
Im Log ist mir folgendes aufgefallen:

2020.11.15 11:27:35 3: CUL_HM set RT_EG_Buero_Clima tempListMon prep 24:00 18.0
2020.11.15 11:27:35 3: CUL_HM set RT_EG_Buero_Clima tempListTue prep 24:00 18.0
2020.11.15 11:27:35 3: CUL_HM set RT_EG_Buero_Clima tempListWed prep 24:00 18.0
2020.11.15 11:27:35 3: CUL_HM set RT_EG_Buero_Clima tempListThu prep 24:00 18.0
2020.11.15 11:27:35 3: CUL_HM set RT_EG_Buero_Clima tempListFri prep 24:00 18.0
2020.11.15 11:27:35 3: CUL_HM set RT_EG_Buero_Clima tempListSat prep 24:00 18.0
2020.11.15 11:27:35 3: CUL_HM set RT_EG_Buero_Clima tempListSun exec exec 24:00 18.0
2020.11.15 11:27:35 1: EG_Buero_WEEKPROFILE(Set): Bad format, use HH:MM TEMP ...


In der vorletzten Zeile taucht 2 mal exec auf, das kann nicht passen.

Sobald ich nur die 10_CUL_HM.pm austausche gegen die "originale" incl reload sieht es so aus:

2020.11.15 11:40:30 3: CUL_HM set RT_EG_Buero_Clima tempListMon prep 24:00 18.0
2020.11.15 11:40:30 3: CUL_HM set RT_EG_Buero_Clima tempListTue prep 24:00 18.0
2020.11.15 11:40:30 3: CUL_HM set RT_EG_Buero_Clima tempListWed prep 24:00 18.0
2020.11.15 11:40:30 3: CUL_HM set RT_EG_Buero_Clima tempListThu prep 24:00 18.0
2020.11.15 11:40:30 3: CUL_HM set RT_EG_Buero_Clima tempListFri prep 24:00 18.0
2020.11.15 11:40:30 3: CUL_HM set RT_EG_Buero_Clima tempListSat prep 24:00 18.0
2020.11.15 11:40:30 3: CUL_HM set RT_EG_Buero_Clima tempListSun exec 24:00 18.0


und der Temperaturplan wird übertragen. Es kann auch an Abhängigkeiten liegen, das kann ich nicht beurteilen.

Gruß Thomas




Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 15 November 2020, 14:32:06
Hallo Thomas,

danke für den Hinweis! Ich hab da einen Fehler beim Paramterparsing für set gemacht.

Die zip oben ist aktualisiert.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: surfi am 15 November 2020, 16:38:37
Hallo Ansgar,

kurze Rückmeldung. Dateien ausgetauscht, Fhem neu gestartet und nu scheint es zu funktionieren. Danke schön.

Gruß Thomas
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: chRydis am 15 November 2020, 20:19:00
Hallo,
ich habe 2 alte Temperatur/Feuchte-Sensoren des Typs ASH 2000 (Transmitter HFS 300) von ELV im Betrieb. Diese senden Daten an einen nanoCUL USB. Mit einer CUL-Version <0.36 (weiß nicht mehr genau mit welcher)  haben sie einwandfrei funktioniert (in fhem als TSCUL_WS). Nach dem Update auf 0.36 hat fhem keine Daten von den beiden Sensoren mehr empfangen. Jetzt nach dem Update auf 0.37 auch nicht. Alle anderen Geräte (FS20 und TSCUL_TX) funktionieren mit dem nanoCUL weiterhin ohne Probleme.
Hat jemand eine Idee?

Grüße
Chris
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 15 November 2020, 21:33:05
Hallo Chris,

hast Du auch ein list vom CUL (mit frischem ccconf) und ASH 2000 für die Glaskugel?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: chRydis am 15 November 2020, 22:46:10
Hallo Ansgar,
die lists sind im Anhang
Grüße
Chris
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 15 November 2020, 23:11:49
Hallo Chris,

setz mal sens auf 8 oder 12 als ersten Step.
agcWait 16 als zweiten Step.
Datenrate 2.461 als dritten step.

Ist es ein 433er nano oder ein 868er, den Du auf 433 betreibst?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: chRydis am 15 November 2020, 23:33:35
Hallo Ansgar,

ich habe beide Module im Einsatz - 433er und 868er - für beide habe ich entsprechende Funkmodule gekauft.
Die Parameter habe ich geändert, bisher kein Empfang.

Grüße
Chris
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 16 November 2020, 07:19:32
Hallo Chris,

ZitatCUL-Version <0.36 (weiß nicht mehr genau mit welcher)
Kannst Du das mal versuchen zu präzisieren? Hast Du den Download noch?

Weißt Du, ob die Sensoren das 1.1 oder 1.2 Funkprotokoll fahren.

1.1 ist in die Firmware VTS0.36 und VTS0.37 nicht reinkompiliert. Das wäre eine Möglichkeit.

Die Basics hast Du natürlich schon gecheckt, sprich Batterien ok?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: chRydis am 16 November 2020, 10:06:55
Hallo Ansgar,

welchen Download meinst Du?
Welches Protokoll die Sensoren fahren weiß ich leider nicht, wie könnte ich es rauskriegen? Dass es an der Version 1.1 liegt, ist eine plausible Erklärung.
Die Batterien sind OK - ich habe auch noch die alte Anzeigeeinheit (Wetterstation) zu den Sensoren und sie zeigt die aktuellen Daten an. Und sie steht ca 60cm von dem CUL entfernt, so sollte es auch kein Reichweitenproblem sein.
Und da die alte Wetterstation noch gut funktioniert habe ich die Sensoren ins fhem angebunden. Sollen sie nicht mehr mit fhem funktionieren, werde ich halt andere Außensensoren installieren müssen.

Grüße
Chris
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: chRydis am 16 November 2020, 14:13:52
Hallo Ansgar,

ich habe in den Abgründen meines PCs nachgeschaut und den alten Download noch gefunden. Es war die Version 0.30

Wäre es viel Aufwand eine 0.37-Testversion mit einkompiliertem Funkprotokoll 1.1 zu bekommen?

Grüße
Chris
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 16 November 2020, 20:19:53
Hallo Chris,

ZitatEs war die Version 0.30
Das ist ein Hoffnungsschimmer, denn da war der Protokoll 1.1 Support noch reincompiliert.
Ich habe es nur rausgenommen, weil die Checksummenprüfung auch für das 1.2 Protokoll damit schlechter wird -> etwas mehr falsch empfangene 1.2 Datenpakete kommen durch.

Im Anhang mal VTS 0.37 hex Files für die 3 Varianten mit WS Protokoll 1.1 Support.

Gruß, Ansgar.

PS: Wenn Du den Prozessor Port C Bit 0 Anschluss des nanoCUL fest nach GND verbindest, markierst Du den nano als 433er nano und bekommst eine entsprechend andere Versionskennung und die Firmwaredefaults werden auf 433.92MHz umgestellt. Siehe auch board.h.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: chRydis am 16 November 2020, 23:46:37
Danke Ansgar,

ich werde es in den nächsten Tagen ausprobieren.

Grüße
Chris
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: chRydis am 18 November 2020, 09:49:00
Hallo Ansgar,

es funktioniert. Super vielen Dank!
Hast Du vor die Unterstützung für das Protokoll 1.1 in der nächsten Version drin zu lassen, oder doch zu entfernen?
Je nach dem muss ich entscheiden ob ich auf das nächste Update verzichte, oder ggf. andere Sensoren installiere.

Grüße
Chris
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 18 November 2020, 18:09:57
Hallo Chris,

ZitatHast Du vor die Unterstützung für das Protokoll 1.1 in der nächsten Version drin zu lassen, oder doch zu entfernen?
da ich selber keine Sensoren mit 1.1 Protokoll habe, sondern nur mit 1.2 Protokoll und lieber weniger fehlerhaft empfangene Daten habe, werde ich es weiterhin nicht rein kompilieren. Der Code bleibt aber im Sourcecode drin.

ZitatJe nach dem muss ich entscheiden ob ich auf das nächste Update verzichte
Du hast schon einige Versionen übersprungen.  ;)
Bei konkretem Interesse an jeweils einer neueren Version, kann ich eine Variante mit 1.1 Support kompilieren.

Für's selber Kompilieren, HAS_NO_WS2000_V1_1_SUPPORT darf nicht definiert sein, damit es rein kompiliert wird.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: chRydis am 18 November 2020, 20:08:04
Hallo Ansgar,

vielen Dank für die Info und nochmal für Deine schnelle Hilfe.

Grüße
Chris
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: presskopf am 08 Dezember 2020, 12:18:25
Das ist jetzt kein Problem oder Fehler der TS-Firmware, dennoch frage ich mal hier. Ich hoffe, das ist okay.

Ich habe mehrere CUL am laufen, die an mehreren Raspberry per ser2net mit dem fhem-Server kommunizieren.
Wenn ich nun einen z.B. von CUL_3 in CUL_Dach umbenennen möchte, kann man das einfachst mit rename umsetzen - aber:

Alle Geräte, die händisch CUL_3 zugewiesen bekamen (attr IODev CUL_3), müsste ich dann händisch entsprechend umkonfigurieren.
Gibt es einen eleganteren Weg?

Ansonsten fiele mir nur die Hardcore-Methode ein: fhem stoppen und in der fhem.cfg per Suchen-Ersetzen zuschlagen.

Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: rudolfkoenig am 08 Dezember 2020, 12:34:49
attr IODev=CUL_3 IODev CUL_Dach
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: presskopf am 08 Dezember 2020, 12:46:21
Gleich mal getestet: Das funktioniert für die Device-Internals.
Aber wie macht man es gesammelt für die ganzen Attributes von allen Devices? Dort bleibt der alte Wert stehen.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 08 Dezember 2020, 20:38:16
Hallo Matthias,

ich bin auch schon drüber gestolpert, als ich mir das rename mal angeschaut habe. Das betrifft nicht nur CUL.

Es gibt leider auch mehr als nur IODev. Für HM z.B. IOgrp und IOlist. Verwendung in notifies etc. ...
Es ist leider nicht trivial umzusetzen, ohne die möglichen Verwendungen und möglichen Trennzeichen auch noch alle zu berücksichtigen. Ein einfacher Ersetzungsmatch über alles kann zu unerwünschten Effekten führen, wenn der Name z.B. Teil eines anderen Namens ist. Und ganz grausig ist eine Teilverwendung in einem Match irgendwo im System, z.B. CUL.* ... .
Aus Nutzersicht praktisch wäre es natürlich, wenn das beim Umbennen eines devices alles automatisch passieren würde.

Es jagt auch ein RENAME notify durchs System, das jedes Modul für ein automatisches Umbennen nutzen könnte. In sofern müsstest Du wohl die Entwicklergemeinde dazu bewegen, das in ihren Modulen umzusetzen.
Für gelegentliches Umbenennen ist das allerdings ein gehöriger Entwicklungsaufwand und dauerhaft fehleranfällig, da erst Funktionen ergänzt oder verbessert werden und dann vielleicht noch eine notwendige Ergänzung der Rename Funktionalität bedacht wird (, wenn die ersten User sich Ihre config über rename zerschossen haben...).

Da ich null Berührungsängste mit der fhem.cfg kenne, sehe ich die Suchen und einzeln(!) Ersetzen Methode als die derzeit effektivste an. Aber auch die ist nicht absolut sicher, siehe oben.

Also am besten: Beim Anlegen bzw. vor weiterer Verwendung schon einen sinnvollen Namen ausdenken.  ;)

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: presskopf am 09 Dezember 2020, 00:42:21
Danke Ansgar.
Ich glaube, ich werde vorerst mal mit meinen begangenen Taten weiterleben.  ;D
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 20 Dezember 2020, 20:09:03
Hallo Zsammen,

ich habe hier https://forum.fhem.de/index.php/topic,24436.msg1098370.html#msg1098370 (https://forum.fhem.de/index.php/topic,24436.msg1098370.html#msg1098370) die FHEM Module aktualisiert. Insbesondere wegen eines Bugs das Peering betreffend, der hier https://forum.fhem.de/index.php/topic,116838.0.html (https://forum.fhem.de/index.php/topic,116838.0.html) aufgefallen ist.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 24 Dezember 2020, 16:16:50
Hallo,

ich habe Verbindungsprobleme mit HM-CC-VD. Zwar kann ich die beiden Ventile koppeln, aber irgendwie funktioniert ein GetConfig (was ja zum peering mit dem virtuellen HM-CC-TC notwendig ist) nicht. Das bleibt als command pending.
Wenn ich den Antrieb in den Anlernmodus versetzte scheint was anzukommen, aber wird irgendwie nicht prozessiert (zumindest erscheint folgende Nachricht im logfile wenn ich nach der 6-stelligen hexadezimalen HM_XXXXXX ID greppe, die auch für den FHEM Device Namen verwendet wird).

2020.12.24 15:59:36 3: CUL_HM set HM_1123B8 getConfig noArg
2020.12.24 16:01:24 4: TSCUL_Parse: CUL_TS  316492 A F501 00689860 00 1A 30 8400 1123B8 000000 14003A4645513030343839383758010100 -42dB
2020.12.24 16:01:24 4: TSCUL_Write: CUL_TS sending As1058A0014444441123B800040000000000
2020.12.24 16:01:24 4: TSCUL_send:  CUL_TS  316615                 As 10 58 A001 444444 1123B8 00040000000000
2020.12.24 16:01:24 4: TSCUL_XmitDlyHM:  CUL_TS  id:1123B8 rtoms:2347
2020.12.24 16:01:24 4: TSCUL_Parse: CUL_TS  316700 A F503 00690012 01 10 58 A001 444444 1123B8 00040000000000 _CCAdly:4 _dhmSt:152
2020.12.24 16:01:25 4: TSCUL_Parse: CUL_TS  316937 A F503 00690288 01 10 58 A001 444444 1123B8 00040000000000 _CCAdly:4 _dhmSt:428
2020.12.24 16:01:25 4: TSCUL_Parse: CUL_TS  317208 A F503 00690560 01 10 58 A001 444444 1123B8 00040000000000 _CCAdly:4 _dhmSt:700
2020.12.24 16:01:25 3: LogHist CUL_TS:  316492 A F501 00689860 00 1A 30 8400 1123B8 000000 14003A4645513030343839383758010100 -42dB
2020.12.24 16:01:25 3: LogHist CUL_TS:  316615                 As 10 58 A001 444444 1123B8 00040000000000
2020.12.24 16:01:25 3: LogHist CUL_TS:  316700 A F503 00690012 01 10 58 A001 444444 1123B8 00040000000000 _CCAdly:4 _dhmSt:152
2020.12.24 16:01:25 3: LogHist CUL_TS:  316937 A F503 00690288 01 10 58 A001 444444 1123B8 00040000000000 _CCAdly:4 _dhmSt:428
2020.12.24 16:01:25 3: LogHist CUL_TS:  317208 A F503 00690560 01 10 58 A001 444444 1123B8 00040000000000 _CCAdly:4 _dhmSt:700
2020.12.24 16:01:25 3: TSCUL_ParseTsHM: CUL_TS HM repeat failed to 1123B8/HM_1123B8:  317446 A F509 00690828 00 10 58 A001 444444 1123B8 00040000000000 _sfail _noAnsw
2020.12.24 16:01:27 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1123B8
2020.12.24 16:01:29 4: TSCUL_Parse: CUL_TS AI1123B8000000
2020.12.24 16:01:29 4: TSCUL_Parse: CUL_TS AI1123B8000000


Ich muss hier mit "grep" arbeiten, das ich <50 HM Devices habe (die über eine andere Zentrale laufen) und das logfile standig messages irgendwelcher devices anzeigt.
Kann jemand was mit den lowlevel Daten anfangen?

P.S. grundsätzlich scheint meine CUL mit HM zu funktionieren. Ich habe testweise noch einen Rollo Antrieb eingebunden und der scheint sauber zu kommunizieren. Für meinen Anwendungsfall brauche ich aber die VDs (da ich direkt Ventilpositionen ansteuern will, was mit der normalen CCU so meines Wissens nicht geht).

PPS: Sehe ich das richtig, dass die LED (an D9) nur irgendwelche fancy Blinkcodes kann? Wäre es nicht schöner damit Aktivität anzuzeigen (z.B. TX/RX Aktionen)?

Danke & Frohe Weihnachten,
Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 24 Dezember 2020, 18:32:06
Hallo Jörg,

Dein HM_1123B8 antwortet nicht auf Deine Kommandos mit Deiner HMid 444444.

Hast Du den HM_1123B8 überhaupt schon mit fhem gepaired? Also erst hmPairForSec <n-sekunden-die-dir-reichen-das-pairing-am-device-mit-knöpfchen-anzustoßen>, sinnvollerweise an der VCCU, dann Pairing am VD auslösen.
Oder ist er vielleicht noch mit einer anderen Zentrale gepaired und fühlt sich nicht angesprochen?

List vom HM_1123B8 bitte...

ZitatWäre es nicht schöner damit Aktivität anzuzeigen (z.B. TX/RX Aktionen)?
Kann man reincompilieren und dann mit den obersten beiden Bits des ledmodes aktivieren.
Siehe auch die verschiedenen HAS_LED_ACTION_ in der board.h. Ist zum Speicher sparen nicht rein compiliert.
Bringt Dir aber auch keine neue Info, denn empfangen und gesendet wird laut Log (ob aus der Antenne was raus kommt, ist damit so oder so nicht ermittelbar).

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 24 Dezember 2020, 23:42:24
Danke. Eigentlich waren die neu gepaired, ich hab das aber jetzt noch mal neu gemacht und auch auf die neueste Version der Module upgegraded.

Jetzt klappt das pairen und peeren eigentlich schon mal grundsätzlich. ValvePos Kommandos die ich vom virtuellen HM-CC-TC absetze funktionieren aber gar nicht. Direkte an die VDs manchmal (zumindest wenn man die Taste drückt). Nach einer Weile fahren aber beide Antriebe (einer ist FW 1.4 und einer FW 2.0) auf die Fehlerposition und das Antennensymbol blinkt).
Nur fährt von den zwei Antrieben nicht unbedingt immer der den ich erwarten würde auf eine Position. Totales Mysterium. HmInfo sagt alles ist gut.
Habe ich da irgendwas grundsätzlich falsch verstanden und falsch konfiguiert. Ich hänge jetzt mal ein "list" von allen beteiligten Devices an. Sorry für den Spam, aber ich hänge das jetzt schon Tage dran. Hab auch schon mit den hmFreqOffset Werten gespielt aber das hat auch zu keinen Verbesserungen geführt (so um die +20 bis +30 scheint ganz gut zu gehen).

Struktur:
CUL_TS -> VCCU
HM_TC_14 -> HMTC14_c1 -> HM_VD_14 (das ist der mit FW 1.4)
HM_TC_20 -> HMTC20_c1 -> HM_VD_20 (und das der mit FW 2.0)

Gruß,
Jörg


Internals:
   CMDS       ABCFGJKRUVWXYeiltx
   CUL_TS_MSGCNT 2097
   CUL_TS_TIME 2020-12-24 23:29:58
   Clients    STACKABLETS:STACKABLE:CUL_HM:CUL_IR:TSHMS
   DEF        /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@38400 4444
   DeviceName /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@38400
   FD         12
   FHTID      4444
   FUUID      5fe33406-f33f-0931-7bb3-07c32a04237b2b17
   NAME       CUL_TS
   NR         67
   PARTIAL   
   RAWMSG     A0F42943F59978800000002022777D2E5::-99.5:CUL_TS:
   RSSI       -99.5
   STATE      Initialized
   TYPE       TSCUL
   VERSION    VTS 0.37 CSM868
   VERSION_HW nanoCUL_V1.x_0014
   VERSION_TS yes AES ChTblSize:210
   XmitOpen   1
   assignUpdCntI 94
   assignUpdCntX 2
   assignedIDsCnt 4
   initString XP0C
X21
Ar
AM5
AH444444
   msgLoadCurrent 0
   owner_CCU  VCCU
   MatchList:
     A:CUL_HM   ^A....................
     B:CUL_IR   ^I............
     C:TSHMS    ^810e04......a001
     Y:STACKABLETS ^\*
     Z:STACKABLE ^\*
   READINGS:
     2020-12-23 14:44:29   FreqOffsEst     +1.587kHz
     2020-12-24 14:56:30   SlowRfconf      freq:868.300MHz freqOffs:50.781kHz bWidth:325kHz freqIF:330.08kHz rAmpl:42dB sens:12dB dRate:2.461kBit/s
agcPrio:0 agcWait:16 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:0 AGC_FREEZE:0
CCAmode:1 csRelThr:10dB csAbsThr:7dB  peakfilter:88
     2020-12-24 21:25:29   Xmit-Events     disconnected:1 ok:1 init:1 non-HM:1
     2020-12-24 22:54:05   ccconf          freq:868.300MHz freqOffs:30.151kHz bWidth:101kHz freqIF:152.34kHz rAmpl:33dB sens:8dB dRate:9.993kBit/s
agcPrio:1 agcWait:16 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:1 AGC_FREEZE:0
CCAmode:3 csRelThr:10dB csAbsThr:7dB
     2020-12-24 21:25:24   cmds             A B C F G J K R U V W X Y e i l t x
     2020-12-24 21:25:29   cond            ok
     2020-12-24 14:56:30   fRfconf         freq:868.300MHz freqOffs:0.000kHz bWidth:541kHz freqIF:304.69kHz rAmpl:42dB sens:4dB dRate:249.939kBit/s
agcPrio:0 agcWait:32 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:3 AGC_FREEZE:0
CCAmode:3 csRelThr:dis csAbsThr:0dB  peakfilter:88
     2020-12-24 14:56:30   peakfilter      88 µs
     2020-12-24 21:25:19   prot_disconnected last
     2020-12-24 21:25:26   prot_init       last
     2020-12-24 21:25:25   prot_non-HM     last
     2020-12-24 21:25:29   prot_ok         last
     2020-12-24 23:24:59   scF             1.000023942999
     2020-12-24 21:25:25   state           Initialized
   helper:
     CUrun      1
     ChkPart    0
     RA_Timeout 0
     SVTS       1
     VTS        1
     VTS_ACK    1
     VTS_AES    1
     assIdCnt   4
     assIdRep   4
     nRec       0
     recd       1
     DEVIOTS:
       RXfailTO   
     HM:
       ChTblSize  210
       FUP        0
       HMactive   1
       hmCrdts    0
       hmSbusy    0
       ChTbl:
         1123B800   00
         1A758E00   00
         55112200   00
         62A6FE00   00
       msgCNT:
         0x01       2097
         0x02       132
         0x03       122
         0x09       12
       unknwn:
         161554:
           lstRecType 02
           nextSend   1608848997.55944
           nxtSndMcnt 81
           tgtDly     88
           lRcTm:
             CUL_TS     7476216
             tnms       383745122
         16A0AB:
           lstRecType 58
           nextSend   1608848882.88434
           nxtSndMcnt 34
           tgtDly     88
           lRcTm:
             CUL_TS     7361544
             tnms       383630453
         16A241:
           lstRecType 58
           nextSend   1608848997.43081
           nxtSndMcnt 81
           tgtDly     88
           lRcTm:
             CUL_TS     7476088
             tnms       383744994
         18DD8E:
           lstRecType 70
           nextSend   1608848940.28044
           nxtSndMcnt 0A
           tgtDly     88
           lRcTm:
             CUL_TS     7418940
             tnms       383687842
         19CA72:
           lstRecType 58
           nextSend   1608848925.4885
           nxtSndMcnt 26
           tgtDly     88
           lRcTm:
             CUL_TS     7404148
             tnms       383673052
         1A7D5E:
           lstRecType 70
           nextSend   1608848939.72833
           nxtSndMcnt 60
           tgtDly     44.5
           lRcTm:
             CUL_TS     7418432
             tnms       383687335
         1A881A:
           lstRecType 02
           nextSend   1608848883.0159
           nxtSndMcnt 34
           tgtDly     88
           lRcTm:
             CUL_TS     7361676
             tnms       383630579
         1CE0A8:
           lstRecType 70
           nextSend   1608848905.42894
           nxtSndMcnt 94
           tgtDly     44.5
           lRcTm:
             CUL_TS     7384132
             tnms       383653061
         1D8CAF:
           lstRecType 70
           nextSend   1608848913.71244
           nxtSndMcnt B6
           tgtDly     88
           lRcTm:
             CUL_TS     7392416
             tnms       383661281
         1DA4C5:
           lstRecType 02
           nextSend   1608848925.6202
           nxtSndMcnt 26
           tgtDly     88
           lRcTm:
             CUL_TS     7404280
             tnms       383673180
         25FFA7:
           lstRecType 83
           nextSend   1608848266.39746
           nxtSndMcnt 12
           tgtDly     88
           lRcTm:
             CUL_TS     6745076
             tnms       383013957
         2D4F8E:
           lstRecType 8E
           nextSend   1608848013.13865
           nxtSndMcnt 10
           tgtDly     88
           lRcTm:
             CUL_TS     6491824
             tnms       382760702
         2E7962:
           lstRecType 10
           nextSend   1608848856.92655
           nxtSndMcnt D9
           tgtDly     88
           lRcTm:
             CUL_TS     7335632
             tnms       383604487
         2E7AE4:
           lstRecType 10
           nextSend   1608848978.6553
           nxtSndMcnt 24
           tgtDly     88
           lRcTm:
             CUL_TS     7457312
             tnms       383726217
         2E89EE:
           lstRecType 10
           nextSend   1608848976.91339
           nxtSndMcnt 26
           tgtDly     88
           lRcTm:
             CUL_TS     7455572
             tnms       383724475
         31068C:
           lstRecType 10
           nextSend   1608848865.82739
           nxtSndMcnt 34
           tgtDly     88
           lRcTm:
             CUL_TS     7344532
             tnms       383613390
         32C710:
           lstRecType 83
           nextSend   1608848853.93473
           nxtSndMcnt 12
           tgtDly     88
           lRcTm:
             CUL_TS     7332596
             tnms       383601509
         332334:
           lstRecType 83
           nextSend   1608848252.22649
           nxtSndMcnt 12
           tgtDly     88
           lRcTm:
             CUL_TS     6730904
             tnms       382999797
         3360EA:
           lstRecType 8E
           nextSend   1608848925.95209
           nxtSndMcnt 10
           tgtDly     88
           lRcTm:
             CUL_TS     7404612
             tnms       383673514
         42586A:
           lstRecType 83
           nextSend   1608847357.12541
           nxtSndMcnt 12
           tgtDly     88
           lRcTm:
             CUL_TS     5835828
             tnms       382104688
         48DC17:
           lstRecType 10
           nextSend   1608848866.56708
           nxtSndMcnt 5A
           tgtDly     88
           lRcTm:
             CUL_TS     7345228
             tnms       383614130
         4EFE5E:
           lstRecType 03
           nextSend   1608848417.70553
           nxtSndMcnt E5
           tgtDly     88
           lRcTm:
             CUL_TS     6896380
             tnms       383165269
         56E3F7:
           lstRecType 83
           nextSend   1608848895.22781
           nxtSndMcnt 12
           tgtDly     88
           lRcTm:
             CUL_TS     7373888
             tnms       383642790
         599788:
           lstRecType 3F
           nextSend   1608848998.51157
           nxtSndMcnt 42
           tgtDly     88
           lRcTm:
             CUL_TS     7477168
             tnms       383746075
         5C6E15:
           lstRecType 83
           nextSend   1608847256.08568
           nxtSndMcnt 12
           tgtDly     88
           lRcTm:
             CUL_TS     5734792
             tnms       382003649
         5CD958:
           lstRecType 5E
           nextSend   1608848994.90691
           nxtSndMcnt 42
           tgtDly     44.5
           lRcTm:
             CUL_TS     7473496
             tnms       383742555
         5F321C:
           lstRecType 8E
           nextSend   1608848361.47618
           nxtSndMcnt 10
           tgtDly     88
           lRcTm:
             CUL_TS     6840152
             tnms       383109050
         6032C1:
           lstRecType 02
           nextSend   1608847260.28102
           nxtSndMcnt 40
           tgtDly     88
           lRcTm:
             CUL_TS     5738984
             tnms       382007842
         6629F7:
           lstRecType 03
           nextSend   1608848701.73053
           nxtSndMcnt FA
           tgtDly     88
           lRcTm:
             CUL_TS     7180396
             tnms       383449292
         682EB1:
           lstRecType 8E
           nextSend   1608848128.99034
           nxtSndMcnt 10
           tgtDly     88
           lRcTm:
             CUL_TS     6607672
             tnms       382876561
         6890D0:
           lstRecType 03
           nextSend   1608847305.67197
           nxtSndMcnt 48
           tgtDly     88
           lRcTm:
             CUL_TS     5784376
             tnms       382053234
         689108:
           lstRecType 03
           nextSend   1608846511.59785
           nxtSndMcnt 06
           tgtDly     88
           lRcTm:
             CUL_TS     4990324
             tnms       381259160
         68CE6F:
           lstRecType 03
           nextSend   1608846548.12685
           nxtSndMcnt BB
           tgtDly     88
           lRcTm:
             CUL_TS     5026852
             tnms       381295705
         68D0AB:
           lstRecType 03
           nextSend   1608848305.09356
           nxtSndMcnt 7F
           tgtDly     88
           lRcTm:
             CUL_TS     6783768
             tnms       383052654
         68D4CC:
           lstRecType 03
           nextSend   1608848789.07335
           nxtSndMcnt 55
           tgtDly     44.5
           lRcTm:
             CUL_TS     7267780
             tnms       383536679
         69486B:
           lstRecType 10
           nextSend   1608848896.12041
           nxtSndMcnt 38
           tgtDly     88
           lRcTm:
             CUL_TS     7374824
             tnms       383643680
         698041:
           lstRecType 5E
           nextSend   1608848961.45661
           nxtSndMcnt 70
           tgtDly     88
           lRcTm:
             CUL_TS     7440160
             tnms       383709019
         6A60E8:
           lstRecType 02
           nextSend   1608848987.79572
           nxtSndMcnt 45
           tgtDly     44.5
           lRcTm:
             CUL_TS     7466496
             tnms       383735408
         6ACE73:
           lstRecType 10
           nextSend   1608848988.06651
           nxtSndMcnt 02
           tgtDly     88
           lRcTm:
             CUL_TS     7466768
             tnms       383735629
         6B4EAE:
           lstRecType 10
           nextSend   1608848987.67137
           nxtSndMcnt 45
           tgtDly     44.5
           lRcTm:
             CUL_TS     7466372
             tnms       383735299
         6EDCFA:
           lstRecType 83
           nextSend   1608848887.14013
           nxtSndMcnt 12
           tgtDly     88
           lRcTm:
             CUL_TS     7365800
             tnms       383634726
         74A42E:
           lstRecType 8E
           nextSend   1608848394.69091
           nxtSndMcnt 10
           tgtDly     88
           lRcTm:
             CUL_TS     6873364
             tnms       383142255
         B3D798:
           lstRecType 8E
           nextSend   1608848925.90002
           nxtSndMcnt 10
           tgtDly     88
           lRcTm:
             CUL_TS     7404560
             tnms       383673465
     cnd:
       0          1
       250        1
       253        1
       255        1
     hmLogHist:
        454491 A F001 07440116 00 0F 70 865E 698041 000000 7DB9110011F8 -82dB
        454534 A F001 07440160 00 0F 70 C65E 698041 000000 7DB9110011F8 _rep -73.5dB
        469947 A F001 07455572 00 0F 26 8610 2E89EE 000000 0A80D2080000 -67.5dB
        470464 A F001 07456088 00 0C 81 8670 16A241 000000 00C13B -44.5dB
        471689 A F001 07457312 00 0F 24 8610 2E7AE4 000000 0A50ED0E0000 -72dB
        480771 A F001 07466372 00 0D 45 E610 6B4EAE 6A60E8 0601BD80 _rep -72.5dB
        480880 A F001 07466496 00 0A 45 C002 6A60E8 6B4EAE 00 _rep -72.5dB
        481101 A F001 07466724 00 0F 02 8610 6ACE73 000000 0AF4C6140040 -95dB
        481146 A F001 07466768 00 0F 02 C610 6ACE73 000000 0AF4C6140040 _rep -74dB
        487840 A F001 07473452 00 14 42 845E 5CD958 000000 852B35000374003408E001 -98.5dB
        488027 A F001 07473496 00 14 42 C45E 5CD958 000000 852B35000374003408E001 _rep -71.5dB
        490466 A F001 07476088 00 0B 81 A258 16A241 161554 0054 -44dB
        490594 A F001 07476216 00 0E 81 8202 161554 16A241 0101420032 -48dB
        491547 A F001 07477168 00 0F 42 943F 599788 000000 02022777D2E5 _bst -99.5dB
     hmQ:
       000000:
       1123B8:
       1A758E:
       62A6FE:
     ids:
       1123B8:
         cfg        +1123B8,00,00,00
         name       HM_VD_14
       1A758E:
         cfg        +1A758E,02,00,00
         name       HM_VD_20
       551122:
         cfg        +551122,00,00,00
         name       551122
       62A6FE:
         cfg        +62A6FE,00,00,00
         name       HM_62A6FE
     loadLvl:
       bl         40
     q:
       ATrNo      0
       HMcndN     0
       InQueues   0
       RQLSt      0
       RQLt       0
       XRpCnt     0
       XRpTm      1608847859.26176
       answerPend 0
       hmLanQlen  1
       apIDs:
         1123B8     0
         1A758E     0
         62A6FE     0
     ref:
       Sdly       3
       TmBmCnt    1
       ioBR       3840
       ioBRMax    3623.06259238436
       ioBRMean   3278.87907510998
       lHMt       7455572
       lSys       383724475
       pTTu       1024
       pndAs      0
       pndCUAp    0
       pndTuP     1
       pngLm      18
       pngRef     6
       scErr      4.482369020232
       scF        1.000023942999
       scFN       6
       scHT       7178224
       scST       383447120
       scpTm      1608848699.46585
Attributes:
   hmId       444444
   rfmode     HomeMatic
   room       CUL_HM
   verbose    4



Internals:
   CUL_TS_MSGCNT 1974
   CUL_TS_RAWMSG A0C35867016A0AB00000000D23A::-80:CUL_TS:
   CUL_TS_RSSI -80
   CUL_TS_TIME 2020-12-24 23:30:33
   DEF        444444
   FUUID      5fe26cf1-f33f-0931-4222-3248890e21d37e16
   IODev      CUL_TS
   LASTInputDev CUL_TS
   MSGCNT     1974
   NAME       VCCU
   NOTIFYDEV  global
   NR         66
   NTFY_ORDER 50-VCCU
   STATE      CUL_TS:ok
   TYPE       CUL_HM
   assignedIOs CUL_TS
   READINGS:
     2020-12-24 21:41:24   IOopen          1
     2020-12-24 22:51:42   cfgState        ok
     2020-12-23 14:32:37   commState       CMDs_done
     2020-12-22 23:25:05   press_broadcast short cnt: 1
     2020-12-24 21:41:24   state           CUL_TS:ok
     2020-12-24 21:38:04   unknown_1123B8  received
     2020-12-24 23:29:57   unknown_161554  received
     2020-12-24 23:30:33   unknown_16A0AB  received
     2020-12-24 23:29:57   unknown_16A241  received
     2020-12-24 23:29:00   unknown_18DD8E  received
     2020-12-24 23:28:45   unknown_19CA72  received
     2020-12-24 23:28:59   unknown_1A7D5E  received
     2020-12-24 23:28:02   unknown_1A881A  received
     2020-12-24 23:28:25   unknown_1CE0A8  received
     2020-12-23 14:41:53   unknown_1CEF5C  received
     2020-12-24 23:28:33   unknown_1D8CAF  received
     2020-12-24 23:28:45   unknown_1DA4C5  received
     2020-12-24 23:17:46   unknown_25FFA7  received
     2020-12-24 15:37:09   unknown_26A653  received
     2020-12-24 23:13:33   unknown_2D4F8E  received
     2020-12-24 23:30:17   unknown_2E7962  received
     2020-12-24 23:29:38   unknown_2E7AE4  received
     2020-12-24 23:29:36   unknown_2E89EE  received
     2020-12-24 23:30:32   unknown_31068C  received
     2020-12-24 14:21:06   unknown_314411  received
     2020-12-24 23:27:33   unknown_32C710  received
     2020-12-24 23:17:32   unknown_332334  received
     2020-12-24 23:28:45   unknown_3360EA  received
     2020-12-24 23:02:37   unknown_42586A  received
     2020-12-24 23:30:14   unknown_48DC17  received
     2020-12-24 23:20:17   unknown_4EFE5E  received
     2020-12-24 23:30:24   unknown_56E3F7  received
     2020-12-24 23:29:58   unknown_599788  received
     2020-12-24 23:00:56   unknown_5C6E15  received
     2020-12-24 23:29:54   unknown_5CD958  received
     2020-12-24 23:19:21   unknown_5F321C  received
     2020-12-24 23:01:00   unknown_6032C1  received
     2020-12-24 15:29:36   unknown_619CAC  received
     2020-12-23 14:21:01   unknown_62A6FE  received
     2020-12-24 23:25:01   unknown_6629F7  received
     2020-12-24 15:37:01   unknown_67276B  received
     2020-12-24 15:37:07   unknown_672796  received
     2020-12-24 15:37:13   unknown_68066D  received
     2020-12-24 23:15:28   unknown_682EB1  received
     2020-12-24 23:01:45   unknown_6890D0  received
     2020-12-24 22:48:31   unknown_689108  received
     2020-12-24 22:49:08   unknown_68CE6F  received
     2020-12-24 23:18:25   unknown_68D0AB  received
     2020-12-24 23:26:29   unknown_68D4CC  received
     2020-12-24 23:28:16   unknown_69486B  received
     2020-12-24 23:29:21   unknown_698041  received
     2020-12-24 23:29:47   unknown_6A60E8  received
     2020-12-24 23:29:48   unknown_6ACE73  received
     2020-12-24 23:29:47   unknown_6B4EAE  received
     2020-12-24 15:35:54   unknown_6B73DE  received
     2020-12-24 23:28:07   unknown_6EDCFA  received
     2020-12-24 23:19:54   unknown_74A42E  received
     2020-12-24 23:28:45   unknown_B3D798  received
   helper:
     HM_CMDNR   132
     mId        FFF0
     peerFriend peerSens,peerAct
     peerOpt    -:virtual
     regLst     
     rxType     1
     ack:
     cmds:
       TmplKey    :no:1608846212.10481
       TmplTs     1608846212.10481
       cmdKey     1:1:1::VCCU:FFF0:01:
       cmdLst:
         assignIO   -IO- [({set}|unset)]
         clear      [(readings|rssi|msgErrors|{msgErrors}|unknownDev)]
         defIgnUnknown noArg
         hmPairForSec [-sec-]
         hmPairSerial -serial-
         peerChan   -btnNumber- -actChn- [({single}|dual|reverse)] [({set}|unset)] [(actor|remote|{both})]
         postEvent  -condition-
         press      [(long|{short})] [(-peer-|{all})] [(noBurst|{Burst})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
         pressL     [(-peer-|{all})]
         pressS     [(-peer-|{all})]
         tplSet_0   -tplChan-
         update     noArg
         virtual    [(1..50;1|{1})]
       lst:
         condition  0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,160,161,162,163,164,165,166,167,168,169,170,171,172,173,174,175,176,177,178,179,180,181,182,183,184,185,186,187,188,189,190,191,192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,208,209,210,211,212,213,214,215,216,217,218,219,220,221,222,223,224,225,226,227,228,229,230,231,232,233,234,235,236,237,238,239,240,241,242,243,244,245,246,247,248,249,250,251,252,253,254,255
         peer       
         peerOpt   
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         listDevice noArg
         param      -param-
     expert:
       def        0
       det        0
       raw        1
       tpl        0
     io:
       prefIO     
       vccu       VCCU
       ioList:
         CUL_TS
     mRssi:
       mNo       
       io:
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       vrt        1
     tmpl:
Attributes:
   IODev      CUL_TS
   IOList     CUL_TS
   IOgrp      VCCU
   expert     rawReg
   model      CCU-FHEM
   msgRepeat  0
   room       CUL_HM
   subType    virtual
   webCmd     virtual:update



Internals:
   CFGFN     
   DEF        112214
   FUUID      5fe50770-f33f-0931-b8c4-6ef33069e0a8fd3e
   IODev      CUL_TS
   NAME       HMTC14
   NOTIFYDEV  global
   NR         2768
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 HMTC14_c1
   protSnd    4 last_at:2020-12-24 22:52:08
   protState  CMDs_done
   READINGS:
     2020-12-24 22:51:42   cfgState        ok
     2020-12-24 22:52:08   commState       CMDs_done
     2020-12-24 22:52:08   state           CMDs_done
   helper:
     HM_CMDNR   233
     mId        FFF1
     peerFriend peerSens,peerAct
     peerOpt    -:virtual
     regLst     
     rxType     1
     cmds:
       TmplKey    :no:1608846220.28988
       TmplTs     1608846220.28988
       cmdKey     0:1:1::HMTC14:FFF1:00:
       cmdLst:
         clear      [(readings|rssi|msgErrors|{msgErrors}|unknownDev)]
         tplSet_0   -tplChan-
         virtual    [(1..50;1|{1})]
       lst:
         condition  0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,160,161,162,163,164,165,166,167,168,169,170,171,172,173,174,175,176,177,178,179,180,181,182,183,184,185,186,187,188,189,190,191,192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,208,209,210,211,212,213,214,215,216,217,218,219,220,221,222,223,224,225,226,227,228,229,230,231,232,233,234,235,236,237,238,239,240,241,242,243,244,245,246,247,248,249,250,251,252,253,254,255
         peer       
         peerOpt   
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         param      -param-
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     
       prefIO     
       rxt        0
       vccu       
       p:
     mRssi:
       mNo       
       io:
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       vrt        1
     tmpl:
Attributes:
   IODev      CUL_TS
   expert     defReg,rawReg
   model      virtual_1
   msgRepeat  0
   room       CUL_HM
   subType    virtual
   webCmd     virtual



Internals:
   CFGFN     
   DEF        112220
   FUUID      5fe508cd-f33f-0931-180f-5cc06e4f99d001d2
   IODev      CUL_TS
   NAME       HMTC20
   NOTIFYDEV  global
   NR         3035
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 HMTC20_c1
   protSnd    4 last_at:2020-12-24 23:19:51
   protState  CMDs_done
   READINGS:
     2020-12-24 22:51:42   cfgState        ok
     2020-12-24 23:19:51   commState       CMDs_done
     2020-12-24 23:19:51   state           CMDs_done
   helper:
     HM_CMDNR   239
     mId        FFF1
     peerFriend peerSens,peerAct
     peerOpt    -:virtual
     regLst     
     rxType     1
     cmds:
       TmplKey    :no:1608845569.86406
       TmplTs     1608845569.86406
       cmdKey     0:1:1::HMTC20:FFF1:01:
       cmdLst:
         clear      [(readings|rssi|msgErrors|{msgErrors}|unknownDev)]
         tplSet_0   -tplChan-
         virtual    [(1..50;1|{1})]
       lst:
         condition  0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,160,161,162,163,164,165,166,167,168,169,170,171,172,173,174,175,176,177,178,179,180,181,182,183,184,185,186,187,188,189,190,191,192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,208,209,210,211,212,213,214,215,216,217,218,219,220,221,222,223,224,225,226,227,228,229,230,231,232,233,234,235,236,237,238,239,240,241,242,243,244,245,246,247,248,249,250,251,252,253,254,255
         peer       
         peerOpt   
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         param      -param-
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     
       prefIO     
       rxt        0
       vccu       
       p:
     mRssi:
       mNo       
       io:
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       vrt        1
     tmpl:
Attributes:
   IODev      CUL_TS
   expert     defReg,rawReg
   model      virtual_1
   msgRepeat  0
   room       CUL_HM
   subType    virtual
   webCmd     virtual



Internals:
   CFGFN     
   DEF        11222001
   FUUID      5fe508fc-f33f-0931-6fe8-5b37d0a5b5ffb1b0
   NAME       HMTC20_c1
   NOTIFYDEV  global
   NR         3071
   STATE      ValveAdjust:52.3 %
   TYPE       CUL_HM
   chanNo     01
   device     HMTC20
   peerList   HM_VD_20,
   READINGS:
     2020-12-24 22:51:42   cfgState        ok
     2020-12-24 22:33:36   peerList        HM_VD_20,
     2020-12-24 22:56:29   state           ValveAdjust:52.3 %
     2020-12-24 22:56:29   valvePosTC      52.3 %
   helper:
     fkt        vdCtrl
     peerFriend peerSD,peerSens,peerAct
     peerOpt    -:virtual
     regLst     
     virtTC     03
     cmds:
       TmplKey    HM_VD_20,:no:1608845569.93125
       TmplTs     1608845569.93125
       cmdKey     1:0:1:vdCtrl:HMTC20:FFF1:01:HM_VD_20,
       cmdLst:
         peerChan   -btnNumber- -actChn- [({single}|dual|reverse)] [({set}|unset)] [(actor|remote|{both})]
         peerSmart  -peerOpt-
         postEvent  -condition-
         press      [(long|{short})] [(-peer-|{all})] [(noBurst|{Burst})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
         pressL     [(-peer-|{all})]
         pressS     [(-peer-|{all})]
         tplSet_0   -tplChan-
         tplSet_HM_VD_20 -tplPeer-
         valvePos   (off|0.0..99.0;0.1)
       lst:
         condition  0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,160,161,162,163,164,165,166,167,168,169,170,171,172,173,174,175,176,177,178,179,180,181,182,183,184,185,186,187,188,189,190,191,192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,208,209,210,211,212,213,214,215,216,217,218,219,220,221,222,223,224,225,226,227,228,229,230,231,232,233,234,235,236,237,238,239,240,241,242,243,244,245,246,247,248,249,250,251,252,253,254,255
         peer       HM_VD_20
         peerOpt    remove_HM_VD_20,HMTC14_c1,HMTC20_Btn1
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         param      -param-
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     role:
       chn        1
       vrt        1
     tmpl:
     vd:
       cmd        A2581122201A758E
       id         1A758E
       idh        682618
       idl        8192
       msgCnt     0
       nDev       HM_VD_20
       next       1608845790.16291
       typ        1
       val        85
       vin        52.3
Attributes:
   model      virtual_1
   peerIDs    1A758E01,
   room       CUL_HM
   webCmd     press short:press long



Internals:
   CFGFN     
   DEF        11221401
   FUUID      5fe507b6-f33f-0931-d02a-ebec2950e2953c29
   NAME       HMTC14_c1
   NOTIFYDEV  global
   NR         2821
   STATE      ValveAdjust:47.0 %
   TYPE       CUL_HM
   chanNo     01
   device     HMTC14
   peerList   HM_VD_14,
   READINGS:
     2020-12-24 22:51:42   cfgState        ok
     2020-12-24 22:39:22   peerList        HM_VD_14,
     2020-12-24 22:55:34   state           ValveAdjust:47.0 %
     2020-12-24 22:55:33   valvePosTC      47.0 %
   helper:
     fkt        vdCtrl
     peerFriend peerSD,peerSens,peerAct
     peerOpt    -:virtual
     regLst     
     virtTC     03
     cmds:
       TmplKey    HM_VD_14,:no:1608845244.09383
       TmplTs     1608845244.09383
       cmdKey     1:0:1:vdCtrl:HMTC14:FFF1:01:HM_VD_14,
       cmdLst:
         peerChan   -btnNumber- -actChn- [({single}|dual|reverse)] [({set}|unset)] [(actor|remote|{both})]
         peerSmart  -peerOpt-
         postEvent  -condition-
         press      [(long|{short})] [(-peer-|{all})] [(noBurst|{Burst})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
         pressL     [(-peer-|{all})]
         pressS     [(-peer-|{all})]
         tplSet_0   -tplChan-
         tplSet_HM_VD_14 -tplPeer-
         valvePos   (off|0.0..99.0;0.1)
       lst:
         condition  0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,160,161,162,163,164,165,166,167,168,169,170,171,172,173,174,175,176,177,178,179,180,181,182,183,184,185,186,187,188,189,190,191,192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,208,209,210,211,212,213,214,215,216,217,218,219,220,221,222,223,224,225,226,227,228,229,230,231,232,233,234,235,236,237,238,239,240,241,242,243,244,245,246,247,248,249,250,251,252,253,254,255
         peer       HM_VD_14
         peerOpt    remove_HM_VD_14,HMTC14_Btn1
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         param      -param-
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     role:
       chn        1
       vrt        1
     tmpl:
     vd:
       cmd        A2581122141123B8
       id         1123B8
       idh        682618
       idl        5120
       msgCnt     0
       nDev       HM_VD_14
       next       1608845492.47505
       typ        1
       val        78
       vin        47.0
Attributes:
   model      virtual_1
   peerIDs    1123B801,
   room       CUL_HM
   webCmd     press short:press long


[code]
Internals:
   CFGFN     
   CUL_TS_MSGCNT 59
   CUL_TS_RAWMSG A0A6180021123B844444400::-59:CUL_TS:
   CUL_TS_RSSI -59
   CUL_TS_TIME 2020-12-24 23:25:57
   DEF        1123B8
   FUUID      5fe4fcc4-f33f-0931-a708-ee901c0f2f597841
   IODev      CUL_TS
   LASTInputDev CUL_TS
   MSGCNT     59
   NAME       HM_VD_14
   NOTIFYDEV  global
   NR         743
   STATE      68
   TYPE       CUL_HM
   chanNo     01
   lastMsg    No:61 - t:02 s:1123B8 d:444444 00
   peerList   HMTC14_c1,
   protCmdDel 21
   protLastRcv 2020-12-24 23:25:57
   protNack   3 last_at:2020-12-24 22:38:10
   protRcv    49 last_at:2020-12-24 23:25:57
   protSnd    27 last_at:2020-12-24 23:25:56
   protState  CMDs_done
   rssi_at_CUL_TS cnt:49 min:-63 max:-44.5 avg:-51.61 lst:-59
   rssi_from_CUL_TS cnt:6 min:-50 max:-43 avg:-47.83 lst:-49
   READINGS:
     2020-12-24 23:25:57   CommandAccepted yes
     2020-12-24 23:25:56   D-firmware      1.4
     2020-12-24 23:25:56   D-serialNr      FEQ0048987
     2020-12-24 22:53:01   PairedTo        0x444444
     2020-12-24 22:53:01   RegL_00.         00:00 02:01 0A:44 0B:44 0C:44
     2020-12-24 22:53:01   RegL_05.         00:00 09:00 0A:0F
     2020-12-24 22:55:33   ValveDesired    47.0 %
     2020-12-24 23:25:56   ValvePosition   68
     2020-12-24 23:25:56   battery         ok
     2020-12-24 22:53:01   cfgState        ok
     2020-12-24 23:25:57   commState       CMDs_done
     2020-12-24 23:25:56   motor           stop
     2020-12-24 23:25:56   motorErr        ok
     2020-12-24 23:25:56   operState       changed
     2020-12-24 23:26:01   peerList        HMTC14_c1,
     2020-12-24 23:25:56   recentStateType ack
     2020-12-24 23:25:56   state           68
   helper:
     HM_CMDNR   97
     PONtest    1
     cSnd       014444441123B80103,014444441123B801040000000005
     mId        003A
     oldDes     0
     peerFriend
     peerIDsRaw ,11221401,00000000,8C
     peerOpt    p:thermostat
     regLst     0,5
     rxType     12
     supp_Pair_Rep 0
     cmds:
       TmplKey    HMTC14_c1,:no:1608848761.58765
       TmplTs     1608848761.58765
       cmdKey     1:1:0::HM_VD_
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 25 Dezember 2020, 00:59:26
Hallo Jörg,

ZitatSorry für den Spam
Spam ist gut, wenn sie auch vollständig wäre.  ;)
Du hast die maximale Nachrichtenlänge wohl überschritten.

Zitatund auch auf die neueste Version der Module upgegraded
Was verstehst Du genau unter neueste Version? Woher und wie gemacht?
Mich wundert, dass model noch virtual_1 statt VIRTUAL ist. Das ist nicht neuer Stand.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 25 Dezember 2020, 09:45:18
Anscheinend. Schaut wirklich abgeschnitten aus. Dann anbei nochmal die beiden VDs.
Mit neuste meine ich neuste CUL FW und FHEM Module aus diesem thread (TSCUL_fwcode_00_37a_FHEM_Modules_00_59.zip).
Der virtual_1 kommt daher, dass ich das nach dieser Anleitung gemacht habe: https://wiki.fhem.de/wiki/HM-CC-VD_Funk-Stellantrieb
Ist das falsch?

Jörg


Internals:
   CFGFN     
   CUL_TS_MSGCNT 59
   CUL_TS_RAWMSG A0A6180021123B844444400::-59:CUL_TS:
   CUL_TS_RSSI -59
   CUL_TS_TIME 2020-12-24 23:25:57
   DEF        1123B8
   FUUID      5fe4fcc4-f33f-0931-a708-ee901c0f2f597841
   IODev      CUL_TS
   LASTInputDev CUL_TS
   MSGCNT     59
   NAME       HM_VD_14
   NOTIFYDEV  global
   NR         743
   STATE      68
   TYPE       CUL_HM
   chanNo     01
   lastMsg    No:61 - t:02 s:1123B8 d:444444 00
   peerList   HMTC14_c1,
   protCmdDel 21
   protLastRcv 2020-12-24 23:25:57
   protNack   3 last_at:2020-12-24 22:38:10
   protRcv    49 last_at:2020-12-24 23:25:57
   protSnd    27 last_at:2020-12-24 23:25:56
   protState  CMDs_done
   rssi_at_CUL_TS cnt:49 min:-63 max:-44.5 avg:-51.61 lst:-59
   rssi_from_CUL_TS cnt:6 min:-50 max:-43 avg:-47.83 lst:-49
   READINGS:
     2020-12-24 23:25:57   CommandAccepted yes
     2020-12-24 23:25:56   D-firmware      1.4
     2020-12-24 23:25:56   D-serialNr      FEQ0048987
     2020-12-24 22:53:01   PairedTo        0x444444
     2020-12-24 22:53:01   RegL_00.         00:00 02:01 0A:44 0B:44 0C:44
     2020-12-24 22:53:01   RegL_05.         00:00 09:00 0A:0F
     2020-12-24 22:55:33   ValveDesired    47.0 %
     2020-12-24 23:25:56   ValvePosition   68
     2020-12-24 23:25:56   battery         ok
     2020-12-24 22:53:01   cfgState        ok
     2020-12-24 23:25:57   commState       CMDs_done
     2020-12-24 23:25:56   motor           stop
     2020-12-24 23:25:56   motorErr        ok
     2020-12-24 23:25:56   operState       changed
     2020-12-24 23:26:01   peerList        HMTC14_c1,
     2020-12-24 23:25:56   recentStateType ack
     2020-12-24 23:25:56   state           68
   helper:
     HM_CMDNR   97
     PONtest    1
     cSnd       014444441123B80103,014444441123B801040000000005
     mId        003A
     oldDes     0
     peerFriend
     peerIDsRaw ,11221401,00000000,8C
     peerOpt    p:thermostat
     regLst     0,5
     rxType     12
     supp_Pair_Rep 0
     cmds:
       TmplKey    HMTC14_c1,:no:1608848761.58765
       TmplTs     1608848761.58765
       cmdKey     1:1:0::HM_VD_14:003A:01:HMTC14_c1,
       cmdLst:
         assignHmKey noArg
         clear      [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
         deviceRename -newName-
         fwUpdate   -filename- [-bootTime-]
         getConfig  noArg
         getDevInfo noArg
         getRegRaw  (List0|List1|List2|List3|List4|List5|List6) [-peerChn-]
         peerBulk   -peer1,peer2,...- [({set}|unset)]
         raw        -data- [...]
         regBulk    -list-.-peerChn- -addr1:data1- -addr2:data2-...
         regSet     [(prep|{exec})] -regName- -value- [-peerChn-]
         reset      noArg
         tplDel     -tplDel-
         tplSet_0   -tplChan-
         tplSet_HMTC14_c1 -tplPeer-
         unpair     noArg
         valvePos   [({off}|0.0..99.0;0.5)]
       lst:
         condition  0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,160,161,162,163,164,165,166,167,168,169,170,171,172,173,174,175,176,177,178,179,180,181,182,183,184,185,186,187,188,189,190,191,192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,208,209,210,211,212,213,214,215,216,217,218,219,220,221,222,223,224,225,226,227,228,229,230,231,232,233,234,235,236,237,238,239,240,241,242,243,244,245,246,247,248,249,250,251,252,253,254,255
         peer       HMTC14_c1
         peerOpt   
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         param      -param-
         reg        -addr- -list- [-peerChn-]
         regList    noArg
         regTable   noArg
         regVal     -addr- -list- [-peerChn-]
         saveConfig [-filename-]
         tplInfo    noArg
     expert:
       def        0
       det        0
       raw        1
       tpl        0
     io:
       lstRecType 02
       newChn     +1123B8,00,00,00
       nextSend   1608848757.32817
       nxtSndMcnt 61
       prefIO     
       rxt        2
       tgtDly     88
       vccu       
       lRcTm:
         CUL_TS     7235992
         tnms       383504890
       p:
         1123B8
         00
         00
         00
     mRssi:
       mNo        61
       io:
         CUL_TS:
           -49
           -49
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     regCollect:
     role:
       chn        1
       dev        1
     rssi:
       at_CUL_TS:
         avg        -51.6122448979592
         cnt        49
         lst        -59
         max        -44.5
         min        -63
       from_CUL_TS:
         avg        -47.8333333333333
         cnt        6
         lst        -49
         max        -43
         min        -50
     shadowReg:
     tmpl:
Attributes:
   IODev      CUL_TS
   IOgrp      VCCU
   autoReadReg 4_reqStatus
   expert     rawReg
   firmware   1.4
   model      HM-CC-VD
   msgRepeat  0
   peerIDs    00000000,11221401,
   room       CUL_HM
   serialNr   FEQ0048987
   subType    thermostat
   webCmd     getConfig:clear msgEvents



Internals:
   CFGFN     
   CUL_TS_MSGCNT 47
   CUL_TS_RAWMSG A0A6D80021A758E44444400::-41:CUL_TS:
   CUL_TS_RSSI -41
   CUL_TS_TIME 2020-12-25 07:37:04
   DEF        1A758E
   FUUID      5fe502e2-f33f-0931-c04a-23459628cbb01919
   IODev      CUL_TS
   LASTInputDev CUL_TS
   MSGCNT     47
   NAME       HM_VD_20
   NOTIFYDEV  global
   NR         1893
   STATE      15
   TYPE       CUL_HM
   chanNo     01
   lastMsg    No:6D - t:02 s:1A758E d:444444 00
   peerList   HMTC20_c1,
   protCmdDel 4
   protLastRcv 2020-12-25 07:37:04
   protNack   1 last_at:2020-12-24 22:13:32
   protRcv    48 last_at:2020-12-25 07:37:04
   protSnd    22 last_at:2020-12-25 07:37:04
   protState  CMDs_done
   rssi_at_CUL_TS cnt:48 min:-49 max:-40.5 avg:-44.91 lst:-41
   rssi_from_CUL_TS cnt:5 min:-48 max:-40 avg:-44.8 lst:-40
   READINGS:
     2020-12-25 07:37:04   CommandAccepted yes
     2020-12-25 07:37:04   D-firmware      2.0
     2020-12-25 07:37:04   D-serialNr      JEQ0222578
     2020-12-24 22:53:12   PairedTo        0x444444
     2020-12-24 22:53:12   RegL_00.         00:00 02:01 0A:44 0B:44 0C:44
     2020-12-24 23:19:51   RegL_05.         00:00 09:00 0A:0F
     2020-12-24 22:56:29   ValveDesired    52.3 %
     2020-12-25 07:37:04   ValvePosition   15
     2020-12-25 07:37:04   battery         ok
     2020-12-24 23:19:51   cfgState        ok
     2020-12-25 07:37:04   commState       CMDs_done
     2020-12-25 07:37:04   motor           stop
     2020-12-25 07:37:04   motorErr        ok
     2020-12-25 07:37:04   operState       changed
     2020-12-25 07:37:09   peerList        HMTC20_c1,
     2020-12-25 07:37:04   recentStateType ack
     2020-12-25 07:37:04   state           15
   helper:
     HM_CMDNR   109
     cSnd       014444441A758E0103,014444441A758E01040000000005
     cfgChkResult No regs found for:-ret--ret-HM_VD_20 type:thermostat - -ret-list:peer register         :value-ret-   0:      pairCentral      :0x444444-ret-   5:      valveErrorPos    :15 %-ret-   5:      valveOffset      :0 %-ret-                       -ret-                       -ret-
     mId        003A
     oldDes     0
     peerFriend
     peerIDsRaw ,11222001,00000000,A0
     peerOpt    p:thermostat
     regLst     0,5
     rxType     12
     supp_Pair_Rep 0
     cmds:
       TmplKey    HMTC20_c1,:no:1608878229.10771
       TmplTs     1608878229.10771
       cmdKey     1:1:0::HM_VD_20:003A:01:HMTC20_c1,
       cmdLst:
         assignHmKey noArg
         clear      [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
         deviceRename -newName-
         fwUpdate   -filename- [-bootTime-]
         getConfig  noArg
         getDevInfo noArg
         getRegRaw  (List0|List1|List2|List3|List4|List5|List6) [-peerChn-]
         peerBulk   -peer1,peer2,...- [({set}|unset)]
         raw        -data- [...]
         regBulk    -list-.-peerChn- -addr1:data1- -addr2:data2-...
         regSet     [(prep|{exec})] -regName- -value- [-peerChn-]
         reset      noArg
         tplDel     -tplDel-
         tplSet_0   -tplChan-
         tplSet_HMTC20_c1 -tplPeer-
         unpair     noArg
         valvePos   [({off}|0.0..99.0;0.5)]
       lst:
         condition  0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,160,161,162,163,164,165,166,167,168,169,170,171,172,173,174,175,176,177,178,179,180,181,182,183,184,185,186,187,188,189,190,191,192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,208,209,210,211,212,213,214,215,216,217,218,219,220,221,222,223,224,225,226,227,228,229,230,231,232,233,234,235,236,237,238,239,240,241,242,243,244,245,246,247,248,249,250,251,252,253,254,255
         peer       HMTC20_c1
         peerOpt   
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         param      -param-
         reg        -addr- -list- [-peerChn-]
         regList    noArg
         regTable   noArg
         regVal     -addr- -list- [-peerChn-]
         saveConfig [-filename-]
         tplInfo    noArg
     expert:
       def        0
       det        0
       raw        1
       tpl        0
     io:
       lstRecType 02
       newChn     +1A758E,00,00,00
       nextSend   1608878224.77691
       nxtSndMcnt 6D
       prefIO     
       rxt        2
       tgtDly     88
       vccu       
       lRcTm:
         CUL_TS     36702808
         tnms       412972354
       p:
         1A758E
         00
         00
         00
     mRssi:
       mNo        6D
       io:
         CUL_TS:
           -31
           -31
     prt:
       bErr       0
       sProc      0
       try        1
     q:
       qReqConf   
       qReqStat   
     regCollect:
     role:
       chn        1
       dev        1
     rssi:
       at_CUL_TS:
         avg        -44.9166666666667
         cnt        48
         lst        -41
         max        -40.5
         min        -49
       from_CUL_TS:
         avg        -44.8
         cnt        5
         lst        -40
         max        -40
         min        -48
     shadowReg:
     tmpl:
   nb:
     cnt        2
Attributes:
   IODev      CUL_TS
   IOgrp      VCCU:CUL_TS
   autoReadReg 4_reqStatus
   expert     rawReg
   firmware   2.0
   model      HM-CC-VD
   msgRepeat  0
   peerIDs    00000000,11222001,
   room       CUL_HM
   serialNr   JEQ0222578
   subType    thermostat
   webCmd     getConfig:clear msgEvents
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 25 Dezember 2020, 10:14:25
Hallo Jörg,

ZitatDer virtual_1 kommt daher
Zumindest nach einem Neustart von FHEM hätte aus dem virtual_1 ein VIRTUAL werden müssen.

Versuch mal die 10_CUL_HM aus dem Anhang (nach entpacken natürlich).
Neustart nicht vergessen.
Mir ist aufgefallen, dass die Initialisierung nicht durchgelaufen ist und denke, das nun korrigiert zu haben. Ich habe keine VDs zum testen (in sofern kann ich zur Qualität der Anleitung auch nichts sagen).
Und Feedback brauche ich natürlich bitte.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: frank am 25 Dezember 2020, 10:56:22
in den hauptdevices der virt tc fehlt jeweils attr IOgrp.
hat hminfo configCheck keine probleme gemeldet?
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 25 Dezember 2020, 12:17:18
Hallo Frank,

ja IOgrp fehlt und muss für virtuelle devices sinnvoll mit passendem prefered IO gesetzt werden.
Und nein, dafür gibt es keine Prüfung in HMInfo configCheck, so weit ich das sehe.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 25 Dezember 2020, 13:17:48
Hi Ansgar,

Erster Erfolg. Nach dem restart sind beide VDs sofort auf die Position gefahren, die in den jeweiligen TC Channels eingestellt war.
Habe dann eine andere Position hinterlegt und sicher 10 Minuten gewartet - keine Reaktion, aber immerhin: Keiner der Antriebe ist mehr auf Störungsposition gefahren.
Nach einem neuerlichen Neustart ist es jetzt besser. Der FW1.4 Antrieb reagiert eigentlich meistens. Der FW2.0 Antrieb gelegentlich. Da gibt es immer wieder Timeouts (siehe Log unten) und dann geht er auf MISSING_ACK.
Was aber richtig seltsam ist: Ich hatte beim testen mehrfach (aber nicht deterministisch) folgenden Effekt:
VD_20 auf neue Position, "Anlernen" auf VD_20 ausführen -> VD_14 fährt auf die Position die ich für VD_20 eingestellt habe. So als würde da irgendwas zwischen den Antrieben über Kreuz laufen - die Config schaut aber eigentlich gut aus. Sämtliche PeerIDs etc. sind richtig verknüpft. Bringt das der (nachträgliche) Anlernmodus irgendwas durcheinander?

Soweit ich weiss, ist ja das Timing bei diesen VDs nicht ganz einfach - und das scheint bei der FW2.0 schwieriger zu sein. Gibt es da irgendwelche Parameter mit denen man spielen könnte?

Gruß,
Jörg

020.12.25 13:06:23 4: TSCUL_Write: CUL_TS sending As0B10A2581122201A758E002E
2020.12.25 13:06:23 4: TSCUL_send:  CUL_TS  193513                 As 0B 10 A258 112220 1A758E 002E
2020.12.25 13:06:23 4: TSCUL_XmitDlyHM:  CUL_TS  id:1A758E rtoms:2342
AF303000453E0010B10A2581122201A758E002E80
2020.12.25 13:06:23 4: TSCUL_Parse: CUL_TS  193709 A F303 01134464 01 0B 10 A258 112220 1A758E 002E _CCAdly:4
2020.12.25 13:06:23 5: TSCUL_Read CUL_TS: /AF30300045424010B10A2581122201A758E002E80
2020.12.25 13:06:23 4: TSCUL_Parse: CUL_TS  193865 A F303 01134736 01 0B 10 A258 112220 1A758E 002E _CCAdly:4
2020.12.25 13:06:24 4: TSCUL_Parse: CUL_TS  194099 A F403 01135004 01 0B 10 A258 112220 1A758E 002E _CCAdly:4
2020.12.25 13:06:24 3: LogHist CUL_TS:  193513                 As 0B 10 A258 112220 1A758E 002E
2020.12.25 13:06:24 3: LogHist CUL_TS:  193709 A F303 01134464 01 0B 10 A258 112220 1A758E 002E _CCAdly:4
2020.12.25 13:06:24 3: LogHist CUL_TS:  193865 A F303 01134736 01 0B 10 A258 112220 1A758E 002E _CCAdly:4
2020.12.25 13:06:24 3: LogHist CUL_TS:  194099 A F403 01135004 01 0B 10 A258 112220 1A758E 002E _CCAdly:4
2020.12.25 13:06:24 3: TSCUL_ParseTsHM: CUL_TS HM repeat failed to 1A758E/HM_VD_20:  194331 A F409 01135268 00 0B 10 A258 112220 1A758E 002E _sfail _noAnsw
2020.12.25 13:06:25 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1A758E
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 25 Dezember 2020, 14:07:33
Hallo Jörg,

zeig bitte nochmal ein list von den virtuellen TC (device und channel).

Ich habe in HMInfo auch mal einen zusätzlichen IOgrp Check eingebaut, siehe Anhang.

Gruß, Ansgar.

PS: Ich denke ich habe auch das Problem mit dem fehlenden Setzen der neuen Position gefunden. Neue 10_CUL_HM.pm auch im Anhang.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 25 Dezember 2020, 14:29:38
Hallo Jörg,

noch eine Ergänzung im vorherigen Beitrag...

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 25 Dezember 2020, 14:56:32
Hi Ansgar,

gerne. Es scheint jetzt soweit zu klappen - mit dem letzten Patch je zwei Änderungen ohne Timeout.
Dann kam aber im "Leerbetrieb" mehrfach ein Timeout beim 2.0 und bei der nächsten Ventiländerung einer beim 1.4 (nach weiteren 3 Minuten hat er die Änderung aber dann gemacht).
Der HMinfo meckert jetzt die IoGrp an - was würde denn da reingehören?
Was noch ein bisschen irritiert, ist dass die VD device als ValvePos erstmal noch die alte Position anzeigt und dann erst beim nächsten Update (nach 3 Minuten) umschwenkt. Das ist zwar einerseits richtig (der Antrieb hat ja noch nicht umgestellt) anderseits dauert es halt doch sehr lange bis es korrekt dasteht. Eventuell könnte man bei korrekt entgegengenommenen Befehl einfach davon ausgehen, das er das auch korrekt ausführt und schon die neue Position anzeigen. (falls es nicht klappt korrigiert sich das ja nach 3 Minuten)

Grundsätzlich schon mal herzlichen Dank. Es funktioniert eigentlich jetzt ausreichend gut. Alles andere ist Feinschliff - und liegt auch evtl. an der Hardware.

Gruß,
Jörg


Internals:
   DEF        112214
   FUUID      5fe50770-f33f-0931-b8c4-6ef33069e0a8fd3e
   IODev      CUL_TS
   NAME       HMTC14
   NOTIFYDEV  global
   NR         72
   NTFY_ORDER 50-HMTC14
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 HMTC14_c1
   READINGS:
     2020-12-25 14:34:51   cfgState        IOGrpVirt
     2020-12-24 22:52:08   commState       CMDs_done
     2020-12-24 22:52:08   state           CMDs_done
   helper:
     HM_CMDNR   145
     mId        FFF1
     peerFriend peerSens,peerAct
     peerOpt    -:virtual
     regLst     
     rxType     1
     ack:
     cfgChk:
       idPc05     fail
     cmds:
       TmplKey    :no:1608903215.80847
       TmplTs     1608903215.80847
       cmdKey     0:1:1::HMTC14:FFF1:01:
       cmdLst:
         clear      [(readings|rssi|msgErrors|{msgErrors}|unknownDev)]
         tplSet_0   -tplChan-
         virtual    [(1..50;1|{1})]
       lst:
         condition  0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,160,161,162,163,164,165,166,167,168,169,170,171,172,173,174,175,176,177,178,179,180,181,182,183,184,185,186,187,188,189,190,191,192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,208,209,210,211,212,213,214,215,216,217,218,219,220,221,222,223,224,225,226,227,228,229,230,231,232,233,234,235,236,237,238,239,240,241,242,243,244,245,246,247,248,249,250,251,252,253,254,255
         peer       
         peerOpt   
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         param      -param-
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       prefIO     
       vccu       
     mRssi:
       mNo       
       io:
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       vrt        1
     tmpl:
Attributes:
   IODev      CUL_TS
   expert     defReg,rawReg
   model      VIRTUAL
   msgRepeat  0
   room       CUL_HM
   subType    virtual
   webCmd     virtual



Internals:
   DEF        112220
   FUUID      5fe508cd-f33f-0931-180f-5cc06e4f99d001d2
   IODev      CUL_TS
   NAME       HMTC20
   NOTIFYDEV  global
   NR         74
   NTFY_ORDER 50-HMTC20
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 HMTC20_c1
   READINGS:
     2020-12-25 14:34:51   cfgState        IOGrpVirt
     2020-12-24 23:19:51   commState       CMDs_done
     2020-12-24 23:19:51   state           CMDs_done
   helper:
     HM_CMDNR   193
     mId        FFF1
     peerFriend peerSens,peerAct
     peerOpt    -:virtual
     regLst     
     rxType     1
     ack:
     cfgChk:
       idPc05     fail
     cmds:
       TmplKey    :no:1608903216.27814
       TmplTs     1608903216.27814
       cmdKey     0:1:1::HMTC20:FFF1:01:
       cmdLst:
         clear      [(readings|rssi|msgErrors|{msgErrors}|unknownDev)]
         tplSet_0   -tplChan-
         virtual    [(1..50;1|{1})]
       lst:
         condition  0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,160,161,162,163,164,165,166,167,168,169,170,171,172,173,174,175,176,177,178,179,180,181,182,183,184,185,186,187,188,189,190,191,192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,208,209,210,211,212,213,214,215,216,217,218,219,220,221,222,223,224,225,226,227,228,229,230,231,232,233,234,235,236,237,238,239,240,241,242,243,244,245,246,247,248,249,250,251,252,253,254,255
         peer       
         peerOpt   
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         param      -param-
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       prefIO     
       vccu       
     mRssi:
       mNo       
       io:
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
       vrt        1
     tmpl:
Attributes:
   IODev      CUL_TS
   expert     defReg,rawReg
   model      VIRTUAL
   msgRepeat  0
   room       CUL_HM
   subType    virtual
   webCmd     virtual



Internals:
   DEF        11221401
   FUUID      5fe507b6-f33f-0931-d02a-ebec2950e2953c29
   NAME       HMTC14_c1
   NOTIFYDEV  global
   NR         73
   NTFY_ORDER 50-HMTC14_c1
   STATE      ValveAdjust:24.0 %
   TYPE       CUL_HM
   chanNo     01
   device     HMTC14
   peerList   HM_VD_14
   READINGS:
     2020-12-25 14:34:51   cfgState        ok
     2020-12-25 14:33:35   peerList        HM_VD_14
     2020-12-25 14:34:11   state           ValveAdjust:24.0 %
     2020-12-25 14:37:35   valveCtrl       ok
     2020-12-25 14:34:11   valvePosTC      24.0 %
   helper:
     fkt        vdCtrl
     peerFriend peerSD,peerSens,peerAct
     peerOpt    -:virtual
     regLst     
     virtTC     00
     cmds:
       TmplKey    HM_VD_14:no:1608903216.26451
       TmplTs     1608903216.26451
       cmdKey     1:0:1:vdCtrl:HMTC14:FFF1:01:HM_VD_14
       cmdLst:
         peerChan   -btnNumber- -actChn- [({single}|dual|reverse)] [({set}|unset)] [(actor|remote|{both})]
         peerSmart  -peerOpt-
         postEvent  -condition-
         press      [(long|{short})] [(-peer-|{all})] [(noBurst|{Burst})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
         pressL     [(-peer-|{all})]
         pressS     [(-peer-|{all})]
         tplSet_0   -tplChan-
         tplSet_HM_VD_14 -tplPeer-
         valvePos   (off|0.0..99.0;0.1)
       lst:
         condition  0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,160,161,162,163,164,165,166,167,168,169,170,171,172,173,174,175,176,177,178,179,180,181,182,183,184,185,186,187,188,189,190,191,192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,208,209,210,211,212,213,214,215,216,217,218,219,220,221,222,223,224,225,226,227,228,229,230,231,232,233,234,235,236,237,238,239,240,241,242,243,244,245,246,247,248,249,250,251,252,253,254,255
         peer       HM_VD_14
         peerOpt    remove_HM_VD_14,HMTC20_c1,VCCU
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         param      -param-
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     role:
       chn        1
       vrt        1
     tmpl:
     vd:
       ackT       2020-12-25 14:40:22
       cmd        A2581122141123B8
       id         1123B8
       idh        682618
       idl        5120
       miss       0
       msgCnt     53
       msgRed     0
       msgSent    0
       nDev       HM_VD_14
       next       1608903784.33319
       nextM      1608903784.33319
       typ        1
       val        3D
       vin        24.0
       virtTC     00
Attributes:
   model      VIRTUAL
   peerIDs    1123B801
   room       CUL_HM
   webCmd     press short:press long



Internals:
   DEF        11222001
   FUUID      5fe508fc-f33f-0931-6fe8-5b37d0a5b5ffb1b0
   NAME       HMTC20_c1
   NOTIFYDEV  global
   NR         75
   NTFY_ORDER 50-HMTC20_c1
   STATE      ValveAdjust:6.1 %
   TYPE       CUL_HM
   chanNo     01
   device     HMTC20
   peerList   HM_VD_20
   READINGS:
     2020-12-25 14:34:51   cfgState        ok
     2020-12-25 14:33:36   peerList        HM_VD_20
     2020-12-25 14:34:25   state           ValveAdjust:6.1 %
     2020-12-25 14:38:08   valveCtrl       ok
     2020-12-25 14:34:24   valvePosTC      6.1 %
   helper:
     fkt        vdCtrl
     peerFriend peerSD,peerSens,peerAct
     peerOpt    -:virtual
     regLst     
     virtTC     00
     cmds:
       TmplKey    HM_VD_20:no:1608903216.68593
       TmplTs     1608903216.68593
       cmdKey     1:0:1:vdCtrl:HMTC20:FFF1:01:HM_VD_20
       cmdLst:
         peerChan   -btnNumber- -actChn- [({single}|dual|reverse)] [({set}|unset)] [(actor|remote|{both})]
         peerSmart  -peerOpt-
         postEvent  -condition-
         press      [(long|{short})] [(-peer-|{all})] [(noBurst|{Burst})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
         pressL     [(-peer-|{all})]
         pressS     [(-peer-|{all})]
         tplSet_0   -tplChan-
         tplSet_HM_VD_20 -tplPeer-
         valvePos   (off|0.0..99.0;0.1)
       lst:
         condition  0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,160,161,162,163,164,165,166,167,168,169,170,171,172,173,174,175,176,177,178,179,180,181,182,183,184,185,186,187,188,189,190,191,192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,208,209,210,211,212,213,214,215,216,217,218,219,220,221,222,223,224,225,226,227,228,229,230,231,232,233,234,235,236,237,238,239,240,241,242,243,244,245,246,247,248,249,250,251,252,253,254,255
         peer       HM_VD_20
         peerOpt    remove_HM_VD_20,HMTC14_c1,VCCU
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         param      -param-
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     role:
       chn        1
       vrt        1
     tmpl:
     vd:
       ackT       2020-12-25 14:40:34
       cmd        A2581122201A758E
       id         1A758E
       idh        682618
       idl        8192
       miss       0
       msgCnt     53
       msgRed     0
       msgSent    0
       nDev       HM_VD_20
       next       1608903776.11677
       nextM      1608903776.11677
       typ        1
       val        0F
       vin        6.1
       virtTC     00
Attributes:
   model      VIRTUAL
   peerIDs    1A758E01
   room       CUL_HM
   webCmd     press short:press long
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 25 Dezember 2020, 15:27:09
Hallo Jörg,

ZitatDer HMinfo meckert jetzt die IoGrp an - was würde denn da reingehören?
attr <Name_des_virtuellen_device> IOgrp <Name_deiner_VCCU>:<Name_des_IO_Dev_dass_gut_zum_VD_senden_kann>

Schön, dass es erst mal besser klappt. Ich bin aber noch nicht zufrieden, weil ich derzeit denke, dass ein neuer Wert nicht immer später noch gesetzt wird, wenn es nicht klappt.

ZitatDas ist zwar einerseits richtig (der Antrieb hat ja noch nicht umgestellt) anderseits dauert es halt doch sehr lange bis es korrekt dasteht.
Das "richtig" ist das Stichwort, denke ich. ;)
Wenn's gut läuft, wirst Du ohnehin nicht mehr drauf schauen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: kadettilac89 am 25 Dezember 2020, 16:02:35
Hi,

ich hatte ein Thermostat (hm-cc-rt-dn) zurückgesetzt weil ich nach dem Firmwareupdate auf 1.5 hohen Batterieverbrauch hatte.

Nach dem Zurücksetzen konnte ich das Thermostat nicht mehr ansprechen und auch nicht mehr pairen. Wollte ausschließen dass es das Thermostat ist, und hab ein weiteres zurückgesetzt. Auch das konnte ich nicht mehr pairen.

Als ich dann die Firmware 0.34 zurückging funktionierte das Pairen von beiden Thermostaten sofort.

Ist es möglich, dass es in Firmware 0.37 ein Bug ist, der beim Pairen Probleme verursacht? Vielleicht in Verbindung mit nanoCul oder mit den HM-Thermostaten?

Mein Setup

VCCU mit nanoCul. hex-File aus Zip, nicht selber compiliert

Fehlersituation mit VCCU
Vorhanden TSFW 0.37 funktioniert mit verbundenen Devices, jedoch kann ich keine Thermostate pairen (Firmware 0.37 download irgendwann Nov. + alle Fhem-Module aus selbem Zip)


Tests nur mit CUL, ohne VCCU
Test1 - völlig nacktes System, neu installiertes Fhem, aktuell, Fhem Module aus Zip
Flashen TSFW 0.34 funktioniert problemlos incl. pairen (Firmware 0.34 + alle Fhem-Module aus selbem Zip)

Test2 - völlig nacktes System, neu installiertes Fhem, aktuell, Fhem Module aus Zip
Flashen TSFW 0.37 funktioniert mit verbundenen Devices, jedoch kann ich auch jetzt wieder keine Thermostate pairen (Firmware 0.37 download 23.12.2020 + alle Fhem-Module aus selbem Zip)

Test3 - völlig nacktes System, neu installiertes Fhem, aktuell, Fhem Module aus Zip
Flashen TSFW 0.34 funktioniert problemlos incl. pairen (Firmware 0.34 + alle Fhem-Module aus selbem Zip)

Ich bleibe jetzt mal auf v 0.34 mit VCCU da alles funktioniert.  .... never run a touching system ... oder so.

Habe etliche, auch selbst gebaute, HM-Geräte. Will diese aber nicht unpairen da diese funktionieren.

Die ganzen "unknown" Messages sind von Nachbarn, mein Cul empfängt da so einiges.

VCCU

Internals:
   CUL868_MSGCNT 1819
   CUL868_RAWMSG A0FD48610638F340000000AA0DB0B0140::-99.5:CUL868:
   CUL868_RSSI -99.5
   CUL868_TIME 2020-12-25 15:26:36
   DEF        F11234
   FUUID      5cf965cb-f33f-ea65-b487-820aa9c46b39985b
   IODev      CUL866_2
   LASTInputDev CUL868
   MSGCNT     1819
   NAME       VCCU
   NOTIFYDEV  global
   NR         26
   NTFY_ORDER 50-VCCU
   STATE      CUL868:ok,CUL866_2:init
   TYPE       CUL_HM
   assignedIOs CUL866_2,CUL868
   chanNo     01
   READINGS:
     2020-11-13 18:21:07   CommandAccepted yes
     2020-12-23 20:42:59   IOopen          2
     2020-12-23 09:30:58   cfgState        ok
     2020-12-01 15:34:57   commState       CMDs_done
     2020-12-23 20:42:59   state           CUL868:ok,CUL866_2:init
     2020-12-23 08:51:50   unknown_28E421  received
     2020-12-25 10:29:55   unknown_441A57  received
     2020-12-25 14:23:18   unknown_5B1656  received
     2020-12-20 12:45:36   unknown_5B5D2D  received
     2020-12-25 15:25:25   unknown_5D11B3  received
     2020-12-25 07:36:34   unknown_600404  received
     2020-12-01 10:42:37   unknown_60045C  received
     2020-12-21 16:47:46   unknown_600CAE  received
     2020-12-22 17:41:38   unknown_60C807  received
     2020-12-25 10:31:51   unknown_60FB06  received
     2020-12-01 07:02:46   unknown_60FB2A  received
     2020-12-22 17:52:28   unknown_61EFEA  received
     2020-11-22 22:26:09   unknown_6307BC  received
     2020-12-25 15:26:36   unknown_638F34  received
   helper:
     HM_CMDNR   60
     mId        FFF0
     peerFriend peerSD,peerSens,peerAct
     peerOpt    -:virtual
     regLst     0
     rxType     1
     ack:
     expert:
       def        1
       det        0
       raw        0
       tpl        0
     io:
       prefIO     
       vccu       VCCU
       ioList:
         CUL868
         CUL866_2
     mRssi:
       mNo       
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       vrt        1
     tmpl:
Attributes:
   DbLogExclude .*
   IODev      CUL866_2
   IOList     CUL868,CUL866_2
   IOgrp      VCCU
   alias      VCCU
   group      Devices
   model      CCU-FHEM
   room       Server
   subType    virtual
   webCmd     virtual:update



Internals:
   CMDS       ABCFGJKRUVWXYZeilmtux
   CUL868_MSGCNT 4572
   CUL868_TIME 2020-12-25 15:29:46
   Clients    STACKABLETS:STACKABLE:CUL_HM:CUL_IR:HMS
   DEF        /dev/ttyUSB0@38400 2236
   DeviceName /dev/ttyUSB0@38400
   FD         13
   FHTID      2236
   FUUID      5e84d75e-f33f-eb0d-e977-993da3be813ddad8
   NAME       CUL868
   NR         586
   PARTIAL   
   RAWMSG     A0F2C86102B74830000000A90C10C0000::-57.5:CUL868:
   RSSI       -57.5
   STATE      Initialized
   TYPE       TSCUL
   VERSION    VTS 0.34 CSM868
   VERSION_HW nanoCUL_V1.x_0014
   VERSION_TS yes AES ChTblSize:208
   XmitOpen   1
   assignUpdCntI 30
   assignedIDsCnt 6
   initString XP0C
X21
Ar
AM5
AHF11234
   msgLoadCurrent 0
   owner_CCU  VCCU
   Helper:
     DBLOG:
       Xmit-Events:
         myDbLog:
           TIME       1608752579.58904
           VALUE      non-HM:1 init:1 disconnected:1 ok:1
         myDbLogRemote:
           TIME       1608752579.62316
           VALUE      non-HM:1 init:1 disconnected:1 ok:1
         myDbLogZero:
           TIME       1608752579.63792
           VALUE      non-HM:1 init:1 disconnected:1 ok:1
       cond:
         myDbLog:
           TIME       1608752579.58904
           VALUE      ok
         myDbLogRemote:
           TIME       1608752579.62316
           VALUE      ok
         myDbLogZero:
           TIME       1608752579.63792
           VALUE      ok
       prot_ok:
         myDbLog:
           TIME       1608752579.58904
           VALUE      last
         myDbLogRemote:
           TIME       1608752579.62316
           VALUE      last
         myDbLogZero:
           TIME       1608752579.63792
           VALUE      last
   MatchList:
     1:STACKABLETS ^\*
     2:STACKABLE ^\*
     A:CUL_HM   ^A....................
     B:CUL_IR   ^I............
     C:HMS      ^810e04......a001
   READINGS:
     2020-12-23 20:42:59   Xmit-Events     non-HM:1 init:1 disconnected:1 ok:1
     2020-12-23 20:42:51   cmds             A B C F G J K R U V W X Y Z e i l m t u x
     2020-12-23 20:42:59   cond            ok
     2020-12-23 20:42:46   prot_disconnected last
     2020-12-23 20:42:53   prot_init       last
     2020-12-23 20:42:53   prot_non-HM     last
     2020-12-23 20:42:59   prot_ok         last
     2020-12-25 15:20:26   scF             0.998964543480984
     2020-12-23 20:42:53   state           Initialized
   helper:
     CUrun      1
     ChkPart    0
     RA_Timeout 0
     SVTS       1
     VTS        1
     VTS_ACK    1
     VTS_AES    1
     assIdCnt   6
     assIdRep   6
     nRec       0
     recAlive   1
     recd       1
     DEVIOTS:
       RXfailTO   
     HM:
       ChTblSize  208
       FUP        0
       HMactive   1
       hmCrdts    0
       hmSbusy    0
       ChTbl:
         00280200   00
         00311100   00
         00311200   00
         28E42100   00
         2B748300   00
         6DF1D100   00
       msgCNT:
         0x01       4572
         0x02       1197
         0x03       144
         0x09       34
       unknwn:
         441A57:
           lstRecType 02
           nextSend   1608888595.63763
           nxtSndMcnt 76
           tgtDly     88
           lRcTm:
             CUL868     136168064
             tnms       423343198
         5B1656:
           lstRecType 02
           nextSend   1608902598.23374
           nxtSndMcnt 62
           tgtDly     88
           lRcTm:
             CUL868     150185224
             tnms       437345794
         5D11B3:
           lstRecType 10
           nextSend   1608906507.9221
           nxtSndMcnt 44
           tgtDly     88
           lRcTm:
             CUL868     154098972
             tnms       441255490
         600404:
           lstRecType 03
           nextSend   1608878195.04184
           nxtSndMcnt 5B
           tgtDly     88
           lRcTm:
             CUL868     125756668
             tnms       412942602
         60FB06:
           lstRecType 12
           nextSend   1608888711.91293
           nxtSndMcnt 04
           tgtDly     88
           lRcTm:
             CUL868     136284464
             tnms       423459480
         638F34:
           lstRecType 10
           nextSend   1608906519.05344
           nxtSndMcnt D5
           tgtDly     88
           lRcTm:
             CUL868     154110108
             tnms       441266613
     cnd:
       0          1
       250        1
       253        1
       255        1
     hmLogHist:
        061558 A F001 02836024 00 0F 1B 8610 28E421 000000 0A7094090000 -76.5dB
        081152 A F001 02855644 00 0F D3 8610 638F34 000000 0AA0DB0B0140 -98.5dB
        111677 A F001 02886192 00 0F 2A 8610 2B7483 000000 0A90C10C0000 -57.5dB
        147028 A F001 02921584 00 0F 43 8610 5D11B3 000000 0A90CB100040 -94dB
        173885 A F002 02948468 00 01 CC _ping
        181807 A F001 02956404 00 0F 1C 8610 28E421 000000 0A7094090000 -76.5dB
        203328 A F001 02977936 00 17 59 8470 003111 000000 00A200004600000000000F2C0000 -62dB
        217907 A F001 02992536 00 0F D4 8610 638F34 000000 0AA0DB0B0140 -99.5dB
        235168 A F001 03009824 00 0F 2B 8610 2B7483 000000 0A90C10C0000 -57.5dB
        274206 A F001 03048888 00 17 1C 8470 003112 000000 00BA00003900000002000EE90000 -69dB
        329282 A F001 03104028 00 0F 44 8610 5D11B3 000000 0A90CA100040 -94dB
        340405 A F001 03115164 00 0F D5 8610 638F34 000000 0AA0DB0B0140 -96.5dB
        351561 A F001 03126332 00 0F 1D 8610 28E421 000000 0A7094090000 -77dB
        408424 A F001 03183252 00 0F 2C 8610 2B7483 000000 0A90C10C0000 -57.5dB
     hmQ:
       000000:
       002802:
       003111:
       003112:
       28E421:
       2B7483:
       6DF1D1:
     ids:
       002802:
         cfg        +002802,00,00,00
         name       HMTempSensor2
       003111:
         cfg        +003111,00,00,00
         name       HMTempSensor3
       003112:
         cfg        +003112,00,00,00
         name       HMTempSensor4
       28E421:
         cfg        +28E421,00,00,00
         name       Heizung_Schlafzimmer
       2B7483:
         cfg        +2B7483,00,00,00
         name       Heizung_Wohnzimmer
       6DF1D1:
         cfg        +6DF1D1,00,00,00
         name       hm_door1
     loadLvl:
       bl         40
     q:
       ATrNo      0
       HMcndN     0
       InQueues   0
       RQLSt      0
       RQLt       0
       XRpCnt     0
       XRpTm      1608828986.42207
       answerPend 0
       hmLanQlen  1
       apIDs:
         002802     0
         003111     0
         003112     0
         28E421     0
         2B7483     0
         6DF1D1     0
     ref:
       Sdly       2
       TmBmCnt    2
       ioBR       3840
       ioBRMax    3787.50623934485
       ioBRMean   3333.65395821033
       lHMt       154178196
       lSys       441334632
       pTTu       1024
       pndAs      0
       pndCUAp    0
       pndTuP     1
       pngLm      14
       pngRef     8
       scErr      -3.68838270194829
       scF        0.998964543480984
       scFN       111
       scHT       153616716
       scST       440773731
       scpTm      1608906026.07541
Attributes:
   group      Devices
   hmId       F11234
   rfmode     HomeMatic
   room       Server


eines der Thermostate

Internals:
   CUL868_MSGCNT 1042
   CUL868_RAWMSG A0F1E861028E4210000000A7094090000::-76.5:CUL868:
   CUL868_RSSI -76.5
   CUL868_TIME 2020-12-25 15:31:25
   DEF        28E421
   FUUID      5fe38527-f33f-27e8-4a17-c8fe83063de76ca0
   IODev      CUL868
   LASTInputDev CUL868
   MSGCNT     1042
   NAME       Heizung_Schlafzimmer
   NOTIFYDEV  global
   NR         671
   NTFY_ORDER 50-Heizung_Schlafzimmer
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 Heizung_Schlafzimmer_Weather
   channel_02 Heizung_Schlafzimmer_Climate
   channel_03 Heizung_Schlafzimmer_WindowRec
   channel_04 Heizung_Schlafzimmer_Clima
   channel_05 Heizung_Schlafzimmer_ClimaTeam
   channel_06 Heizung_Schlafzimmer_remote
   lastMsg    No:1E - t:10 s:28E421 d:000000 0A7094090000
   protLastRcv 2020-12-25 15:31:25
   protRcv    1042 last_at:2020-12-25 15:31:25
   protResnd  1 last_at:2020-12-24 17:53:38
   protSnd    58 last_at:2020-12-24 18:04:38
   protState  CMDs_done
   rssi_CUL868 cnt:2 min:-80 max:-80 avg:-80 lst:-80
   rssi_at_CUL868 cnt:1042 min:-83.5 max:-74.5 avg:-78.06 lst:-76.5
   Helper:
     DBLOG:
       actuator:
         myDbLog:
           TIME       1608906530.13999
           VALUE      0
         myDbLogRemote:
           TIME       1608906530.17049
           VALUE      0
         myDbLogZero:
           TIME       1608906530.18585
           VALUE      0
       cmdState:
         myDbLog:
           TIME       1608828980.01974
           VALUE      -
         myDbLogRemote:
           TIME       1608828980.06148
           VALUE      -
         myDbLogZero:
           TIME       1608828980.08546
           VALUE      -
       desired-temp:
         myDbLog:
           TIME       1608906530.13999
           VALUE      14.0
         myDbLogRemote:
           TIME       1608906530.17049
           VALUE      14.0
         myDbLogZero:
           TIME       1608906530.18585
           VALUE      14.0
       measured-temp:
         myDbLog:
           TIME       1608905792.87345
           VALUE      14.8
         myDbLogRemote:
           TIME       1608905792.88785
           VALUE      14.8
         myDbLogZero:
           TIME       1608905792.89606
           VALUE      14.8
   READINGS:
     2020-12-23 20:42:56   Activity        alive
     2020-12-24 17:56:19   CommandAccepted yes
     2020-12-23 19:18:46   D-firmware      1.5
     2020-12-23 19:18:46   D-serialNr      LTK0026095
     2020-12-24 13:18:16   PairedTo        0xF11234
     2020-12-23 19:14:36   R-backOnTime    10 s
     2020-12-23 19:14:36   R-btnLock       off
     2020-12-24 13:18:16   R-burstRx       on
     2020-12-23 19:14:36   R-cyclicInfoMsg on
     2020-12-23 19:14:36   R-cyclicInfoMsgDis 0
     2020-12-23 19:14:36   R-globalBtnLock off
     2020-12-23 19:14:36   R-localResDis   off
     2020-12-23 19:14:36   R-lowBatLimitRT 2.1 V
     2020-12-23 19:14:36   R-modusBtnLock  off
     2020-12-23 19:21:32   R-pairCentral   0xF11234
     2020-12-24 13:18:16   RegL_00.         00:00 01:01 02:01 09:01 0A:F1 0B:12 0C:34 0E:0A 0F:00 11:00 12:15 16:00 18:00 19:00 1A:00
     2020-12-24 14:01:00   RegL_07.       
     2020-12-25 15:31:25   actuator        0
     2020-12-25 15:31:25   battery         ok
     2020-12-25 15:31:25   batteryLevel    2.4
     2020-12-25 15:31:25   cmdState        -
     2020-12-25 15:31:25   desired-temp    14.0
     2020-12-25 15:31:25   measured-temp   14.8
     2020-12-25 15:31:25   motorErr        ok
     2020-12-23 19:15:15   powerOn         2020-12-23 19:15:15
     2020-12-23 19:15:15   recentStateType info
     2020-12-24 18:04:38   state           CMDs_done
     2020-12-24 18:04:38   time-request    -
   helper:
     HM_CMDNR   30
     PONtest    1
     cSnd       11F1123428E42186041D,11F1123428E42186041D
     mId        0095
     peerFriend
     peerOpt    -:thermostat
     regLst     0
     rxType     140
     supp_Pair_Rep 0
     expert:
       def        1
       det        1
       raw        1
       tpl        1
     io:
       lstRecType 10
       newChn     +28E421,00,00,00
       nextSend   1608906685.46505
       nxtSndMcnt 1E
       rxt        2
       tgtDly     88
       vccu       VCCU
       lRcTm:
         CUL868     154276692
         tnms       441433032
       p:
         28E421
         00
         00
         00
       prefIO:
         CUL868
     mRssi:
       mNo        1E
       io:
         CUL866_2:
         CUL868:
           -74.5
           -74.5
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     regCollect:
     role:
       dev        1
       prs        1
     rssi:
       CUL868:
         avg        -80
         cnt        2
         lst        -80
         max        -80
         min        -80
       at_CUL868:
         avg        -78.0681381957773
         cnt        1042
         lst        -76.5
         max        -74.5
         min        -83.5
     shRegW:
       07         04
     shadowReg:
     tmpl:
Attributes:
   DbLogExclude Activity,D-firmware,D-serialNr,R-backOnTime,R-btnLock,R-burstRx,R-cyclicInfoMsg,
attr Heizung_Schlafzimmer DbLogInclude actuator,desired-temp,measured-temp
   DbLogInclude actuator,desired-temp,measured-temp
   IODev      CUL868
   IOgrp      VCCU:CUL868
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   event-min-interval measured-temp:1800,desired-temp:1800,actuator:1800
   event-on-change-reading desired-temp,measured-temp,actuator,cmdState
   expert     251_anything
   firmware   1.5
   group      HomeMatic
   model      HM-CC-RT-DN
   room       Server
   serialNr   LTK002****
   subType    thermostat
   userReadings cmdState { InternalVal($name,"protCmdPend","-"); }
   userattr   CUL_HM CUL_HM_map structexclude
   webCmd     getConfig:clear msgEvents:burstXmit
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 25 Dezember 2020, 17:22:16
Ich hab die IOGrp mal gesetzt. Scheint mir aber in diesem Fall irgendwie redundant zu sein. Sagt ihm ja nur noch die VCCU, die aber das selbe IODev hat.
Timeouts gibt's nach wie vor regelmäßig (das ist jetzt im Ruhezustand ohne Änderung)
Der FW 1.4 (1123B8) scheint jetzt doch häufiger von Timeouts betroffen zu sein. Ich spiel jetzt nochmal bisschen mit dem hmFreqOff um zu sehen ob sich hier was ändert.
Die beiden VDs liegen übrigens nebeneinander auf dem Schreibtisch, es sollte also keine Unterschiede im Empfang geben - und die CUL ist vielleicht 3m entfernt (mit externer Antenne).
Ich werde das Setup so schnell noch nicht produktiv schalten. Wenn ich also noch was testen soll, dann gerne.

Danke,
Jörg

2020.12.25 16:25:03 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1A758E
2020.12.25 16:25:08 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1123B8
2020.12.25 16:29:47 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1123B8
2020.12.25 16:32:49 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1123B8
2020.12.25 16:35:37 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1123B8
2020.12.25 16:38:10 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1123B8
2020.12.25 16:40:28 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1A758E
2020.12.25 16:40:30 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1123B8
2020.12.25 16:43:15 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1A758E
2020.12.25 16:45:28 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1123B8
2020.12.25 16:48:07 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1123B8
2020.12.25 16:48:10 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1A758E
2020.12.25 16:58:29 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1123B8
2020.12.25 17:01:01 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1123B8
2020.12.25 17:03:21 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1A758E
2020.12.25 17:05:20 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1123B8
2020.12.25 17:08:39 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1A758E
2020.12.25 17:10:50 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1123B8
2020.12.25 17:12:58 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1A758E
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 25 Dezember 2020, 18:52:05
Hallo kadettilac89,

also ich habe naturgemäß aktuelle Module und die Firmware 0.37 (allerdings nicht auf einem nano) drauf.

Bei einem meiner RT mit Firmware 1.5 habe ich erst mal alle sign on zu sign off gesetzt, dann am RT Hauptdevice ein set reset ausgelöst. Hat der RT auch ausgeführt. Somit dann auch nicht mehr gepairt.
Dann habe ich an der VCCU hmPairForSec 300 und am RT für 5 Sekunden den Boost Button gedrückt (auf den Countdown gewartet), Countdown lief an und nach kurzer Zeit kam AC.
In FHEM wurden auch Registerwerte aktualisiert, insbesondere natürlich R-pairCentral korrekt gesetzt.
Damit Pairing erfolgreich.
Es mag passieren, dass das Auslesen von Registerwerten nicht in einem Rutsch durchläuft, ok. Man kann es wohl mit dem Timing nicht allen Devices immer recht machen.

Informationen könntest Du nur mit einem Logging mit verbose 4 am nano während eines Pairing Versuchs mit FW 0.37 und meinen aktuellen Modulen liefern.
Danach ein List der devices. Nach Deiner History Beschreibung sind die Zusatzinfos jetzt leider erst mal sinnlos.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 25 Dezember 2020, 19:43:18
Hallo Jörg,

setz bitte erst mal
attr global mseclog 1

Damit die Zeiten im Log auf ms erweitert werden.

Dann im Anfang noch ein update für die 10_CUL_HM.pm.

Zum Spielen auch noch gut bei den virtuellen TCs ist das Attribut cyclicMsgOffset. Der Default ist 200 und ich habe es ein wenig relativiert, sprich die 200 gelten nur als Offset für die Mitte des Intervalls. Wenn das Intervall kürzer ausfällt, dann auch der Offset entsprechend und andersrum bei längerem Intervall. Das ist eine Inerpretation mehr in Richtung eines Gangunterschiedes der Uhren.

Was auch noch stören kann, sind andere Module mit regelmäßig langer Rechenzeit. Die machen auch das Timing seitens FHEM kaputt. Das Sendeintervall wird nur durch FHEM gemacht und wenn das nicht in das Empfangsintervall des VD trifft, dann ist es leider so.

Aber vielleicht ist noch was anderes faul. Melden die VDs denn Kontaktverlust?
Eventuell beantworten sie auch die "pleasing"-Messages einfach nicht und deswegen sieht sieht es so aus als würde es Ausfälle geben?
Wenn neu gesetzte Ventilpositionen immer innerhalb von etwa 3 Minuten beim Ventil ankommen, dann wäre das ein Grund und ich könnte das Sendekommado eventuell modifizieren.
Hast Du die Ventilposition mal längere Zeit konstant gelassen und dann beobachtet, wie die TSCUL_XmitAwaitHMTo Logeinträge kommen (warst Du z.B. ab 16:25 mit dem anderen Ventil zugange)?

Gruß, Ansgar.

Edit: Anhang auch angehangen...
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 25 Dezember 2020, 21:38:22
Hi Ansgar,

Die Antriebe melden keinen Kontaktverlust (Antennensymbol ist immer stetig an) und selbst wenn es einen timeout gab, wir ein Ventilwert dann üblicherweise nach weiteren 3 Minuten übermittelt und eingestellt. Es dauert halt ggf. etwas länger, scheint aber dann zuverlässig zu funktionieren.
Das Log mit den timeout ("tail -f <logfile> | grep timeout") war aus absoluter Ruhephase (keine Ventiländerungen). Es handelt sich zwar um einen Raspberry 1, der hat aber sonst rein gar nichts anderes zu tun.
Hier ein Logausschnitt mit "grep 1123B8" (also nur den FW 1.4 VD betreffend) bis zu einem Timeout und Millisekunden (ist das weit genug zurück?) und deinem neusten Patch.
Die Frage ist inwieweit das nicht einfach normal ist. Bei einem Hardware HM-CC-TC hat sich sicher auch noch keiner danebengesetzt und kontrolliert ob Ventiländerungen nach 3, 6 oder 9 Minuten ankommen. Ich hab jetzt so ca. alle 10 Minuten einen timeout (pro VD). Mit dem Offset hab ich jetzt noch nicht gespielt.

Gruß,
Jörg

2020.12.25 21:19:40.557 4: TSCUL_Write: CUL_TS sending As0BD2A2581122141123B80023
2020.12.25 21:19:40.566 4: TSCUL_send:  CUL_TS  430485                 As 0B D2 A258 112214 1123B8 0023
2020.12.25 21:19:40.572 4: TSCUL_XmitDlyHM:  CUL_TS  id:1123B8 rtoms:2341
AF10300078F49010BD2A2581122141123B8002380
2020.12.25 21:19:40.679 4: TSCUL_Parse: CUL_TS  430575 A F103 01981732 01 0B D2 A258 112214 1123B8 0023 _CCAdly:4
2020.12.25 21:19:40.746 5: TSCUL_Read CUL_TS: /AF10100078F71000ED282021123B8112
2020.12.25 21:19:40.753 5: TSCUL_Read CUL_TS: AF10100078F71000ED282021123B8112/21401011C002E34
2020.12.25 21:19:40.763 4: TSCUL_Parse: CUL_TS  430661 A F101 01981892 00 0E D2 8202 1123B8 112214 01011C002E -48dB
2020.12.25 21:19:40.772 5: CUL_TS: dispatch A0ED282021123B811221401011C002E::-48:CUL_TS:
2020.12.25 21:21:58.493 4: TSCUL_Write: CUL_TS sending As0BD3A2581122141123B80023
2020.12.25 21:21:58.502 4: TSCUL_send:  CUL_TS  044133                 As 0B D3 A258 112214 1123B8 0023
2020.12.25 21:21:58.508 4: TSCUL_XmitDlyHM:  CUL_TS  id:1123B8 rtoms:2341
AF103000815FC010BD3A2581122141123B8002380
2020.12.25 21:21:58.627 4: TSCUL_Parse: CUL_TS  044235 A F103 02119664 01 0B D3 A258 112214 1123B8 0023 _CCAdly:4
2020.12.25 21:21:58.682 5: TSCUL_Read CUL_TS: /AF10100081624000ED382021123B8112
2020.12.25 21:21:58.690 5: TSCUL_Read CUL_TS: AF10100081624000ED382021123B8112/21401011C002C36
2020.12.25 21:21:58.699 4: TSCUL_Parse: CUL_TS  044310 A F101 02119824 00 0E D3 8202 1123B8 112214 01011C002C -47dB
2020.12.25 21:21:58.709 5: CUL_TS: dispatch A0ED382021123B811221401011C002C::-47:CUL_TS:
2020.12.25 21:24:01.909 4: TSCUL_Write: CUL_TS sending As0BD4A2581122141123B80023
2020.12.25 21:24:01.917 4: TSCUL_send:  CUL_TS  167548                 As 0B D4 A258 112214 1123B8 0023
2020.12.25 21:24:01.923 4: TSCUL_XmitDlyHM:  CUL_TS  id:1123B8 rtoms:2341
AF10300088E82010BD4A2581122141123B8002380
2020.12.25 21:24:02.025 4: TSCUL_Parse: CUL_TS  167636 A F103 02243080 01 0B D4 A258 112214 1123B8 0023 _CCAdly:4
2020.12.25 21:24:02.097 5: TSCUL_Read CUL_TS: /AF10100088EAA000ED482021123B8112
2020.12.25 21:24:02.105 5: TSCUL_Read CUL_TS: AF10100088EAA000ED482021123B8112/21401011C002B38
2020.12.25 21:24:02.115 4: TSCUL_Parse: CUL_TS  167725 A F101 02243240 00 0E D4 8202 1123B8 112214 01011C002B -46dB
2020.12.25 21:24:02.123 5: CUL_TS: dispatch A0ED482021123B811221401011C002B::-46:CUL_TS:
2020.12.25 21:24:48.333 3: LogHist CUL_TS:  167725 A F101 02243240 00 0E D4 8202 1123B8 112214 01011C002B -46dB
2020.12.25 21:26:54.893 4: TSCUL_Write: CUL_TS sending As0BD5A2581122141123B80023
2020.12.25 21:26:54.918 4: TSCUL_send:  CUL_TS  340548                 As 0B D5 A258 112214 1123B8 0023
2020.12.25 21:26:54.934 4: TSCUL_XmitDlyHM:  CUL_TS  id:1123B8 rtoms:2341
AF10300093773010BD5A2581122141123B8002380
2020.12.25 21:26:55.102 4: TSCUL_Parse: CUL_TS  340702 A F103 02416076 01 0B D5 A258 112214 1123B8 0023 _CCAdly:4
2020.12.25 21:26:55.245 4: TSCUL_Parse: CUL_TS  340860 A F103 02416344 01 0B D5 A258 112214 1123B8 0023 _CCAdly:4
2020.12.25 21:26:55.511 4: TSCUL_Parse: CUL_TS  341126 A F103 02416612 01 0B D5 A258 112214 1123B8 0023 _CCAdly:4
2020.12.25 21:26:55.785 3: LogHist CUL_TS:  340548                 As 0B D5 A258 112214 1123B8 0023
2020.12.25 21:26:55.789 3: LogHist CUL_TS:  340702 A F103 02416076 01 0B D5 A258 112214 1123B8 0023 _CCAdly:4
2020.12.25 21:26:55.793 3: LogHist CUL_TS:  340860 A F103 02416344 01 0B D5 A258 112214 1123B8 0023 _CCAdly:4
2020.12.25 21:26:55.796 3: LogHist CUL_TS:  341126 A F103 02416612 01 0B D5 A258 112214 1123B8 0023 _CCAdly:4
2020.12.25 21:26:55.801 3: TSCUL_ParseTsHM: CUL_TS HM repeat failed to 1123B8/HM_VD_14:  341363 A F109 02416876 00 0B D5 A258 112214 1123B8 0023 _sfail _noAnsw
2020.12.25 21:26:57.282 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1123B8
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 25 Dezember 2020, 22:49:30
Hallo Jörg,

danke für den Log Auszug.

Damit ist schon mal klar, dass der VD auf die "pleasing"-Messages grundsätzlich nach 160ms antwortet.
Also bleibt das FHEM Sendetiming -> Spielwiese cyclicMsgOffset.

Zitatist das weit genug zurück?
Gerne noch was mehr und auch mal mit neuer Ventilstellung. Danke!

Bezuglich Frequenzoffsetoptimierung ist es ganz gut das Spektrum sichtbar machen zu können, z.B. in günstiger Form mit DVB-T Stick mit RTL2832 Chip, der mit HDSDR oder SDRSharp harmoniert.
Dann kann man sich durch beobachten und senden schön in die Mitte der Devices optimieren.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 26 Dezember 2020, 00:03:50
Hi Ansgar,

Ich habe den Offset jetzt bei beiden auf 160 gestellt und hatte dann deutlich weniger Meldungen im Idle Modus.
Was mir aber dann aufgefallen ist, ist das Ventilbefehle oft ankamen (Antrieb reagiert) aber trotzdem ein Timeout kam (nicht 100% immer, aber tendenziell). Eventuell braucht man ein anderes Timing je nachdem ob man nur den Status abfragt oder einen Befehl sendet?

Anbei jetzt Logauszüge getrennt nach ID über ca. 1h (nachdem das Offset geändert wurde) mit ein paar Ventilbefehlen drin.

Gruß,
Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 26 Dezember 2020, 08:54:36
Update: Über Nacht gab es weiter in unregelmäßigen Abständen (alle ca. 10 Minuten) timeouts. Etwas häufiger vom FW1.4 Gerät.
Noch zu Bedenken dabei: Ich hab 50+ Homematic Geräte im Haus die munter dazwischenfunken. Vielleicht sind da einfach auch Kollisionen dabei. Diese Messages sind im Log ausgefiltert.

Gruß,
Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 26 Dezember 2020, 13:08:26
Hallo Jörg,

ich habe mal für den 1A758E nachprüfen wollen, ob das (variable) Intervall denn passt. Dabei ist mir ein Abweichung von etwa -2.3s aufgefallen und ich dachte zuerst, der Takt vom nano sei so schlecht, weil ich die Timestamps dafür genutzt habe.
Da der Unterschied zum Host aber schon mit scF gemessen wird und der bei Dir ganz gut aussah, konnte ich beim weiteren Check der Intervallzeiten nicht recht glauben, dass auch Deine Pi Uhr gleich schlecht gehen soll.
Aber nach weiterem Check im Code denke ich nun, dass es ein Laufzeitproblem in FHEM ursächlich ist. Es wurde versucht, auf einen erfolgreichen Ack die letzte Sendezeit zum aufsynchronisieren zu nutzen, das Holen der Zeit aber laufzeitbehaftet nicht passt und damit das Intervall verkürzt wird. Das habe ich jetzt raus geworfen und mal nur auf das berechnete Intervall gesetzt. Beeinflussen lässt sich das Intervall mit den Attributen unten.

Teste bitte mal mit der angehängten 10_CUL_HM.pm.
attr cyclicMsgOffset ist nun wieder offset und per default auf 0.
attr cyclicMsgCorr ist ergänzt und kann quasi als Uhrgangunterschiedskorrektur genutzt werden, default ebenfalls 0.

Kannst Du bitte damit nochmal testen und loggen?

Gruß, Ansgar.

PS: außerdem ein HMinfo, um ein Ergebnistextersetzungsproblem von Frank zu beheben.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 26 Dezember 2020, 15:59:41
Test läuft. Ich hatte das cyclicMsgOffset attribut jetzt erstmal wieder gelöscht und habe aktuell gefühlt mehr timeouts.
Jetzt habe ich CyclicMsgCorr auf -40 gesetzt , das müsste wieder meinen 160ms entsprechen, oder habe ich das jetzt falsch verstanden?

Das Testsetup ist jetzt automatisiert und stellt die Ventile per DOIF  :)

([:15]) (set HMTC14_c1 valvePos 10)
DOELSEIF
([:30]) (set HMTC20_c1 valvePos 20)
DOELSEIF
([:45]) (set HMTC14_c1 valvePos 60)
DOELSEIF
([:00]) (set HMTC20_c1 valvePos 70)
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 26 Dezember 2020, 16:23:57
Hallo Jörg,

nein, zuvor warst Du etwa 2280ms zu früh dran nach Rechnung relativ konstant. Das wäre wohl eher -2280 als CyclicMsgOffset, um auf ähnliches zu kommen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 26 Dezember 2020, 18:01:27
Hi Ansgar,

kann es sein das es eher -228 als -2280 hätten sein müssen? - auf jeden Fall haben die Antriebe mit diesem Wert total gestreikt und sind  dann auf Fehlerposition gefahren. Ich hab es dann nach einer Weile wieder auf 0 gesetzt.

Auf jeden Fall viel Log zu schmökern.

Gruß,
Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 27 Dezember 2020, 12:00:00
Hallo Jörg,

verstehen tu ich es noch nicht, aber die 2.x Sekunden sind geblieben.
Nur der Empfangstimeout für Antworten passt dazu, auch wenn ich eigentlich keinen Zusammenhang sehe.

Bitte setz mal beim nano das Attribut hmLanQLen auf 3. Das ist per default auf 1. Mal sehen, ob das irgendeinen Unterschied macht.

Hattest Du wirklich mit den letzten Modulen gearbeitet und auch den Neustart nach einspielen nicht vergessen?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 27 Dezember 2020, 12:48:01
Bin mir sehr sicher dass ich neu gestartet habe und die ...i version ist korrekt kopiert. Habe auch nochmal im fhem.save und fhem.cfg geschaut ob der Wert irgendwo "hängengeblieben" ist, obwohl ich das Attribut gelöscht habe und nichts verdächtiges gefunden.
Auf jeden Fall hmLanQLen auf 3 gesetzt und fhem auf service level mit frischen logfile neugestartet. Lass ich jetzt mal eine Weile laufen und schicke dann die Logfiles.
Läuft jetzt ca. 15 Minuten mit 3 timeouts und zwei (erfolgreichen) Ventilländerungen.

Gruß,
Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 27 Dezember 2020, 14:10:08
Hallo Jörg,

nochmal 3 neue Dateien zum Testen.
Ich habe den cyclicMsgOffset wieder auf default 200 gesetzt. Die Berechnung des Intervalls habe ich mal nach meinem Verständis neu geschrieben.

Noch ein Hinweis, es macht bezüglich der Timergenauigkeit einen Unterschied, ob FHEM-Seite im Browser offen ist, weil die regelmäßig aktualisiert wird, was sich in einem größeren Jitter bemerkbar macht.
Beim virtuellen TC kannst Du verbose auf 2 stellen und bekommst dann das nächste berechnete Sendeintervall ins log geschrieben.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 27 Dezember 2020, 16:42:52
Hi Ansgar,

ok. Hab die eine PM mit link zum vollständigen Log geschickt. Da dürfte zwar nichts kritisches drinstehen, möchte es aber trotzdem nicht posten. Sag Bescheid wenn ichs wieder löschen kann.

Ich denke mir im kompletten Log siehst du eventuell ob die Timeouts irgendwelche Seiteneffekte haben.

Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 27 Dezember 2020, 20:18:27
Hallo Jörg,

manchmal ist man einfach nur doof.
Klar, wenn ich mit der falschen HMID rechne, dann kommt eine Differenz raus...

Mit der jeweils richtigen HMID, also der Deines jeweiligen virtuellen TCs, passsen errechnete Sendezeitpunkte. Du hast offenbar das letzte Log ohne Offset oder Corr laufen lassen.

Hier übrigens mal der link zum Thread bezüglich cyclicMsgOffset https://forum.fhem.de/index.php/topic,45735.msg572806.html#msg572806 (https://forum.fhem.de/index.php/topic,45735.msg572806.html#msg572806).

Meine Theorie dazu:
FHEM jittert im Sendezeitpunkt, weil je nach Auslastung Timer nicht rechtzeitig ausgeführt werden und das nicht zu knapp. Der Jitter verlängert und verkürzt das Sendeintervall. Zu früh senden ist offenbar ebenso ungeschickt, wie zu spät senden. Der Offset verzögert den Sendezeitpunkt. Sendet FHEM zu früh, weil es zuvor zu spät gesendet hat, dann hilft der Offset, trotzdem noch im Empfangsfenster zu bleiben. Übertreibt man es mit dem Offset, fliegt man raus, wenn FHEM zu spät sendet.

Der nächste Punkt ist natürlich der Gleichtakt der Uhren. Um das zumindest besser aufeinander abstimmen zu können, habe ich den cyclicMsgCorr ergänzt. Leider ist erst mal unbekannt, wie die Uhr am Empfänger tickt.

Die beiden Anteile wirken als Summe.

Für den 1A758E hab ich mir das Spiel mal intensiver angeschaut. Dein Pi war sehr brav beim Sendezeitpunkt mit einer Abwichung von max. 10ms im Log Zeitraum nach nano Zeit.

Anfangs hat er gut empfangen. Dann kam der erste Aussetzer, danach nochmal direkt empfangen, dann bei der 1. Wiederholung, dann zwei mal bei der 2. Wiederholung, Aussetzter, 2. Wiederholung, Aussetzer, 2. Wiederholung, Aussetzter, 2. Wiederholung, Aussetzer.
Da das Sendeintervall nicht korrigiert war und er wohl auf den Empfang synchronisiert, vermute ich aus den 2. Wiederholungen mal, dass Du eher am Anfang des Empfangszeitraums gesendet hast. Und da es möglich war, bei der 1. Wiederholung mit wohl unverändertem Empfangintervall zu empfangen, müßte der Empfangszeitraum mindestens 272ms sein.

Du solltest das bei dem Richtung + korrigieren.

Das spricht weiterhin dafür, dass ich den resynch für den virtTC wieder einbaue. Festes Intervall ist wohl ungünstig mit Bezug auf die Empfangschancen bei Wiederholungen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: frank am 27 Dezember 2020, 22:21:58
hi ansgar,

attr cyclicMsgOffset wurde eigentlich erst viel später wegen problemen bei externen tempfühlern ergänzt.
ich habe gerade erst gesehen, dass das auch beim virtuellen tc verfügbar ist. hm..., schon immer?
ich habe es jedenfalls nie benötigt, allerdings beim virt tc auch noch keinen cul probiert.

falls der offset grundsätzlich auch nach jedem miss erneut addiert wird, könnte auch hinderlich sein.



die theorie der kommunikationsfenster beim vd gibt es hier: https://forum.fhem.de/index.php/topic,18193.msg120907.html#msg120907 (https://forum.fhem.de/index.php/topic,18193.msg120907.html#msg120907)

vd und tc synchronisieren sich nur bei jeder gelungenen kommunikation.

gruss frank
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 28 Dezember 2020, 02:36:14
Hallo Frank,

vielen Dank für den Link. Ich lese, Du warst da auch schon schwer aktiv.

Zwei Dinge sind mir noch nicht klar bezüglich der Interpretation bei Empfangsproblemen.

1. Wie ist die Wachfolge?
250 ms nix empfangen
250 ms nix empfangen
750 ms nix empfangen
1250 ms nix empfangen
1750 ms nix empfangen
2250 ms nix empfangen
2750 ms nix empfangen
? Zumindest würde ich den zitierten Text so verstehen
oder
250 ms nix empfangen
750 ms nix empfangen
1250 ms nix empfangen
1750 ms nix empfangen
2250 ms nix empfangen
2750 ms nix empfangen
? So verstehe ich weitere Forumsbeiträge

2.
Macht der VD zwischen den verlängerten Wachzeiten die gleiche Pausenlänge nach Intervallberechnung oder wird die Pause um die Wachverlängerung verkürzt?

@Ralf:

nochmal eine neue Test CUL_HM im Anhang.

Gruß, Ansgar
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: frank am 28 Dezember 2020, 11:19:59
hi ansgar,

mein verständnis sieht so aus:

die geplanten zeitpunkte nenne ich mal meetings (m0, m1, .... , m6).
m0 ist das gerade durchgeführte (last) meeting.
war m0 erfolgreich, gibt es genau 6 versuche (m1 .. m6), erneut ein erfolgreiches meeting durchzuführen (keep-alive-mechanismus).
waren alle 6 meetings in folge erfolglos, schläft der vd für ca 60min ein.
anschliessend wacht der vd für längere zeit auf, so dass auf alle fälle der nächste versuch erfolgreich sein wird.

ein erfolgreiches meeting wird im vtc im reading valveCtrl mit ok angezeigt.
die misslungenen meetings werden mit "miss_1, ... , miss_5, lost" angezeigt.
wenn fhem wirklich alle messages vom vd empfängt, kann man sich darauf verlassen, dass bei valveCtrl=lost der vd wirklich eingeschlafen ist. ab dann kann man auch davon ausgehen, dass nun valvePosition=valveErrorPos gilt.

wenn m0=ok ist, sind dadurch die zeitpunkte der nächsten 6 meetings (m1 .. m6) im prinzip festgelegt.
für m4 also: m0 plus die summe der ersten 4 berechnungen.

ich bin in meinen überlegungen immer davon ausgegangen, das die jeweiligen "fenster" dann symmetrisch um die berechneten zeitpunkte liegen. das könnte aber auch anders sein. die länge der fenster ist für die berechnung eigentlich uninteressant.
wichtig ist der synchronisations zeitpunkt.


zum verständnis des codes ist es eventuell hilfreich zu wissen, dass noch ein mechanismus eingebaut ist, um den traffic der io zu reduzieren:
über das "attr param msgReduce:N" kann man N meetings nach einem erfolgreichen meeting auslassen.
ich nutze zb "msgReduce:2", wodurch in der regel m1 und m2 ausgelassen wird. erst ab m3 wird dann der keep-alive versucht.
wenn allerdings beim vtc die valvePos geändert wird, wird ab diesem moment für den anstehenden keep-alive zyklus kein meeting ausgelassen. das auslassen wird erst wieder in gang gesetzt, wenn es ein erfolgreiches meeting gegeben hat.
mit "msgReduce:2" sehe ich zusätzlich den effekt, dass es pro tag weniger miss gibt. erstens wegen weniger versuchen pro tag und zweitens wohl, weil das fenster dann natürlich auch grösser ist.


@Adimarantis
zum überwachen des readings valveCtrl nutze ich zb die fehlererkennung von hminfo.
dazu habe ich das attribut sumERROR mit "valveCtrl:restart:unknown:ok:miss_1:miss_2:miss_3:miss_4:miss_5" erweitert. dadurch wird für valveCtrl=lost die jeweilige entity in den internals angezeigt.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 28 Dezember 2020, 12:23:48
Hallo Frank,

danke für Deine Erläuterung.

Hatte ich auch im Prinzip schon aus dem verlinkten Thread rausgelesen.

Zitatdas die jeweiligen "fenster" dann symmetrisch um die berechneten zeitpunkte liegen. das könnte aber auch anders sein. die länge der fenster ist für die berechnung eigentlich uninteressant.
Das Fenster will getroffen werden.
Symetrisch um die berechneten Zeitpunkte wäre sinnvoll, muss aber nicht so im VD programmiert sein. Was dafür spricht, wäre die jeweils +500ms = +2*250ms.
Wenn dem nicht so ist, dann muss das Sendeintervall verlängert werden, um das verlängerte Empfangsintervall auch sinnvoll nutzen zu können. Für irgendwas muss der reale TC ja auch das Ack anfordern (klar, Error Meldungen sind auch schön ;-). Für Fehlermeldungen könnte man auch im Sinne von Stromverbrauch nur jedes n-te mal ein Ack anfordern.
Über die Ack Info kann aber auch das Intervall angepasst werden.

Ist eine Intervallveränderung Richtung länger mit dem realen TC mal aufgefallen, wenn bei VD z.B. die Batterien einfach mal rausgenommen werden?

Für ein asymetrisches Empfangsfenster würde der Stromverbrauch sprechen. Wenn der Anfang des Empfangsfensters getroffen wird, kann früher wieder komplett geschlafen werden, inklusive Empfänger. Ist natürlich auch eine Frage der in der Produktion erreichbaren Taktgenauigkeit für die HM devices.

Ich kann nur mit RT testen und habe dafür nun den Offset dynamisiert. Bekannt ist der Soll-Aufrufzeitpunkt des Timers. Gemessen wird schon der Ist-Zeitpunkt des Timers. Systemlast bedingt werden Timer wenn falsch, dann immer nur zu spät ausgeführt. Mit dem cyclicMsgOffset lässt sich das nutzen, um bei Systemverspätung den Offset zu veringern.
Bei krassen Verspätungen sende ich nun einfach gar nicht zum RT, damit kann der das auch nicht versehentlich empfangen.

Wenn das noch um das Sollintervall herum symetrisiert wird, dann wäre das auch auf den VD anwendbar (und sollte es auch für den RT weiter verbessern). Wäre also als eine Art Zeitpuffer im engen Rahmen des Empfangsfensters zu verstehen.

Edit:
Nebenbei führt das Anfordern das Acks zu Repeats durch das IO (macht HMLAN und auch tsculfw). Wenn der VD auf einen IO-Repeat synchronisiert ist auch schlecht. Dafür müsste Senderseitig der Ack Zeitpunkt mit einbezogen werden. Macht der reale TC so was, sprich springt das Sendeintervall schon mal?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 28 Dezember 2020, 17:07:04
Ich habe heute noch ein wenig mit den Offsets rumgespielt.
Der FW2.0 Antrieb (1A758E) läuft recht gut mit 220 - beim FW 1.4 (1123B8) Antrieb hab ich nicht wirklich viel Unterschied bemerkt, außer dass zu große Abweichungen dann dazu geführt haben, dass er in den Fehlerzustand ging.
Ich bringe da zu diesen Deltas vom TC nicht wirklich eine Relation hergestellt. Anbei nochmal die Daten der letzten Stunde (Offset konstant 1A758E=220 , 1123B8=230
Wenn ich noch etwas probieren soll, dann bitte welche spezifischen Settings. Für mich funktioniert das jetzt "gut genug".

Danke,
Jörg

2020.12.28 15:19:58.865 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1123B8
2020.12.28 15:20:53.501 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1A758E
2020.12.28 15:24:38.325 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1123B8
2020.12.28 15:28:36.659 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1A758E
2020.12.28 15:30:27.769 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1123B8
2020.12.28 15:36:18.057 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1A758E
2020.12.28 15:37:23.950 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1123B8
2020.12.28 15:59:11.038 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1A758E
2020.12.28 16:04:28.233 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1A758E
2020.12.28 16:08:47.697 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1A758E
2020.12.28 16:10:11.446 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1123B8
2020.12.28 16:15:14.663 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1123B8
2020.12.28 16:21:33.271 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1A758E
2020.12.28 16:25:39.827 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1123B8
2020.12.28 16:27:56.060 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1123B8
2020.12.28 16:35:26.248 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1123B8
2020.12.28 16:39:56.953 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1123B8
2020.12.28 16:42:54.680 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1123B8
2020.12.28 16:45:37.931 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1123B8
2020.12.28 16:48:39.950 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1A758E
2020.12.28 16:50:21.133 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1123B8
2020.12.28 16:51:37.665 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1A758E
2020.12.28 16:53:25.101 4: TSCUL_XmitAwaitHMTo CUL_TS: timeout - 1123B8


2020.12.28 15:59:08.683 2: CUL_HM HMTC20_c1 mc:FA->FB dt:165720ms
2020.12.28 16:00:07.415 2: CUL_HM HMTC14_c1 mc:FB->FC dt:171980ms
2020.12.28 16:01:54.414 2: CUL_HM HMTC20_c1 mc:FB->FC dt:151470ms
2020.12.28 16:02:59.397 2: CUL_HM HMTC14_c1 mc:FC->FD dt:157730ms
2020.12.28 16:04:25.880 2: CUL_HM HMTC20_c1 mc:FC->FD dt:136970ms
2020.12.28 16:05:37.126 2: CUL_HM HMTC14_c1 mc:FD->FE dt:143230ms
2020.12.28 16:06:42.845 2: CUL_HM HMTC20_c1 mc:FD->FE dt:122470ms
2020.12.28 16:08:00.361 2: CUL_HM HMTC14_c1 mc:FE->FF dt:128730ms
2020.12.28 16:08:45.342 2: CUL_HM HMTC20_c1 mc:FE->FF dt:171970ms
2020.12.28 16:10:09.086 2: CUL_HM HMTC14_c1 mc:FF->00 dt:158730ms
2020.12.28 16:11:37.298 2: CUL_HM HMTC20_c1 mc:FF->00 dt:137970ms
2020.12.28 16:12:47.826 2: CUL_HM HMTC14_c1 mc:00->01 dt:144480ms
2020.12.28 16:13:55.265 2: CUL_HM HMTC20_c1 mc:00->01 dt:123720ms
2020.12.28 16:15:12.298 2: CUL_HM HMTC14_c1 mc:01->02 dt:129980ms
2020.12.28 16:15:58.976 2: CUL_HM HMTC20_c1 mc:01->02 dt:173220ms
2020.12.28 16:17:22.276 2: CUL_HM HMTC14_c1 mc:02->03 dt:179480ms
2020.12.28 16:18:52.203 2: CUL_HM HMTC20_c1 mc:02->03 dt:158720ms
2020.12.28 16:20:21.755 2: CUL_HM HMTC14_c1 mc:03->04 dt:164980ms
2020.12.28 16:21:30.916 2: CUL_HM HMTC20_c1 mc:03->04 dt:144470ms
2020.12.28 16:23:06.737 2: CUL_HM HMTC14_c1 mc:04->05 dt:150730ms
2020.12.28 16:23:55.384 2: CUL_HM HMTC20_c1 mc:04->05 dt:129970ms
2020.12.28 16:25:37.466 2: CUL_HM HMTC14_c1 mc:05->06 dt:136230ms
2020.12.28 16:26:05.354 2: CUL_HM HMTC20_c1 mc:05->06 dt:179470ms
2020.12.28 16:27:53.706 2: CUL_HM HMTC14_c1 mc:06->07 dt:121730ms
2020.12.28 16:29:04.836 2: CUL_HM HMTC20_c1 mc:06->07 dt:164970ms
2020.12.28 16:29:55.427 2: CUL_HM HMTC14_c1 mc:07->08 dt:171480ms
2020.12.28 16:31:49.804 2: CUL_HM HMTC20_c1 mc:07->08 dt:150720ms
2020.12.28 16:32:46.906 2: CUL_HM HMTC14_c1 mc:08->09 dt:156980ms
2020.12.28 16:34:20.515 2: CUL_HM HMTC20_c1 mc:08->09 dt:136220ms
2020.12.28 16:35:23.894 2: CUL_HM HMTC14_c1 mc:09->0A dt:142480ms
2020.12.28 16:36:36.742 2: CUL_HM HMTC20_c1 mc:09->0A dt:121720ms
2020.12.28 16:37:46.372 2: CUL_HM HMTC14_c1 mc:0A->0B dt:128230ms
2020.12.28 16:38:38.465 2: CUL_HM HMTC20_c1 mc:0A->0B dt:171470ms
2020.12.28 16:39:54.598 2: CUL_HM HMTC14_c1 mc:0B->0C dt:177730ms
2020.12.28 16:41:29.925 2: CUL_HM HMTC20_c1 mc:0B->0C dt:156970ms
2020.12.28 16:42:52.326 2: CUL_HM HMTC14_c1 mc:0C->0D dt:163230ms
2020.12.28 16:44:06.894 2: CUL_HM HMTC20_c1 mc:0C->0D dt:142470ms
2020.12.28 16:45:35.576 2: CUL_HM HMTC14_c1 mc:0D->0E dt:148730ms
2020.12.28 16:46:29.375 2: CUL_HM HMTC20_c1 mc:0D->0E dt:128220ms
2020.12.28 16:48:04.291 2: CUL_HM HMTC14_c1 mc:0E->0F dt:134480ms
2020.12.28 16:48:37.595 2: CUL_HM HMTC20_c1 mc:0E->0F dt:177720ms
2020.12.28 16:50:18.775 2: CUL_HM HMTC14_c1 mc:0F->10 dt:183980ms
2020.12.28 16:51:35.310 2: CUL_HM HMTC20_c1 mc:0F->10 dt:163220ms
2020.12.28 16:53:22.745 2: CUL_HM HMTC14_c1 mc:10->11 dt:169480ms
2020.12.28 16:54:18.530 2: CUL_HM HMTC20_c1 mc:10->11 dt:148970ms
2020.12.28 16:56:12.225 2: CUL_HM HMTC14_c1 mc:11->12 dt:155230ms
2020.12.28 16:56:47.496 2: CUL_HM HMTC20_c1 mc:11->12 dt:134470ms
2020.12.28 16:58:47.456 2: CUL_HM HMTC14_c1 mc:12->13 dt:140730ms
2020.12.28 16:59:01.968 2: CUL_HM HMTC20_c1 mc:12->13 dt:183970ms
2020.12.28 17:01:08.186 2: CUL_HM HMTC14_c1 mc:13->14 dt:126230ms
2020.12.28 17:02:05.940 2: CUL_HM HMTC20_c1 mc:13->14 dt:169470ms
2020.12.28 17:03:14.415 2: CUL_HM HMTC14_c1 mc:14->15 dt:175980ms
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 29 Dezember 2020, 00:05:49
Hallo Jörg,

danke für die Tests.

Mit dem virtuellen TH bin ich jetzt gut weiter gekommen und baue den virtuellen TC entsprechend um. Dann gibt's wieder Testbedarf.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 29 Dezember 2020, 21:33:38
Hallo Jörg,

anbei nochmal was zum testen.

Ich habe in der Firmware die Wiederholung der Ventil- und TH Messages abgeschaltet, weil die mangels Info, ob die erste Message oder ein Repeat empfangen wurde, kontraproduktiv sind.
Daher erst mal die Firmware des nano auf neuen Stand bringen (ich habe auch mal eine hex für den CUL V3 beigepackt, falls jemand mit CUL V3 testen möchte). Natürlich auch alle Module aus der Zip.

4 Attribute gibt es nun.

cyclicMsgRecWinHalf: Damit setzt man die Hälfte des des Empfangsfensters, entsprechend dem des Empfängers, in ms. 125 ist default und sollte dem VD entsprechen. Solltest Du nicht anpassen müssen.

cyclicMsgCorr: Wie schon bekannt ein Korrekturwert für die Zeit. 0 default. Solltest Du nicht ändern müssen, sofern Deine Pi Uhr nicht nach dem Mond geht und auch nich die der VDs.

cyclicMsgMissOffs: Damit wird eine Intervallverlängerung im Fall von misses (keine Antwort vom VD) in 125ms Schritten eingestellt. 0 bis 4 können eingestellt werden. 2 ist default und "Spielwiese" für Dich. Da das Empfangsfenster größer werden soll, wird damit der Sendezeitpunkt verschoben um da rein zu fallen. Das müsste beim "Einfangen" helfen, wenn das Empfangsfenster einseitg vergrößert wird (beim RT ist mein Eindruck so, der muss sich aber nicht wie ein VD verhalten).
0 wäre der alte Zustand, sprich im normalen Sendeinterval wird weiter gesendet.

cyclicMsgRtAck: Nur für Tests mit RT. Damit wird mit einer TH Message ein Ack angefordert. Damit kann man im Log an den Rohmessages sehen, ob die Messages empfangen werden. 0 default.

CUL_HM sendet nun grundsätzlich etwas verzögert zum regulären Intervall (etwa 62ms). Das soll etwas FHEM Jitter abdämpfen. Außerdem sendet CUL_HM gar nicht, wenn FHEM den Timer so unpünktlich aufruft, so dass nicht damit zu rechnen ist, dass der Empfänger wach ist. Damit bleibt das Syncen in einem genaueren Rahmen und es wird auch nicht sinnlos gesendet.
Mit RT hat das gut geholfen. FHEM neigt bisweilen zu mehreren Sekunden Verzögerung. Durch diese Änderung bleibt es besser im Sendetakt und der Empfänger sieht so nur einen garantierten "Empfangsausfall", statt eines verschobenen Sendeintervalls in der Folge.

Kommt ein Ack, wird auf Basis des letzten Sendezeitpunkt zum VD weiter gesendet, wie das auch zuvor schon so war.

Ich bin gespannt, ob das auch beim VD so besser funktioniert.
Wie gehabt mit verbose 4 beim nano und verbose 2 beim virtuellen TC.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 31 Dezember 2020, 10:31:52
Hallo Jörg,

nochmal ein kleines Update.
Nur 00_TSCUL.pm und 10_CUL_HM.pm sind zum letzten Stand verändert.
In TSCUL habe ich entsprechend der fehlenden Wiederholungen den Queue Sendetimeout für das Warten auf Antwort noch angepasst.
In CUL_HM hatte ich noch ein Fehler beim peerIDs Handling gemacht, was beim Setzen von Templates auffallen würde.

Deswegen erwarte ich aber keinen wesentlichen Unterschied im VD Kommunikationstestergebnis, also kein Grund für eine aufwändige Testserie.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 31 Dezember 2020, 14:22:59
Hi Ansgar,

dein neustes update habe ich jetzt erst gesehen. An gewohnter Stelle findest du ein Logfile der Version von gestern. Mit dem cyclicMsgMissOffs hab ich ein wenig gespielt (siehst du am Logfile wann ich das geändert habe?) und bin am Ende bei "0" gelandet - das lief meine ich am Besten, aber die Timeouts kommen nach wie vor regelmäßig. Ich spiele jetzt dein letztes update ein und lasse das einfach mit "0" weiterlaufen.

Gruß,
Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Lowbird am 01 Januar 2021, 20:20:02
Hallo Ansgar,

ich habe das Problem, dass wenn ich mit der 00_TSCUL.pm das System neu starten möchte, FHEM gar nicht bis in WebUi lädt. In der Logdatei habe ich folgende Meldung als Problem festgestellt:

2021.01.01 20:03:49 0: Server shutdown
Undefined subroutine &main::RemoveInternalTimerM called at ./FHEM/00_TSCUL.pm line 7535.
2021.01.01 20:03:51 1: Including fhem.cfg
2021.01.01 20:03:51 3: WEB: port 8083 opened
2021.01.01 20:03:52 2: eventTypes: loaded 1556 events from ./log/eventTypes.txt
Undefined subroutine &main::RemoveInternalTimerM called at ./FHEM/00_TSCUL.pm line 7630, <$fh> line 31.



Wenn ich die Timer in Zeile 7535,7630,7631 und 7632 auskommentiere, startet er ohne Fehlermeldung.

Alle nötigen Dateien gemäß deinem Post #1037 ersetzt.

nanoCul gefüttert mit der VTS 0.37 CSM868


Wenn du noch internals zur Fehlerbehebung benötigst sag Bescheid.


Ich danke dir für deine Zeit.

LG Chris
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 01 Januar 2021, 21:41:34
Hallo Chris,

ZitatAlle nötigen Dateien gemäß deinem Post #1037 ersetzt.
98_timerTS.pm war wohl nicht dabei, aber die muss auch ergänzt werden.  ;)

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Lowbird am 02 Januar 2021, 17:31:36
Hallo Ansgar,

keine Ahnung warum die 97_timerTS.pm nicht mitkopiert wurde. Aber das war der Fehler.
Danke dir fürs supporten.

LG Chris
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 02 Januar 2021, 17:47:52
Hallo Jörg,

anbei wieder was neues zum Testen (nur Module verändert, Firmware ist gleich).

Ich habe ein Reading ergänzt:
timing        mc: 37 miss: 0 tQ: 0.545 rQ: 0.600 mSkp: 0 mNck: 5 dtu: 130500 errS: -2 errC: -1
mc: ist der HM Message Counter für die letzte gesendete Nachricht dezimal
miss: ist die anzahl misses seit letztem Ack
tQ: ist ein Qualitätsindikator für die Übertragung als "Summe der bestätigten messages"/"Summe aller gesendeten messages" -> 1 ist Spitze, 0 nix geht
rQ: ist ein Qualitätsindikator für das Resyncen als "Summe der Übertragunsunterbrechungen"/"Summe der nicht bestätigten messages" -> 1 ist Spitze für Recovery, 0 nix geht
mSkp: ist die Anzahl ausgelassener Übertragungen, wenn nicht explizit angefordert, dann gibt es die "Störungen" des Timer-Timings an
mNck: ist die Anzahl nicht bestätigter messages, kann Funkübetragungsprobleme bedeuten oder Systemtimingprobleme oder was auch immer inklusive meiner Bugs  ;)
dtu: ist das für diese message genutzte Timerintervall
errS: der dabei mittels Rückmeldung vom CUL ermittelte Systemtimingfehler (Ist-Soll -> positiv=später)
errC: der dabei nach CUL Timestamp ermittelte Sendetimingfehler (Ist-Soll -> positiv=später)

im Log gibt es bei verbose 2 beim virtuellen TC ein oder zwei Einträge
2021.01.02 16:40:51.217 2: CUL_HM V_ValveCtrl_TC 11222001 hI:125ms S:0 A:0 O:2 mc:21->22  dtp: 159500 ms  dtF: 159500 ms  dtcall: 5 ms  nv:n
2021.01.02 16:41:21.363 2: CUL_HM V_ValveCtrl_TC 11222001 mc:22  tQ: 0.625  rQ: 0.667  dtu: 173754 ms  errS: 2 ms  errC: 2 ms  miss: 1
2021.01.02 16:43:30.715 2: CUL_HM V_ValveCtrl_TC 11222001 hI:125ms S:0 A:0 O:2 mc:22->23  dtp: 145000 ms  dtF: 145000 ms  dtcall: 5 ms  nv:n  miss: 1
2021.01.02 16:44:00.848 2: CUL_HM V_ValveCtrl_TC 11222001 mc:23  tQ: 0.556  rQ: 0.500  dtu: 159500 ms  errS: -3 ms  errC: 0 ms  miss: 2

hI: ist die halbe (angenommene) Empfangsfenstergröße nach Attribut cyclicMsgRecWinHalf
S: Sendezeitpunktshifting entsprechend Attribut cyclicMsgDoShift
A: Sendeintervallsverlängerung entsprechend Attribut cyclicMsgMissAdd
O: Zeitbasis für Sendezeitpunktshifting und dtcall limit nach Attribut cyclicMsgMissOffs
mc: ist der HM Message Counter für die letzte gesendete Nachricht hexadezimal
dtp: ist das vorherberechnete Sendeintervall zur nächsten message
dtF: ist das vorherberechnete Sendeintervall zur nächsten message im Fall ausbleibender message Bestätigung
dtcall: ist die Verspätung des Timeraufrufs
nv: n -> keine neue Ventilstellung, Y -> neue Ventilstellung zu übertragen

Damit kannst Du jetzt auch selbst recht einfach sehen, wie der Erfolg einer Änderung ist.
Wenn eines der Attribute gändert wird, dann wird die Statistik auch mit zurück gesetzt. Vor dem Spielen also besser erst notieren. Ansonsten bei verbose 2 beim TC auch noch im Log nachvollziehbar.

Aus Deinem vorletzten Log nehme ich an, dass sich die beiden VD Firmwareversionen 1.4 und 2.0 im Timing anders verhalten.
Dem 1.4er hat Shifting und Recovery Sendeintervallvergrößerung eher nicht gefallen. Wenn es mit einem Ackausfall wieder kürzer wird, scheint er sich wieder zu fangen. Mal sehen, wie er mit der jetzigen Defaulteinstellung arbeitet.
Dem 2.0er schien das Shifting eher zu gefallen und auch beim Recovery sah eine Sendeintervallvergrößerung eher besser aus. Da wäre cyclicMsgDoShift=1 und/oder cyclicMsgMissAdd=1 oder 2 hoffnungsvoll.

Insgesammt gibt es aber viele Ack-Ausfälle die allein aus dem Timing nicht wirklich zu erklären sind. Irgendwas anderes scheint mit zu stören. (Netzteil vom Pi? Ein 868.3MHz Slow RF Gerät? Die Wanze in Deiner Tischlampe? ;) Die Qualität der VD Firmware? Ein Rechner oder Laptop oder...? Mein übersehener Bug?  ;D ).
Für aussagekräftige Ergebnisse bringt es wohl nur was, wenn Du nach jeder Änderung den Beobachtungszeitraum deutlich vergrösserst. Dafür sind die Qualitätsindikatoren hoffentlich hilfreich.

Wenn Du mir Log Daten zum virtuellen TC zukommen lassen möchtest, dann bitte erst mal nur die mit verbose 2 von oben. Logging vom nano hilft nicht weiter, da darin schon verarbeitet.
Ich bin gespannt.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: frank am 02 Januar 2021, 18:34:49
wow, hört sich super an.
funktioniert das auch mit anderen io oder nur mit cul?
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 02 Januar 2021, 18:56:17
Hallo Frank,

Zitatfunktioniert das auch mit anderen io oder nur mit cul?
Das reine Intervalltiming zu den VDs hat nichts mit dem IO zu tun (wenn ich brav war ;) ). Die Qualitätsindikatoren hängen auch nur an Zählern in CUL_HM.

Das Messen des Timings hängt am tscul, weil ich mir die Daten aus der tscul Sendebstätigung (also nicht das ACK vom device) im TSCUL Modul ziehe und von da direkt ins HM device zur weiteren Verarbeitung durch CUL_HM schreibe.
Wenn Du Deinen CUL noch nicht verschrottet hast, kannst Du natürlich gerne mit testen. Mich würde ohnehin interessieren, ob es auch mit HMLAN & Co. im Mischbetrieb noch alles funktioniert. Kann ich selber nicht testen.

Natürlich ist zu beachten, dass gerade Winter ist und eine funktionierende Heizung somit von Vorteil ist... . Backup etc...

Nebenbei, ich vermute es war der F1 Bug bei den VDs bei voller Öffnung, die zur Begrenzung des Ventilöffnungsgrads geführt hat.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 02 Januar 2021, 21:22:54
Alles klar. Test läuft mit FW1.4 komplett auf defaults and FW2.0 mit cyclicMsgDoShift=1 und cyclicMsgMissAdd=1
Nano wieder auf Verbose 0.
Als Netzteil kommt aktuell ein Hutschienen-China-Teil zum Einsatz - und das ist ziemlich nah am Raspi - schon möglich das da was stört.
Ich selbst habe außer den anderen 50+ Homematic Devices nichts auf 868Mhz, aber wer weiss was mein Nachbar so macht. Zumindest mein rfxtrx433 findet massig Fremdgeräte - gut möglich dass der auch auf 868 fleissig ist. Ich hab jetzt auch noch die crontab geputzt und in FHEM noch ein paar weitere Dinge disabled so das jetzt hoffentlich von der Seite nix mehr stört.

Die ersten 20 Minuten des aktuellen Test lief alles super (rq/tq=1.000) aber plötzlich habe ich auf beiden gehäuft "misses". ErrS/ErrC sind meist einstellig, selten mal (+/-)15-20ms. Die größte Varianz sehe ich bei dtu/dtp/dtF.
Ich lasse das jetzt weiter mit Ventiländerung alle 20 Minuten (versetzt um 10 Minuten) über Nacht laufen und morgen gibts dann ein log.

Auf den 1.4er würde ich nicht all zu viel Energie verschwenden. Nicht umsonst gibt es HW/FW Revisionen - der hat sicher seine Fehler.

Gruß,
Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 02 Januar 2021, 21:50:23
Hallo Jörg,

ZitatAls Netzteil kommt aktuell ein Hutschienen-China-Teil zum Einsatz - und das ist ziemlich nah am Raspi - schon möglich das da was stört.
Das wird sich doch ändern lassen + Versorgunsleitung ein paar mal um einen Ferritkern.  ;)

ZitatErrS/ErrC sind meist einstellig, selten mal (+/-)15-20ms.
Ja, dass Du diesbezüglich eigentlich traumhafte Verhältnisse auf Deinem Pi hast, ist mir auch schon aufgefallen. Ab und zu durch Fehltiming nachvollziehbare Aussetzer wären eigentlich zum Testen eher zu begrüßen.

ZitatDie größte Varianz sehe ich bei dtu/dtp/dtF.
Das die sich ändern ist normal, da pseudozufällig gerechnet. dtp ist das gerechnete "Ideal". Auf dtF wird was drauf gerechnet je nach Einstellung und auch so bei dtu.

ZitatAuf den 1.4er würde ich nicht all zu viel Energie verschwenden. Nicht umsonst gibt es HW/FW Revisionen - der hat sicher seine Fehler.
Es gab mal die Möglichkeit, die bei ELV einzuschicken und gegen kleines Entgeld updaten zu lassen. Over The Air geht bei denen leider nicht.

Versorgst Du die VD mit Batterie oder auch über ein Netzteil?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 03 Januar 2021, 13:42:29
Hallo Jörg,

anbei eine neue Version zum Testen, wieder nur Module geändert.

der 2.0er hat mit einem miss noch gut Resynct. Ab 2 war dann Ende. Entweder habe ich einen Miss zu früh mit dem Add angefangen oder der zusätzlich wachsende Shift hat ein Problem gemacht, oder Add ist ein Holzweg.
Wenn cyclicMsgMissAdd=1 dann wird jetzt nur noch minimal geshiftet ohne zu erweitern. Das Verlängern des Intervalls passiert jetzt einen Miss später.

Bitte teste nochmal mit FW2.0 mit cyclicMsgDoShift=1 und cyclicMsgMissAdd=1. Sehen muss ich mindestens 3, besser 4, Misses in Folge im Log.

Für den 1.4er kannst Du mal mit cyclicMsgDoShift=1 testen und nach und nach cyclicMsgMissOffs 1 bis 4 durchspielen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 04 Januar 2021, 15:06:01
Hallo Jörg,

anbei eine neue Version der Module, Firmware wieder unverändert.

Ich habe CUL_HM bezüglich des Updates der Readings geändert. Die Readings werden, so weit möglich, mit Timern etwas verzögert aktualisiert. Das verringert die direkten Verzögerungen insbesondere beim devices mit vielen Readings. Durch die Art der Abarbeitung von Timern sind damit Summenverzögerungen allerdings auch nicht ausgeschlossen.

Setz bei beiden VD Versionen cyclicMsgMissAdd=0 erst mal 0. cyclicMsgDoShift und cyclicMsgMissOffs bleiben Spielwiese.

Bei TSCUL habe ich ein set getFreqOffsEst ergänzt. Damit kann vom CUL das lesen des Frequency Offset Estimate Register getriggert werden und damit das Reading FreqOffsEst mittels notify aktualisiert werden.
Das gibt die Möglichkeit mittels notify auf eine einzelene Aktualiserung eines Status eines der HM devices hin das FreqOffsEst reading zu aktualisieren und beim CUL zu loggen.
Die Werte von FreqOffsEst sind aber mit Verstand und Vorsicht zu genießen, da sie damit nicht zwingend wirklich dem HM device zuzordnen sind (wenn z.B. ein weiteres device mittlerweile empfangen wurde oder im Multi-CUL Betrieb, weil es nur von einem anderen CUL empfangen wurde). Nutzbar ist es ohnehin nur bei Protokollen, die das Register auch seitens cc1101 nutzbar machen, also auf jeden Fall nicht bei SlowRf.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 04 Januar 2021, 20:11:31
Hi Ansgar,

Ja, das mit dem GetFreqOffsEst wird bei mir schwierig, da aufgrund der vielen HM Device einiges los ist.

Also bisher muss ich leider sagen, dass sich die Situation eher immer weiter verschlechtert. Die Misses zählen fast ununterbrochen hoch und die Antriebe gehen sogar teilweise auf Fehlerposition.
Hab auch schon versucht die Antriebe in andere Zimmer zu stellen und habe auch die Antenne vom Nano nachgelötet (da hatte ich auch den Eindruck, das da was vom umherräumen gelitten hatte). Die Antriebe sind jetzt auch auf Netzbetrieb umgebaut (Hohlstecker sind angekommen) und einer läuft jetzt mit Netzteil.
Das Spielen mit den Parametern hat leider auch keinen nachvollziehbaren Effekt. Ich hab jetzt alle Attribute gelöscht (=Default) und der 2.0er scheint sich gerade ein bisschen zu fangen.

Gruß, Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 04 Januar 2021, 23:26:33
Hallo Jörg,

bei der letzten Version saß der Fehler vor der Tastatur.

Im Anhang nochmal ein neuer Stand, wieder nur Module geändert.

Ich habe zusätzlich noch die Granularität verfeinert. Entsprechend ist der Wertebereich für die Attribute erweitert.
Jetz kannst Du cyclicMsgDoShift von 1 bis 2 (auch bis 4) nochmal eine Chance geben.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: frank am 05 Januar 2021, 12:33:02
hi ansgar.

Zitat von: noansi am 02 Januar 2021, 18:56:17
Hallo Frank,
Das reine Intervalltiming zu den VDs hat nichts mit dem IO zu tun (wenn ich brav war ;) ). Die Qualitätsindikatoren hängen auch nur an Zählern in CUL_HM.
gut zu wissen.

ZitatDas Messen des Timings hängt am tscul, weil ich mir die Daten aus der tscul Sendebstätigung (also nicht das ACK vom device) im TSCUL Modul ziehe und von da direkt ins HM device zur weiteren Verarbeitung durch CUL_HM schreibe.
das müsste beim alten hmlan doch auch möglich sein.

ZitatWenn Du Deinen CUL noch nicht verschrottet hast, kannst Du natürlich gerne mit testen. Mich würde ohnehin interessieren, ob es auch mit HMLAN & Co. im Mischbetrieb noch alles funktioniert. Kann ich selber nicht testen.
natürlich verschrotte ich meinen guten cul nicht. selbst mit fw 1.58 kann ich mich an keine probleme erinnern.
allerdings hat er meist nicht viel zu tun, dient hauptsächlich zum monitoren und als backup.

gestern abend gegen 01:00 uhr habe ich ihn das erste mal als prefered io an einen vd assigned, um erst mal zu schauen, wie es mit standard modulen so funktioniert.

ich bin geade völlig überrascht, da es seit 10 stunden im cul betrieb noch keinen einzigen miss gegeben hat. der vd hat nun in den vergangenen 48 std drei miss_1 gezeigt. ich habe sogar mit hmuart und hmlan mitgesnifft, um zu sehen, ob wirklich der cul sendet.

der average dieses vd (etwa zur hälfte mit hmlan und hmuart betrieben) liegt bei 3.0 fehler pro tag seit anfang august. da scheint sich der cul im vergleich nicht verstecken zu müssen. dabei zähle ich aufeinander folgende miss als einen fehler. zwischen 2 fehlern muss also mindestens ein ok erfolgen.

das grundsätzliche prinzip der kommunikation mit den vds funktioniert also schon sehr gut.
ein vergleich meiner 6 vd zeigt eine gewisse korrelation zwischen fehlerhäufigkeit und rssi. also je schlechter der rssi, desto grösser wird der average. da könnten dann zb reflexionen eine rolle spielen, vermute ich.

sorry, aber ein test mit tsculfw wird wohl erst einmal nichts.


ZitatNebenbei, ich vermute es war der F1 Bug bei den VDs bei voller Öffnung, die zur Begrenzung des Ventilöffnungsgrads geführt hat.
möglich, aber martin wollte sich damals nicht dazu äussern.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 05 Januar 2021, 13:22:39
Hallo Frank,

danke für's mit schauen.

Welche VD Firmwares hast Du im Einsatz? Die V1.4 sieht deutlich kritischer aus, als die V2.0.

Zitatdas müsste beim alten hmlan doch auch möglich sein.
Schickt HMLAN Sendequittungen mit Sendetimestamp?
Ich habe aber nicht vor, am HMLAN Modul Änderungen anzufangen, weil ich schon allein keinen Testkandidaten dafür habe.

Zitatich bin geade völlig überrascht, da es seit 10 stunden im cul betrieb noch keinen einzigen miss gegeben hat. der vd hat nun in den vergangenen 48 std drei miss_1 gezeigt. ich habe sogar mit hmuart und hmlan mitgesnifft, um zu sehen, ob wirklich der cul sendet.
Hmm, jetzt weiss ich natürlich noch nicht, ob nur das ACK nicht vom CUL empfangen wurde. Zumindest hast Du nicht so Funkprobleme, wie Jörg sie zu haben scheint, VD agieren, aberi kein Ack.

Zitatdas grundsätzliche prinzip der kommunikation mit den vds funktioniert also schon sehr gut.
Ein guter Hinweis!
So lange das Sendtiming nicht immer mal wieder vom System gestört wird und die"Uhren" im Gleichtakt schlagen, sehe ich das auch so.
Mit dem Browser drauf gucken ist schon eine Störquelle, erst recht, wenn man reglemäßigen Refresh eingestellt hat. Hier https://forum.fhem.de/index.php/topic,117399.0.html (https://forum.fhem.de/index.php/topic,117399.0.html) hat Rudolf gestern abend eine Verbesserung dazu eingebaut.

Die Frage die mich beschäftigt, ist, wie geht es bei mehr Misses am Besten weiter.
Für einen Shift des Sendeintervalls spricht übrigens rein technisch prinzipiell noch, dass das Intervall nur von den 2 unteren Bytes der HMID bestimmt wird. Wenn zwei TCs mit gleichen 2 unteren Bytes in der HMID in Reichweite eines VDs wären, dann würden sie immer mal wieder langsam (je nach Uhrunterschied) gegenseitigstörend "aneinander vorbei ziehen" können. Gleiches gilt für andere regelmäßig sendende devices, wie Temperatursensoren mit gleichen unteren 2 Bytes. Unter der Betrachtung wäre es sinnvoll, wenn ein TC bei fehlenden Acks sein Sendeintervall verschieben würde.

Was passiert, wenn Du msgRed schrittweise erhöst? Mit Deiner anscheined grundsätzlich guten Funkverbindung müssten bei unverändertem Empfangsstartintervall nach Formel auch auch größere msgRed (2+) relativ problemlos funktionieren und ich kann die "Add" Variante beerdigen und nur noch "Shift increase on miss" als Option beibehalten.

Bei meinen RTs funktioniert die leichte Verzögerung und nicht Senden bei Sinnlosigkeit gut und ich hatte die Hoffnung, dass das auch bei VDs besser läuft.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 05 Januar 2021, 17:02:40
Hallo Jörg,

anbei eine neu Version zum Testen.

In der letzten Version ist mir ein Problem beim virtTC Anlauf noch nicht aufgefallen, dass durch die Readingsänderungen entstanden ist.

Wieder nur Module geändert.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 05 Januar 2021, 19:04:46
Hallo Ansgar,

Ich habe hier wieder mit default (S:0, A:0, O:2) gestartet - das führte bei beiden VDs zu einer Miss-Serie bis hin zum Fehlerzustand.
Änderung auf S:1 brachte auch keinen Erfolg, erst mit O:1 läuft es jetzt wieder besser.
Ich beobachte weiter und probiere ggf. noch andere Werte.

P.S. habe FHEMWEB und TcpServerUtils (und nur die) mal geupdated.

Gruß,
Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 05 Januar 2021, 19:37:48
Hallo Jörg,

dann bin ich auf das verbose 2 Log gespannt.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 05 Januar 2021, 21:59:01
Hallo Ansgar,

neues Logfile an gewohnter Stelle.
Ich hatte jetzt teilweise längere Perioden ohne Misses, aber irgendwann fing es dann doch wieder an. Kommt mir fast so vor als würde es nach einer Parameteränderung eine Weile gut laufen und dann auseinanderdriften. Schau mal ob du die Interpretation nachvollziehen kannst.

Gruß,
Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 06 Januar 2021, 10:02:51
Hallo Jörg,

ich kann keinen wirklichen Zusammenhang zwischen Sendetiming und den Misses erkennen, so es denn ein 250ms Empfangsfensters gibt. Auch wenn es es mittig liegt, hätte immer getroffen werden müssen, so die Uhren nicht deutlich unterschiedlich laufen.
Mit jedem Ack sollte der VD eigentlich wieder seinen Empfangszeitpunkt angepasst haben.
Der 2.0er hat wieder die Nase vorn.
Wie war das Positionierverhalten? Sind Änderungen mit jedem neuen Event angekommen, auch wenn es misses waren?

Aus meiner Sicht bleiben Funkprobleme. Wenn's blöd läuft auch nicht mal direkte Kollisionen, sonderen ein anderes Gerät aus Deiner Farm wird so knapp vorher empfangen, dass es nicht mehr zum Rückschalten auf Empfang bis zum "richtigen" reicht.
Leider ist es jetzt wohl nicht so einfach, einen funkstillen Vergleichsraum zu finden und nutzen zu können. Franks Vergleichsdaten sagen aber schon, dass es prinzipiell besser gehen muss.

Hast Du eigentlich nuch einen zweiten CUL? Damit könnte man vergleichen, ob es Unterschiede im Empfang der Acks gibt (sinnvollerweise dann mit differierender Hardware, insbesondere Tranceivermodul).
Ein HM-MOD-RPI-PCB wäre auch eine günstige Möglichkeit mit höchster Diversität bezüglich Hard und Software.
Für Dein Vorhaben ist etwas Ersatzteillager wohl ohnehin erforderlich, oder was ist Dein Plan zur Ausfallsicherheit?

Nach dem Aufstarten auf ein Problem zu schließen ist auch sicherlich ein Fehler. Erst mal müssen die VDs synchronisieren. Am Anfang wird über den restart gar nicht gesendet. Wenn dann beim ersten Senden nicht getroffen wird, ist das Timing eventuell schon raus und der VD muss den Pi erst mal wieder finden.

Von daher würde ich sagen lass mal S:0 A:0 O:2 einen Tag durchlaufen. Und dann S:1 A:0 O:2, dann S:1 A:0 O:4. Nur so wirst Du wohl auf die beste Variante kommen.
Eine Funkverbindung ist immer auch eine Frage von Statistik.

Wo holst Du eigentlich die Uhrzeit für Deinen Pi her? Via NTP von z.B. einer Fritbox, die sie aus der großen freien Welt holt, hoffe ich doch.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: frank am 06 Januar 2021, 16:09:39
meine vds haben alle fw 2.0.

ZitatHmm, jetzt weiss ich natürlich noch nicht, ob nur das ACK nicht vom CUL empfangen wurde.
da bin ich mit 3 unterschiedlichen io, sicher im vorteil. im internal LASTInputDev vom vd habe ich bisher den cul zb noch nicht gesehen, aber hmuart und hmlan. die latenz zum cul über usb vermute ich daher mal deutlich grösser.

@mgernoth ermittelt zb für den hmuart im HMUARTLGW modul alle 15s ein "roundtrip delay", um msgs nicht zu früh zu senden. mein hmuart, der im pi auf dem gpio steckt, zeigt hier ziehmlich konstant knapp 3ms. über lan angebundene hmuarts liegen da so um 6-7ms. für über usb angebundene hmuarts habe ich noch keine daten gesehen.
die latenz des jeweiligen io sehe ich näherungsweise bei halbem roundtrip delay.


ZitatDie Frage die mich beschäftigt, ist, wie geht es bei mehr Misses am Besten weiter.
Für einen Shift des Sendeintervalls spricht übrigens rein technisch prinzipiell noch, dass das Intervall nur von den 2 unteren Bytes der HMID bestimmt wird. Wenn zwei TCs mit gleichen 2 unteren Bytes in der HMID in Reichweite eines VDs wären, dann würden sie immer mal wieder langsam (je nach Uhrunterschied) gegenseitigstörend "aneinander vorbei ziehen" können. Gleiches gilt für andere regelmäßig sendende devices, wie Temperatursensoren mit gleichen unteren 2 Bytes. Unter der Betrachtung wäre es sinnvoll, wenn ein TC bei fehlenden Acks sein Sendeintervall verschieben würde.
nach meinen beobachtungen sind die letzten 2 stellen der 6-stelligen hmid in der regel unterschiedlich, wenn man gleiche devices zusammen kauft. am extremsten sieht es bei mir bei einem 3er pack sec-sd aus: 52BB90,52BB9D,52C4DF.

"überholungen" habe ich aber auch schon bemerkt, haben bei mir aber (bisher?) keine probleme gemacht. ich habe aber noch einen hinweis von dir an martin im ohr, der hier eventuell passt:
Zitat von: noansi am 28 November 2020, 21:07:07
Edit: Ich habe gerade gesehen, dass Du Zeile 426 gelöscht (virtThSens sollten damit wieder laufen) aber nicht nach if ($hash->{helper}{fkt} eq "vdCtrl"){ umgezogen hast. Eventuell erzeugt das mal ein Problem mit zwei laufenden Timern für einen vdCtrl. Das hängt davon ab, ob der erste set für den vdCtrl vor der ersten Ausführung von CUL_HM_valvePosUpdt ausgeführt wird oder werden kann.

allerdings sind es ja immer auch batteriegeräte, die ihren zyklus erst beim einlegen der batterie starten, wodurch sie erst einmal eigentlich nicht zu dicht bei einander liegen sollten. auszuschliessen ist es natürlich nicht.

für ein shift zur "entzerrung", um solche möglichen kollisionen zu umgehen, wäre sicherlich nach einem lost ein guter zeitpunkt. da ist der vd ziehmlich lange wach, vielleicht 10 min, aber jetzt nur geraten.



meine misses, egal von welchem io, sind, geschätzt zu 98%, immer einzelne misses. das darauf folgende meeting ist also in der regel wieder erfolgreich.
die ursache hierfür sehe ich als "zufällig und kurzzeitig" an. zb: fhem freezes, funkkollisionen, verlorene funkmessages durch externe störungen, sendeverzögerungen durch nicht systematische serverdelays, .... .
"ständig wechselnde" shifts von meeting zu meeting bei aufeinander folgenden misses halte ich daher für nicht so zielführend.

die verbleibenden 2% misses sind da schon interessanter.
davon sind die meisten 2-fache misses. je mehr misses aufeinander folgen, desto seltener. am seltensten sind fehler von miss_1 bis lost.
das schlechteste scenario ist sicherlich, wenn der vd sich bei einer zufällig verzögerten msg, die garade noch ins fenster trifft, synchronisiert und das ack nicht in fhem ankommt. je grösser das fenster zu diesem meeting war, um so fataler das ergebnis.
im letzten versuch vor lost könnte man vielleicht noch versuchen, die msg mehrfach zu senden. so eine art "streufeuer".  8)



ein echter tc kann bis zu 4 vd betreiben, muss also auch damit klar kommen.
apropo "sinn der ack vom vd": der tc zeigt im display funkstörungen zu den vd an, wenn die acks zu lange ausbleiben. wenn zur vollen stunde eine funkstörung zu einem vd vorliegt, piept er sogar ein paar mal.


ps: ich habe gerade festgestellt, dass es auch noch ein bug geben muss, siehe screenshot.
der letzte miss_1 ist viel zu lang, fast 5min. eventuell wird hier der miss zähler nicht auf 2 gestellt. das scheint auch häufiger zu passieren.


gruss frank
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 06 Januar 2021, 18:58:09
Hallo Frank,

danke für Deine Zusatzinfos.
msgReduce=2 steht ja über Deinem Graphen.

Zitatps: ich habe gerade festgestellt, dass es auch noch ein bug geben muss, siehe screenshot.
der letzte miss_1 ist viel zu lang, fast 5min. eventuell wird hier der miss zähler nicht auf 2 gestellt. das scheint auch häufiger zu passieren.
Kann das eventuell ein Problem/Nebenwirkung bei Deiner Auswertung unter Berücksichtigung von msgReduce sein, wenn zwischendurch mal ein neuer Stellwert an den VD geschickt wird? Der würde ja gesendet und damit der miss "zu früh" zurück gesetzt.
Ist an den Stellen, wo Daten dazwischen sein müßten, auch etwas?
Edit: beim msgRepeat msgReduce miss wird der miss Zähler intern zwar höher gezählt, aber nicht da Reading valveCtrl aktualisiert, dass Du ja für das Log nutzt. Ist ja auch ein gewollter miss und kein funkabhängiger.

Zitatdie latenz des jeweiligen io sehe ich näherungsweise bei halbem roundtrip delay.
Wenn der Pi nicht gerade busy ist, dann wird die Annahme wohl auch stimmen.

Zur Zeitmessung des tatsächlichen Sendezeitpunktes aber leider mit Busy-Unsicherheit behaftet. Anfangs habe ich auch mal versucht, Standard-culfw das Antworttiming auf FHEM-Seite zu verbessern. Hat auch was gebracht, aber nicht zufriedenstellend.

ZitatEventuell erzeugt das mal ein Problem mit zwei laufenden Timern für einen vdCtrl.
Ja, hat sich aber erledigt, weil ich zu dem Zeitpunkt den VD nur am Rande betrachtet hatte und damit bei den Timern die heilende Auswirkungen des removes beim restart nicht übersehen hatte.

Zitatfür ein shift zur "entzerrung", um solche möglichen kollisionen zu umgehen, wäre sicherlich nach einem lost ein guter zeitpunkt. da ist der vd ziehmlich lange wach, vielleicht 10 min, aber jetzt nur geraten.
Dafür würde mich ja mal ein Log eines realen TC interessieren, bei dessen VD die Batterien entfernt werden.
Das Empfangsfenster entsprechend Deinem link so weit aufzureißen bringt ja eigentlich auch nur was, wenn ein extremer Gangunterschied zu einem Zustand, bei dem nur jede zweite Übertragung überhaupt erfolgreich ist, zu erwarten ist. Für den Betrieb von 4 VDs an einem TC wäre das vielleicht eine Überlegung gewesen (aber wenn der TC in seinem Zyklus bleibt, können die VDs auch auf jede ventilrelevante message vom TC synchronisieren, auch wenn sie für einen anderen der 4 VDs gedacht ist).

Zitat"ständig wechselnde" shifts von meeting zu meeting bei aufeinander folgenden misses halte ich daher für nicht so zielführend.
Davon bin ich im Grunde auch schon ab. Dafür aber ein bischen shift.

Für das Sendtiming könnte ich übrigens auch die Möglichkeit nutzen im Rahmen der verfügbaren Sendpuffer und des genuzten timer-ranges auf dem tscul zu einem bestimmten Zeitpunkt zu senden. Nur wäre das direkt voll inkompatibel zu HMLAN, etc., da der Sendezeipunkt mit in die Sendemessage an das IOs rein müßte.

Zitatim letzten versuch vor lost könnte man vielleicht noch versuchen, die msg mehrfach zu senden. so eine art "streufeuer".
Auch eine gute Idee.
Wenn das Problem ist, dass der Ack nicht zuverlässig empfangen werden kann, hilft das ziellos auch nicht weiter.
Man könnte versuchen mit größeren shifts zu arbeiten und zum lost zu allen infrage kommenden Intervallfortsetzungspunkten zu senden, zu denen nur eine VD Antwort nicht empfangen wurde.
Das macht aber erst Sinn, wenn man sicher weiß, wie sich das Empfangsfenster vergrößert. Symetrisch oder asymetrisch.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 06 Januar 2021, 21:05:58
Hallo Ansgar,

Zitat
Wie war das Positionierverhalten? Sind Änderungen mit jedem neuen Event angekommen, auch wenn es misses waren?
Soweit ich es mitbekommen habe, ist die neue Ventileinstellung üblicherweise trotz "miss" vom VD übernommen worden.

Zitat
Hast Du eigentlich noch einen zweiten CUL? Damit könnte man vergleichen, ob es Unterschiede im Empfang der Acks gibt (sinnvollerweise dann mit differierender Hardware, insbesondere Tranceivermodul).
Hab mir jetzt mal einen zweiten aufgebaut (und zwar so, dass ich Nano und CC1101 stecken, also ggf. austauschen kann).  Der läuft jetzt allerdings mit der kleinen Spiralantenne, verhält sich aber ähnlich bis schlechter. Das CC1101 Modul schaut aber ziemlich baugleich aus. Ich hab mir jetzt mal spasshalber welche bestellt die etwas anders aussehen (in rot). Aber dazu mehr in 1-2 Monaten :).
Meine "echte" CCU ist ja ein HM-MOD-RPI-PCB unter piVCCU - da habe ich durchaus auch 1-2 Devices am Tag die "Kommunikation gestört" melden. Das sind oft aber die selben Geräte und teilweise nachvollziehbar, weil die ungünstig platziert sind. Da hab ich schon viel mit einem Repeater verbessern können.

Zitat
Wo holst Du eigentlich die Uhrzeit für Deinen Pi her? Via NTP von z.B. einer Fritbox, die sie aus der großen freien Welt holt, hoffe ich doch.
Standard Raspian Einstellung - irgend so ein Debian NTP Server.

Wahrscheinlich sollte ich wirklich etwas länger warten. Wenn ich sehe das er in einer Einstellung bis miss=10 oder mehr hochzählt, denke ich mir halt: Ok, das war wohl nichts, probieren wir was anderes.

Gruß,
Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 06 Januar 2021, 23:02:33
Hallo Jörg,

ZitatHab mir jetzt mal einen zweiten aufgebaut (und zwar so, dass ich Nano und CC1101 stecken, also ggf. austauschen kann).
Dann schließ beide am Pi an. Den 2. auch in die IOList der VCCU. Dann beide auf verbose 4. Mal schauen, wo ein Ack ankommt.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: frank am 07 Januar 2021, 13:37:18
hallo ansgar,

Zitat
Zitatps: ich habe gerade festgestellt, dass es auch noch ein bug geben muss, siehe screenshot.
    der letzte miss_1 ist viel zu lang, fast 5min. eventuell wird hier der miss zähler nicht auf 2 gestellt. das scheint auch häufiger zu passieren.

Kann das eventuell ein Problem/Nebenwirkung bei Deiner Auswertung unter Berücksichtigung von msgReduce sein, wenn zwischendurch mal ein neuer Stellwert an den VD geschickt wird? Der würde ja gesendet und damit der miss "zu früh" zurück gesetzt.
Ist an den Stellen, wo Daten dazwischen sein müßten, auch etwas?
Edit: beim msgRepeat miss wird der miss Zähler intern zwar höher gezählt, aber nicht da Reading valveCtrl aktualisiert, dass Du ja für das Log nutzt. Ist ja auch ein gewollter miss und kein funkabhängiger.

das log zeigt auch, dass ausgelassen wurde. eigentlich sollte nach miss grundsätzlich nicht ausgelassen werden. na gut.
mitte märz 2020 gab es das phänomen jedenfalls auch schon.

2021.01.06 12:53:48.809 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:85771470 d:FF r:FFD8     m:87 A258 B3B3B3 193A9A 03DE
2021.01.06 12:53:48.818 0: HMUARTLGW hmuart1 recv: 01 05 00 00 0E msg: 87 A2 58 B3B3B3 193A9A 03DE
2021.01.06 12:53:48.969 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:857714F3 d:FF r:FFC2     m:87 8202 193A9A B3B3B3 0101BC203E
2021.01.06 12:53:48.972 0: HMUARTLGW hmuart1 recv: 01 05 00 00 41 msg: 87 82 02 193A9A B3B3B3 0101BC203E

2021.01.06 12:56:28.992 0: HMUARTLGW hmuart1 recv: 01 05 00 00 0E msg: 88 A2 58 B3B3B3 193A9A 03D7
hmlan hat cul nicht gehört?
miss

2021.01.06 12:58:54.960 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:857BC07D d:FF r:FFD9     m:89 A258 B3B3B3 193A9A 03CF
2021.01.06 12:58:54.967 0: HMUARTLGW hmuart1 recv: 01 05 00 00 0E msg: 89 A2 58 B3B3B3 193A9A 03CF
2021.01.06 12:58:55.118 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:857BC100 d:FF r:FFC3     m:89 8202 193A9A B3B3B3 0101BC223E
2021.01.06 12:58:55.121 0: HMUARTLGW hmuart1 recv: 01 05 00 00 41 msg: 89 82 02 193A9A B3B3B3 0101BC223E

2021.01.06 13:01:06.394 0: HMUARTLGW hmuart1 recv: 01 05 00 00 0E msg: 8A A2 58 B3B3B3 193A9A 03C7
2021.01.06 13:01:06.402 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:857DC207 d:FF r:FFD8     m:8A A258 B3B3B3 193A9A 03C7
miss

2021.01.06 13:04:07.344 0: HMUARTLGW hmuart1 recv: 01 05 00 00 0E msg: 8B A2 58 B3B3B3 193A9A 03C0
2021.01.06 13:04:07.352 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:858084F3 d:FF r:FFD9     m:8B A258 B3B3B3 193A9A 03C0
2021.01.06 13:04:07.500 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:85808576 d:FF r:FFC3     m:8B 8202 193A9A B3B3B3 0101BC223E
2021.01.06 13:04:07.504 0: HMUARTLGW hmuart1 recv: 01 05 00 00 41 msg: 8B 82 02 193A9A B3B3B3 0101BC223E

msg 8C ausgelassen

2021.01.06 13:09:26.000 0: HMUARTLGW hmuart1 recv: 01 05 00 00 0E msg: 8D A2 58 B3B3B3 193A9A 03B8
2021.01.06 13:09:26.006 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:858561DB d:FF r:FFD8     m:8D A258 B3B3B3 193A9A 03B8
2021.01.06 13:09:26.164 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:8585625D d:FF r:FFC3     m:8D 8202 193A9A B3B3B3 0101BC2241
2021.01.06 13:09:26.167 0: HMUARTLGW hmuart1 recv: 01 05 00 00 44 msg: 8D 82 02 193A9A B3B3B3 0101BC2241

2021.01.06 13:11:43.735 0: HMUARTLGW hmuart1 recv: 01 05 00 00 0E msg: 8E A2 58 B3B3B3 193A9A 03AE
2021.01.06 13:11:43.743 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:85877BD4 d:FF r:FFD8     m:8E A258 B3B3B3 193A9A 03AE
miss

msg 8F ausgelassen

2021.01.06 13:16:39.886 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:858C00D1 d:FF r:FFD8     m:90 A258 B3B3B3 193A9A 03A6
2021.01.06 13:16:39.895 0: HMUARTLGW hmuart1 recv: 01 05 00 00 0E msg: 90 A2 58 B3B3B3 193A9A 03A6
2021.01.06 13:16:40.035 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:858C0154 d:FF r:FFC3     m:90 8202 193A9A B3B3B3 0101BC223F
2021.01.06 13:16:40.039 0: HMUARTLGW hmuart1 recv: 01 05 00 00 42 msg: 90 82 02 193A9A B3B3B3 0101BC223F




ZitatDafür würde mich ja mal ein Log eines realen TC interessieren, bei dessen VD die Batterien entfernt werden.
Das Empfangsfenster entsprechend Deinem link so weit aufzureißen bringt ja eigentlich auch nur was, wenn ein extremer Gangunterschied zu einem Zustand, bei dem nur jede zweite Übertragung überhaupt erfolgreich ist, zu erwarten ist. Für den Betrieb von 4 VDs an einem TC wäre das vielleicht eine Überlegung gewesen (aber wenn der TC in seinem Zyklus bleibt, können die VDs auch auf jede ventilrelevante message vom TC synchronisieren, auch wenn sie für einen anderen der 4 VDs gedacht ist).

hier mal ein sniff eines realen tc mit einem virtuellen vd gepeert (inkl events des vvd).
batterien habe ich mit "attr dummy 1" entfernt, steht im log.  ;)
12:29:?? => 10 min nach dem ersten ausbleiben des ack war die gestörte verbindung im display erkennbar.
13:00:00 => hat der tc gepiept.
nach ner guten stunde wieder batterien rein => die displayinfo nach dem ersten ack wieder weg.

2021.01.07 12:11:01.801 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 41 msg: F7 86 70 20DFE1 000000 00CE31
2021.01.07 12:11:01.805 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A766E4E d:FF r:FFCA     m:F7 8670 20DFE1 000000 00CE31
2021.01.07 12:11:21.897 0 : HMLAN_Send:  hmlan1 S:SDC8B4040 stat:  00 t:00000000 d:01 r:DC8B4040 m:F7 8002 C1C1C1 20DFE1 0101960000
2021-01-07 12:11:21.958 CUL_HM virt_vd ValveDesired: 75
2021-01-07 12:11:21.958 CUL_HM virt_vd commState: CMDs_done
2021-01-07 12:11:21.958 CUL_HM virt_vd CMDs_done
2021-01-07 12:11:21.958 CUL_HM virt_vd set_75
2021-01-07 12:11:21.990 CUL_HM virt_vd_Btn1 ValveAdjCmd: 00
2021-01-07 12:11:21.990 CUL_HM virt_vd_Btn1 ValvePosition: 75 %
2021.01.07 12:11:21.992 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 41 msg: F7 A2 58 20DFE1 C1C1C1 00C1
2021.01.07 12:11:21.996 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 29 msg: F7 80 02 C1C1C1 20DFE1 0101960000
2021.01.07 12:11:22.002 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A76BC71 d:FF r:FFCB     m:F7 A258 20DFE1 C1C1C1 00C1
2021.01.07 12:11:22.005 0 : HMLAN_Parse: hmlan1 R:RDC8B4040 stat:0002 t:00000000 d:FF r:7FFF     m:F7 8002 C1C1C1 20DFE1 0101960000
2021.01.07 12:13:15.478 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A7877E0 d:FF r:FFCA     m:F8 8670 20DFE1 000000 00CD31
2021.01.07 12:13:15.483 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 42 msg: F8 86 70 20DFE1 000000 00CD31
2021.01.07 12:13:35.404 0 : HMLAN_Send:  hmlan1 S:SDC8D49C8 stat:  00 t:00000000 d:01 r:DC8D49C8 m:F8 8002 C1C1C1 20DFE1 0101960000
2021-01-07 12:13:35.467 CUL_HM virt_vd ValveDesired: 75
2021-01-07 12:13:35.467 CUL_HM virt_vd commState: CMDs_done
2021-01-07 12:13:35.467 CUL_HM virt_vd CMDs_done
2021-01-07 12:13:35.467 CUL_HM virt_vd set_75
2021-01-07 12:13:35.500 CUL_HM virt_vd_Btn1 ValveAdjCmd: 00
2021-01-07 12:13:35.500 CUL_HM virt_vd_Btn1 ValvePosition: 75 %
2021.01.07 12:13:35.504 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A78C603 d:FF r:FFCA     m:F8 A258 20DFE1 C1C1C1 00C1
2021.01.07 12:13:35.507 0 : HMLAN_Parse: hmlan1 R:RDC8D49C8 stat:0002 t:00000000 d:FF r:7FFF     m:F8 8002 C1C1C1 20DFE1 0101960000
2021.01.07 12:13:35.514 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 43 msg: F8 A2 58 20DFE1 C1C1C1 00C1
2021.01.07 12:13:35.518 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 29 msg: F8 80 02 C1C1C1 20DFE1 0101960000
2021.01.07 12:16:18.315 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 40 msg: F9 86 70 20DFE1 000000 00CD31
2021.01.07 12:16:18.320 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A7B42D6 d:FF r:FFCA     m:F9 8670 20DFE1 000000 00CD31
2021.01.07 12:16:38.410 0 : HMLAN_Send:  hmlan1 S:SDC90149F stat:  00 t:00000000 d:01 r:DC90149F m:F9 8002 C1C1C1 20DFE1 0101960000
2021-01-07 12:16:38.469 CUL_HM virt_vd ValveDesired: 75
2021-01-07 12:16:38.469 CUL_HM virt_vd commState: CMDs_done
2021-01-07 12:16:38.469 CUL_HM virt_vd CMDs_done
2021-01-07 12:16:38.469 CUL_HM virt_vd set_75
2021-01-07 12:16:38.501 CUL_HM virt_vd_Btn1 ValveAdjCmd: 00
2021-01-07 12:16:38.501 CUL_HM virt_vd_Btn1 ValvePosition: 75 %
2021.01.07 12:16:38.503 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A7B90F9 d:FF r:FFC9     m:F9 A258 20DFE1 C1C1C1 00C1
2021.01.07 12:16:38.507 0 : HMLAN_Parse: hmlan1 R:RDC90149F stat:0002 t:00000000 d:FF r:7FFF     m:F9 8002 C1C1C1 20DFE1 0101960000
2021.01.07 12:16:38.513 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 3F msg: F9 A2 58 20DFE1 C1C1C1 00C1
2021.01.07 12:16:38.516 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 29 msg: F9 80 02 C1C1C1 20DFE1 0101960000
2021-01-07 12:16:55.105 Global global ATTR virt_vd dummy 1
2021.01.07 12:19:07.113 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A7DD620 d:FF r:FFCA     m:FA 8670 20DFE1 000000 00CD31
2021.01.07 12:19:07.128 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 40 msg: FA 86 70 20DFE1 000000 00CD31
2021-01-07 12:19:27.109 CUL_HM virt_vd ValveDesired: 75
2021-01-07 12:19:27.109 CUL_HM virt_vd commState: CMDs_done_Errors:1
2021-01-07 12:19:27.109 CUL_HM virt_vd CMDs_done_Errors:1
2021-01-07 12:19:27.109 CUL_HM virt_vd dummy
2021-01-07 12:19:27.109 CUL_HM virt_vd set_75
2021-01-07 12:19:27.136 CUL_HM virt_vd_Btn1 ValveAdjCmd: 00
2021-01-07 12:19:27.136 CUL_HM virt_vd_Btn1 ValvePosition: 75 %
2021.01.07 12:19:27.138 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 41 msg: FA A2 58 20DFE1 C1C1C1 00C1
2021.01.07 12:19:27.141 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A7E2443 d:FF r:FFCA     m:FA A258 20DFE1 C1C1C1 00C1
2021.01.07 12:21:41.336 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 3F msg: FB 86 70 20DFE1 000000 00CD31
2021.01.07 12:21:41.343 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A8030C4 d:FF r:FFC9     m:FB 8670 20DFE1 000000 00CD31
2021-01-07 12:22:01.360 CUL_HM virt_vd ValveDesired: 75
2021-01-07 12:22:01.360 CUL_HM virt_vd commState: CMDs_done_Errors:1
2021-01-07 12:22:01.360 CUL_HM virt_vd CMDs_done_Errors:1
2021-01-07 12:22:01.360 CUL_HM virt_vd dummy
2021-01-07 12:22:01.360 CUL_HM virt_vd set_75
2021-01-07 12:22:01.390 CUL_HM virt_vd_Btn1 ValveAdjCmd: 00
2021-01-07 12:22:01.390 CUL_HM virt_vd_Btn1 ValvePosition: 75 %
2021.01.07 12:22:01.391 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A807EE6 d:FF r:FFCA     m:FB A258 20DFE1 C1C1C1 00C1
2021.01.07 12:22:01.395 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 3F msg: FB A2 58 20DFE1 C1C1C1 00C1
2021.01.07 12:24:01.085 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 3E msg: FC 86 70 20DFE1 000000 00CD31
2021.01.07 12:24:01.089 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A8252C1 d:FF r:FFCA     m:FC 8670 20DFE1 000000 00CD31
2021-01-07 12:24:21.115 CUL_HM virt_vd ValveDesired: 75
2021-01-07 12:24:21.115 CUL_HM virt_vd commState: CMDs_done_Errors:1
2021-01-07 12:24:21.115 CUL_HM virt_vd CMDs_done_Errors:1
2021-01-07 12:24:21.115 CUL_HM virt_vd dummy
2021-01-07 12:24:21.115 CUL_HM virt_vd set_75
2021-01-07 12:24:21.142 CUL_HM virt_vd_Btn1 ValveAdjCmd: 00
2021-01-07 12:24:21.142 CUL_HM virt_vd_Btn1 ValvePosition: 75 %
2021.01.07 12:24:21.144 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A82A0E3 d:FF r:FFC9     m:FC A258 20DFE1 C1C1C1 00C1
2021.01.07 12:24:21.147 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 3F msg: FC A2 58 20DFE1 C1C1C1 00C1
2021.01.07 12:25:17.680 3 : CUL_HM set Thermostat.OZ_Climate desired-temp 22.5
2021.01.07 12:25:17.718 0 : HMUARTLGW hmuart1 send: 01 0620DFE1000100
2021.01.07 12:25:17.738 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A837DA5 d:FF r:FFC9     m:FD A410 20DFE1 1ACE1F 06022D00000000
2021.01.07 12:25:17.746 0 : HMUARTLGW hmuart1 recv: 01 05 01 00 3F msg: FD A4 10 20DFE1 1ACE1F 06022D00000000
2021.01.07 12:25:17.750 0 : HMUARTLGW hmuart1 added peer: 20DFE1, aesChannels: FFFFFFFFFFFFFFFF
2021.01.07 12:25:17.753 0 : HMUARTLGW hmuart1 send: 01 0620DFE1000100
2021.01.07 12:25:17.761 0 : HMUARTLGW hmuart1 added peer: 20DFE1, aesChannels: FFFFFFFFFFFFFFFF
2021.01.07 12:26:06.630 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A843D11 d:FF r:FFC9     m:FD 8670 20DFE1 000000 00CD31
2021.01.07 12:26:06.686 0 : HMUARTLGW hmuart1 send: 01 02 00 00 00 msg: FE A1 12 1ACE1F 20DFE1
2021.01.07 12:26:06.716 0 : HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:8A843D8B d:FF r:FFD3     m:18 A112 1ACE1F 20DFE1
2021.01.07 12:26:06.744 0 : HMUARTLGW hmuart1 send: 01 02 00 00 00 msg: FE A1 12 1ACE1F 20DFE1
2021.01.07 12:26:06.802 0 : HMUARTLGW hmuart1 send: 01 02 00 00 00 msg: FE A1 12 1ACE1F 20DFE1
2021.01.07 12:26:06.839 0 : HMUARTLGW hmuart1 recv: 01 05 10 00 3F msg: FD 86 70 20DFE1 000000 00CD31
2021.01.07 12:26:06.846 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A843E0B d:FF r:FFC9     m:18 8002 20DFE1 1ACE1F 00
2021.01.07 12:26:06.933 0 : HMUARTLGW hmuart1 send: 01 02 00 00 00 msg: FE A1 12 1ACE1F 20DFE1
2021.01.07 12:26:06.983 0 : HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:8A843E96 d:FF r:FFD3     m:FE A112 1ACE1F 20DFE1
2021.01.07 12:26:07.108 0 : HMUARTLGW hmuart1 recv: 01 04 03 00 3F msg: FE 80 02 20DFE1 1ACE1F 00
2021.01.07 12:26:07.112 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A843F15 d:FF r:FFC9     m:FE 8002 20DFE1 1ACE1F 00
2021.01.07 12:26:07.205 0 : HMUARTLGW hmuart1 send: 01 02 00 00 00 msg: FE A1 12 1ACE1F 20DFE1
2021.01.07 12:26:07.315 0 : HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:8A843F9F d:FF r:FFD3     m:FE A112 1ACE1F 20DFE1
2021.01.07 12:26:07.401 0 : HMUARTLGW hmuart1 recv: 01 04 03 00 3F msg: FE 80 02 20DFE1 1ACE1F 00
2021.01.07 12:26:07.412 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A84401F d:FF r:FFC9     m:FE 8002 20DFE1 1ACE1F 00
2021.01.07 12:26:07.493 0 : HMUARTLGW hmuart1 send: 01 02 00 00 00 msg: FF A0 11 1ACE1F 20DFE1 02022D
2021.01.07 12:26:07.532 0 : HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:8A8440BB d:FF r:FFD3     m:FF A011 1ACE1F 20DFE1 02022D
2021.01.07 12:26:07.727 0 : HMUARTLGW hmuart1 recv: 01 04 03 00 3F msg: FF 80 02 20DFE1 1ACE1F 01022D0048
2021.01.07 12:26:07.731 0 : HMUARTLGW hmuart1 send: 01 0620DFE1000000
2021.01.07 12:26:07.735 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A84413B d:FF r:FFC9     m:FF 8002 20DFE1 1ACE1F 01022D0048
2021.01.07 12:26:07.742 0 : HMUARTLGW hmuart1 added peer: 20DFE1, aesChannels: FFFFFFFFFFFFFFFF
2021.01.07 12:26:07.746 0 : HMUARTLGW hmuart1 send: 01 0620DFE1000000
2021.01.07 12:26:07.755 0 : HMUARTLGW hmuart1 added peer: 20DFE1, aesChannels: FFFFFFFFFFFFFFFF
2021-01-07 12:26:26.687 CUL_HM virt_vd ValveDesired: 75
2021-01-07 12:26:26.687 CUL_HM virt_vd commState: CMDs_done_Errors:1
2021-01-07 12:26:26.687 CUL_HM virt_vd CMDs_done_Errors:1
2021-01-07 12:26:26.687 CUL_HM virt_vd dummy
2021-01-07 12:26:26.687 CUL_HM virt_vd set_75
2021-01-07 12:26:26.722 CUL_HM virt_vd_Btn1 ValveAdjCmd: 00
2021-01-07 12:26:26.722 CUL_HM virt_vd_Btn1 ValvePosition: 75 %
2021.01.07 12:26:26.724 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A848B34 d:FF r:FFCA     m:FD A258 20DFE1 C1C1C1 00C1
2021.01.07 12:26:26.730 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 3F msg: FD A2 58 20DFE1 C1C1C1 00C1
2021.01.07 12:29:01.597 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 3E msg: FE 86 70 20DFE1 000000 00CD31
2021.01.07 12:29:01.601 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A86E8C7 d:FF r:FFC9     m:FE 8670 20DFE1 000000 00CD31
2021-01-07 12:29:21.678 CUL_HM virt_vd ValveDesired: 100
2021-01-07 12:29:21.678 CUL_HM virt_vd commState: CMDs_done_Errors:1
2021-01-07 12:29:21.678 CUL_HM virt_vd CMDs_done_Errors:1
2021-01-07 12:29:21.678 CUL_HM virt_vd dummy
2021-01-07 12:29:21.678 CUL_HM virt_vd set_100
2021-01-07 12:29:21.703 CUL_HM virt_vd_Btn1 ValveAdjCmd: 00
2021-01-07 12:29:21.703 CUL_HM virt_vd_Btn1 ValvePosition: 100 %
2021.01.07 12:29:21.705 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 3E msg: FE A2 58 20DFE1 C1C1C1 00FF
2021.01.07 12:29:21.708 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A8736EA d:FF r:FFC9     m:FE A258 20DFE1 C1C1C1 00FF
2021.01.07 12:31:42.258 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A895BD6 d:FF r:FFC2     m:FF 8670 20DFE1 000000 00CE31
2021.01.07 12:31:42.264 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 3F msg: FF 86 70 20DFE1 000000 00CE31
2021-01-07 12:32:02.132 CUL_HM virt_vd ValveDesired: 100
2021-01-07 12:32:02.132 CUL_HM virt_vd commState: CMDs_done_Errors:1
2021-01-07 12:32:02.132 CUL_HM virt_vd CMDs_done_Errors:1
2021-01-07 12:32:02.132 CUL_HM virt_vd dummy
2021-01-07 12:32:02.132 CUL_HM virt_vd set_100
2021-01-07 12:32:02.161 CUL_HM virt_vd_Btn1 ValveAdjCmd: 00
2021-01-07 12:32:02.161 CUL_HM virt_vd_Btn1 ValvePosition: 100 %
2021.01.07 12:32:02.163 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 3F msg: FF A2 58 20DFE1 C1C1C1 00FF
2021.01.07 12:32:02.166 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A89A9F8 d:FF r:FFC2     m:FF A258 20DFE1 C1C1C1 00FF
2021.01.07 12:34:08.506 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 3F msg: 00 86 70 20DFE1 000000 00CF31
2021.01.07 12:34:08.512 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A8B9738 d:FF r:FFC1     m:00 8670 20DFE1 000000 00CF31
2021-01-07 12:34:28.422 CUL_HM virt_vd ValveDesired: 100
2021-01-07 12:34:28.422 CUL_HM virt_vd commState: CMDs_done_Errors:1
2021-01-07 12:34:28.422 CUL_HM virt_vd CMDs_done_Errors:1
2021-01-07 12:34:28.422 CUL_HM virt_vd dummy
2021-01-07 12:34:28.422 CUL_HM virt_vd set_100
2021-01-07 12:34:28.463 CUL_HM virt_vd_Btn1 ValveAdjCmd: 00
2021-01-07 12:34:28.463 CUL_HM virt_vd_Btn1 ValvePosition: 100 %
2021.01.07 12:34:28.465 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 3F msg: 00 A2 58 20DFE1 C1C1C1 00FF
2021.01.07 12:34:28.469 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A8BE55A d:FF r:FFC1     m:00 A258 20DFE1 C1C1C1 00FF
2021.01.07 12:37:04.478 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A8E46D5 d:FF r:FFC1     m:01 8670 20DFE1 000000 00D031
2021.01.07 12:37:04.482 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 3C msg: 01 86 70 20DFE1 000000 00D031
2021-01-07 12:37:24.416 CUL_HM virt_vd ValveDesired: 100
2021-01-07 12:37:24.416 CUL_HM virt_vd commState: CMDs_done_Errors:1
2021-01-07 12:37:24.416 CUL_HM virt_vd CMDs_done_Errors:1
2021-01-07 12:37:24.416 CUL_HM virt_vd dummy
2021-01-07 12:37:24.416 CUL_HM virt_vd set_100
2021-01-07 12:37:24.452 CUL_HM virt_vd_Btn1 ValveAdjCmd: 00
2021-01-07 12:37:24.452 CUL_HM virt_vd_Btn1 ValvePosition: 100 %
2021.01.07 12:37:24.483 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A8E94F7 d:FF r:FFC2     m:01 A258 20DFE1 C1C1C1 00FF
2021.01.07 12:37:24.498 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 3C msg: 01 A2 58 20DFE1 C1C1C1 00FF
2021.01.07 12:39:46.196 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A90BEC5 d:FF r:FFC0     m:02 8670 20DFE1 000000 00D131
2021.01.07 12:39:46.200 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 3C msg: 02 86 70 20DFE1 000000 00D131
2021-01-07 12:40:06.151 CUL_HM virt_vd ValveDesired: 100
2021-01-07 12:40:06.151 CUL_HM virt_vd commState: CMDs_done_Errors:1
2021-01-07 12:40:06.151 CUL_HM virt_vd CMDs_done_Errors:1
2021-01-07 12:40:06.151 CUL_HM virt_vd dummy
2021-01-07 12:40:06.151 CUL_HM virt_vd set_100
2021-01-07 12:40:06.182 CUL_HM virt_vd_Btn1 ValveAdjCmd: 00
2021-01-07 12:40:06.182 CUL_HM virt_vd_Btn1 ValvePosition: 100 %
2021.01.07 12:40:06.184 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 3C msg: 02 A2 58 20DFE1 C1C1C1 00FF
2021.01.07 12:40:06.187 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A910CE8 d:FF r:FFC0     m:02 A258 20DFE1 C1C1C1 00FF
2021.01.07 12:42:13.519 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 3C msg: 03 86 70 20DFE1 000000 00D130
2021.01.07 12:42:13.523 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A92FE11 d:FF r:FFBE     m:03 8670 20DFE1 000000 00D130
2021-01-07 12:42:33.416 CUL_HM virt_vd ValveDesired: 100
2021-01-07 12:42:33.416 CUL_HM virt_vd commState: CMDs_done_Errors:1
2021-01-07 12:42:33.416 CUL_HM virt_vd CMDs_done_Errors:1
2021-01-07 12:42:33.416 CUL_HM virt_vd dummy
2021-01-07 12:42:33.416 CUL_HM virt_vd set_100
2021-01-07 12:42:33.442 CUL_HM virt_vd_Btn1 ValveAdjCmd: 00
2021-01-07 12:42:33.442 CUL_HM virt_vd_Btn1 ValvePosition: 100 %
2021.01.07 12:42:33.444 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 3C msg: 03 A2 58 20DFE1 C1C1C1 00FF
2021.01.07 12:42:33.448 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A934C33 d:FF r:FFBF     m:03 A258 20DFE1 C1C1C1 00FF
2021.01.07 12:44:26.199 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 3B msg: 04 86 70 20DFE1 000000 00D230
2021.01.07 12:44:26.202 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A9504B4 d:FF r:FFAD     m:04 8670 20DFE1 000000 00D230
2021.01.07 12:44:31.433 3 : CUL_HM set Thermostat.OZ_Climate desired-temp 16.0
2021.01.07 12:44:31.458 0 : HMUARTLGW hmuart1 send: 01 0620DFE1000100
2021.01.07 12:44:31.474 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A95193B d:FF r:FFBD     m:05 A410 20DFE1 1ACE1F 06022000000000
2021.01.07 12:44:31.478 0 : HMUARTLGW hmuart1 recv: 01 05 01 00 3D msg: 05 A4 10 20DFE1 1ACE1F 06022000000000
2021.01.07 12:44:31.985 0 : HMUARTLGW hmuart1 send: 01 0620DFE1000100
2021.01.07 12:44:31.994 0 : HMUARTLGW hmuart1 added peer: 20DFE1, aesChannels: FFFFFFFFFFFFFFFF
2021.01.07 12:44:31.998 0 : HMUARTLGW hmuart1 send: 01 0620DFE1000100
2021.01.07 12:44:32.005 0 : HMUARTLGW hmuart1 added peer: 20DFE1, aesChannels: FFFFFFFFFFFFFFFF
2021-01-07 12:44:46.195 CUL_HM virt_vd ValveDesired: 100
2021-01-07 12:44:46.195 CUL_HM virt_vd commState: CMDs_done_Errors:1
2021-01-07 12:44:46.195 CUL_HM virt_vd CMDs_done_Errors:1
2021-01-07 12:44:46.195 CUL_HM virt_vd dummy
2021-01-07 12:44:46.195 CUL_HM virt_vd set_100
2021-01-07 12:44:46.221 CUL_HM virt_vd_Btn1 ValveAdjCmd: 00
2021-01-07 12:44:46.221 CUL_HM virt_vd_Btn1 ValvePosition: 100 %
2021.01.07 12:44:46.223 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A9552D7 d:FF r:FFBD     m:04 A258 20DFE1 C1C1C1 00FF
2021.01.07 12:44:46.263 0 : HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:8A955352 d:FF r:FFD3     m:0A A112 1ACE1F 20DFE1
2021.01.07 12:44:46.543 0 : HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:8A95546A d:FF r:FFD3     m:0A A112 1ACE1F 20DFE1
2021.01.07 12:44:46.630 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 3C msg: 04 A2 58 20DFE1 C1C1C1 00FF
2021.01.07 12:44:46.694 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A9554EA d:FF r:FFBD     m:0A 8002 20DFE1 1ACE1F 00
2021.01.07 12:44:46.762 0 : HMUARTLGW hmuart1 send: 01 02 00 00 00 msg: 0B A0 11 1ACE1F 20DFE1 020220
2021.01.07 12:44:46.812 0 : HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:8A955577 d:FF r:FFD3     m:0B A011 1ACE1F 20DFE1 020220
2021.01.07 12:44:46.966 0 : HMUARTLGW hmuart1 recv: 01 04 03 00 3D msg: 0B 80 02 20DFE1 1ACE1F 0102200047
2021.01.07 12:44:46.968 0 : HMUARTLGW hmuart1 send: 01 0620DFE1000000
2021.01.07 12:44:46.972 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A9555F7 d:FF r:FFBD     m:0B 8002 20DFE1 1ACE1F 0102200047
2021.01.07 12:44:46.976 0 : HMUARTLGW hmuart1 added peer: 20DFE1, aesChannels: FFFFFFFFFFFFFFFF
2021.01.07 12:44:46.979 0 : HMUARTLGW hmuart1 send: 01 0620DFE1000000
2021.01.07 12:44:46.986 0 : HMUARTLGW hmuart1 added peer: 20DFE1, aesChannels: FFFFFFFFFFFFFFFF
2021.01.07 12:47:28.827 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A97CDB9 d:FF r:FFCC     m:05 8670 20DFE1 000000 00D231
2021.01.07 12:47:28.831 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 49 msg: 05 86 70 20DFE1 000000 00D231
2021-01-07 12:47:48.731 CUL_HM virt_vd ValveDesired: 0
2021-01-07 12:47:48.731 CUL_HM virt_vd commState: CMDs_done_Errors:1
2021-01-07 12:47:48.731 CUL_HM virt_vd CMDs_done_Errors:1
2021-01-07 12:47:48.731 CUL_HM virt_vd dummy
2021-01-07 12:47:48.731 CUL_HM virt_vd set_0
2021-01-07 12:47:48.757 CUL_HM virt_vd_Btn1 ValveAdjCmd: 00
2021-01-07 12:47:48.757 CUL_HM virt_vd_Btn1 ValvePosition: 0 %
2021.01.07 12:47:48.759 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 47 msg: 05 A2 58 20DFE1 C1C1C1 0000
2021.01.07 12:47:48.763 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A981BDB d:FF r:FFCC     m:05 A258 20DFE1 C1C1C1 0000
2021.01.07 12:50:16.773 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 44 msg: 06 86 70 20DFE1 000000 00D230
2021.01.07 12:50:16.777 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A9A5E14 d:FF r:FFCB     m:06 8670 20DFE1 000000 00D230
2021-01-07 12:50:36.680 CUL_HM virt_vd ValveDesired: 0
2021-01-07 12:50:36.680 CUL_HM virt_vd commState: CMDs_done_Errors:1
2021-01-07 12:50:36.680 CUL_HM virt_vd CMDs_done_Errors:1
2021-01-07 12:50:36.680 CUL_HM virt_vd dummy
2021-01-07 12:50:36.680 CUL_HM virt_vd set_0
2021-01-07 12:50:36.709 CUL_HM virt_vd_Btn1 ValveAdjCmd: 00
2021-01-07 12:50:36.709 CUL_HM virt_vd_Btn1 ValvePosition: 0 %
2021.01.07 12:50:36.711 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 44 msg: 06 A2 58 20DFE1 C1C1C1 0000
2021.01.07 12:50:36.715 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A9AAC37 d:FF r:FFCC     m:06 A258 20DFE1 C1C1C1 0000
2021.01.07 12:52:50.165 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A9CB5CA d:FF r:FFCC     m:07 8670 20DFE1 000000 00D230
2021.01.07 12:52:50.173 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 46 msg: 07 86 70 20DFE1 000000 00D230
2021-01-07 12:53:10.237 CUL_HM virt_vd ValveDesired: 0
2021-01-07 12:53:10.237 CUL_HM virt_vd commState: CMDs_done_Errors:1
2021-01-07 12:53:10.237 CUL_HM virt_vd CMDs_done_Errors:1
2021-01-07 12:53:10.237 CUL_HM virt_vd dummy
2021-01-07 12:53:10.237 CUL_HM virt_vd set_0
2021-01-07 12:53:10.280 CUL_HM virt_vd_Btn1 ValveAdjCmd: 00
2021-01-07 12:53:10.280 CUL_HM virt_vd_Btn1 ValvePosition: 0 %
2021.01.07 12:53:10.284 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 48 msg: 07 A2 58 20DFE1 C1C1C1 0000
2021.01.07 12:53:10.289 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A9D03EC d:FF r:FFCC     m:07 A258 20DFE1 C1C1C1 0000
2021.01.07 12:55:09.674 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 45 msg: 08 86 70 20DFE1 000000 00D130
2021.01.07 12:55:09.688 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A9ED5D2 d:FF r:FFCB     m:08 8670 20DFE1 000000 00D130
2021-01-07 12:55:29.479 CUL_HM virt_vd ValveDesired: 0
2021-01-07 12:55:29.479 CUL_HM virt_vd commState: CMDs_done_Errors:1
2021-01-07 12:55:29.479 CUL_HM virt_vd CMDs_done_Errors:1
2021-01-07 12:55:29.479 CUL_HM virt_vd dummy
2021-01-07 12:55:29.479 CUL_HM virt_vd set_0
2021-01-07 12:55:29.518 CUL_HM virt_vd_Btn1 ValveAdjCmd: 00
2021-01-07 12:55:29.518 CUL_HM virt_vd_Btn1 ValvePosition: 0 %
2021.01.07 12:55:29.520 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8A9F23F5 d:FF r:FFCB     m:08 A258 20DFE1 C1C1C1 0000
2021.01.07 12:55:29.525 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 45 msg: 08 A2 58 20DFE1 C1C1C1 0000
2021.01.07 12:57:14.168 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 51 msg: 09 86 70 20DFE1 000000 00D130
2021.01.07 12:57:14.173 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8AA0BD35 d:FF r:FFCC     m:09 8670 20DFE1 000000 00D130
2021-01-07 12:57:34.236 CUL_HM virt_vd ValveDesired: 0
2021-01-07 12:57:34.236 CUL_HM virt_vd commState: CMDs_done_Errors:1
2021-01-07 12:57:34.236 CUL_HM virt_vd CMDs_done_Errors:1
2021-01-07 12:57:34.236 CUL_HM virt_vd dummy
2021-01-07 12:57:34.236 CUL_HM virt_vd set_0
2021-01-07 12:57:34.276 CUL_HM virt_vd_Btn1 ValveAdjCmd: 00
2021-01-07 12:57:34.276 CUL_HM virt_vd_Btn1 ValvePosition: 0 %
2021.01.07 12:57:34.278 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8AA10B58 d:FF r:FFCC     m:09 A258 20DFE1 C1C1C1 0000
2021.01.07 12:57:34.284 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 52 msg: 09 A2 58 20DFE1 C1C1C1 0000
2021.01.07 13:00:08.599 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8AA365FD d:FF r:FFCC     m:0A 8670 20DFE1 000000 00D030
2021.01.07 13:00:08.604 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 43 msg: 0A 86 70 20DFE1 000000 00D030
2021-01-07 13:00:28.461 CUL_HM virt_vd ValveDesired: 0
2021-01-07 13:00:28.461 CUL_HM virt_vd commState: CMDs_done_Errors:1
2021-01-07 13:00:28.461 CUL_HM virt_vd CMDs_done_Errors:1
2021-01-07 13:00:28.461 CUL_HM virt_vd dummy
2021-01-07 13:00:28.461 CUL_HM virt_vd set_0
2021-01-07 13:00:28.489 CUL_HM virt_vd_Btn1 ValveAdjCmd: 00
2021-01-07 13:00:28.489 CUL_HM virt_vd_Btn1 ValvePosition: 0 %
2021.01.07 13:00:28.491 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 43 msg: 0A A2 58 20DFE1 C1C1C1 0000
2021.01.07 13:00:28.495 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8AA3B41F d:FF r:FFCC     m:0A A258 20DFE1 C1C1C1 0000
2021.01.07 13:02:48.432 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 42 msg: 0B 86 70 20DFE1 000000 00D030
2021.01.07 13:02:48.437 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8AA5D718 d:FF r:FFCC     m:0B 8670 20DFE1 000000 00D030
2021-01-07 13:03:08.463 CUL_HM virt_vd ValveDesired: 0
2021-01-07 13:03:08.463 CUL_HM virt_vd commState: CMDs_done_Errors:1
2021-01-07 13:03:08.463 CUL_HM virt_vd CMDs_done_Errors:1
2021-01-07 13:03:08.463 CUL_HM virt_vd dummy
2021-01-07 13:03:08.463 CUL_HM virt_vd set_0
2021-01-07 13:03:08.492 CUL_HM virt_vd_Btn1 ValveAdjCmd: 00
2021-01-07 13:03:08.492 CUL_HM virt_vd_Btn1 ValvePosition: 0 %
2021.01.07 13:03:08.494 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8AA6253B d:FF r:FFCC     m:0B A258 20DFE1 C1C1C1 0000
2021.01.07 13:03:08.498 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 43 msg: 0B A2 58 20DFE1 C1C1C1 0000
2021.01.07 13:05:13.940 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 41 msg: 0C 86 70 20DFE1 000000 00D030
2021.01.07 13:05:13.945 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8AA80F8C d:FF r:FFCB     m:0C 8670 20DFE1 000000 00D030
2021-01-07 13:05:33.996 CUL_HM virt_vd ValveDesired: 0
2021-01-07 13:05:33.996 CUL_HM virt_vd commState: CMDs_done_Errors:1
2021-01-07 13:05:33.996 CUL_HM virt_vd CMDs_done_Errors:1
2021-01-07 13:05:33.996 CUL_HM virt_vd dummy
2021-01-07 13:05:33.996 CUL_HM virt_vd set_0
2021-01-07 13:05:34.036 CUL_HM virt_vd_Btn1 ValveAdjCmd: 00
2021-01-07 13:05:34.036 CUL_HM virt_vd_Btn1 ValvePosition: 0 %
2021.01.07 13:05:34.038 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8AA85DAF d:FF r:FFCB     m:0C A258 20DFE1 C1C1C1 0000
2021.01.07 13:05:34.045 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 41 msg: 0C A2 58 20DFE1 C1C1C1 0000
2021.01.07 13:07:24.945 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 43 msg: 0D 86 70 20DFE1 000000 00D030
2021.01.07 13:07:24.950 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8AAA0F5A d:FF r:FFCB     m:0D 8670 20DFE1 000000 00D030
2021-01-07 13:07:44.973 CUL_HM virt_vd ValveDesired: 0
2021-01-07 13:07:44.973 CUL_HM virt_vd commState: CMDs_done_Errors:1
2021-01-07 13:07:44.973 CUL_HM virt_vd CMDs_done_Errors:1
2021-01-07 13:07:44.973 CUL_HM virt_vd dummy
2021-01-07 13:07:44.973 CUL_HM virt_vd set_0
2021-01-07 13:07:44.999 CUL_HM virt_vd_Btn1 ValveAdjCmd: 00
2021-01-07 13:07:44.999 CUL_HM virt_vd_Btn1 ValvePosition: 0 %
2021.01.07 13:07:45.001 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 43 msg: 0D A2 58 20DFE1 C1C1C1 0000
2021.01.07 13:07:45.004 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8AAA5D7C d:FF r:FFCB     m:0D A258 20DFE1 C1C1C1 0000
2021.01.07 13:10:25.452 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 43 msg: 0E 86 70 20DFE1 000000 00D030
2021.01.07 13:10:25.456 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8AACD08D d:FF r:FFCB     m:0E 8670 20DFE1 000000 00D030
2021-01-07 13:10:45.499 CUL_HM virt_vd ValveDesired: 0
2021-01-07 13:10:45.499 CUL_HM virt_vd commState: CMDs_done_Errors:1
2021-01-07 13:10:45.499 CUL_HM virt_vd CMDs_done_Errors:1
2021-01-07 13:10:45.499 CUL_HM virt_vd dummy
2021-01-07 13:10:45.499 CUL_HM virt_vd set_0
2021-01-07 13:10:45.534 CUL_HM virt_vd_Btn1 ValveAdjCmd: 00
2021-01-07 13:10:45.534 CUL_HM virt_vd_Btn1 ValvePosition: 0 %
2021.01.07 13:10:45.536 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8AAD1EB0 d:FF r:FFCB     m:0E A258 20DFE1 C1C1C1 0000
2021.01.07 13:10:45.542 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 43 msg: 0E A2 58 20DFE1 C1C1C1 0000
2021.01.07 13:13:11.717 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 43 msg: 0F 86 70 20DFE1 000000 00D030
2021.01.07 13:13:11.724 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8AAF5A14 d:FF r:FFCB     m:0F 8670 20DFE1 000000 00D030
2021-01-07 13:13:31.768 CUL_HM virt_vd ValveDesired: 0
2021-01-07 13:13:31.768 CUL_HM virt_vd commState: CMDs_done_Errors:1
2021-01-07 13:13:31.768 CUL_HM virt_vd CMDs_done_Errors:1
2021-01-07 13:13:31.768 CUL_HM virt_vd dummy
2021-01-07 13:13:31.768 CUL_HM virt_vd set_0
2021-01-07 13:13:31.806 CUL_HM virt_vd_Btn1 ValveAdjCmd: 00
2021-01-07 13:13:31.806 CUL_HM virt_vd_Btn1 ValvePosition: 0 %
2021.01.07 13:13:31.809 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 41 msg: 0F A2 58 20DFE1 C1C1C1 0000
2021.01.07 13:13:31.813 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8AAFA836 d:FF r:FFCB     m:0F A258 20DFE1 C1C1C1 0000
2021.01.07 13:15:43.583 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 40 msg: 10 86 70 20DFE1 000000 00CF30
2021.01.07 13:15:43.586 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8AB1AAF3 d:FF r:FFCB     m:10 8670 20DFE1 000000 00CF30
2021-01-07 13:16:03.498 CUL_HM virt_vd ValveDesired: 0
2021-01-07 13:16:03.498 CUL_HM virt_vd commState: CMDs_done_Errors:1
2021-01-07 13:16:03.498 CUL_HM virt_vd CMDs_done_Errors:1
2021-01-07 13:16:03.498 CUL_HM virt_vd dummy
2021-01-07 13:16:03.498 CUL_HM virt_vd set_0
2021-01-07 13:16:03.525 CUL_HM virt_vd_Btn1 ValveAdjCmd: 00
2021-01-07 13:16:03.525 CUL_HM virt_vd_Btn1 ValvePosition: 0 %
2021.01.07 13:16:03.527 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 40 msg: 10 A2 58 20DFE1 C1C1C1 0000
2021.01.07 13:16:03.531 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8AB1F915 d:FF r:FFCC     m:10 A258 20DFE1 C1C1C1 0000
2021.01.07 13:18:00.722 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 42 msg: 11 86 70 20DFE1 000000 00CF30
2021.01.07 13:18:00.727 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8AB3C32E d:FF r:FFCB     m:11 8670 20DFE1 000000 00CF30
2021-01-07 13:18:20.755 CUL_HM virt_vd ValveDesired: 0
2021-01-07 13:18:20.755 CUL_HM virt_vd commState: CMDs_done_Errors:1
2021-01-07 13:18:20.755 CUL_HM virt_vd CMDs_done_Errors:1
2021-01-07 13:18:20.755 CUL_HM virt_vd dummy
2021-01-07 13:18:20.755 CUL_HM virt_vd set_0
2021-01-07 13:18:20.783 CUL_HM virt_vd_Btn1 ValveAdjCmd: 00
2021-01-07 13:18:20.783 CUL_HM virt_vd_Btn1 ValvePosition: 0 %
2021.01.07 13:18:20.785 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 42 msg: 11 A2 58 20DFE1 C1C1C1 0000
2021.01.07 13:18:20.789 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8AB41150 d:FF r:FFCB     m:11 A258 20DFE1 C1C1C1 0000
2021.01.07 13:20:03.724 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 42 msg: 12 86 70 20DFE1 000000 00CF30
2021.01.07 13:20:03.734 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8AB5A3BA d:FF r:FFCB     m:12 8670 20DFE1 000000 00CF30
2021-01-07 13:20:23.760 CUL_HM virt_vd ValveDesired: 0
2021-01-07 13:20:23.760 CUL_HM virt_vd commState: CMDs_done_Errors:1
2021-01-07 13:20:23.760 CUL_HM virt_vd CMDs_done_Errors:1
2021-01-07 13:20:23.760 CUL_HM virt_vd dummy
2021-01-07 13:20:23.760 CUL_HM virt_vd set_0
2021-01-07 13:20:23.786 CUL_HM virt_vd_Btn1 ValveAdjCmd: 00
2021-01-07 13:20:23.786 CUL_HM virt_vd_Btn1 ValvePosition: 0 %
2021.01.07 13:20:23.787 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8AB5F1DD d:FF r:FFCB     m:12 A258 20DFE1 C1C1C1 0000
2021.01.07 13:20:23.791 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 42 msg: 12 A2 58 20DFE1 C1C1C1 0000
2021.01.07 13:22:56.246 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 42 msg: 13 86 70 20DFE1 000000 00CF30
2021.01.07 13:22:56.254 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8AB845AB d:FF r:FFCB     m:13 8670 20DFE1 000000 00CF30
2021-01-07 13:23:16.266 CUL_HM virt_vd ValveDesired: 0
2021-01-07 13:23:16.266 CUL_HM virt_vd commState: CMDs_done_Errors:1
2021-01-07 13:23:16.266 CUL_HM virt_vd CMDs_done_Errors:1
2021-01-07 13:23:16.266 CUL_HM virt_vd dummy
2021-01-07 13:23:16.266 CUL_HM virt_vd set_0
2021-01-07 13:23:16.295 CUL_HM virt_vd_Btn1 ValveAdjCmd: 00
2021-01-07 13:23:16.295 CUL_HM virt_vd_Btn1 ValvePosition: 0 %
2021.01.07 13:23:16.297 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8AB893CE d:FF r:FFCB     m:13 A258 20DFE1 C1C1C1 0000
2021.01.07 13:23:16.301 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 43 msg: 13 A2 58 20DFE1 C1C1C1 0000
2021.01.07 13:25:34.244 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 42 msg: 14 86 70 20DFE1 000000 00CF30
2021.01.07 13:25:34.249 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8ABAAEF7 d:FF r:FFCC     m:14 8670 20DFE1 000000 00CF30
2021-01-07 13:25:54.303 CUL_HM virt_vd ValveDesired: 0
2021-01-07 13:25:54.303 CUL_HM virt_vd commState: CMDs_done_Errors:1
2021-01-07 13:25:54.303 CUL_HM virt_vd CMDs_done_Errors:1
2021-01-07 13:25:54.303 CUL_HM virt_vd dummy
2021-01-07 13:25:54.303 CUL_HM virt_vd set_0
2021-01-07 13:25:54.341 CUL_HM virt_vd_Btn1 ValveAdjCmd: 00
2021-01-07 13:25:54.341 CUL_HM virt_vd_Btn1 ValvePosition: 0 %
2021.01.07 13:25:54.344 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8ABAFD19 d:FF r:FFCC     m:14 A258 20DFE1 C1C1C1 0000
2021.01.07 13:25:54.350 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 42 msg: 14 A2 58 20DFE1 C1C1C1 0000
2021.01.07 13:27:58.068 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 40 msg: 15 86 70 20DFE1 000000 00CE30
2021.01.07 13:27:58.071 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8ABCE095 d:FF r:FFCB     m:15 8670 20DFE1 000000 00CE30
2021-01-07 13:28:18.067 CUL_HM virt_vd ValveDesired: 0
2021-01-07 13:28:18.067 CUL_HM virt_vd commState: CMDs_done_Errors:1
2021-01-07 13:28:18.067 CUL_HM virt_vd CMDs_done_Errors:1
2021-01-07 13:28:18.067 CUL_HM virt_vd dummy
2021-01-07 13:28:18.067 CUL_HM virt_vd set_0
2021-01-07 13:28:18.105 CUL_HM virt_vd_Btn1 ValveAdjCmd: 00
2021-01-07 13:28:18.105 CUL_HM virt_vd_Btn1 ValvePosition: 0 %
2021.01.07 13:28:18.108 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8ABD2EB7 d:FF r:FFCC     m:15 A258 20DFE1 C1C1C1 0000
2021.01.07 13:28:18.113 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 40 msg: 15 A2 58 20DFE1 C1C1C1 0000
2021-01-07 13:29:52.750 Global global DELETEATTR virt_vd virt_vd dummy
2021.01.07 13:30:07.258 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8ABED98C d:FF r:FFCC     m:16 8670 20DFE1 000000 00CE30
2021.01.07 13:30:07.264 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 41 msg: 16 86 70 20DFE1 000000 00CE30
2021.01.07 13:30:27.347 0 : HMLAN_Send:  hmlan1 S:SDCD3A92C stat:  00 t:00000000 d:01 r:DCD3A92C m:16 8002 C1C1C1 20DFE1 0101000000
2021-01-07 13:30:27.403 CUL_HM virt_vd ValveDesired: 0
2021-01-07 13:30:27.403 CUL_HM virt_vd commState: CMDs_done
2021-01-07 13:30:27.403 CUL_HM virt_vd CMDs_done
2021-01-07 13:30:27.403 CUL_HM virt_vd set_0
2021-01-07 13:30:27.441 CUL_HM virt_vd_Btn1 ValveAdjCmd: 00
2021-01-07 13:30:27.441 CUL_HM virt_vd_Btn1 ValvePosition: 0 %
2021.01.07 13:30:27.449 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8ABF27AE d:FF r:FFCC     m:16 A258 20DFE1 C1C1C1 0000
2021.01.07 13:30:27.453 0 : HMLAN_Parse: hmlan1 R:RDCD3A92C stat:0002 t:00000000 d:FF r:7FFF     m:16 8002 C1C1C1 20DFE1 0101000000
2021.01.07 13:30:27.455 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 42 msg: 16 A2 58 20DFE1 C1C1C1 0000
2021.01.07 13:30:27.458 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 29 msg: 16 80 02 C1C1C1 20DFE1 0101000000
2021.01.07 13:33:06.010 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 41 msg: 17 86 70 20DFE1 000000 00CE30
2021.01.07 13:33:06.014 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8AC193E7 d:FF r:FFCB     m:17 8670 20DFE1 000000 00CE30
2021.01.07 13:33:26.103 0 : HMLAN_Send:  hmlan1 S:SDCD6636F stat:  00 t:00000000 d:01 r:DCD6636F m:17 8002 C1C1C1 20DFE1 0101000000
2021-01-07 13:33:26.147 CUL_HM virt_vd ValveDesired: 0
2021-01-07 13:33:26.147 CUL_HM virt_vd commState: CMDs_done
2021-01-07 13:33:26.147 CUL_HM virt_vd CMDs_done
2021-01-07 13:33:26.147 CUL_HM virt_vd set_0
2021-01-07 13:33:26.183 CUL_HM virt_vd_Btn1 ValveAdjCmd: 00
2021-01-07 13:33:26.183 CUL_HM virt_vd_Btn1 ValvePosition: 0 %
2021.01.07 13:33:26.190 0 : HMLAN_Parse: hmlan1 R:E20DFE1   stat:0000 t:8AC1E20B d:FF r:FFCB     m:17 A258 20DFE1 C1C1C1 0000
2021.01.07 13:33:26.193 0 : HMLAN_Parse: hmlan1 R:RDCD6636F stat:0002 t:00000000 d:FF r:7FFF     m:17 8002 C1C1C1 20DFE1 0101000000
2021.01.07 13:33:26.196 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 41 msg: 17 A2 58 20DFE1 C1C1C1 0000
2021.01.07 13:33:26.199 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 29 msg: 17 80 02 C1C1C1 20DFE1 0101000000
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 07 Januar 2021, 14:05:34
Hallo Frank,

Zitat
das log zeigt auch, dass ausgelassen wurde. eigentlich sollte nach miss grundsätzlich nicht ausgelassen werden. na gut.
mitte märz 2020 gab es das phänomen jedenfalls auch schon.
Der miss Zähler wird für msgReduce mit genutzt.
Gewollt ausgelassene Sends sind somit kein miss im eigentlichen Sinne und daher hat Martin sich vielleicht entschlossen, das Reading nicht zu aktualisieren?!
Unschön, dass es danach mit 3 weiter geht.

Zitathier mal ein sniff eines realen tc mit einem virtuellen vd gepeert (inkl events des vvd).
Super, danke, da muss ich mich mahl durchwühlen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 07 Januar 2021, 14:23:14
Hi Ansgar,

ok, läuft. Auf die ersten paar Stunden habe ich den Eindruck, das es weniger Miss-Serien gibt (also höchstens mal 1-2 in Folge).

Hast du einen Tipp, wie ich die serial id ändern kann, dass die sich in /dev/serial/by-id nicht ins Gehege kommen?
Beide melden sich mit der selben ID an. Ich verwende jetzt /dev/ttyUSB0+1 aber das ist ja Port-abhängig - wäre schöner wenn sich jeder Nano mit einer eindeutigen ID anmeldet.

In welchem Log soll ich mit verbose=4 die ACKs sehen? Sehe ich weder in der CUL, noch VCCU oder virt.TC?

Gruß,
Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 07 Januar 2021, 16:19:21
Hallo Jörg,

ZitatHast du einen Tipp, wie ich die serial id ändern kann, dass die sich in /dev/serial/by-id nicht ins Gehege kommen?
Beide melden sich mit der selben ID an. Ich verwende jetzt /dev/ttyUSB0+1 aber das ist ja Port-abhängig - wäre schöner wenn sich jeder Nano mit einer eindeutigen ID anmeldet.
Das hängt an dem USB-Seriell Interface Chip auf den Nanos. Da müsstest Du schauen, ob die auch eine eindeutige Seriennummer haben.
sudo lsusb -v
gibt unter iSerial auch die Seriennummer aus.
Eventuell gibt es ein Tool, mit dem die auch gesetzt werden kann?

Die beiden nanos sollen auf verbose 4 gestellt sein. Der virtuelle TC auf 2.

Wie ich aus Franks sehr hilfreichem Log schon sehen kann, cyclicMsgMissAdd ist gestorben. Da passiert nichts in der Richtung.
cyclicMsgDoShift macht danach im Vergleich zu einem realen TC auch direkt keinen Sinn. Außerdem sendet der TC exakt 20s nach der VD message seinen Status. Shift würde wohl irgendwann auch mal damit kollidieren.
Die HMLAN Uhr und die TC Uhr weichen voneinander ab. Die TC Uhr geht um etwa 25ms gegenüber HMLAN pro message nach.

Edit: die HMLAN Uhr tickt um 0.013% schneller, als Franks Server Uhr.
Die TC Uhr geht etwa 5,9ms pro message gegenüber Franks Server nach. Einen ähnlichen Wert habe ich bei mir auch mal bei einem TH-Sensor beobachtet.

Das entspräche einem cyclicMsgCorr von 6, wenn die HMLAN Uhr richtig geht (muss ich noch vergleichen).

Ich denke über einen Mix zwischen cyclicMsgDoShift (=1) und cyclicMsgCorr nach, weil nur mit cyclicMsgDoShift ein wenig Timerjitterkompensation möglich ist.

Aber erst mal schauen, wie die HMLAN Uhr tickt.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 07 Januar 2021, 17:56:50
Hallo Jörg,

anbei eine neue Version zum Testen (nur Module geändert).

Die Erkenntnisse aus dem letzten Beitrag sind eingearbeitet inklusive cyclicMsgCorr mit Default 6.

cyclicMsgDoShift ist per Default auf 0, bleibt aber Spielwiese zum Durchtesten in längeren Messreihen für 0 und 1 für den TC.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 07 Januar 2021, 19:48:17
Hi Ansgar,

ok, habe jetzt erstmal wieder alle Attribute gelöscht und starte mit defaults.
Ich hatte vorher den Effekt , dass er wohl automatisch die CUL gewechselt hat (wohl nach massiven Misses), zumindest stand in beiden VD devices als IODev plötzlich die andere CUL. Was ist da das Kriterium? Wirklich gleichzeitig scheint er sie nicht zu verwenden
Danach war sicher 20 Minuten komplett Ruhe mit Misses (auf beiden VDs, beide liefen mit  S:1 A:0 O:3 ).
Nach dem Neustart mit neuen Modulen nimmt er wieder die erste und hat jetzt erstmal wieder misses (wie gesagt, mit deinen Defaults S:0, O:1) und gerade laufen beide VD sogar auf Fehler.
Hab jetzt beide VDs manuell auf die zweite CUL geschaltet und sie haben sich sofort wieder gefangen, wobei ich im Log "TSCUL_Send" und "TSCUL_XmitDlyHM" immer noch bei der ersten sehe. Die "Parse" Einträge sehe ich eigentlich immer bei beiden.

Jörg

Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 07 Januar 2021, 20:11:08
Hallo Jörg,

ZitatIch hatte vorher den Effekt , dass er wohl automatisch die CUL gewechselt hat (wohl nach massiven Misses), zumindest stand in beiden VD devices als IODev plötzlich die andere CUL. Was ist da das Kriterium? Wirklich gleichzeitig scheint er sie nicht zu verwenden
Das Kriterium sollte der RSSI beim jeweiligen VD device sein, da über die gesendet wird. Außerdem ggf. noch Überlastung der credits eines IOs.

Eventuell ist es schon ein Zeichen, wenn es über den "neuen" nano besser läuft.

Schick mal einen Log Auszug.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 08 Januar 2021, 13:29:37
Hi Ansgar,

nach dem HW-Fix an der ersten CUL lief es schon deutlich runder. Ich habe den Vergleich der beiden CUL auch mal genutzt um mit dem Frequenzoffset zu spielen (man sieht da ja recht schnell anhand des RSSI Vergleichs der gleichen Message, ob man was verbessert oder verschlechtert hat). Habe das jetzt von +25 auf +50 hochgedreht.
An üblicher Stelle nochmal ziemlich viel Logfile, das aber auch einige Spielereinen und evtl. auch kurzfristiges Abstecken einer CUL enthält.

Ich habe jetzt wieder auf Standard Szenario (eine CUL, TS_CUL verbose 0, S:0 O:1 ) zurückgedreht: Deutlich weniger misses und maximal einer in Folge, meistens bei Ventiländerungen (anbei das "grep miss"):

2021.01.08 10:27:56.176 2: CUL_HM HMTC20_c1 11222001 mc:E7  tQ: 0.900  rQ: 0.000  dtu: 148510 ms  ueS: -23 ms  ueC: -21 ms  dti: 148506 ms  ieS: -18 ms  ieC: -16 ms  miss: 1
2021.01.08 10:29:40.187 2: CUL_HM HMTC20_c1 11222001 hI:125ms S:0 O:1 mc:E7->E8  dtp: 183507 ms  dtF: 183507 ms  dtcall: 8 ms  nv:n  miss: 1
2021.01.08 10:55:58.871 2: CUL_HM HMTC14_c1 11221401 mc:05  tQ: 0.905  rQ: 0.500  dtu: 164766 ms  ueS: 1 ms  ueC: 2 ms  dti: 164757 ms  ieS: 10 ms  ieC: 11 ms  miss: 1
2021.01.08 10:57:59.382 2: CUL_HM HMTC14_c1 11221401 hI:125ms S:0 O:1 mc:05->06  dtp: 136005 ms  dtF: 136005 ms  dtcall: 2 ms  nv:n  miss: 1
2021.01.08 11:10:37.182 2: CUL_HM HMTC14_c1 11221401 mc:0B  tQ: 0.889  rQ: 0.667  dtu: 142260 ms  ueS: -53 ms  ueC: -55 ms  dti: 142256 ms  ieS: -48 ms  ieC: -50 ms  miss: 1
2021.01.08 11:12:15.194 2: CUL_HM HMTC14_c1 11221401 hI:125ms S:0 O:1 mc:0B->0C  dtp: 177507 ms  dtF: 177506 ms  dtcall: 4 ms  nv:Y  miss: 1
2021.01.08 11:58:38.842 2: CUL_HM HMTC20_c1 11222001 mc:0B  tQ: 0.957  rQ: 0.500  dtu: 121507 ms  ueS: -66 ms  ueC: -68 ms  dti: 121505 ms  ieS: -63 ms  ieC: -65 ms  miss: 1
2021.01.08 12:01:00.112 2: CUL_HM HMTC20_c1 11222001 hI:125ms S:0 O:1 mc:0B->0C  dtp: 156756 ms  dtF: 156756 ms  dtcall: 10 ms  nv:Y  miss: 1
2021.01.08 12:31:52.040 2: CUL_HM HMTC14_c1 11221401 mc:2B  tQ: 0.932  rQ: 0.750  dtu: 128757 ms  ueS: 9 ms  ueC: -3 ms  dti: 128755 ms  ieS: 11 ms  ieC: 0 ms  miss: 1
2021.01.08 12:34:20.301 2: CUL_HM HMTC14_c1 11221401 hI:125ms S:0 O:1 mc:2B->2C  dtp: 164006 ms  dtF: 164006 ms  dtcall: 3 ms  nv:Y  miss: 1
2021.01.08 13:00:30.625 2: CUL_HM HMTC20_c1 11222001 mc:23  tQ: 0.957  rQ: 0.667  dtu: 159508 ms  ueS: -75 ms  ueC: -76 ms  dti: 159506 ms  ieS: -72 ms  ieC: -73 ms  miss: 1
2021.01.08 13:02:25.632 2: CUL_HM HMTC20_c1 11222001 hI:125ms S:0 O:1 mc:23->24  dtp: 130505 ms  dtF: 130504 ms  dtcall: 5 ms  nv:Y  miss: 1


Gruß,
Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 08 Januar 2021, 16:52:17
Noch eine andere Frage:
An sich sollte doch ein hmPairForSec nötig sein um mit autocreate ein neues Device zu erzeugen und es zu pairen, oder?
Ich hatte jetzt schon zwei Mal einfach so ein neues Device im Setup. Einmal eine RT-DN und einmal einen Steckdosen Switch. Von beiden habe ich brav Modell, Firmware Version und XEQXXXXXX Nummer empfangen - und es sind bestimmt nicht meine.
Ich befürchte mein Nachbar versucht verzweifelt Homematic Devices zu pairen und meine CUL schnappt die ihm immer mal wieder weg. Ist da was falsch eingestellt oder ist das ein Bug?

Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 08 Januar 2021, 17:30:00
Hallo Jörg,

für den 1.4er (bisher nur den betrachtet) sehe ich, dass oft mal der eine und mal der andere nano den Ack bekommt.
So wirklich rund läuft der Ack Empfang bei beiden nanos noch nicht. Ist auch nicht abhängig davon, welcher zuvor gesendet hat. Und leider passiert es dann wohl auch, dass beide nicht empfangen.

ZitatAn sich sollte doch ein hmPairForSec nötig sein um mit autocreate ein neues Device zu erzeugen und es zu pairen, oder?
Zum Pairen ja, aber Anlegen eines devices und Pairen sind zwei verschiedene Dinge.
Für das Anlegen reicht schon der Empfang einer Message mit passendem Message Typ von einem device bei aktivem Autocreate.
Ist ein gewolltes Verhalten und ändere ich auch nicht, wenn Martin es nicht ändert. Ohne hmPair... paired CUL_HM dann halt nicht.

Ich habe autocreate normalerweise disabled und aktivieres es nur, wenn ich irgend ein neues device anlernen möchte.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 08 Januar 2021, 18:35:49
Hallo Jörg,

ich habe Dir mal eine spezial Version der Firmware für den nano gebaut.
Mit der wird die agcMaxDVGA Eunstellung vom SlowRF Modus für HM verwendet.
Wie Du mit ccconf sehen kannst, ist die bisher 1 und mit rfmode Homematic nicht änderbar.

Wenn Du diese Version flashest, dann kannst Du den nano temporär auf slowRf stellen, dort die gewünschte  Einstellung setzen und wieder nach Homeatic wechseln.
Dann da ein ccconf, um die Änderung zu prüfen.
Besser anschließend FHEM nochmal neu starten.

Schau mal, ob 0, 2 oder 3 eine Verbesserung bringen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 12 Januar 2021, 10:48:49
Hallo Ansgar,

mein Setup läuft jetzt über 2 Tage produktiv (ohne die Firmware vom letzten Post). Frequenzoffset hab ich auf +70 wodurch der RSSI halbwegs in der Mitte ist.
Von den Einstellungen her läuft alles mit Standard ausser cyclicMsgDoShift=1

rssi done:
    Device          receive         from             last   avg      min_max    count
    HM_VD_14        CUL_TS          HM_VD_14         -48.5  -50.0  -53.5< -47.5   397
    HM_VD_14        HM_VD_14        CUL_TS           -45.0  -46.3  -50.0< -45.0   397
    HM_VD_20        CUL_TS          HM_VD_20         -54.0  -54.1  -62.5< -53.5   374
    HM_VD_20        HM_VD_20        CUL_TS           -53.0  -53.6  -62.0< -52.0   374


Ich würde sagen die Anzahl der Fails hält sich in Grenzen. Alles in allem läuft es dafür, dass meine CC1101 wahrscheinlich ein ziemlicher Schrott ist, relativ gut.
Besten Danke für deine Hilfe und die geniale Firmware.

Jörg

protoEvents send to devices done:
    name     :State           |CmdPend   |Snd       |Resnd     #CmdDel    |ResndFail |Nack      |IOerr     
    HM_VD_14 : done           |  -       | 403      |  -       #  -       | 6        |  -       |  -       
    HM_VD_20 : done           |  -       | 385      |  -       # 4        | 11       |  -       |  -       
=======================================================================================================
    sum      0                |0         |788       |0         #4         |17        |0         |0       
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 12 Januar 2021, 21:29:59
Hallo Jörg,

nochmal eine neue Version zum Testen.

Ich habe das Attribut cyclicMsgRecWinHalf entfernt (ist jetzt fest auf 125ms) und eine langsame dynamische Korrektur des Sendezeitpunkts ergänzt, was sich effektiv nur auf die Einstellung cyclicMsgDoShift=0 mit wenigen ms früherem Sendezeitpunkt äußern sollte (startet bei cyclicMsgDoShift=0 bei -5.4ms). Wie es sich entwickelt, ist am timing Reading mit c: x.x zu sehen.
Außerdem habe ich noch kleinere Bugs an Modulen behoben.

Bei der Firmware habe ich einen Ag Befehl ergänzt, mit dem die AGCCTRL2 Einstellung des Tranceivers für HM remanent verändert werden kann. Damit verbunden ist auch eine Änderung der EEPROM Belegung, was beim Flashen ein Reset aller CUL Einstellungen bewirkt. Also vor dem Flashen alle individuellen CUL Einstellungen notieren und anschließend FHEM neu starten.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 17 Januar 2021, 10:31:04
Hallo Ansgar,

hier das Resultat des produktiven Langzeittests über ca. 5 Tage:

    name     :State           |CmdPend   |Snd       |Resnd     #CmdDel    |ResndFail |Nack      |IOerr     
    HM_VD_14 : done           |  -       | 1775     |  -       #  -       | 40       |  -       |  -       
    HM_VD_20 : done           |  -       | 1802     |  -       #  -       | 64       |  -       |  -       
=======================================================================================================
    sum      0                |0         |3577      |0         #0         |104       |0         |0     

TC 14: mc: 9 miss: 0 tQ: 0.977 rQ: 0.950 mSkp: 235 mNck: 40 dtu: 171267 ueS: -62 ueC: 1 dti: 171257 ieS: -51 ieC: 11 c: -1.8
cyclicMsgDoShift=1

TC 20: mc: 28 miss: 0 tQ: 0.964 rQ: 0.859 mSkp: 208 mNck: 64 dtu: 132513 ueS: 0 ueC: 0 dti: 132505 ieS: 8 ieC: 8 c: -2.2
cyclicMsgDoShift=1

    Device          receive         from             last   avg      min_max    count
    HM_VD_14        CUL_TS          HM_VD_14         -51.5  -48.8  -54.0< -41.5  1738
    HM_VD_14        HM_VD_14        CUL_TS           -47.0  -45.1  -55.0< -39.0  1738
    HM_VD_20        CUL_TS          HM_VD_20         -55.0  -54.2  -75.0< -52.5  1741
    HM_VD_20        HM_VD_20        CUL_TS           -54.0  -53.4  -74.0< -52.0  1741

Wenn du aus den Werten spontan einen Vorschlag hast irgendeine Einstellung zu ändern, kann ich das gerne mal probieren und wieder ein paar Tage so laufen lassen.

Wie anderweitig besprochen, blockiert mein ADS Modul ja derzeit FHEM hin- und wieder länger als notwendig. Das könnte durchaus einen Einfluss haben. Ich werde die neue Version dann demnächst in den Produktivtests nehmen - mal sehen ob das auch auf die ResndFail einen Einfluss hat. Außerdem muss ich wohl den 14 und 20 umwechseln. Der 14er hat irgendwie ein Problem auf Maximalposition (99) zu stellen und meldet dann immer 98. Ich brauche hier aber meistens volle Ventilöffnung. Scheint jetzt keinen wirklichen Einfluss auf die Funktion zu haben, führt aber dazu das ständig wieder ein "set_99%" ausgeführt wird (weil der Antrieb ja nicht da ist wo er hin soll). Der 20er verhält sich hier konsistenter (da brauche ich aber für meine Fußbodenheizung nur Position 25)

Gruß,
Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 17 Januar 2021, 12:17:49
Hallo Jörg,

ZitatWenn du aus den Werten spontan einen Vorschlag hast irgendeine Einstellung zu ändern
Mit Deiner nano Empfangsproblematik würde mir ein besserer Angleich der RSSI Werte ins Auge springen. Die RSSI Werte vom 20er sind im Vergleich schlechter. Normalerweise wären das keine Problemwerte aber bei Dir macht das vielleicht schon den Unterschied.
Ich habe nochmal eine neue Variante bezüglich der Module angehangen, bei CUL wird damit der neue Ag Befehl per set unterstützt. Damit kannst Du per set hmAgcMaxDVGA bei den nanos doch mal an dem Parameter spielen (mit get ccconf siehst Du, ob es auch eingestellt wurde). Also statt dem default 1 mal 0 und 2 testen, ob das einen Unterschied macht.

ZitatDer 14er hat irgendwie ein Problem auf Maximalposition (99) zu stellen und meldet dann immer 98.
Was wird bei einem Stellwert von 98% zurück gemeldet?
Dann bräuchte ich nochmal ein nano verbose 4 Log vom Stellen auf 99%, "erfolgreich" sprich mit der raw Rückmeldung der 98%.
Das gleiche bitte auch vom 20er zum Vergleich, was da bei 99% Stellwert raw zurück gemeldet wird.

ZitatWie anderweitig besprochen, blockiert mein ADS Modul ja derzeit FHEM hin- und wieder länger als notwendig.
Wahrscheinlich nicht nur das ADS Modul, da Du etwas mehr als 10% Skips hast. Sprich, die maximale, systembedingte Sendezeitpunktsverschiebung/Timeraufrufzeitpunkt hat entsprechend oft das Limit überschritten und es wurde deswegen nicht gesendet. 0% wird in FHEM nicht zu erreichen sein, aber schon konsequente Reduzierung nicht benötigter Events mit event-on-change-reading und event-on-update-reading bei allen FHEM devices ist ein erster Weg zur Besserung.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 17 Januar 2021, 15:23:10
Hi Ansgar,

hier schon mal die Logs. Da sollte jeweils eine Positionierung auf 99% drin sein (der 20er hat sich dann aber über meine Regelung wohl relativ schnell wieder auf 25% stellt, weiss also nicht ob da alles drin ist).
Ich tippe hier aber sowieso eher auf ein HW oder FW Problem im 14er VD und der Workaround mit Tausch der Antriebe ist ja auch einfach :)

Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 17 Januar 2021, 15:52:18
Hallo Jörg,

fahr den 14er mal auf 98%, wieder mit Log bitte.

Er meldet, dass er versucht zu öffnen, aber der Motor da oben blockiert. Müßtest Du auch beim VD in den Readings sehen können. Wenn's nur bis 98% geht, dann geht's halt nicht weiter und dann verlang es auch nicht von dem.  ;)
Es gibt bei der 1.4er Firmware wohl auch noch einen F1 Bug, wenn man 100% versucht. Demnach endet ein Versuch auf 100% zu fahren auch schon mal in Zustand F1 im Display und nix fährt mehr, bis Reset mit Batterie raus und wieder rein, hab ich zumindest so gelesen.

Der 20er dagegen fährt nach seiner Rückmeldung ohne Murren auf die 99%.

Gruß, Ansgar.

PS: Möglicherweise fährt der 14er auch auf 99%, wenn Du ihn vorher ganz zu fährst. Dann wäre ein Bug in der Firmware, dass er mit der Zeit "Schritte" verliert.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: frank am 17 Januar 2021, 16:18:53
ZitatWenn's nur bis 98% geht, dann geht's halt nicht weiter und dann verlang es auch nicht von dem.
das sollte ja normal kein problem sein, da der motor den stössel im vd eigentlich sehr viel weiter zurückziehen kann.
bei 100% berührt der stössel des vd ja gerade den stift am ventil.

ich würde mal eine neue adaptierungsfahrt durchführen.

bei meinen vd mit fw2.0 ist das auch manchmal zu beobachten.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 17 Januar 2021, 16:21:14
Hi Ansgar,

Bitte (erst auf 98, dann nochmal auf 99) - ich sehe bei 99 aber keine Fehler im Device, er bleibt aber nach wie vor auf 98.
Wenns ein HW Problem ist, dann war der Wechsel ja ok. Der eine Use Case braucht nie mehr als 25%.
@frank: Adaptierfahrten hab ich seitdem ich das Problem festgestellt habe, schon des öfteren gemacht. Das ändert nichts.

Jörg

2021.01.17 16:07:45 4: TSCUL_Write: CUL_TS sending As0B92A2581122141123B803FA
2021.01.17 16:07:45 4: TSCUL_send:  CUL_TS  214264                 As 0B 92 A258 112214 1123B8 03FA
2021.01.17 16:07:45 4: TSCUL_XmitDlyHM:  CUL_TS  id:1123B8 rtoms:1178
2021.01.17 16:07:45 4: TSCUL_Parse: CUL_TS  14894369 A F503 00779212 01 0B 92 A258 112214 1123B8 03FA _CCAdly:4
2021.01.17 16:07:45 4: TSCUL_Parse: CUL_TS  14894503 A F501 00779372 00 0E 92 8202 1123B8 112214 0101341031 -53.5dB
2021.01.17 16:10:30 4: TSCUL_Write: CUL_TS sending As0B93A2581122141123B800FA
2021.01.17 16:10:30 4: TSCUL_send:  CUL_TS  379041                 As 0B 93 A258 112214 1123B8 00FA
2021.01.17 16:10:30 4: TSCUL_XmitDlyHM:  CUL_TS  id:1123B8 rtoms:1178
2021.01.17 16:10:30 4: TSCUL_Parse: CUL_TS  15059145 A F403 00943992 01 0B 93 A258 112214 1123B8 00FA _CCAdly:4
2021.01.17 16:10:30 4: TSCUL_Parse: CUL_TS  15059278 A F401 00944148 00 0E 93 8202 1123B8 112214 0101C40032 -53.5dB
2021.01.17 16:10:30 4: TSCUL_Write: CUL_TS sending As0994A1124444441123B8
2021.01.17 16:10:30 4: TSCUL_send:  CUL_TS  379265                 As 09 94 A112 444444 1123B8
2021.01.17 16:10:30 4: TSCUL_XmitDlyHM:  CUL_TS  id:1123B8 rtoms:2340
2021.01.17 16:10:31 4: TSCUL_Parse: CUL_TS  15059753 A F403 00944244 01 09 94 A112 444444 1123B8  _CCAdly:4 _dhmSt:96
2021.01.17 16:10:31 4: TSCUL_Parse: CUL_TS  15059753 A F401 00944396 00 0A 94 8002 1123B8 444444 00 -53.5dB
2021.01.17 16:10:31 4: TSCUL_Write: CUL_TS sending As1095A0014444441123B800040000000000
2021.01.17 16:10:31 4: TSCUL_send:  CUL_TS  379740                 As 10 95 A001 444444 1123B8 00040000000000
2021.01.17 16:10:31 4: TSCUL_XmitDlyHM:  CUL_TS  id:1123B8 rtoms:2347
2021.01.17 16:10:31 4: TSCUL_Parse: CUL_TS  15059873 A F403 00944692 01 10 95 A001 444444 1123B8 00040000000000 _CCAdly:4 _dhmSt:296
2021.01.17 16:10:31 4: TSCUL_Parse: CUL_TS  15060124 A F403 00944968 01 10 95 A001 444444 1123B8 00040000000000 _CCAdly:4 _dhmSt:572
2021.01.17 16:10:31 4: TSCUL_Parse: CUL_TS  15060256 A F401 00945128 00 14 95 8010 1123B8 444444 0202010A440B440C440000 -53dB
2021.01.17 16:10:31 4: TSCUL_Write: CUL_TS sending As0B96A0014444441123B80103
2021.01.17 16:10:31 4: TSCUL_send:  CUL_TS  380252                 As 0B 96 A001 444444 1123B8 0103
2021.01.17 16:10:31 4: TSCUL_XmitDlyHM:  CUL_TS  id:1123B8 rtoms:2342
2021.01.17 16:10:31 4: TSCUL_Parse: CUL_TS  15060376 A F403 00945224 01 0B 96 A001 444444 1123B8 0103 _CCAdly:4 _dhmSt:96
2021.01.17 16:10:31 4: TSCUL_Parse: CUL_TS  15060511 A F401 00945384 00 13 96 8010 1123B8 444444 0111221401000000002D -53.5dB
2021.01.17 16:10:32 4: TSCUL_Write: CUL_TS sending As1097A0014444441123B801040000000005
2021.01.17 16:10:32 4: TSCUL_send:  CUL_TS  380516                 As 10 97 A001 444444 1123B8 01040000000005
2021.01.17 16:10:32 4: TSCUL_XmitDlyHM:  CUL_TS  id:1123B8 rtoms:2347
2021.01.17 16:10:32 4: TSCUL_Parse: CUL_TS  15060727 A F403 00945480 01 10 97 A001 444444 1123B8 01040000000005 _CCAdly:4 _dhmSt:96
2021.01.17 16:10:33 4: TSCUL_Parse: CUL_TS  15061956 A F401 00945636 00 10 97 8010 1123B8 444444 0209000A630000 -53.5dB
2021.01.17 16:13:00 4: TSCUL_Write: CUL_TS sending As0B94A2581122141123B803FD
2021.01.17 16:13:00 4: TSCUL_send:  CUL_TS  005015                 As 0B 94 A258 112214 1123B8 03FD
2021.01.17 16:13:00 4: TSCUL_XmitDlyHM:  CUL_TS  id:1123B8 rtoms:1178
2021.01.17 16:13:00 4: TSCUL_Parse: CUL_TS  15209408 A F303 01094256 01 0B 94 A258 112214 1123B8 03FD _CCAdly:4
2021.01.17 16:13:01 4: TSCUL_Parse: CUL_TS  15209541 A F301 01094412 00 0E 94 8202 1123B8 112214 0101C41032 -53.5dB
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 17 Januar 2021, 16:36:04
Hallo Jörg,

Zitatich sehe bei 99 aber keine Fehler im Device
motorErr blocked hätte bei 99% eigentlich beim 14er VD angezeigt werden müssen.

Von 26% auf 98% ist der 14er ohne Murren gefahren.

@Frank: solltest Du heute ein Update von CUL_HM und HMInfo fahren wollen, dann beobachte, ob Deine virtuellen TCs anlaufen. Da lauert ein Bug mit den Peer Namen (_chn-01), wie ich beim Umsetzen auf meine Version bemerkt habe, so dass ein virtueller TC nicht mehr checken kann, dass er mit einem VD gepeert ist und daher gar nicht mehr zum virtuellen TC werden kann.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: frank am 17 Januar 2021, 17:02:10
Zitat@frank: Adaptierfahrten hab ich seitdem ich das Problem festgestellt habe, schon des öfteren gemacht. Das ändert nichts.
beim adaptieren ist:
A1 zurückfahren
A2 total zurückgefahren, warten auf tasterdruck
A3 rausfahren, um die punkte 100% und 0% zu ermitteln.

wie weit ist der stössel bei A2 zurückgefahren?
fährt er vielleicht nicht mehr ganz zurück?


motorErr:
kleine abweichungen werden hier nicht gemeldet, nur die fehler codes F1-3, die auch im display zu sehen sind (siehe BA).

operState: hier steht dann etwa "target not met" und
operStateErrCnt: zählt hoch.



Zitat@Frank: solltest Du heute ein Update von CUL_HM und HMInfo fahren wollen,
vielen dank für den hinweis.  8)
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 17 Januar 2021, 17:30:55
Hallo Frank,

Zitatkleine abweichungen werden hier nicht gemeldet, nur die fehler codes F1-3, die auch im display zu sehen sind (siehe BA).
das ist in Jörgs Log zum 14er (Firmware 1.4) zu sehen:
2021.01.17 14:46:17 4: TSCUL_send:  CUL_TS  044991                 As 0B 72 A258 112214 1123B8 03FD
2021.01.17 14:46:17 4: TSCUL_XmitDlyHM:  CUL_TS  id:1123B8 rtoms:1178
2021.01.17 14:46:17 4: TSCUL_Parse: CUL_TS  10006503 A F103 03115380 01 0B 72 A258 112214 1123B8 03FD _CCAdly:4
2021.01.17 14:46:18 4: TSCUL_Parse: CUL_TS  10006636 A F101 03115540 00 0E 72 8202 1123B8 112214 0101C41230 -51.5dB
2021.01.17 14:49:16 4: TSCUL_Write: CUL_TS sending As0B73A2581122141123B800FD
2021.01.17 14:49:16 4: TSCUL_send:  CUL_TS  223257                 As 0B 73 A258 112214 1123B8 00FD
2021.01.17 14:49:16 4: TSCUL_XmitDlyHM:  CUL_TS  id:1123B8 rtoms:1178
2021.01.17 14:49:16 4: TSCUL_Parse: CUL_TS  10184770 A F103 03293648 01 0B 73 A258 112214 1123B8 00FD _CCAdly:4
2021.01.17 14:49:16 4: TSCUL_Parse: CUL_TS  10184911 A F101 03293808 00 0E 73 8202 1123B8 112214 0101C4022F -52.5dB

Laut CUL_HM Code wird aus 0xC4=196 => 98% und aus 0x12 -> motor:opening/motorErr:blocked bzw. 0x02 -> motor:stop/motorErr:blocked, demnach F1(?).

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 18 Januar 2021, 10:19:51
Zitat von: frank am 17 Januar 2021, 17:02:10
wie weit ist der stössel bei A2 zurückgefahren?
fährt er vielleicht nicht mehr ganz zurück?
Ganz schwer zu sagen. Ich spüre den Unterschied von 1% zumindest nicht :) Kam mir zumindest ok vor.

@Ansgar: Einen Übeltäter gibt es in meinem Produktivsystem auf jeden Fall noch: Ich rufe für einen über SPI angesteuerten Sensor ein C-Programm auf - und das hat auch usleeps drin. Nach intensiven Kämpfen in Perl mit pack/unpack eine ioctl Struktur aufzubauen und mit dem Sensor zu kommunizieren, habe ich das gestern Abend endlich geschafft. Da werde ich jetzt bei Gelegenheit ein einfaches Modul auf Basis meines ADS-Moduls bauen.
Richtig Schick wäre ja ein SPI Modul das kompatibel zum I2C Modul funktioniert. Der ADS hat eine SPI Variante (ADS1118) und z.B. der BME280 geht sowohl als auch. Das müsste man eigentlich transparent bauen können, so dass man nur die IODevice austauschen muss (naja, die Funktion i2cwrite würde halt bei SPI weiter i2c heissen müssen). Aber ich denke das überfordert meine Perl Kenntnisse momentan noch :)

Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: frank am 18 Januar 2021, 16:11:22
so sah letztens ein echtes blockieren bei mir aus, F1 im display:

2021.01.06 11:38:09.776 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:8531CFAA d:FF r:FFD9     m:69 A258 B3B3B3 193A9A 00FD
2021.01.06 11:38:09.928 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:8531D02D d:FF r:FFC5     m:69 8202 193A9A B3B3B3 0101C6003F
2021.01.06 11:45:45.381 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:8538C397 d:FF r:FFD9     m:6C A258 B3B3B3 193A9A 00FD
2021.01.06 11:45:45.526 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:8538C41A d:FF r:FFC5     m:6C 8202 193A9A B3B3B3 0101C6003F
2021.01.06 11:53:19.232 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:853FB0AB d:FF r:FFD9     m:6F A258 B3B3B3 193A9A 00FD
2021.01.06 11:53:19.380 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:853FB12E d:FF r:FFC5     m:6F 8202 193A9A B3B3B3 0101C6003F
2021.01.06 12:00:51.343 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:854696E8 d:FF r:FFD9     m:72 A258 B3B3B3 193A9A 00FD
2021.01.06 12:03:14.540 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:8548C65B d:FF r:FFD9     m:73 A258 B3B3B3 193A9A 00FD
2021.01.06 12:03:14.698 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:8548C6DE d:FF r:FFC5     m:73 8202 193A9A B3B3B3 0101C6003F
2021.01.06 12:11:05.387 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:854FF5DA d:FF r:FFD9     m:76 A258 B3B3B3 193A9A 00FD
2021.01.06 12:11:05.537 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:854FF65D d:FF r:FFC4     m:76 8202 193A9A B3B3B3 0101C6003F
2021.01.06 12:17:50.488 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:8556247A d:FF r:FFD9     m:79 A258 B3B3B3 193A9A 00FD
2021.01.06 12:17:50.640 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:855624FE d:FF r:FFC4     m:79 8202 193A9A B3B3B3 0101C6003F
2021.01.06 12:25:37.839 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:855D464B d:FF r:FFD9     m:7C A258 B3B3B3 193A9A 00FD
2021.01.06 12:25:37.988 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:855D46CE d:FF r:FFC5     m:7C 8202 193A9A B3B3B3 0101C6003F
2021.01.06 12:30:41.446 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:8561E79D d:FF r:FFD9     m:7E A258 B3B3B3 193A9A 03FD
2021.01.06 12:30:41.449 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:8561E821 d:FF r:FFC3     m:7E 8202 193A9A B3B3B3 0101C6003F
2021.01.06 12:38:04.343 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:8568AAB1 d:FF r:FFD9     m:81 A258 B3B3B3 193A9A 00FD
2021.01.06 12:38:04.489 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:8568AB35 d:FF r:FFC3     m:81 8202 193A9A B3B3B3 0101C6003E
2021.01.06 12:46:29.444 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:85705FFD d:FF r:FFD9     m:84 A258 B3B3B3 193A9A 03F8
2021.01.06 12:46:29.599 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:85706080 d:FF r:FFC3     m:84 8202 193A9A B3B3B3 0101C6203E
2021.01.06 12:48:48.897 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:857280CB d:FF r:FFD9     m:85 A258 B3B3B3 193A9A 03F0
2021.01.06 12:48:49.053 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:8572814E d:FF r:FFC2     m:85 8202 193A9A B3B3B3 0101C2203E
2021.01.06 12:53:48.809 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:85771470 d:FF r:FFD8     m:87 A258 B3B3B3 193A9A 03DE
2021.01.06 12:53:48.969 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:857714F3 d:FF r:FFC2     m:87 8202 193A9A B3B3B3 0101BC203E
2021.01.06 12:58:54.960 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:857BC07D d:FF r:FFD9     m:89 A258 B3B3B3 193A9A 03CF
2021.01.06 12:58:55.118 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:857BC100 d:FF r:FFC3     m:89 8202 193A9A B3B3B3 0101BC223E
2021.01.06 13:01:06.402 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:857DC207 d:FF r:FFD8     m:8A A258 B3B3B3 193A9A 03C7
2021.01.06 13:04:07.352 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:858084F3 d:FF r:FFD9     m:8B A258 B3B3B3 193A9A 03C0
2021.01.06 13:04:07.500 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:85808576 d:FF r:FFC3     m:8B 8202 193A9A B3B3B3 0101BC223E
2021.01.06 13:09:26.006 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:858561DB d:FF r:FFD8     m:8D A258 B3B3B3 193A9A 03B8
2021.01.06 13:09:26.164 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:8585625D d:FF r:FFC3     m:8D 8202 193A9A B3B3B3 0101BC2241
2021.01.06 13:11:43.743 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:85877BD4 d:FF r:FFD8     m:8E A258 B3B3B3 193A9A 03AE
2021.01.06 13:16:39.886 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:858C00D1 d:FF r:FFD8     m:90 A258 B3B3B3 193A9A 03A6
2021.01.06 13:16:40.035 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:858C0154 d:FF r:FFC3     m:90 8202 193A9A B3B3B3 0101BC223F
2021.01.06 13:21:42.266 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:85909E36 d:FF r:FFD8     m:92 A258 B3B3B3 193A9A 039E
2021.01.06 13:21:42.429 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:85909EB8 d:FF r:FFC4     m:92 8202 193A9A B3B3B3 0101BC223E
2021.01.06 13:26:51.160 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:85955500 d:FF r:FFD8     m:94 A258 B3B3B3 193A9A 0397
2021.01.06 13:26:51.376 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:85955583 d:FF r:FFC5     m:94 8202 193A9A B3B3B3 0101BC223E
2021.01.06 13:32:06.311 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:859A2437 d:FF r:FFD8     m:96 A258 B3B3B3 193A9A 038F
2021.01.06 13:32:06.469 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:859A24BB d:FF r:FFC4     m:96 8202 193A9A B3B3B3 0101BC223E
2021.01.06 13:36:23.717 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:859E11D0 d:FF r:FFD8     m:98 A258 B3B3B3 193A9A 0385
2021.01.06 13:36:23.878 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:859E1253 d:FF r:FFC4     m:98 8202 193A9A B3B3B3 0101BC223E
2021.01.06 13:44:13.564 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:85A53D69 d:FF r:FFD8     m:9B A258 B3B3B3 193A9A 0085
2021.01.06 13:44:13.727 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:85A53DEB d:FF r:FFC4     m:9B 8202 193A9A B3B3B3 0101BC023E
2021.01.06 13:46:21.293 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:85A7304F d:FF r:FFD8     m:9C A258 B3B3B3 193A9A 037D
2021.01.06 13:52:01.665 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:85AC6229 d:FF r:FFD8     m:9E A258 B3B3B3 193A9A 0375
2021.01.06 13:52:01.828 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:85AC62AC d:FF r:FFC4     m:9E 8202 193A9A B3B3B3 0101BC223E
2021.01.06 13:59:48.020 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:85B38014 d:FF r:FFD8     m:A1 A258 B3B3B3 193A9A 036B
2021.01.06 13:59:48.181 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:85B38097 d:FF r:FFC4     m:A1 8202 193A9A B3B3B3 0101BC223E
2021.01.06 14:07:32.618 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:85BA9726 d:FF r:FFD8     m:A4 A258 B3B3B3 193A9A 0363
2021.01.06 14:07:32.776 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:85BA97A8 d:FF r:FFC4     m:A4 8202 193A9A B3B3B3 0101BC223E
2021.01.06 14:09:38.574 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:85BC8335 d:FF r:FFD8     m:A5 A258 B3B3B3 193A9A 0359
2021.01.06 14:15:15.218 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:85C1A667 d:FF r:FFD8     m:A7 A258 B3B3B3 193A9A 0059
2021.01.06 14:15:15.384 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:85C1A6EB d:FF r:FFC5     m:A7 8202 193A9A B3B3B3 0101BC023E
2021.01.06 14:22:56.070 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:85C8AED4 d:FF r:FFD8     m:AA A258 B3B3B3 193A9A 034F
2021.01.06 14:22:56.238 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:85C8AF57 d:FF r:FFC5     m:AA 8202 193A9A B3B3B3 0101BC223E
2021.01.06 14:28:16.470 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:85CD928C d:FF r:FFD8     m:AC A258 B3B3B3 193A9A 0347
2021.01.06 14:28:16.627 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:85CD930F d:FF r:FFC5     m:AC 8202 193A9A B3B3B3 0101BC223E
2021.01.06 14:30:35.209 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:85CFB06E d:FF r:FFD8     m:AD A258 B3B3B3 193A9A 0345
2021.01.06 14:35:33.079 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:85D43C3F d:FF r:FFD8     m:AF A258 B3B3B3 193A9A 0045
2021.01.06 14:35:33.247 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:85D43CC2 d:FF r:FFC4     m:AF 8202 193A9A B3B3B3 0101BC023E
2021.01.06 14:42:47.934 0: HMLAN_Parse: hmlan1 R:EB3B3B3   stat:0000 t:85DADF1A d:FF r:FFD8     m:B2 A258 B3B3B3 193A9A 0045
2021.01.06 14:42:48.206 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:85DADF9D d:FF r:FFBD     m:B2 8202 193A9A B3B3B3 0101FE064B


in der letzten message nach einem adaptierungsversuch hat er dann F3 (adjusting range too small) gemeldet.

ich musste den vd komplett auseinanderschrauben, da der stössel zu weit reingefahren war.
so ein totalausfall hatte ich das erste mal.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 18 Januar 2021, 19:47:45
Hallo Frank,

2021.01.06 12:58:55.118 0: HMLAN_Parse: hmlan1 R:E193A9A   stat:0000 t:857BC100 d:FF r:FFC3     m:89 8202 193A9A B3B3B3 0101BC223E
Hier hat er schon angefangen mit 0x22 Blockade (von 94% auf 87%) zu melden. Hat Dein Ventil da eventuell mechanisch gehangen?
Das würde zumindest den zu kleinen Einstellbereich nach der Adaptierfahrt mit erklären. (natürlich nicht, dass er sich dann auch noch intern fest fährt)

Lustig die Meldung des Öffnungsgrads in der letzten Zeile. 0xFE entspräche 127%, soll aber wohl eher FEhler bedeuten, könnte ich mir vorstellen.

Apropos Ventil Schwergängigkeit, machst Du in FHEM regelmäßig eine "Entkalkungsfahrt", wie es der reale TC laut Anleitung wohl machen würde?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 18 Januar 2021, 19:52:21
Hallo Jörg,

ZitatDas müsste man eigentlich transparent bauen können, so dass man nur die IODevice austauschen muss (naja, die Funktion i2cwrite würde halt bei SPI weiter i2c heissen müssen). Aber ich denke das überfordert meine Perl Kenntnisse momentan noch
Eventuell kannst Du Dir auch noch Anregungen aus dem 97_PiXtendV2.pm Modul zu SPI holen. Da sieht's nach SPI Kommunikation aus + noch mehr.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 19 Januar 2021, 13:59:12
Hi Ansgar,

Zwischenstand mit hmAgcMaxDVGA = 0, ich schalte jetzt mal auf  =2 um.


    Device          receive         from             last   avg      min_max    count
    HM_VD_14        CUL_TS          HM_VD_14         -55.5  -55.5  -56.5< -52.5   468
    HM_VD_14        HM_VD_14        CUL_TS           -52.0  -51.7  -52.0< -48.0   468
    HM_VD_20        CUL_TS          HM_VD_20         -47.0  -46.9  -48.5< -46.0   449
    HM_VD_20        HM_VD_20        CUL_TS           -46.0  -46.1  -48.0< -45.0   449

    name     :State           |CmdPend   |Snd       |Resnd     #CmdDel    |ResndFail |Nack      |IOerr     
    HM_VD_14 : done           |  -       | 484      |  -       #  -       | 15       |  -       |  -       
    HM_VD_20 : done           |  -       | 477      |  -       #  -       | 26       |  -       |  -       
=======================================================================================================
    sum      0                |0         |961       |0         #0         |41        |0         |0     


Was mir aufgefallen ist: Er verliert irgendwie Registerinfos.


missing register list
    HM_VD_14: RegL_00.,RegL_05.
    HM_VD_20: RegL_00.,RegL_05.

PairedTo missing/unknown
    HM_VD_14:
    HM_VD_20:


Nach einem getConfig passt es dann wieder. Sofort nach dem ändern von hmAgcMaxDVGA und "clear all" vom hminfo wieder das selbe.

Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 19 Januar 2021, 19:00:07
Hallo Jörg,

hast Du auch noch gleichzeitig an der Antennenposition oder am Offset gedreht? Die RSSI Werte sind zwischen den beiden "gewandert".
Prozentual ist es insgesamt bei beiden etwas schlechter geworden.

ZitatWas mir aufgefallen ist: Er verliert irgendwie Registerinfos.
Wie hast Du das Attribut autoReadReg jetzt bei den beiden stehen?
Bei >= 5 wäre das so wohl gewollt bei clear all, warum auch immer.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 19 Januar 2021, 19:29:22
Hallo Ansgar,

Offset ist gleich, aber die beiden Ventile haben die Plätze getauscht (wegen dem 99% Fehler). Beide sind sehr nah an der CUL (ca. 1.5m und 3.5m).
autoReadReg ist auf default - beide Ventile auf 4.

Die aktuelle Versuchsreihe mit hmAgcMaxDVGA=2 läuft übrigens soweit etwas besser. Erst in Summe 6 fails auf 248 Sends. Mein SPI Modul ist jetzt übrigens soweit nutzbar und läuft (Source auch unter meinem GitHub).

Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 19 Januar 2021, 20:21:16
Hallo Jörg,

ZitatautoReadReg ist auf default - beide Ventile auf 4.
Ok, das clear all sorgt aber dafür, dass die Register Listen gelöscht werden (immer noch, wofür auch immer).

ZitatDie aktuelle Versuchsreihe mit hmAgcMaxDVGA=2 läuft übrigens soweit etwas besser. Erst in Summe 6 fails auf 248 Sends.
Gib dem was mehr Zeit vor dem Hoffnungsschimmer.
Wenn's weiter besser ausschaut, kannst Du natürlich auch die 3 noch testen. Die Empfindlichkeit sinkt damit zwar, aber Du willst ja nur auf kurze Distanz empfangen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: frank am 25 Januar 2021, 15:06:46
hi ansgar,

ZitatHier hat er schon angefangen mit 0x22 Blockade (von 94% auf 87%) zu melden. Hat Dein Ventil da eventuell mechanisch gehangen?
Das würde zumindest den zu kleinen Einstellbereich nach der Adaptierfahrt mit erklären. (natürlich nicht, dass er sich dann auch noch intern fest fährt)
das war schon ein echtes blockieren, würde ich meinen, da nach dem entfernen des vd beim drücken auf den ventilstift ein einmaliges "rucken" zu spüren war.
das ventil ist auch noch eines der ältesten, vielleicht 20 jahre alt.

ZitatApropos Ventil Schwergängigkeit, machst Du in FHEM regelmäßig eine "Entkalkungsfahrt", wie es der reale TC laut Anleitung wohl machen würde?
das hatte ich anfänglich überlegt.
doch dann gab es einen thread, in dem viele von hängen gebliebenen ventilen beim rt während der entkalkungsfahrt berichtet haben. damit war die idee erst einmal gestorben.



macht es eigentlich sinn, tsculfw auch mit martins "original" dateien zu nutzen?
mich würde nämlich die möglichkeit der frequenzanpassung für homematic interessieren.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 25 Januar 2021, 19:36:00
Hallo Frank,

Zitatmacht es eigentlich sinn, tsculfw auch mit martins "original" dateien zu nutzen?
mich würde nämlich die möglichkeit der frequenzanpassung für homematic interessieren.

Gute Frage. Da ich es nicht teste, kann ich Dir nichts direktes zu Nebenwirkungen nach den letzten Ständen sagen.

Ich habe allerdings Optimierungen für CULs eingebaut und Martin hat nicht alles bezüglich TSCUL übernommen.
Insbesondere, dass zum FHEM Start die schon im CUL hinterlegten devices ausgelesen und nicht glöscht werden, was bei den CULs mit wenig Speicher zu weniger EEPROM Verschleiß führen soll, da auf denen das EEPROM als Speicher herhalten muss. Das betrifft nanoCULs und CUL V3/V4, um die wesentlichen zu nennen.
Außerdem habe ich die IO Zuteilung nach RSSI geändert, insbesondere mit einstellbarer switch Hysterese, um unnötige IO Umschaltung für solche CULs minimieren zu können.

Für virtuelle THs Sensoren, die nur einen peer haben, wird auch eine dynamische IO Zuweisung nach RSSI gemacht.

Virtuelle THs und TCs sind etwas anders im Sendeverhalten, wie Du ja schon mitbekommen hast.

Bei RTs werden logisch unnötige Reading Updates nicht mehr durchgeführt (auch beim Weather Channel wird die Temperatur noch raus fliegen).
Grundsätzlich bevorzuge ich den state (und lst) update zuletzt nach allen anderen Readings (und das auch mit Timer leicht verzögert), so dass das state event meist auch anzeigt, dass alle anderen Readings schon aktualisiert wurden und damit aktuell direkt aus dem device gelesen werden können, statt mehrere Events zu aktivieren und verarbeiten zu müssen.

Und viele Kleinigkeiten mehr, wenn mir was auffällt oder im Forum was auffällt. Die letzte Änderung von Martin ist noch nicht in dem enthalten, was Du hier findest. Es ist schwierig, einen Überblick zu bekommen, wo welche Namensvariante verwendet wird/wurde/werden muss, um das gerade zu ziehen.

Feedback zur Nutzung mit Standard CUL_HM fehlt hier (sicherlich weil ich ja auch darauf hinweise, meine Variante zu nutzen).
Probier es halt (kontrolliert) aus und berichte. Allerdings musst Du Dich mit Änderungswünschen an der Standard CUL_HM letztlich an Martin wenden. Ich kann dann nur versuchen zur Problemaufklärung beizutragen. Im Code umsetzen muss es Martin.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 26 Januar 2021, 13:54:18
So, Testreihe mit den verschiedenen hmAgcMaxDVGA settings abgeschlossen.
Nach dieser Reihe hat der Wert =2 leicht die Nase vorn - die Daten basieren allerdings auf weniger Sends als bei den anderen. Ich stelle das jetzt mal ein und lasse es so über länger laufen.
Alles in allem sind die Werte aber nicht so unterschiedlich, wobei "0" und "3" schon sichtbar schlechter sind.

Details siehe Textfile.

Gruß,
Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 26 Januar 2021, 19:51:21
Hallo Jörg,

danke für's Feedback und die Tests.

Die Übertragung und Recover klappt inzwischen recht gut. Der 1.4 hat nun die Nase vorn, sowohl bei der Übertragung, als auch beim Recover.

Systemverspätungen kommen recht häufig, belasten nun aber immehin nicht sinnlos das Funkbudget (auch wenn es bei Deinem System derzeit wohl keine Rolle spielt). Als Du die 0 getestet hast, waren besonders viele mSkp dabei, war da was anders im System?

Bezüglich MAX_DVGA ist 1 für den 2.0er und 2 für den 1.4er besser auf diese kurze Distanz deutet tQ an, leider ist keine drastische Verbesserung zu erkennen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 26 Januar 2021, 22:00:29
Hallo Ansgar,

bei dieser Testreihe sollte alles in etwa ähnlich gewesen sein. Natürlich können die Parameter die letztendlich zu Ventiländerungen geführt haben anders gewesen sein. Grundsätzlich ist zu sagen, dass der 2.0 deutlich mehr Änderungsbefehle gehabt hat (adaptive Regelung abhängig von Eingangs/Ausgangswert die sich ständig nachregelt) als der 1.4er (Fussbodenheizung die eigentlich nur zu festen Zeiten auf an oder aus geht, sowie abregelt wenn jemand länger das Fenster aufmacht).

Gruß,
Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 29 Januar 2021, 17:04:28
Hi Ansgar,

ich hatte gelegentlich eine PERL WARNING im logfile and hab den stacktrace jetzt mal eingeschaltet, jetzt kommt ständig (alle 1-10 Sekunden) folgende Meldung:
2021.01.29 17:01:28 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4591.
2021.01.29 17:01:28 1: stacktrace:
2021.01.29 17:01:28 1:     main::__ANON__                      called by fhem.pl (4591)
2021.01.29 17:01:28 1:     main::AttrVal                       called by ./FHEM/00_TSCUL.pm (1378)
2021.01.29 17:01:28 1:     main::TSCUL_ParseTsHM               called by ./FHEM/00_TSCUL.pm (708)
2021.01.29 17:01:28 1:     main::TSCUL_Parse                   called by ./FHEM/00_TSCUL.pm (636)
2021.01.29 17:01:28 1:     main::TSCUL_Read                    called by fhem.pl (3818)
2021.01.29 17:01:28 1:     main::CallFn                        called by fhem.pl (759)


Ist da noch was falsch konfiguriert? Oder kannst du da noch was checken und abfangen?

Edit: hier noch das list:
Internals:
   CMDS       ABCFGJKRUVWXYeiltx
   CUL_TS_MSGCNT 252004
   CUL_TS_TIME 2021-01-29 17:04:54
   Clients    STACKABLETS:STACKABLE:CUL_HM:CUL_IR:TSHMS
   DEF        /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@38400 4444
   DeviceName /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@38400
   FD         12
   FHTID      4444
   FUUID      5ffa454c-f33f-0931-cfe7-68a61b161da0b76b
   NAME       CUL_TS
   NR         57
   PARTIAL   
   RAWMSG     A0F63C61069486B0000000A80BF0B0000::-61.5:CUL_TS:
   RSSI       -61.5
   ReReadTO   0.002
   STATE      Initialized
   TYPE       TSCUL
   VERSION    VTS 0.38 CSM868
   VERSION_HW nanoCUL_V1.x_0014
   VERSION_TS yes AES ChTblSize:209
   XmitOpen   1
   assignUpdCntI 40
   assignedIDsCnt 2
   initString XP0C
X21
Ar
AM5
AH444444
   msgLoadCurrent 0
   owner_CCU  VCCU
   MatchList:
     A:CUL_HM   ^A....................
     B:CUL_IR   ^I............
     C:TSHMS    ^810e04......a001
     Y:STACKABLETS ^\*
     Z:STACKABLE ^\*
   READINGS:
     2021-01-29 15:58:31   FreqOffsEst      +4.761
     2021-01-18 13:15:16   SlowRfconf      freq:868.300MHz freqOffs:0.000kHz bWidth:325kHz freqIF:330.08kHz rAmpl:42dB sens:12dB dRate:2.461kBit/s
agcPrio:0 agcWait:16 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:0 AGC_FREEZE:0
CCAmode:1 csRelThr:10dB csAbsThr:7dB  peakfilter:88
     2021-01-29 14:00:47   Xmit-Events     non-HM:6 ok:4 init:4 disconnected:3
     2021-01-29 14:19:04   ccconf          freq:868.300MHz freqOffs:0.000kHz bWidth:101kHz freqIF:152.34kHz rAmpl:33dB sens:8dB dRate:9.993kBit/s
agcPrio:1 agcWait:16 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:1 AGC_FREEZE:0
CCAmode:3 csRelThr:10dB csAbsThr:7dB
     2021-01-29 14:00:44   cmds             A B C F G J K R U V W X Y e i l t x
     2021-01-29 14:00:47   cond            ok
     2021-01-18 13:15:16   peakfilter      88 µs
     2021-01-29 13:59:25   prot_disconnected last
     2021-01-29 14:00:45   prot_init       last
     2021-01-18 13:15:16   prot_non-HM     last
     2021-01-29 14:00:47   prot_ok         last
     2021-01-29 16:56:43   scF             0.999656134943209
     2021-01-29 14:00:46   state           Initialized
   helper:
     CUrun      1
     ChkPart    0
     RA_Timeout 0
     SVTS       1
     VTS        1
     VTS_ACK    1
     VTS_AES    1
     assIdCnt   2
     assIdRep   2
     nRec       0
     recd       1
     DEVIOTS:
       RXfailTO   
     HM:
       ChTblSize  209
       FUP        0
       HMactive   1
       hmCrdts    0
       hmSbusy    0
       ChTbl:
         1123B800   00
         1A758E00   00
       msgCNT:
         0x01       252002
         0x02       3367
         0x03       12015
         0x09       466
       unknwn:
         161554:
           lstRecType 02
           nextSend   1611936196.50303
           nxtSndMcnt EA
           tgtDly     88
           lRcTm:
             CUL_TS     10958728
             tnms       249718595
         16A0AB:
           lstRecType 58
           nextSend   1611936061.03333
           nxtSndMcnt DB
           tgtDly     88
           lRcTm:
             CUL_TS     10823212
             tnms       249583126
         16A241:
           lstRecType 70
           nextSend   1611935286.84245
           nxtSndMcnt E4
           tgtDly     88
           lRcTm:
             CUL_TS     10048756
             tnms       248808931
         18DD8E:
           lstRecType 70
           nextSend   1611936255.36605
           nxtSndMcnt 7B
           tgtDly     88
           lRcTm:
             CUL_TS     11016620
             tnms       249777542
         19CA72:
           lstRecType 58
           nextSend   1611936259.32987
           nxtSndMcnt 95
           tgtDly     88
           lRcTm:
             CUL_TS     11021576
             tnms       249781419
         1A7D5E:
           lstRecType 70
           nextSend   1611936175.85922
           nxtSndMcnt DF
           tgtDly     88
           lRcTm:
             CUL_TS     10938124
             tnms       249697950
         1A881A:
           lstRecType 02
           nextSend   1611936191.17282
           nxtSndMcnt DC
           tgtDly     88
           lRcTm:
             CUL_TS     10953396
             tnms       249713262
         1CC674:
           lstRecType 03
           nextSend   1611843907.33293
           nxtSndMcnt C3
           tgtDly     88
           lRcTm:
             CUL_TS     871837676
             tnms       157429421
         1CE0A8:
           lstRecType 58
           nextSend   1611936213.64922
           nxtSndMcnt E1
           tgtDly     88
           lRcTm:
             CUL_TS     10975880
             tnms       249735741
         1CEF5C:
           lstRecType 02
           nextSend   1611936213.78565
           nxtSndMcnt E1
           tgtDly     88
           lRcTm:
             CUL_TS     10976016
             tnms       249735874
         1D8CAF:
           lstRecType 70
           nextSend   1611936267.83183
           nxtSndMcnt 04
           tgtDly     88
           lRcTm:
             CUL_TS     11030124
             tnms       249789920
         1DA4C5:
           lstRecType 02
           nextSend   1611936259.45945
           nxtSndMcnt 95
           tgtDly     88
           lRcTm:
             CUL_TS     11021704
             tnms       249781547
         21A713:
           lstRecType 10
           nextSend   1611904056.25892
           nxtSndMcnt 52
           tgtDly     88
           lRcTm:
             CUL_TS     931987548
             tnms       217578347
         25FFA7:
           lstRecType 83
           nextSend   1611921780.88226
           nxtSndMcnt 12
           tgtDly     88
           lRcTm:
             CUL_TS     949711340
             tnms       235303058
         26A653:
           lstRecType 10
           nextSend   1611928957.31443
           nxtSndMcnt 4E
           tgtDly     88
           lRcTm:
             CUL_TS     3717060
             tnms       242479402
         26A678:
           lstRecType 10
           nextSend   1611914406.98732
           nxtSndMcnt 64
           tgtDly     88
           lRcTm:
             CUL_TS     942338392
             tnms       227929075
         26A874:
           lstRecType 10
           nextSend   1611565015.18707
           nxtSndMcnt 01
           tgtDly     88
           lRcTm:
             CUL_TS     592940832
             tnms       952279099
         29628D:
           lstRecType 10
           nextSend   1611870834.90848
           nxtSndMcnt 1C
           tgtDly     88
           lRcTm:
             CUL_TS     898765580
             tnms       184356997
         2D4F8E:
           lstRecType 83
           nextSend   1611936205.63176
           nxtSndMcnt 12
           tgtDly     88
           lRcTm:
             CUL_TS     10967860
             tnms       249727721
         2E296F:
           lstRecType 10
           nextSend   1611911058.60252
           nxtSndMcnt 02
           tgtDly     88
           lRcTm:
             CUL_TS     938989964
             tnms       224580696
         2E7962:
           lstRecType 10
           nextSend   1611936278.14402
           nxtSndMcnt 83
           tgtDly     88
           lRcTm:
             CUL_TS     11040440
             tnms       249800233
         2E7AE4:
           lstRecType 10
           nextSend   1611935995.32048
           nxtSndMcnt B6
           tgtDly     88
           lRcTm:
             CUL_TS     10757476
             tnms       249517410
         2E89EE:
           lstRecType 10
           nextSend   1611936215.6408
           nxtSndMcnt 10
           tgtDly     88
           lRcTm:
             CUL_TS     10977872
             tnms       249737732
         31068C:
           lstRecType 10
           nextSend   1611936202.457
           nxtSndMcnt AB
           tgtDly     88
           lRcTm:
             CUL_TS     10964728
             tnms       249724547
         314411:
           lstRecType 10
           nextSend   1611934822.57873
           nxtSndMcnt 47
           tgtDly     88
           lRcTm:
             CUL_TS     9584336
             tnms       248344672
         32C710:
           lstRecType 8E
           nextSend   1611935173.01703
           nxtSndMcnt 10
           tgtDly     88
           lRcTm:
             CUL_TS     9934892
             tnms       248695108
         332334:
           lstRecType 8E
           nextSend   1611935993.33281
           nxtSndMcnt 10
           tgtDly     88
           lRcTm:
             CUL_TS     10755488
             tnms       249515421
         3360EA:
           lstRecType 8E
           nextSend   1611686037.90534
           nxtSndMcnt 10
           tgtDly     88
           lRcTm:
             CUL_TS     8543596
             tnms       1073301819
         3CFC44:
           lstRecType 10
           nextSend   1611580919.56704
           nxtSndMcnt 8A
           tgtDly     88
           lRcTm:
             CUL_TS     608846136
             tnms       968183481
         42586A:
           lstRecType 83
           nextSend   1611936201.5972
           nxtSndMcnt 12
           tgtDly     88
           lRcTm:
             CUL_TS     10963824
             tnms       249723688
         463350:
           lstRecType 10
           nextSend   1611914406.38254
           nxtSndMcnt 67
           tgtDly     88
           lRcTm:
             CUL_TS     942337788
             tnms       227928474
         48DC17:
           lstRecType 10
           nextSend   1611936290.30008
           nxtSndMcnt 73
           tgtDly     88
           lRcTm:
             CUL_TS     11052556
             tnms       249812389
         4EFE5E:
           lstRecType 03
           nextSend   1611934960.37821
           nxtSndMcnt B0
           tgtDly     88
           lRcTm:
             CUL_TS     9722180
             tnms       248482466
         56E3F7:
           lstRecType 83
           nextSend   1611936014.31025
           nxtSndMcnt 12
           tgtDly     88
           lRcTm:
             CUL_TS     10776472
             tnms       249536398
         5C6E15:
           lstRecType 83
           nextSend   1611936292.21594
           nxtSndMcnt 12
           tgtDly     88
           lRcTm:
             CUL_TS     11054472
             tnms       249814306
         5CD958:
           lstRecType 5E
           nextSend   1611936223.04252
           nxtSndMcnt B3
           tgtDly     88
           lRcTm:
             CUL_TS     10985320
             tnms       249745133
         5F321C:
           lstRecType 8E
           nextSend   1611686396.4302
           nxtSndMcnt 10
           tgtDly     88
           lRcTm:
             CUL_TS     10846564
             tnms       1073660345
         6032C1:
           lstRecType 02
           nextSend   1611904083.33489
           nxtSndMcnt 09
           tgtDly     88
           lRcTm:
             CUL_TS     932014580
             tnms       217605426
         619CAC:
           lstRecType 10
           nextSend   1611677747.35965
           nxtSndMcnt FF
           tgtDly     88
           lRcTm:
             CUL_TS     897942248
             tnms       1065011274
         644A7F:
           lstRecType 10
           nextSend   1611904017.32235
           nxtSndMcnt 7E
           tgtDly     88
           lRcTm:
             CUL_TS     931948556
             tnms       217539410
         6553A9:
           lstRecType 10
           nextSend   1611904027.71853
           nxtSndMcnt 56
           tgtDly     88
           lRcTm:
             CUL_TS     931958964
             tnms       217549808
         6555A5:
           lstRecType 10
           nextSend   1611904002.1777
           nxtSndMcnt 52
           tgtDly     88
           lRcTm:
             CUL_TS     931932328
             tnms       217524354
         65B0D7:
           lstRecType 10
           nextSend   1611914404.86397
           nxtSndMcnt 67
           tgtDly     88
           lRcTm:
             CUL_TS     942336268
             tnms       227926952
         65B0FC:
           lstRecType 02
           nextSend   1611904032.68289
           nxtSndMcnt 51
           tgtDly     88
           lRcTm:
             CUL_TS     931963928
             tnms       217554779
         6629F7:
           lstRecType 03
           nextSend   1611933628.5166
           nxtSndMcnt ED
           tgtDly     88
           lRcTm:
             CUL_TS     8389864
             tnms       247150605
         666666:
           lstRecType 3F
           nextSend   1611862225.79763
           nxtSndMcnt 01
           tgtDly     88
           lRcTm:
             CUL_TS     890156364
             tnms       175747888
         668A0C:
           lstRecType 10
           nextSend   1611904038.07929
           nxtSndMcnt 5B
           tgtDly     88
           lRcTm:
             CUL_TS     931969324
             tnms       217560168
         669BF5:
           lstRecType 10
           nextSend   1611904066.37459
           nxtSndMcnt 52
           tgtDly     88
           lRcTm:
             CUL_TS     931997620
             tnms       217588464
         669E36:
           lstRecType 10
           nextSend   1611904062.7309
           nxtSndMcnt 51
           tgtDly     88
           lRcTm:
             CUL_TS     931993976
             tnms       217584823
         67274B:
           lstRecType 10
           nextSend   1611904044.95879
           nxtSndMcnt 56
           tgtDly     88
           lRcTm:
             CUL_TS     931976204
             tnms       217567047
         67276B:
           lstRecType 10
           nextSend   1611934814.8057
           nxtSndMcnt 47
           tgtDly     88
           lRcTm:
             CUL_TS     9576608
             tnms       248336898
         672796:
           lstRecType 10
           nextSend   1611934819.47228
           nxtSndMcnt 2C
           tgtDly     88
           lRcTm:
             CUL_TS     9581228
             tnms       248341561
         68065C:
           lstRecType 10
           nextSend   1611565013.36638
           nxtSndMcnt 01
           tgtDly     88
           lRcTm:
             CUL_TS     592939764
             tnms       952277279
         68066D:
           lstRecType 10
           nextSend   1611934826.58167
           nxtSndMcnt 35
           tgtDly     88
           lRcTm:
             CUL_TS     9588340
             tnms       248348676
         682EB1:
           lstRecType 8E
           nextSend   1611935274.566
           nxtSndMcnt 10
           tgtDly     88
           lRcTm:
             CUL_TS     10036476
             tnms       248796654
         6890D0:
           lstRecType 03
           nextSend   1611934021.56192
           nxtSndMcnt F0
           tgtDly     88
           lRcTm:
             CUL_TS     8783044
             tnms       247543652
         689108:
           lstRecType 03
           nextSend   1611933396.47817
           nxtSndMcnt 0E
           tgtDly     88
           lRcTm:
             CUL_TS     8157744
             tnms       246918567
         68CE6F:
           lstRecType 03
           nextSend   1611922886.41873
           nxtSndMcnt D7
           tgtDly     88
           lRcTm:
             CUL_TS     950817912
             tnms       236408509
         68D0AB:
           lstRecType 03
           nextSend   1611934247.17696
           nxtSndMcnt 61
           tgtDly     88
           lRcTm:
             CUL_TS     9008736
             tnms       247769267
         68D4CC:
           lstRecType 03
           nextSend   1611934585.60075
           nxtSndMcnt 95
           tgtDly     88
           lRcTm:
             CUL_TS     9347320
             tnms       248107691
         69486B:
           lstRecType 10
           nextSend   1611936294.15523
           nxtSndMcnt 63
           tgtDly     88
           lRcTm:
             CUL_TS     11056456
             tnms       249816243
         698041:
           lstRecType 5E
           nextSend   1611936221.35055
           nxtSndMcnt E4
           tgtDly     88
           lRcTm:
             CUL_TS     10983628
             tnms       249743440
         699D79:
           lstRecType 40
           nextSend   1611851533.46749
           nxtSndMcnt D5
           tgtDly     88
           lRcTm:
             CUL_TS     879463904
             tnms       165055556
         6A60E8:
           lstRecType 11
           nextSend   1611935843.39615
           nxtSndMcnt 12
           tgtDly     88
           lRcTm:
             CUL_TS     10605500
             tnms       249365485
         6ACE73:
           lstRecType 10
           nextSend   1611936156.66146
           nxtSndMcnt 06
           tgtDly     88
           lRcTm:
             CUL_TS     10918872
             tnms       249678752
         6B4EAE:
           lstRecType 10
           nextSend   1611935253.21019
           nxtSndMcnt D6
           tgtDly     44.5
           lRcTm:
             CUL_TS     10015156
             tnms       248775343
         6B73DE:
           lstRecType 02
           nextSend   1611935043.48675
           nxtSndMcnt 41
           tgtDly     88
           lRcTm:
             CUL_TS     9803812
             tnms       248565663
         6EDCFA:
           lstRecType 8E
           nextSend   1611935798.29889
           nxtSndMcnt 10
           tgtDly     88
           lRcTm:
             CUL_TS     10560388
             tnms       249320389
         704203:
           lstRecType 10
           nextSend   1611904073.02698
           nxtSndMcnt 52
           tgtDly     88
           lRcTm:
             CUL_TS     932004272
             tnms       217595115
         74A42E:
           lstRecType 83
           nextSend   1611936118.51022
           nxtSndMcnt 12
           tgtDly     88
           lRcTm:
             CUL_TS     10880708
             tnms       249640598
         B3D798:
           lstRecType 8E
           nextSend   1611686447.10159
           nxtSndMcnt 10
           tgtDly     88
           lRcTm:
             CUL_TS     10605532
             tnms       1073711017
     cnd:
       0          4
       250        6
       253        3
       255        4
     hmLogHist:
        14864109 A F001 10985276 00 14 B3 845E 5CD958 000000 958C85000447004108CC04 -57dB
        14864152 A F001 10985320 00 14 B3 C45E 5CD958 000000 958C85000447004108CC04 _rep -60.5dB
        14880396 A F001 11001568 00 0C 95 8670 19CA72 000000 00D334 -71dB
        14896518 A F001 11016620 00 0C 7B 8670 18DD8E 000000 80DB32 -82dB
        14900395 A F001 11021576 00 0B 95 A258 19CA72 1DA4C5 0075 -71dB
        14900523 A F001 11021704 00 0E 95 8202 1DA4C5 19CA72 01015C002D -80.5dB
        14908896 A F001 11030080 00 0C 04 8670 1D8CAF 000000 00ED2B -69.5dB
        14908940 A F001 11030124 00 0C 04 C670 1D8CAF 000000 00ED2B _rep -60dB
        14919209 A F001 11040396 00 0F 83 8610 2E7962 000000 0A80BE090000 -69.5dB
        14919253 A F001 11040440 00 0F 83 C610 2E7962 000000 0A80BE090000 _rep -60dB
        14931365 A F001 11052556 00 0F 73 8610 48DC17 000000 0A80BE100000 -82.5dB
        14933282 A F001 11054472 00 13 12 0083 5C6E15 F00001 03B8D8697E35823AB136 -53.5dB
        14935219 A F001 11056412 00 0F 63 8610 69486B 000000 0A80BF0B0000 -67dB
        14935265 A F001 11056456 00 0F 63 C610 69486B 000000 0A80BF0B0000 _rep -61.5dB
     hmQ:
       000000:
       1123B8:
       1A758E:
     ids:
       1123B8:
         cfg        +1123B8,00,00,00
         name       HM_VD_14
       1A758E:
         cfg        +1A758E,00,00,00
         name       HM_VD_20
     loadLvl:
       bl         40
     q:
       ATrNo      0
       HMcndN     0
       InQueues   0
       RQLSt      0
       XRpCnt     0
       XRpTm      1611925386.1815
       answerPend 0
       hmLanQlen  3
       apIDs:
         1123B8     0
         1A758E     0
     ref:
       Sdly       2
       TmBmCnt    13
       ioBR       3840
       ioBRMax    3643.43813956275
       ioBRMean   3485.98049590924
       lHMt       11056412
       lSys       249816243
       pTTu       1024
       pndAs      0
       pndCUAp    0
       pndTuP     1
       pngLm      17
       pngRef     6
       scErr      3.11781815369613
       scF        0.999656134943209
       scFN       7
       scHT       10566124
       scST       249326123
       scpTm      1611935803.94139
Attributes:
   event-on-update-reading FreqOffsEst
   hmId       444444
   hmLanQlen  3_normal
   rfmode     HomeMatic
   room       CUL_HM
   verbose    0


Danke,
Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 30 Januar 2021, 12:08:10
Hallo Jörg,

irgendwo wird noch eine kaputte CUL_HM Definition eingetragen, was noch dazu führt. Vermutlich über undefinierte devices, die empfangen werden und davon hast Du ja reichlich. Mühsam, so was zu finden.

In meiner fhem.pl Variante habe ich abgefangen, dass auch ein undefinierter Name bei AttrVal ohne Mecker zur Rückgabe des default Wertes führt... . Von daher ist es für mich kein Problem.  ;)

Im Anhang ein neuer Satz Module. Gib mir bitte Feedback, ob es damit verschwindet.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 30 Januar 2021, 14:31:12
Hallo Ansgar,

das Problem scheint verschwunden zu sein.
Irgendwie wird die Liste der Module die ich vom Update ausschließen muss immer länger
00_TSCUL.pm 16_STACKABLETS.pm DevIoTS.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.pm CalcUtil.pm 97_timerTS.pm 98_TSCULflash.pm 97_timerTS.pm 98_apptime.pm 10_IT.pm 10_CULG.pm 10_CUL_HM.pm HMConfig.pm 98_HMinfo.pm 98_autocreate.pm

Ok, da sind jetzt einfach alle aus deiner "Lieferung" dabei - egal ob es sie überhaupt über FHEM update gibt. Irgendwie wäre da Merge mit dem FHEM "main" schon mal interessant. Schließlich läuft es (zumindest für meinen Anwendungsfall) ja wirklich deutlich besser als der Standard.

Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 30 Januar 2021, 15:35:00
Hallo Jörg,

Zitatdas Problem scheint verschwunden zu sein.
Schön, wenn es schon geholfen hat/hätte. Ich hatte mit noch mehr Iterationen gerechnet.

ZitatIrgendwie wird die Liste der Module die ich vom Update ausschließen muss immer länger
Mich stört mehr, dass die Änderungen an CUL_HM mittlerweile recht umfangreich sind und damit ein Einbau von Martins Updates immer mühsamer wird.  ;)

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 30 Januar 2021, 16:20:51
Zitat von: noansi am 30 Januar 2021, 15:35:00
Mich stört mehr, dass die Änderungen an CUL_HM mittlerweile recht umfangreich sind und damit ein Einbau von Martins Updates immer mühsamer wird.  ;)
Tja, da wäre schön wenn ihr zwei zusammenfinden könntet um eine "best of both worlds" Version zu veröffentlichen.

Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 09 Februar 2021, 14:30:39
Hi Ansgar,

nach längerer Zeit jetzt nochmal ein kleines Fazit:
Nachdem ich längere Zeit hmAgcMaxDVGA=1 laufen hatte und da in etwa bei 4% resends lag, habe ich jetzt hmAgcMaxDVGA=2 mit 3% an laufen. Das werde ich wohl jetzt so lassen.
Außer RsndFail gab es in beiden Fällen keine weiteren Fehler in der Statistik.

Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 09 Februar 2021, 21:10:02
Hallo Jörg,

danke für's Feedback.
Dann ist die Einstellmöglichkeit ja nicht ganz sinnlos.  :)

Im Anhang nochmal ein neuer Satz Module, in den auch Martins letzte Änderungen eingeflossen sind.
Schau bitte mal, ob es Auffälligkeiten gibt.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: presskopf am 10 Februar 2021, 20:28:59
Nach längerer Update-Abstinenz, habe ich mal vo V0.30 auf 0.37 geupdated.
Bei mir hängen im Netz drei Nanoculs an Raspis und sind mit ser2net im Fhem verfügbar.
Jedem HM-Device ist ein CUL zugeordnet.

Nun habe ich bei zwei Rolladenaktoren Probleme in Form eines MISSING ACK.
Interessanterweise sind diese beiden Aktoren nicht ganz alleine. D.h. diese beiden haben inder Nachbardose direkt einen weiteren HM-Rolladenaktor.
Ich weiß, die räumliche Nähe ist nicht optimal, aber bis dato war das eigentlich nie ein Problem.

Ha, eben ist er einmal gefahren. Aber das missing ack ist reproduzierbarer.

Kann man da was machen?
LG
Matthias

Im log finde ich folgendes (exemplarisch für den aktor roll_dining_right):

2021.02.10 20:25:47 3: CUL_HM set roll_dining_right stop noArg
2021.02.10 20:25:48 3: LogHist CUL1:  486329 A F101 05230036 00 0D F7 8002 E47309 5160AA 01012100 -70dB
2021.02.10 20:25:48 3: LogHist CUL1:  488935 A F101 05232576 00 0D 9B A641 516081 E47309 011F2180 -63dB
2021.02.10 20:25:48 3: LogHist CUL1:  488984 A F101 05232696 00 0A 9B 8002 E47309 516081 00 -70dB
2021.02.10 20:25:48 3: LogHist CUL1:  489093 A F101 05232804 00 0D 9B 8002 E47309 516081 01012100 -70dB
2021.02.10 20:25:48 3: LogHist CUL1:  494145 A F101 05237864 00 0C 58 8470 430ED3 000000 00CE31 -59.5dB
2021.02.10 20:25:48 3: LogHist CUL1:  498764 A F101 05242484 00 0D 1E 8410 6263BB E47309 06010000 -54.5dB
2021.02.10 20:25:48 3: LogHist CUL1:  502408 A F101 05246144 00 0D A8 8410 516475 E47309 06012100 -57dB
2021.02.10 20:25:48 3: LogHist CUL1:  502440 A F101 05246172 00 0C 76 8470 3F81C7 000000 00B535 -73.5dB
2021.02.10 20:25:48 3: LogHist CUL1:  508943 A F101 05252684 00 0D B1 8410 51609B E47309 06012200 -57.5dB
2021.02.10 20:25:48 3: LogHist CUL1:  522898 A F101 05266624 00 0C 43 865A 432C73 000000 98CE2D -60dB
2021.02.10 20:25:48 3: LogHist CUL1:  008580 A F101 05276640 00 0E 5B 8410 432C73 000000 0B98CE0C00 -60dB
2021.02.10 20:25:48 3: LogHist CUL1:  008774 A F103 05276804 01 0B A8 A011 E47309 3E0FFC 0301 _CCAdly:4
2021.02.10 20:25:48 3: LogHist CUL1:  009046 A F103 05277072 01 0B A8 A011 E47309 3E0FFC 0301 _CCAdly:4
2021.02.10 20:25:48 3: LogHist CUL1:  009317 A F103 05277340 01 0B A8 A011 E47309 3E0FFC 0301 _CCAdly:4
2021.02.10 20:25:48 3: TSCUL_ParseTsHM: CUL1 HM repeat failed to 3E0FFC/roll_dining_right:  009564 A F109 05277604 00 0B A8 A011 E47309 3E0FFC 0301 _sfail _noAnsw
2021.02.10 20:25:53 3: LogHist CUL1:  498764 A F101 05242484 00 0D 1E 8410 6263BB E47309 06010000 -54.5dB
2021.02.10 20:25:53 3: LogHist CUL1:  502408 A F101 05246144 00 0D A8 8410 516475 E47309 06012100 -57dB
2021.02.10 20:25:53 3: LogHist CUL1:  502440 A F101 05246172 00 0C 76 8470 3F81C7 000000 00B535 -73.5dB
2021.02.10 20:25:53 3: LogHist CUL1:  508943 A F101 05252684 00 0D B1 8410 51609B E47309 06012200 -57.5dB
2021.02.10 20:25:53 3: LogHist CUL1:  522898 A F101 05266624 00 0C 43 865A 432C73 000000 98CE2D -60dB
2021.02.10 20:25:53 3: LogHist CUL1:  008580 A F101 05276640 00 0E 5B 8410 432C73 000000 0B98CE0C00 -60dB
2021.02.10 20:25:53 3: LogHist CUL1:  008774 A F103 05276804 01 0B A8 A011 E47309 3E0FFC 0301 _CCAdly:4
2021.02.10 20:25:53 3: LogHist CUL1:  009046 A F103 05277072 01 0B A8 A011 E47309 3E0FFC 0301 _CCAdly:4
2021.02.10 20:25:53 3: LogHist CUL1:  009317 A F103 05277340 01 0B A8 A011 E47309 3E0FFC 0301 _CCAdly:4
2021.02.10 20:25:53 3: LogHist CUL1:  009564 A F109 05277604 00 0B A8 A011 E47309 3E0FFC 0301 _sfail _noAnsw
2021.02.10 20:25:53 3: LogHist CUL1:  012128 A F101 05280164 00 0D A3 8041 3F81A7 4B7E69 0733C880 -40dB
2021.02.10 20:25:53 3: LogHist CUL1:  013760 A F103 05281784 01 0B A8 A011 E47309 3E0FFC 0301 _CCAdly:4
2021.02.10 20:25:53 3: LogHist CUL1:  014032 A F103 05282056 01 0B A8 A011 E47309 3E0FFC 0301 _CCAdly:4
2021.02.10 20:25:53 3: LogHist CUL1:  014288 A F103 05282324 01 0B A8 A011 E47309 3E0FFC 0301 _CCAdly:4
2021.02.10 20:25:53 3: TSCUL_ParseTsHM: CUL1 HM repeat failed to 3E0FFC/roll_dining_right:  014527 A F109 05282588 00 0B A8 A011 E47309 3E0FFC 0301 _sfail _noAnsw
2021.02.10 20:25:57 3: LogHist CUL1:  522898 A F101 05266624 00 0C 43 865A 432C73 000000 98CE2D -60dB
2021.02.10 20:25:57 3: LogHist CUL1:  008580 A F101 05276640 00 0E 5B 8410 432C73 000000 0B98CE0C00 -60dB
2021.02.10 20:25:57 3: LogHist CUL1:  008774 A F103 05276804 01 0B A8 A011 E47309 3E0FFC 0301 _CCAdly:4
2021.02.10 20:25:57 3: LogHist CUL1:  009046 A F103 05277072 01 0B A8 A011 E47309 3E0FFC 0301 _CCAdly:4
2021.02.10 20:25:57 3: LogHist CUL1:  009317 A F103 05277340 01 0B A8 A011 E47309 3E0FFC 0301 _CCAdly:4
2021.02.10 20:25:57 3: LogHist CUL1:  009564 A F109 05277604 00 0B A8 A011 E47309 3E0FFC 0301 _sfail _noAnsw
2021.02.10 20:25:57 3: LogHist CUL1:  012128 A F101 05280164 00 0D A3 8041 3F81A7 4B7E69 0733C880 -40dB
2021.02.10 20:25:57 3: LogHist CUL1:  013760 A F103 05281784 01 0B A8 A011 E47309 3E0FFC 0301 _CCAdly:4
2021.02.10 20:25:57 3: LogHist CUL1:  014032 A F103 05282056 01 0B A8 A011 E47309 3E0FFC 0301 _CCAdly:4
2021.02.10 20:25:57 3: LogHist CUL1:  014288 A F103 05282324 01 0B A8 A011 E47309 3E0FFC 0301 _CCAdly:4
2021.02.10 20:25:57 3: LogHist CUL1:  014527 A F109 05282588 00 0B A8 A011 E47309 3E0FFC 0301 _sfail _noAnsw
2021.02.10 20:25:57 3: LogHist CUL1:  017803 A F103 05285832 01 0B A8 A011 E47309 3E0FFC 0301 _CCAdly:4
2021.02.10 20:25:57 3: LogHist CUL1:  018059 A F103 05286100 01 0B A8 A011 E47309 3E0FFC 0301 _CCAdly:4
2021.02.10 20:25:57 3: LogHist CUL1:  018331 A F103 05286368 01 0B A8 A011 E47309 3E0FFC 0301 _CCAdly:4
2021.02.10 20:25:57 3: TSCUL_ParseTsHM: CUL1 HM repeat failed to 3E0FFC/roll_dining_right:  018570 A F109 05286632 00 0B A8 A011 E47309 3E0FFC 0301 _sfail _noAnsw
2021.02.10 20:26:02 3: LogHist CUL1:  009564 A F109 05277604 00 0B A8 A011 E47309 3E0FFC 0301 _sfail _noAnsw
2021.02.10 20:26:02 3: LogHist CUL1:  012128 A F101 05280164 00 0D A3 8041 3F81A7 4B7E69 0733C880 -40dB
2021.02.10 20:26:02 3: LogHist CUL1:  013760 A F103 05281784 01 0B A8 A011 E47309 3E0FFC 0301 _CCAdly:4
2021.02.10 20:26:02 3: LogHist CUL1:  014032 A F103 05282056 01 0B A8 A011 E47309 3E0FFC 0301 _CCAdly:4
2021.02.10 20:26:02 3: LogHist CUL1:  014288 A F103 05282324 01 0B A8 A011 E47309 3E0FFC 0301 _CCAdly:4
2021.02.10 20:26:02 3: LogHist CUL1:  014527 A F109 05282588 00 0B A8 A011 E47309 3E0FFC 0301 _sfail _noAnsw
2021.02.10 20:26:02 3: LogHist CUL1:  017803 A F103 05285832 01 0B A8 A011 E47309 3E0FFC 0301 _CCAdly:4
2021.02.10 20:26:02 3: LogHist CUL1:  018059 A F103 05286100 01 0B A8 A011 E47309 3E0FFC 0301 _CCAdly:4
2021.02.10 20:26:02 3: LogHist CUL1:  018331 A F103 05286368 01 0B A8 A011 E47309 3E0FFC 0301 _CCAdly:4
2021.02.10 20:26:02 3: LogHist CUL1:  018570 A F109 05286632 00 0B A8 A011 E47309 3E0FFC 0301 _sfail _noAnsw
2021.02.10 20:26:02 3: LogHist CUL1:  018586 A F101 05286648 00 0C 43 8470 432C73 000000 00CE2D -60.5dB
2021.02.10 20:26:02 3: LogHist CUL1:  022613 A F103 05290652 01 0B A8 A011 E47309 3E0FFC 0301 _CCAdly:4
2021.02.10 20:26:02 3: LogHist CUL1:  022889 A F103 05290920 01 0B A8 A011 E47309 3E0FFC 0301 _CCAdly:4
2021.02.10 20:26:02 3: LogHist CUL1:  023142 A F103 05291188 01 0B A8 A011 E47309 3E0FFC 0301 _CCAdly:4
2021.02.10 20:26:02 3: TSCUL_ParseTsHM: CUL1 HM repeat failed to 3E0FFC/roll_dining_right:  023382 A F109 05291452 00 0B A8 A011 E47309 3E0FFC 0301 _sfail _noAnsw


list roll_dining_right

Internals:
   CUL1_MSGCNT 9
   CUL1_RAWMSG A0D72A4103E0FFCE473090601B400::-65.5:CUL1:
   CUL1_RSSI  -65.5
   CUL1_TIME  2021-02-10 20:32:38
   CUL3_MSGCNT 9
   CUL3_RAWMSG A0D72A4103E0FFCE473090601B400::-77.5:CUL3:
   CUL3_RSSI  -77.5
   CUL3_TIME  2021-02-10 20:32:38
   CUL5_MSGCNT 9
   CUL5_RAWMSG A0D72A4103E0FFCE473090601B400::-78.5:CUL5:
   CUL5_RSSI  -78.5
   CUL5_TIME  2021-02-10 20:32:38
   DEF        3E0FFC
   FUUID      5c4b0d7b-f33f-bfeb-7e57-fff7aed16ce88215
   IODev      CUL1
   LASTInputDev CUL3
   MSGCNT     27
   NAME       roll_dining_right
   NOTIFYDEV  global
   NR         240
   NTFY_ORDER 50-roll_dining_right
   STATE      RESPONSE TIMEOUT:RegisterRead
   TYPE       CUL_HM
   chanNo     01
   lastMsg    No:72 - t:10 s:3E0FFC d:E47309 0601B400
   protCmdDel 6
   protLastRcv 2021-02-10 20:32:09
   protRcv    4 last_at:2021-02-10 20:32:09
   protResnd  12 last_at:2021-02-10 20:53:10
   protResndFail 4 last_at:2021-02-10 20:53:15
   protSnd    14 last_at:2021-02-10 20:52:54
   protState  CMDs_done_Errors:1
   rssi_at_CUL1 cnt:9 min:-67.5 max:-65 avg:-66.44 lst:-65.5
   rssi_at_CUL3 cnt:9 min:-79.5 max:-77 avg:-78.11 lst:-77.5
   rssi_at_CUL5 cnt:9 min:-78.5 max:-76.5 avg:-77.27 lst:-78.5
   rssi_from_CUL1 cnt:3 min:-95 max:-94 avg:-94.66 lst:-94
   READINGS:
     2021-02-10 20:32:04   CommandAccepted yes
     2016-03-24 20:56:27   D-firmware      2.8
     2016-03-24 20:56:27   D-serialNr      MEQ0678181
     2020-03-24 17:12:20   PairedTo        0xE47309
     2016-03-31 09:51:27   R-driveDown     25 s
     2016-03-31 09:51:27   R-driveTurn     0.5 s
     2020-03-24 17:12:21   R-driveUp       27.5 s
     2016-09-25 19:01:59   R-pairCentral   0xE47309
     2020-03-24 17:12:16   R-powerUpAction off
     2016-03-31 09:51:27   R-sign          off
     2021-02-10 20:52:54   cfgState        updating
     2021-02-10 20:53:15   commState       CMDs_done_Errors:1
     2021-02-10 20:32:09   deviceMsg       90 (to VCCU)
     2021-02-10 20:37:24   level           set_80
     2016-12-31 09:18:34   levelMissed     desired:100
     2021-02-10 20:32:09   motor           stop:90
     2021-02-10 20:32:09   pct             90
     2017-07-12 17:38:31   powerOn         2017-07-12 17:38:31
     2021-02-10 20:32:09   recentStateType info
     2021-02-10 20:53:15   state           RESPONSE TIMEOUT:RegisterRead
     2021-02-10 20:32:09   timedOn         off
     RegL_00.:
       VAL       
   helper:
     HM_CMDNR   118
     cSnd       11E473093E0FFC0201A0,01E473093E0FFC00040000000000
     dlvlCmd    ++A011E473093E0FFC0201A0
     getCfgList all
     getCfgListNo ,3
     mId        0005
     peerFriend peerSens,peerVirt
     peerOpt    3:blindActuator
     regLst     0,1,3p
     rxType     1
     supp_Pair_Rep 0
     ack:
     cmds:
       TmplKey    :no:1612985471.14737
       TmplTs     1612985471.14737
       cmdKey     1:1:0::roll_dining_right:0005:01:
       cmdLst:
         assignHmKey noArg
         clear      [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
         deviceRename -newName-
         down       [(-changeValue-|{10})] [(-ontime-|{0})] [(-ramptime-|{0})]
         fwUpdate   -filename- [-bootTime-]
         getConfig  noArg
         getDevInfo noArg
         getRegRaw  (List0|List1|List2|List3|List4|List5|List6) [-peerChn-]
         getVersion noArg
         inhibit    [(on|{off})]
         off        noArg
         on         noArg
         pair       noArg
         pct        -value- [(-ontime-|{0})]
         peerBulk   -peer1,peer2,...- [({set}|unset)]
         peerIODev  [IO] -btn- [({set}|unset)] 'not for future use'
         peerSmart  -peerOpt-
         press      [(long|{short})] [(-peer-|{self01})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
         raw        -data- [...]
         regBulk    -list-.-peerChn- -addr1:data1- -addr2:data2-...
         regSet     [(prep|{exec})] -regName- -value- [-peerChn-]
         reset      noArg
         sign       [(on|{off})]
         statusRequest noArg
         stop       noArg
         toggle     noArg
         toggleDir  noArg
         tplDel     -tplDel-
         tplSet_0   -tplChan-
         unpair     noArg
         up         [(-changeValue-|{10})] [(-ontime-|{0})] [(-ramptime-|{0})]
       lst:
         condition  0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,160,161,162,163,164,165,166,167,168,169,170,171,172,173,174,175,176,177,178,179,180,181,182,183,184,185,186,187,188,189,190,191,192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,208,209,210,211,212,213,214,215,216,217,218,219,220,221,222,223,224,225,226,227,228,229,230,231,232,233,234,235,236,237,238,239,240,241,242,243,244,245,246,247,248,249,250,251,252,253,254,255
         peer       
         peerOpt    VCCU_Btn1,door_base,door_main,door_patio,motion_base,motion_floor,motion_living,motion_main,motion_shed,motion_stairs,remote_block_LEGO_off,remote_block_LEGO_on,remote_block_switch_off,remote_block_switch_on,smoke_team,water_cafe,water_kitchen
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         param      -param-
         reg        -addr- -list- [-peerChn-]
         regList    noArg
         regTable   noArg
         regVal     -addr- -list- [-peerChn-]
         saveConfig [-filename-]
         tplInfo    noArg
     dir:
       cur        stop
       rct        down
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       lstRecType 10
       newChn     +3E0FFC,00,01,00
       nextSend   1612985558.21914
       nxtSndMcnt 72
       rxt        0
       tgtDly     88
       vccu       VCCU
       lRcTm:
         CUL1       121428
         CUL3       110308
         CUL5       102372
         tnms       225338489
       p:
         3E0FFC
         00
         01
         00
       prefIO:
         CUL1
     mRssi:
       mNo        72
       io:
         CUL1:
           -55.5
           -55.5
         CUL3:
           -77.5
           -77.5
         CUL5:
           -78.5
           -78.5
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       prs        1
     rpt:
       IO         CUL1
       flg        A
       ts         1612985558.15174
       ack:
         HASH(0x3b466f0)
         728002E473093E0FFC00
     rssi:
       at_CUL1:
         avg        -66.4444444444444
         cnt        9
         lst        -65.5
         max        -65
         min        -67.5
       at_CUL3:
         avg        -78.1111111111111
         cnt        9
         lst        -77.5
         max        -77
         min        -79.5
       at_CUL5:
         avg        -77.2777777777778
         cnt        9
         lst        -78.5
         max        -76.5
         min        -78.5
       from_CUL1:
         avg        -94.6666666666667
         cnt        3
         lst        -94
         max        -94
         min        -95
     tmpl:
Attributes:
   IODev      CUL1
   IOgrp      VCCU:CUL1
   autoReadReg 4_reqStatus
   devStateIcon up:fts_shutter_10@green down:fts_shutter_100@black 9\d.*:fts_shutter_10 8\d.*:fts_shutter_20 7\d.*:fts_shutter_30 6\d.*:fts_shutter_40 5\d.*:fts_shutter_50 4\d.*:fts_shutter_60 3\d.*:fts_shutter_70 2\d.*:fts_shutter_80 1\d.*:fts_shutter_90 0\d.*:fts_shutter_100
   eventMap   on:up off:down stop:stop
   expert     defReg,rawReg
   firmware   2.8
   gassistantName Esszimmerrolladen-Rechts
   genericDeviceType blinds
   model      HM-LC-BL1PBU-FM
   peerIDs    00000000,
   room       CUL_HM,Erdgeschoss,GoogleAssistant,roll
   serialNr   MEQ0678181
   subType    blindActuator
   webCmd     stop:up:down:90:80:70:60:50:40:30:20:10


Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 10 Februar 2021, 21:48:33
Hallo Matthias,

hattest Du im alten Stand noch Einstellungen am CUL gesetzt und jetzt vergessen wieder zu setzen, nachdem sie durch das Firmware Update überschrieben wurden?
Da nur erfolglos gesendet wird, ohne das etwas erkennbar dazwischen gefunkt hat, wäre das die naheliegendste Möglichkeit, was den CUL angeht.
Oder hast Du die CUL Position/Antennenlage auch verändert -> kann sich auch negativ auf den Empfang durch die Gegenstelle auswirken.

List vom CUL1 bitte.
Dann mach mal ein ccconf bei CUL1 und dann ein neues List von dem CUL1. Die Glaskugel glimmt noch extrem schwach.  ;)

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: presskopf am 10 Februar 2021, 21:54:12
Hi Ansgar,

mit den Einstellungen muss ich nochmal gucken. Da habe ich nix mehr gesetzt nach dem Update.
Was da vorher war, muss ich noch checken.
Antenne ist wie vorher. Ein set hm rssi offenbart nicht den schlechtesten Empfang:

    roll_dining_right CUL1            roll_dining_right  -65.5  -66.4  -67.5< -65.0     9
    roll_dining_right CUL3            roll_dining_right  -77.5  -78.1  -79.5< -77.0     9
    roll_dining_right CUL5            roll_dining_right  -78.5  -77.3  -78.5< -76.5     9


list CUL1

Internals:
   CMDS       ABCFGJKRUVWXYeiltx
   CUL1_MSGCNT 946
   CUL1_TIME  2021-02-10 21:49:51
   Clients    STACKABLETS:STACKABLE:CUL_HM:CUL_IR:TSHMS
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL013QHR-if00-port0@38400 1111
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AL013QHR-if00-port0@38400
   FD         9
   FHTID      1111
   FUUID      5c4b0d6a-f33f-bfeb-9249-077af5e7ec7f0c22
   NAME       CUL1
   NR         32
   PARTIAL   
   RAWMSG     A0D0B84105160AAE4730906012200::-57.5:CUL1:
   RSSI       -57.5
   STATE      Initialized
   TYPE       TSCUL
   VERSION    VTS 0.37 CSM868
   VERSION_HW nanoCUL_V1.x_0014
   VERSION_TS yes AES ChTblSize:210
   XmitOpen   1
   assignUpdCntI 46
   assignedIDsCnt 23
   initString XP0C
X21
Ar
AM5
AHE47309
   msgLoadCurrent 0
   owner_CCU  VCCU
   MatchList:
     A:CUL_HM   ^A....................
     B:CUL_IR   ^I............
     C:TSHMS    ^810e04......a001
     Y:STACKABLETS ^\*
     Z:STACKABLE ^\*
   READINGS:
     2021-02-10 13:14:04   Ints_per_sec    SI: 13.95224  TI: 1.36779  S: 3.94967  L: 0.64401  F: 1.24132  M: 0.26072
     2021-02-10 20:31:23   Xmit-Events     init:1 non-HM:1 ok:1 disconnected:1
     2021-01-05 09:03:16   ccconf          freq:868.300MHz freqOffs:-20.630kHz bWidth:101kHz freqIF:152.34kHz rAmpl:33dB sens:8dB dRate:9.993kBit/s
agcPrio:1 agcWait:16 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:1 AGC_FREEZE:0
CCAmode:3 csRelThr:10dB csAbsThr:7dB
     2021-02-10 20:30:40   cmds             A B C F G J K R U V W X Y e i l t x
     2021-02-10 20:31:23   cond            ok
     2016-04-24 23:12:33   fhtbuf          AE
     2021-02-03 12:36:19   prot_ERROR-Overload last
     2021-02-03 12:36:29   prot_Warning-HighLoad last
     2021-02-10 20:30:35   prot_disconnected last
     2021-02-10 20:30:41   prot_init       last
     2021-02-10 20:30:41   prot_non-HM     last
     2021-02-10 20:31:23   prot_ok         last
     2016-04-24 23:12:29   raw             No answer
     2021-02-10 21:39:41   scF             0.998915998557398
     2021-02-10 20:30:41   state           Initialized
     2018-11-26 20:28:51   uptime          0 00:00:21
     2021-02-10 12:33:17   version         VTS 0.37 CSM868
   helper:
     CUrun      1
     ChkPart    0
     RA_Timeout 0
     SVTS       1
     VTS        1
     VTS_ACK    1
     VTS_AES    1
     assIdCnt   23
     assIdRep   23
     nRec       0
     recd       1
     DEVIOTS:
       RXfailTO   
     HM:
       ChTblSize  210
       FUP        0
       HMactive   1
       hmCrdts    0
       hmSbusy    0
       ChTbl:
         3E0FEC00   01
         3E0FF700   01
         3E0FFC00   01
         3E100600   01
         3E105A00   01
         3E107900   01
         3EF2D600   01
         3F81A700   01
         3F81C700   01
         3FC88B00   01
         430ED300   01
         430EFE00   01
         43110F00   01
         432C7300   01
         469D3100   01
         470C3400   01
         4B7CB000   01
         4B851500   01
         4B883300   01
         4D25FC01   01
         4EC38800   01
         4ECAE800   01
         51609B00   01
       msgCNT:
         0x01       850
         0x02       120
         0x03       182
         0x09       20
         0x0C       48
         0x0E       20
         0x12       17
       unknwn:
     cnd:
       0          1
       250        1
       253        1
       255        1
     hmLogHist:
        297067 A F001 04723128 00 0C 64 865A 432C73 000000 98C72A -59.5dB
        299023 A F001 04725064 00 0C 5B 865A 43110F 000000 B0C831 -79.5dB
        300149 A F001 04726184 00 0D C6 A641 51609B E47309 01CE2E80 -59.5dB
        300248 A F103 04726280 01 0A C6 8002 E47309 51609B 00 _CCAdly:4 _dhmSt:96
        300359 A F103 04726384 01 0D C6 8002 E47309 51609B 01012E00 _CCAdly:4 _dhmSt:200
        305608 A F101 04731592 00 0D 0A A641 5160AA E47309 01942280 -57dB
        305650 A F101 04731708 00 0A 0A 8002 E47309 5160AA 00 -69.5dB
        305760 A F101 04731816 00 0D 0A 8002 E47309 5160AA 01012200 -69dB
        311754 A F001 04737800 00 0C EC 865A 3F81A7 000000 B8EB26 -40.5dB
        317076 A F001 04743148 00 0C 64 8470 432C73 000000 00C72A -60dB
        319009 A F001 04745084 00 0C 5B 8470 43110F 000000 00C831 -80dB
        321630 A F001 04747716 00 0D C7 8410 51609B E47309 06012E00 -59dB
        331742 A F001 04757820 00 0C EC 8470 3F81A7 000000 00EB26 -40.5dB
        333798 A F001 04759848 00 0D 0B 8410 5160AA E47309 06012200 -57.5dB
     hmQ:
       000000:
       3E0FEC:
       3E0FF7:
       3E0FFC:
       3E1006:
       3E105A:
       3E1079:
       3FC88B:
       469D31:
       470C34:
       4B7CB0:
       4B8515:
       4B8833:
       4D25FC:
       51609B:
     ids:
       3E0FEC:
         cfg        +3E0FEC,00,01,00
         name       roll_stairs
       3E0FF7:
         cfg        +3E0FF7,00,01,00
         name       roll_living
       3E0FFC:
         cfg        +3E0FFC,00,01,00
         name       roll_dining_right
       3E1006:
         cfg        +3E1006,00,01,00
         name       roll_office
       3E105A:
         cfg        +3E105A,00,01,00
         name       roll_vincent
       3E1079:
         cfg        +3E1079,00,01,00
         name       roll_dining_left
       3EF2D6:
         cfg        +3EF2D6,00,01,00
         name       thermo_office
       3F81A7:
         cfg        +3F81A7,00,01,00
         name       thermo_living
       3F81C7:
         cfg        +3F81C7,00,01,00
         name       thermo_stairs
       3FC88B:
         cfg        +3FC88B,00,01,00
         name       roll_kitchen
       430ED3:
         cfg        +430ED3,00,01,00
         name       thermo_leonard
       430EFE:
         cfg        +430EFE,00,01,00
         name       thermo_sleep
       43110F:
         cfg        +43110F,00,01,00
         name       thermo_bath_og
       432C73:
         cfg        +432C73,00,01,00
         name       thermo_vincent
       469D31:
         cfg        +469D31,00,01,00
         name       roll_bathroom_guest
       470C34:
         cfg        +470C34,00,01,00
         name       EFBH_OG_bath
       4B7CB0:
         cfg        +4B7CB0,00,01,00
         name       FBH_OG
       4B8515:
         cfg        +4B8515,00,01,00
         name       smoke_office
       4B8833:
         cfg        +4B8833,00,01,00
         name       smoke_living
       4D25FC:
         cfg        +4D25FC,01,01,02
         name       water_cafe
       4EC388:
         cfg        +4EC388,00,01,00
         name       door_patio
       4ECAE8:
         cfg        +4ECAE8,00,01,00
         name       water_kitchen
       51609B:
         cfg        +51609B,00,01,00
         name       motion_living
     loadLvl:
       bl         40
     q:
       ATrNo      0
       HMcndN     0
       InQueues   0
       RQLSt      0
       RQLt       0
       XRpCnt     0
       XRpTm      1612985486.62439
       answerPend 0
       hmLanQlen  1
       apIDs:
         3E0FEC     0
         3E0FF7     0
         3E0FFC     0
         3E1006     0
         3E105A     0
         3E1079     0
         3FC88B     0
         469D31     0
         470C34     0
         4B7CB0     0
         4B8515     0
         4B8833     0
     ref:
       Sdly       51
       TmBmCnt    1
       ioBR       3840
       ioBRMax    3722.3088234169
       ioBRMean   3249.95706292953
       lHMt       4723128
       lSys       229935211
       pTTu       1024
       pndAs      0
       pndCUAp    0
       pndTuP     1
       pngLm      16
       pngRef     8
       scErr      7.00880521337967
       scF        0.998915998557398
       scFN       7
       scHT       4149168
       scST       229361877
       scpTm      1612989581.51694
Attributes:
   hmId       E47309
   hmLanQlen  1_min
   icon       cul_cul
   rfmode     HomeMatic



ccconf CUL1
CUL1 ccconf => freq:868.300MHz freqOffs:0.000kHz bWidth:101kHz freqIF:152.34kHz rAmpl:33dB sens:8dB dRate:9.993kBit/s
agcPrio:1 agcWait:16 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:1 AGC_FREEZE:0
CCAmode:3 csRelThr:10dB csAbsThr:7dB



Nachtrag: Mir ist aufgefallen, dass die FW nicht taufrisch ist, aber ob das damit zusammenhängt?

Nachtrag 2: Alle attr waren vor und nach dem Update identisch.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 10 Februar 2021, 22:19:46
Hallo Matthias,

ich tippe auf
freqOffs:-20.630kHz
nach altem ccconf Stand.

also set hmFreqOffs -20.630 für CUL1, Edit: C&P Vorzeichenfehler korrigiert.

bei den anderen beiden entsprechend der jeweiligen alten Einstellung.

ZitatNachtrag: Mir ist aufgefallen, dass die FW nicht taufrisch ist, aber ob das damit zusammenhängt?
Nein, siehe auch die gefühlt letzten 4 Seiten Thread.  ;)
Wären wenn, ganz andere Probleme.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: presskopf am 10 Februar 2021, 23:41:30
Hi Ansgar,
das hat es leider nicht so gebracht. Ich habe mal bei den Frequenzen ordentlich nach oben und unten durchprobiert, ca solche Schritte +/- 15 30 ...
Irgendwann ging halt gar nix mehr.

Daher habe ich jetzt nochmal die Probe auf's Exempel gemacht und die 0.30 wieder überall drauf gemacht.
Damit lassen sich alle HM-Geräte ansprechen; auch die zwei betroffenen Rolladenaktoren.
Dabei habe ich nun nochmal die hmFreqOffs getestet: -20.630 / 0 / 20.630
Bei allen drei tut es.

Komisch. Soll ich mal alle Versionen über 0.30 durchtesten?
(Tät aber etwas dauern.  ;) )

LG
Mathtias

Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 11 Februar 2021, 06:26:04
Hallo Matthias,

dann logge mit dem V0.30 Stand beim CUL1 mit verbose 4 mal, was da gesendet wird, wenn Du den Aktor schaltest.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: presskopf am 11 Februar 2021, 08:55:24
Hallo Ansgar,
so, habe den CUL1 mal auf verbose 4 gestellt und den betreffenden Rolli ein Stück gefahren:

021.02.11 08:49:51 3: CUL_HM set roll_dining_right 90
2021.02.11 08:49:51 4: TSCUL_send:  CUL1  087716                 As 0C 8D A011 E47309 3E0FFC 0201B4
2021.02.11 08:49:51 4: TSCUL_XmitDlyHM:  CUL1  id:3E0FFC rtoms:2343
2021.02.11 08:49:51 4: TSCUL_Parse: CUL1  087775 A F103 16692296 01 0C 8D A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 08:49:51 4: TSCUL_Parse: CUL1  087935 A F101 16692448 00 0E 8D 8002 3E0FFC E47309 0101C82059 -67dB
2021.02.11 08:49:56 4: TSCUL_Parse: CUL1  092903 A F001 16697440 00 0D 8E A410 3E0FFC E47309 0601B400 -70dB
2021.02.11 08:49:56 4: TSCUL_Parse: CUL1  092994 A F103 16697536 01 0A 8E 8002 E47309 3E0FFC 00 _CCAdly:4 _dhmSt:96
2021.02.11 08:49:57 4: TSCUL_Parse: CUL1  093688 A F101 16697996 00 0F BD 8610 440AAE 000000 0AB0CA0F6440 -65dB
2021.02.11 08:49:59 4: TSCUL_Parse: CUL1  095534 A F101 16700104 00 0D 97 8410 5160AA E47309 06012C00 -58.5dB
2021.02.11 08:50:15 4: TSCUL_Parse: CUL1  112192 A F001 16716772 00 0C F1 865A 3F81A7 000000 B0DD25 -40dB
2021.02.11 08:50:18 4: TSCUL_Parse: CUL1  114841 A F001 16719436 00 0C BE 865A 3EF2D6 000000 B0E123 -49dB
2021.02.11 08:50:28 4: TSCUL_Parse: CUL1  124729 A F001 16729280 00 0D B5 8041 430EFE 4B7CB0 07EBC880 -80dB
2021.02.11 08:50:33 4: TSCUL_Parse: CUL1  130014 A F001 16734608 00 0C 61 865A 43110F 000000 B0CA30 -76dB
2021.02.11 08:50:33 4: TSCUL_Parse: CUL1  130089 A F001 16734680 00 0C 69 865A 432C73 000000 A8C031 -66.5dB
2021.02.11 08:50:35 4: TSCUL_Parse: CUL1  132184 A F001 16736796 00 0C F1 8470 3F81A7 000000 00DD25 -40dB
2021.02.11 08:50:38 4: TSCUL_Parse: CUL1  134861 A F001 16739460 00 0C BE 8470 3EF2D6 000000 00E123 -49dB
2021.02.11 08:50:51 4: TSCUL_Parse: CUL1  148292 A F001 16752920 00 0D A3 8041 3F81A7 4B7E69 07EEC880 -40dB
2021.02.11 08:50:53 4: TSCUL_Parse: CUL1  150019 A F001 16754632 00 0C 61 8470 43110F 000000 00CA30 -76dB
2021.02.11 08:50:53 4: TSCUL_Parse: CUL1  150107 A F001 16754704 00 0C 69 8470 432C73 000000 00C031 -68.5dB
2021.02.11 08:51:06 4: TSCUL_Parse: CUL1  162947 A F001 16767580 00 0C 7F 865A 430ED3 000000 A4C032 -59.5dB
2021.02.11 08:51:17 4: TSCUL_Parse: CUL1  174183 A F001 00001624 00 0D DF 8041 432C73 4B7CB0 0792C880 -65dB
2021.02.11 08:51:26 4: TSCUL_Parse: CUL1  182953 A F001 00010384 00 0C 7F 8470 430ED3 000000 00C032 -59.5dB
2021.02.11 08:51:45 4: TSCUL_Parse: CUL1  201913 A F001 00029376 00 0C 9D 865A 3F81C7 000000 A8A435 -75dB
2021.02.11 08:51:47 4: TSCUL_Parse: CUL1  203814 A F001 00031288 00 0C 28 865A 430EFE 000000 8CA736 -77.5dB
2021.02.11 08:51:55 4: TSCUL_Parse: CUL1  211916 A F001 00039392 00 0E A9 8410 3F81C7 000000 0BA8A40D00 -75.5dB
2021.02.11 08:51:56 4: TSCUL_Parse: CUL1  213256 A F001 00040732 00 0D B8 8410 6263BB E47309 06017A00 -60dB
2021.02.11 08:52:05 4: TSCUL_Parse: CUL1  221907 A F001 00049400 00 0C 9D 8470 3F81C7 000000 00A435 -75.5dB
2021.02.11 08:52:07 4: TSCUL_Parse: CUL1  223841 A F001 00051312 00 0C 28 8470 430EFE 000000 00A736 -78dB
2021.02.11 08:52:11 4: TSCUL_Parse: CUL1  227595 A F001 00055044 00 0D C7 8041 430ED3 4B7CB0 0728C880 -59.5dB
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 11 Februar 2021, 19:07:03
Hallo Matthias,

ok, es wird auf jeden Fall was anderes gesendet, als in Deinen Problemlogs.

Kommt also aus der CUL_HM.

Es wird anscheinend ein "toggleDir" oder "stop" gesendet, was nicht beantwortet wird.
Kannst Du bitte mal mit verbose 4 am CUL1 ein toggleDir und ein stop am Actor senden und das log posten.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 11 Februar 2021, 20:46:19
Hallo Matthias,

ich habe doch noch einen Firmwareunterschied gefunden.

Probier es nochmal mit der V0.37 und setz den hmFreqOffs jeweils wieder entsprechend der alten Einstellung bei den CUls.
Dann noch ein set patable 9 bei den CULs.

Ich habe die Sendleistung über die Versionen auch einstellbar gemacht und der default ist 8, aber 9 entsprechend ist der alte fixe Stand in V0.30 für hm.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: presskopf am 11 Februar 2021, 21:32:09
Hallo Ansgar,

Hut ab, es tut mit 0.37!
Deinen ersten Beitrag habe ich erst übersehen und bin gleich zum Versuch mit set CULx patable 9 übergegangen.
Damit funktionieren alle Aktoren. Die Gegenprobe mit zurück auf den Wert 8 zeigte wieder das Versagen.

Woran erkenne ich denn in den Readings, welchen Wert das patable hat?
Soll ich nochmal den Test aus Deinem ersten Beitrag zum Erkenntnisgewinn nachschieben oder ist das nicht mehr nötig?

Alles logs mit 0.37, verbose 4 am CUL1
Hier im Log mit patable 8: Da habe ich an roll_office ein stopp gesendet, welches quittiert wurde; danach ein set_90 an roll_dining_right, welches Probleme macht:
2021.02.11 21:23:35 3: CUL_HM set roll_office stop noArg
2021.02.11 21:23:35 4: TSCUL_Write: CUL1 sending As0B8CA011E473093E10060301
2021.02.11 21:23:35 4: TSCUL_send:  CUL1  222806                 As 0B 8C A011 E47309 3E1006 0301
2021.02.11 21:23:35 4: TSCUL_XmitDlyHM:  CUL1  id:3E1006 rtoms:2342
2021.02.11 21:23:35 4: TSCUL_Parse: CUL1  222851 A F703 00742132 01 0B 8C A011 E47309 3E1006 0301 _CCAdly:4
2021.02.11 21:23:35 4: TSCUL_Parse: CUL1  222984 A F701 00742288 00 0E 8C 8002 3E1006 E47309 0101000034 -45.5dB
2021.02.11 21:23:36 4: TSCUL_Parse: CUL1  224290 A F702 00743600 00 34 AA00112200000049AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2021.02.11 21:23:44 4: TSCUL_Parse: CUL1  231786 A F702 00751100 00 34 AA00112200000048AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2021.02.11 21:23:44 4: TSCUL_Write: CUL1 sending As0C52A011E473093E0FFC0201B4
2021.02.11 21:23:44 4: TSCUL_send:  CUL1  231904                 As 0C 52 A011 E47309 3E0FFC 0201B4
2021.02.11 21:23:44 4: TSCUL_XmitDlyHM:  CUL1  id:3E0FFC rtoms:2343
2021.02.11 21:23:44 4: TSCUL_Parse: CUL1  231952 A F703 00751244 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:44 4: TSCUL_Parse: CUL1  232222 A F703 00751512 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:44 4: TSCUL_Parse: CUL1  232495 A F703 00751780 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:45 3: LogHist CUL1:  208182 A F802 00727468 00 34 AA00112200000051AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2021.02.11 21:23:45 3: LogHist CUL1:  208617 A F801 00727908 00 0C C6 8470 3F81C7 000000 00B834 -71dB
2021.02.11 21:23:45 3: LogHist CUL1:  217381 A F701 00736468 00 0F E6 8610 440AAE 000000 0AB0C70F6440 -68dB
2021.02.11 21:23:45 3: LogHist CUL1:  218202 A F702 00737500 00 34 AA00112200000050AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2021.02.11 21:23:45 3: LogHist CUL1:  219737 A F701 00739020 00 0C 50 8470 430EFE 000000 00B137 -74.5dB
2021.02.11 21:23:45 3: LogHist CUL1:  222806                 As 0B 8C A011 E47309 3E1006 0301
2021.02.11 21:23:45 3: LogHist CUL1:  222851 A F703 00742132 01 0B 8C A011 E47309 3E1006 0301 _CCAdly:4
2021.02.11 21:23:45 3: LogHist CUL1:  222984 A F701 00742288 00 0E 8C 8002 3E1006 E47309 0101000034 -45.5dB
2021.02.11 21:23:45 3: LogHist CUL1:  224290 A F702 00743600 00 34 AA00112200000049AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2021.02.11 21:23:45 3: LogHist CUL1:  231786 A F702 00751100 00 34 AA00112200000048AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2021.02.11 21:23:45 3: LogHist CUL1:  231904                 As 0C 52 A011 E47309 3E0FFC 0201B4
2021.02.11 21:23:45 3: LogHist CUL1:  231952 A F703 00751244 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:45 3: LogHist CUL1:  232222 A F703 00751512 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:45 3: LogHist CUL1:  232495 A F703 00751780 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:45 3: TSCUL_ParseTsHM: CUL1 HM repeat failed to 3E0FFC/roll_dining_right:  232718 A F709 00752044 00 0C 52 A011 E47309 3E0FFC 0201B4 _sfail _noAnsw
2021.02.11 21:23:46 4: TSCUL_XmitAwaitHMTo CUL1: timeout - 3E0FFC
2021.02.11 21:23:48 4: TSCUL_Write: CUL1 sending As0C52A011E473093E0FFC0201B4
2021.02.11 21:23:48 4: TSCUL_send:  CUL1  236109                 As 0C 52 A011 E47309 3E0FFC 0201B4
2021.02.11 21:23:48 4: TSCUL_XmitDlyHM:  CUL1  id:3E0FFC rtoms:2343
2021.02.11 21:23:48 4: TSCUL_Parse: CUL1  236156 A F703 00755452 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:48 4: TSCUL_Parse: CUL1  236429 A F703 00755724 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:49 4: TSCUL_Parse: CUL1  236698 A F703 00755992 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:49 3: LogHist CUL1:  222806                 As 0B 8C A011 E47309 3E1006 0301
2021.02.11 21:23:49 3: LogHist CUL1:  222851 A F703 00742132 01 0B 8C A011 E47309 3E1006 0301 _CCAdly:4
2021.02.11 21:23:49 3: LogHist CUL1:  222984 A F701 00742288 00 0E 8C 8002 3E1006 E47309 0101000034 -45.5dB
2021.02.11 21:23:49 3: LogHist CUL1:  224290 A F702 00743600 00 34 AA00112200000049AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2021.02.11 21:23:49 3: LogHist CUL1:  231786 A F702 00751100 00 34 AA00112200000048AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2021.02.11 21:23:49 3: LogHist CUL1:  231904                 As 0C 52 A011 E47309 3E0FFC 0201B4
2021.02.11 21:23:49 3: LogHist CUL1:  231952 A F703 00751244 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:49 3: LogHist CUL1:  232222 A F703 00751512 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:49 3: LogHist CUL1:  232495 A F703 00751780 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:49 3: LogHist CUL1:  232718 A F709 00752044 00 0C 52 A011 E47309 3E0FFC 0201B4 _sfail _noAnsw
2021.02.11 21:23:49 3: LogHist CUL1:  236109                 As 0C 52 A011 E47309 3E0FFC 0201B4
2021.02.11 21:23:49 3: LogHist CUL1:  236156 A F703 00755452 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:49 3: LogHist CUL1:  236429 A F703 00755724 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:49 3: LogHist CUL1:  236698 A F703 00755992 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:49 3: TSCUL_ParseTsHM: CUL1 HM repeat failed to 3E0FFC/roll_dining_right:  236938 A F709 00756256 00 0C 52 A011 E47309 3E0FFC 0201B4 _sfail _noAnsw
2021.02.11 21:23:50 4: TSCUL_XmitAwaitHMTo CUL1: timeout - 3E0FFC
2021.02.11 21:23:54 4: TSCUL_Write: CUL1 sending As0C52A011E473093E0FFC0201B4
2021.02.11 21:23:54 4: TSCUL_send:  CUL1  242111                 As 0C 52 A011 E47309 3E0FFC 0201B4
2021.02.11 21:23:54 4: TSCUL_XmitDlyHM:  CUL1  id:3E0FFC rtoms:2343
2021.02.11 21:23:54 4: TSCUL_Parse: CUL1  242168 A F703 00761460 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:54 4: TSCUL_Parse: CUL1  242421 A F703 00761732 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:55 4: TSCUL_Parse: CUL1  242696 A F703 00762000 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:55 3: LogHist CUL1:  231904                 As 0C 52 A011 E47309 3E0FFC 0201B4
2021.02.11 21:23:55 3: LogHist CUL1:  231952 A F703 00751244 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:55 3: LogHist CUL1:  232222 A F703 00751512 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:55 3: LogHist CUL1:  232495 A F703 00751780 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:55 3: LogHist CUL1:  232718 A F709 00752044 00 0C 52 A011 E47309 3E0FFC 0201B4 _sfail _noAnsw
2021.02.11 21:23:55 3: LogHist CUL1:  236109                 As 0C 52 A011 E47309 3E0FFC 0201B4
2021.02.11 21:23:55 3: LogHist CUL1:  236156 A F703 00755452 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:55 3: LogHist CUL1:  236429 A F703 00755724 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:55 3: LogHist CUL1:  236698 A F703 00755992 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:55 3: LogHist CUL1:  236938 A F709 00756256 00 0C 52 A011 E47309 3E0FFC 0201B4 _sfail _noAnsw
2021.02.11 21:23:55 3: LogHist CUL1:  242111                 As 0C 52 A011 E47309 3E0FFC 0201B4
2021.02.11 21:23:55 3: LogHist CUL1:  242168 A F703 00761460 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:55 3: LogHist CUL1:  242421 A F703 00761732 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:55 3: LogHist CUL1:  242696 A F703 00762000 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:23:55 3: TSCUL_ParseTsHM: CUL1 HM repeat failed to 3E0FFC/roll_dining_right:  242926 A F709 00762264 00 0C 52 A011 E47309 3E0FFC 0201B4 _sfail _noAnsw
2021.02.11 21:23:55 4: TSCUL_Parse: CUL1  243240 A F701 00762560 00 0C A8 865A 430ED3 000000 98CA31 -61dB
2021.02.11 21:23:56 4: TSCUL_XmitAwaitHMTo CUL1: timeout - 3E0FFC
2021.02.11 21:23:57 4: TSCUL_Parse: CUL1  245389 A F702 00764728 00 34 AA00112200000047AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2021.02.11 21:24:00 4: TSCUL_Write: CUL1 sending As0C52A011E473093E0FFC0201B4
2021.02.11 21:24:00 4: TSCUL_send:  CUL1  247929                 As 0C 52 A011 E47309 3E0FFC 0201B4
2021.02.11 21:24:00 4: TSCUL_XmitDlyHM:  CUL1  id:3E0FFC rtoms:2343
2021.02.11 21:24:00 4: TSCUL_Parse: CUL1  247986 A F703 00767284 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:24:00 4: TSCUL_Parse: CUL1  248254 A F703 00767560 02 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:8
2021.02.11 21:24:01 4: TSCUL_Parse: CUL1  248543 A F803 00767832 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:24:01 3: LogHist CUL1:  236429 A F703 00755724 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:24:01 3: LogHist CUL1:  236698 A F703 00755992 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:24:01 3: LogHist CUL1:  236938 A F709 00756256 00 0C 52 A011 E47309 3E0FFC 0201B4 _sfail _noAnsw
2021.02.11 21:24:01 3: LogHist CUL1:  242111                 As 0C 52 A011 E47309 3E0FFC 0201B4
2021.02.11 21:24:01 3: LogHist CUL1:  242168 A F703 00761460 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:24:01 3: LogHist CUL1:  242421 A F703 00761732 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:24:01 3: LogHist CUL1:  242696 A F703 00762000 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:24:01 3: LogHist CUL1:  242926 A F709 00762264 00 0C 52 A011 E47309 3E0FFC 0201B4 _sfail _noAnsw
2021.02.11 21:24:01 3: LogHist CUL1:  243240 A F701 00762560 00 0C A8 865A 430ED3 000000 98CA31 -61dB
2021.02.11 21:24:01 3: LogHist CUL1:  245389 A F702 00764728 00 34 AA00112200000047AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2021.02.11 21:24:01 3: LogHist CUL1:  247929                 As 0C 52 A011 E47309 3E0FFC 0201B4
2021.02.11 21:24:01 3: LogHist CUL1:  247986 A F703 00767284 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:24:01 3: LogHist CUL1:  248254 A F703 00767560 02 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:8
2021.02.11 21:24:01 3: LogHist CUL1:  248543 A F803 00767832 01 0C 52 A011 E47309 3E0FFC 0201B4 _CCAdly:4
2021.02.11 21:24:01 3: TSCUL_ParseTsHM: CUL1 HM repeat failed to 3E0FFC/roll_dining_right:  248766 A F809 00768096 00 0C 52 A011 E47309 3E0FFC 0201B4 _sfail _noAnsw
2021.02.11 21:24:02 4: TSCUL_XmitAwaitHMTo CUL1: timeout - 3E0FFC
2021.02.11 21:24:06 4: TSCUL_Parse: CUL1  253848 A F701 00773192 00 0C 1B 865A 3F81A7 000000 B8F824 -40.5dB
2021.02.11 21:24:15 4: TSCUL_Parse: CUL1  263261 A F701 00782580 00 0C A8 8470 430ED3 000000 00CA31 -60.5dB
2021.02.11 21:24:17 4: TSCUL_Parse: CUL1  264903 A F702 00784260 00 34 AA00112200000046AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2021.02.11 21:24:20 4: TSCUL_Parse: CUL1  267906 A F701 00787252 00 0C 8B 865A 43110F 000000 B0C831 -86dB
2021.02.11 21:24:23 4: TSCUL_Parse: CUL1  270593 A F702 00789944 00 34 AA00112200000045AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2021.02.11 21:24:26 4: TSCUL_Parse: CUL1  273872 A F701 00793216 00 0C 1B 8470 3F81A7 000000 00F824 -40.5dB
2021.02.11 21:24:29 4: TSCUL_Parse: CUL1  276593 A F701 00795932 00 0D E8 8410 516081 E47309 06012200 -66dB
2021.02.11 21:24:30 4: TSCUL_Parse: CUL1  277935 A F701 00797264 00 0E BC 8410 43110F 000000 0BB0C80D40 -86.5dB
2021.02.11 21:24:31 4: TSCUL_Parse: CUL1  278803 A F701 00798096 00 0D 10 8041 3F81C7 4B7E69 07E4C880 -71dB
2021.02.11 21:24:31 4: TSCUL_Parse: CUL1  279032 A F702 00798404 00 34 AA00112200000044AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping


Und so schaut ein set_80 an mit patable 9 aus.
2021.02.11 21:26:52 4: TSCUL_Parse: CUL1  420091 A F701 00939616 00 0D 63 A641 6263BB E47309 01000080 -60dB
2021.02.11 21:26:52 4: TSCUL_Parse: CUL1  420224 A F701 00939736 00 0A 63 8002 E47309 6263BB 00 -62dB
2021.02.11 21:26:52 4: TSCUL_Parse: CUL1  420313 A F701 00939840 00 0D 63 8002 E47309 6263BB 01010000 -62dB
2021.02.11 21:26:52 4: TSCUL_Parse: CUL1  420412 A F701 00939916 00 0C 8C 865A 43110F 000000 B0C931 -86dB
2021.02.11 21:26:56 4: TSCUL_Parse: CUL1  424321 A F702 00943848 00 34 AA00112200000029AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2021.02.11 21:27:00 4: TSCUL_Write: CUL1 sending As0C53A011E473093E0FFC0201A0
2021.02.11 21:27:00 4: TSCUL_send:  CUL1  427767                 As 0C 53 A011 E47309 3E0FFC 0201A0
2021.02.11 21:27:00 4: TSCUL_XmitDlyHM:  CUL1  id:3E0FFC rtoms:2343
2021.02.11 21:27:00 4: TSCUL_Parse: CUL1  427811 A F703 00947316 01 0C 53 A011 E47309 3E0FFC 0201A0 _CCAdly:4
2021.02.11 21:27:00 4: TSCUL_Parse: CUL1  427937 A F701 00947472 00 0E 53 8002 3E0FFC E47309 0101C82059 -67.5dB
2021.02.11 21:27:01 4: TSCUL_Parse: CUL1  428546 A F701 00948056 00 0C E9 865A 3EF2D6 000000 B0E422 -47.5dB
2021.02.11 21:27:02 4: TSCUL_Parse: CUL1  430413 A F701 00949928 00 0E BD 8410 43110F 000000 0BB0C90D40 -83dB
2021.02.11 21:27:02 4: TSCUL_Parse: CUL1  430479 A F701 00950012 00 0C A9 8470 430ED3 000000 00CA32 -60dB
2021.02.11 21:27:03 4: TSCUL_Parse: CUL1  431150 A F701 00950692 00 0D 2C 8410 51609B E47309 06012500 -63.5dB
2021.02.11 21:27:07 4: TSCUL_Parse: CUL1  434794 A F701 00954332 00 0D 54 A410 3E0FFC E47309 0601A000 -70dB
2021.02.11 21:27:07 4: TSCUL_Write: CUL1 sending As0A548002E473093E0FFC00
2021.02.11 21:27:07 4: TSCUL_Parse: CUL1  434907 A F703 00954428 01 0A 54 8002 E47309 3E0FFC 00 _CCAdly:4 _dhmSt:96
2021.02.11 21:27:11 4: TSCUL_Parse: CUL1  439057 A F702 00958604 00 34 AA00112200000028AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2021.02.11 21:27:12 4: TSCUL_Parse: CUL1  440388 A F701 00959940 00 0C 8C 8470 43110F 000000 00C931 -86.5dB
221 serrano closing connection (timeout)
2021.02.11 21:27:20 4: TSCUL_Parse: CUL1  448124 A F701 00967672 00 0C C8 865A 3F81C7 000000 A8B834 -71dB
2021.02.11 21:27:20 4: TSCUL_Parse: CUL1  448523 A F701 00968080 00 0C E9 8470 3EF2D6 000000 00E422 -47.5dB
2021.02.11 21:27:23 4: TSCUL_Parse: CUL1  450980 A F702 00970540 00 34 AA00112200000027AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2021.02.11 21:27:24 4: TSCUL_Parse: CUL1  451543 A F701 00971096 00 0D 50 8410 5160AA E47309 06012200 -57dB
2021.02.11 21:27:35 4: TSCUL_Parse: CUL1  462618 A F702 00982164 00 34 AA00112200000026AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
2021.02.11 21:27:37 4: TSCUL_Parse: CUL1  465057 A F701 00984604 00 0C 94 865A 432C73 000000 98CD2F -71.5dB
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 11 Februar 2021, 21:59:35
Hallo Matthias,

ZitatWoran erkenne ich denn in den Readings, welchen Wert das patable hat?
get PAtable1 und Blick in den Code

ZitatSoll ich nochmal den Test aus Deinem ersten Beitrag zum Erkenntnisgewinn nachschieben oder ist das nicht mehr nötig?
Der Erkenntnisgewinn ist schon da.  ;)

Gruß, Ansgar.

PS: Der Empfangslevel auf Aktorseite ist nicht gut. -89dB. Deswegen macht die Änderung wohl den Unterschied.
      Die 8 bleibt aber Default, als Hinweis für das nächste Update.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: presskopf am 12 Februar 2021, 08:31:51
Danke nochmal!

Da werde ich mir bei Gelegenheit mal die Antenne angucken.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 12 Februar 2021, 23:54:49
Hi Ansgar,

Zitat von: noansi am 09 Februar 2021, 21:10:02
Im Anhang nochmal ein neuer Satz Module, in den auch Martins letzte Änderungen eingeflossen sind.
Schau bitte mal, ob es Auffälligkeiten gibt.

laufen jetzt seit ein paar Tagen. Wir hatten doch vor einer Weile diesen Stacktrace:
2021.02.10 20:46:26 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4591.
2021.02.10 20:46:26 1: stacktrace:
2021.02.10 20:46:26 1:     main::__ANON__                      called by fhem.pl (4591)
2021.02.10 20:46:26 1:     main::AttrVal                       called by ./FHEM/00_TSCUL.pm (1381)
2021.02.10 20:46:26 1:     main::TSCUL_ParseTsHM               called by ./FHEM/00_TSCUL.pm (711)
2021.02.10 20:46:26 1:     main::TSCUL_Parse                   called by ./FHEM/00_TSCUL.pm (639)
2021.02.10 20:46:26 1:     main::TSCUL_Read                    called by fhem.pl (3818)
2021.02.10 20:46:26 1:     main::CallFn                        called by fhem.pl (759)


Da dachte ich ja der wäre nach deinem kleinen Patch weg gewesen - nun, war er da noch nicht - aber jetzt scheint er wirklich weg zu sein.
Dafür habe ich jetzt einen Seiteneffekt mit deiner modifizierten timerTS und GPIO4:

2021.02.12 07:36:47 1: PERL WARNING: readline() on closed filehandle DATA at ./FHEM/58_GPIO4.pm line 132.
2021.02.12 07:36:47 1: stacktrace:
2021.02.12 07:36:47 1:     main::__ANON__                      called by ./FHEM/58_GPIO4.pm (132)
2021.02.12 07:36:47 1:     main::GPIO4_Get                     called by ./FHEM/58_GPIO4.pm (123)
2021.02.12 07:36:47 1:     main::GPIO4_DeviceUpdateLoop        called by ./FHEM/97_timerTS.pm (60)
2021.02.12 07:36:47 1:     main::HandleTimeout                 called by fhem.pl (681)


Das kommt nur alle paar Stunden, dafür dann gleich 2-3 hintereinander (ich habe 10 GPIO4 Temperatursensoren, ich nehme mal an das es da wirklich ein Problem auf dem Bus gibt - nur mit der alten TimerTS hab ich das nie gesehen.

Sonst läuft es unauffällig. Aktuell scheine ich noch weniger resends zu haben (nur so 2%), allerdings finden witterungsbedingt aktuell kaum Ventiländerungen statt. Mal sehen ob das wieder hochgeht, wenn der Schnee weg ist und die Solaranlage wieder warmes Wasser liefert.
Das würde dann meine alte These unterstützen, dass Ventiländerungen eher zu resends führen.

Gruß,
Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: noansi am 13 Februar 2021, 09:24:09
Hallo Jörg,

Zitat58_GPIO4.pm
Das Modul ist nicht im SVN vorhanden. Was ist der Inhalt? In contrib hat es sich versteckt...

ZitatDafür habe ich jetzt einen Seiteneffekt mit deiner modifizierten timerTS und GPIO4:
Hier muss ich stark vermuten, dass es sich um einen Fall von "Shit in -> Shit Out" handelt.

timerTS führt da einen Timer "GPIO4_DeviceUpdateLoop" zur vorgesehen Zeit aus. Anscheinend hat aber das Modul auf anderem Wege bereits den File handle geschlossen (und hätte den Timer abschießen müssen oder gar nicht erst starten dürfen)Das Modul öffnet da eine Zeile zuvor ein File, prüft aber nicht, ob die Aktion von Erfolg gekrönt ist, was zu dem Fehlerbild führt.
Das wirst Du wohl im 58_GPIO4.pm Modul debuggen müssen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 14 Februar 2021, 17:43:41
Hallo Testwillige,

hier eine neue Version 0.38 der Timestamp Firmware und der dazu benötigten FHEM Module.

Die Version 0.38 verhindert repeats für TC und TH Messages, was für virtuelle TC und TH Sensoren sinnvoll ist.
Auszug aus de Changed:
- ASKSIN repeats for TC and TH messages set to 0
- ASKSIN Ag command added, allow setting ASKSIN non FUP AGCCTRL2 value in EEPROM
Außerdem Verbesserungen in Modulen, insbesondere für virtuelle TCs und TH Sensoren.
Beim Reboot nach dem Flashen werden alle EEPROM Einstellungen auf Default gesetzt. Also alle am CUL vorgenommenen Einstellungen notieren, um sie wieder einstellen zu können.

In Version 0.37 ist der Readout des Tranceiver RX Fifos insbesondere für ASKSIN verändert. Beim Reboot nach dem Flashen werden alle EEPROM Einstellungen auf Default gesetzt. Also alle am CUL vorgenommenen Einstellungen notieren, um sie wieder einstellen zu können.
RF_Router und fast_rf sind verändert und nicht kompatibel zu vorherigen Versionen.

Version 0.36 behebt ein Überlaufproblem des RX-FIFOs des Transceivers, der zum Empfangsausfall führen konnte (fiel nur beim reinen Empfangsbetrieb ohne regelmäßiges Senden auf). Danke Stefan für den Hinweis.

Auszug aus der Changed:
- little correction in rf_native, if slowrf monitoring is active
- lacrosse emu reworked
- SlowRf reception adapted for better ESA reception with still well E and HMS reception
- generic Manchester raw send added with Gm command
- ESA send added with 'S' command
- HMS send added with 'Q' command
- IT reception corrected
- RfRouter with repeat in FastRF packet, better send timing and reduced receive timeout
- for pure USB CULs blinking while waiting on watchdog reboot and during boot/bootloader reboot with different frequencies
- message finalization with \n on PIM receive buffer full
- ASKSIN, fastRF, RF-Router, moritz, rwe, RX-FIFO Overflow detection improved

Noch als Hinweis, für HMS und ESA scheint sens 12 eine ungünstige Einstellung für den Empfang  dieser Protokolle zu sein.

Diese Version bietet wakup support und keep awake Support. Für CULs mit wenig Speicher kann dies mit dem Attribut "hmForceLzyCfg" aktiviert werden, siehe auch der Hinweis zum EEPROM Verschleiß weiter unten.

Das RF-Router Ping Timing ist geändert, damit also auch nicht kompatibel mit Standard culffw oder a-culfw und auch nicht zur Version 0.32.
Ergänzt ist SlowRf Empfang von Pearl NC7427 Temperatur/Luftfeuchte Sensoren. Entsprechend Kanalwahlschalter können 3 Stück empfangen werden. Zum Anlernen mittels autocreate muss der TEST Taster am Sensor gedrückt werden.

Das EEPROM Layout ist geändert und daher werden nach dem Flashen alle Einstellungen auf default zurück gestellt. Also vor dem Flashen individuelle Einstellungen, z.B. Frequenzoffsets, notieren und nacher neu einstellen.

Auszug aus der Changed:
- FULL_PA_RAMPING bugs corrected
- CCA CS thresholds setable for ASKSIN, MORITZ, HAS_RWE, RFNATIVE and MBUS with XTxy, x=CARRIER_SENSE_REL_THR, y=CARRIER_SENSE_ABS_THR as in AGCCTRL1
- SlowRf receive timing limits corrected
- SlowRf lower filter switched off by define in rf_receive_timing.h
- RFR timing/timeout shortened, FastRF CCA disabled
- auto Ci interrupt counter messages
- XP command extended to switch on auto Ci messages, AP removed as all PLL messages switchable by XP
- improvement and corrections for CUNX RS485 PIG support
- CUNX: PIG RTS controllable by USB Host for serial foward and RS485 serial forward
- CUNX: DMX interupts changed to HI priority and CC1101 interrupts to MED priority
- CUNX: USB interrupts to LO priority
- GPIOR1 used for USB USB_DeviceState
- GPIOR1 used for SERIAL STACKING stacking_ST_state


Ein Peakfilter für SlowRF Empfang ist ergänzt und mit "peakfilter" einstellbar.
In dem Zusammenhang ist auch das RF-Router Ping Timing geändert, damit also auch nicht kompatibel mit Standard culffw oder a-culfw.
Außerdem kann das Senden von RF-Router Daten nach deren Empfang einstellbar verzögert werden (RfRdelay).

CCAMode wirkt nun auch auf IT-Senden und SOMY-Senden, sowie auf das Senden des RF-Router Pings. Mit fRfCCAMode kann auch das CCA Verhalten für RF-Router Senden und FastRF geändert werden.

Auszug aus der Changed:
- IT and SOMYFY use SlowRF EEPROM CCA setting now for sending
- changes in SlowRF reception for reset and sync start. IT V1 reception tested succsessfully.
- SlowRF filter and match adaption
- SlowRF spike filter improved, max. peak lenght settable with Xpxx, xx hex time in 8us units
- IR receive/transmit pause during send of SlowRF changed to not globally switching off all interrupts
- periodic RF-Router ping RSSI display as "Cuxx\r\n" with xx = RSSI Hex
- RF-Router ping timing changed for better distinguish from other protocols
- RF-Router pre silence before send settable with uRxx, xx hex time in 4ms units
- Xrrt commands bits:
   rr:
   report known protocol data                                                      Bit 0
   report repeated data                                                            Bit 1
   report received bits                                                            Bit 2
   report 'r' (rising) or 'f' (falling) edge, '.' (collect) or '?' (sync) timeout  Bit 3
   report edges, bit times and timeouts                                            Bit 4
   report S300 data with valid checksum only                                       Bit 5
   report FHT                                                                      Bit 6
   report 'l' RSSI decimal data continuosly                                        Bit 7
   t:
   report recorded SlowRF timing                                                   Bit 0
- corrections in interrupt flag clearing
- correction in delay function
- fastRF bug corrected, untested
- EEPROM layout changed for the new parameters


TSCUNX kann mit entsprechendem RS485 Modul nun auch DMX.
Auch HM485 ist für TXCUNX angepasst.
In dem Zuge ist auch die DMX Funktionalität bei CUNO2 etwas erweitert.
IR läuft nun auch richtig mit TSCONO2.
Außerdem läuft RF-Router auf der tsculfw, allerdings mit einer Änderung. Das 'U' ist durch '~' ersetzt. 'U' kollidierte mit dem Uniroll Senden.

Kurzer Auszug aus der CHANGED:
- IO optimizations CUNX, especially to/from PIM and Ethernet
- CUNX DHCP non blocking operation
- IO optimizations
- HM485 support for CUNX (like CUNO2) with RS485 PIM.
  HM485 switch off with Hx for CUNX. With CUNX after Hx RS485 PIM again accessible via PIM USB or Ethernet Interface
- CUNX support for DMX and HM485 with RS485 PIM (to be tested), a Dwxxxxyy switches to DMX via CUNX Interface, a Hsxxxxxxxxxxxxxxxxxx switches to HM485 via CUNX Interface
- DMX switch off with Dx. With CUNX after Dx RS485 PIM is again accessible via PIM USB- or Ethernet Interface
  DMX flexible channel usage. Channels are sent out upto the highest channel set (0 sent as default for unset channels). With switching off with Dx the highest channel is reset.
  DMX changed in timing and resting behaviour. Rests on IDLE if less then 24 device, only, to keep 1204µs min. BREAK to BREAK (to be tested)
  DMX Dt command to set/view timing of MarkAfterBreak and BREAK
  DMX less disturbed while sending SlowRF
- W function gives feedback after writing EEPROM
- clock timer unburdened, may impact onewire and fht (to be tested)
- corrections for IRTX
- IR base timings changed to 12500Hz or 20000Hz
- RF-Router working, but 'U' changed to '~' (definable in board.h, but 'U' disables HAS_UNIROLL)

Es ist eine Prüfung auf Stacküberlauf eingebaut. Am Anfang des heap werden zwei Byte mit einem Bitmuster beschrieben. Wird das verändert, dann ist der Speicher wahrscheinlich korrumpiert, was durch einen Stacküberlauf ausgelöst sein sollte. Sofern der CUL dann noch kann sendet er ein "C_M" an TSCUL, was zu einem entsprechenden Log Eintrag führt.
Damit kann man vorsichtig die Speichergrenzen ausloten. Ein langer Testzeitraum ist aber erforderlich, um einigermaßen sicher zu sein, dass der worst case auch mal durchlaufen worden ist.
Außerdem ist ein Kommando mU (je nach Firmware) eingebaut, mit dem man den vom Stack ungenutzen heap in etwa auslesen kann (auch als get unusedstack in TSCUL verfügbar). Auch hier gilt, nur nach langer Laufzeit einigermaßen sinnvoll. Es macht sicher keinen Sinn auf Grund des Wertes den Speicher bis auf das letzte Byte auszuquetschen, denn weiterhin hängt die Stacknutzung vom gewählten Protokoll und Einstellungen ab.

In TSCULflash ist Flashen auch von NanoCULs und MiniCULs ergänzt. Vor dem Flashen wird ein "B00" also Reset für die TSCUL Firmware an den nano/Mini geschickt, 1 Sekunde gewartet und dann versucht mit avrdude zu flashen.
Also erst die Firmware in den FHEM/Firmware Ordner kopieren und dann in FHEM mit
TSCULflash <nanodevicename> TSnanoCUL
bzw.
TSCULflash <minidevicename> TSminiCUL
versuchen zu Flashen. Im Log sollte danach (dauert etwas) die avrdude Ausgabe zu finden sein.

Ebenfalls (nur über USB Anschluss) möglich ist das Flashen eines PIGATOR Moduls an einem CUNX
TSCULflash <pigatordevicename>|<cunxdevicename> TSPIGATOR

AESCommReq wird unterstützt. Die Nutzung ist unverändert zu Standard CUL, sprich, beim gewünschten Gerät/Kanal aesCommReq auf 1 setzen und ggf. noch aesKey passend zum verteilten Key setzen.
Es werden von tsculfw nur die Keys 0 (Default Key) bis 3 unterstützt.

Diese Erweiterung erfordert jedoch auch zusätzliche Empfangspuffer im knappen Speicher des CULs. Ein CUL V3 nutzt bis zu 6 Empfangspuffer. Auch der FlashSpeicherbdarf ist angestiegen, so dass einige Protokolle nicht mehr gleichzeitig in ein Kompilat passen. Das sollte aber weniger tragisch sein, da im ASKSIN Modus ohnehin nur HM empfangen werden kann.

Bei CUL V2 reicht der verfügbare Speicher leider hinten und vorne nicht aus, um diese Version nutzen zu können.

Im Anhang ist in TSCUL_fwcode_00_xx_FHEM_Modules_00_xx.zip wieder die Timestamp Firmware zu finden. Getestet habe ich TSCUNX, TSPIGATOR , TSCUL_V3 , TSCUL_V3_RFR, TSCUNO2, TSCOC und TSSCC. (TSCUL_V3_RFR ist ohne HM Unterstützung, also nur SlowRF)

Die tsculfw Firmware kann für TSCUL_V3, TSCUL_V3_RFR (via USB), TSCUNO2, TSCOC, TSSCC, TSCUNX und TSPIGATOR (an CUNX) mit FHEM mit dem TSCULflash geflashed werden. Die anderen müssen mit dem jeweiligen Flash Programmer geflashed werden. Bei CUNO2 und SCC muss die Bootloadertaste gedrückt werden, bis der Flashvorgang anläuft.
So z.B. https://forum.fhem.de/index.php/topic,24436.msg631743.html#msg631743 kann es mit einem USB CUL Stick gehen, wenn man nicht TSCULflash verwendet.
TSCULflash ist erweitert auf COC, SCC, CCD, rpiaddon, CUNO2 und CUNO. Jedoch ist es nicht ganz so einfach zu handhaben, da zum einen teilweise die Taste zu drücken ist und bei Raspberry PI Modulen die Rechteproblematik für den Zugriff auf die IO-Pins überwunden werden muss. Tips dazu in der Command-Ref auch bei RPI_GPIO.
Bei einem Stapel aus SCC mit aufgesetztem COC, CCD oder (rpiaddon?) ist unbedingt beim SCC Flash darauf zu achten, die Taste am gewünschten Modul zu drücken. Sonst wird das oberste Nicht-SCC Modul mit der SCC Firmware geflashed.
Mit CUNO2 ist das flashen getestet (generell nur über USB!). Wichtig, aber auch hier, die Taste zu drücken.

Es gibt nicht den Luxus des Downloads beim TSCULflash, sondern die Firmware muss händisch in den FHEM/firmware Ordner kopiert werden. Der Typ ist dann z.B. TSCUL_V3.
Beispiel:
TSCULflash MeinCulV3Device TSCUL_V3

Wichtig für SCC Nutzer. TSSTACKED ist entfallen und wird nicht mehr unterstützt.
Statt dessen gibt es das neue Modul STACKABLETS (als Abwandlung von Rudolfs STACKABLE).
Dieses wird sozusagen zwischen die Stackteilnehmer eingebaut.

Beispiel für fhem.cfg:
#erstes SCC Modul als Basis
define SCC_WS868 TSCUL /dev/ttyAMA0@38400 0000
attr SCC_WS868 event-on-change-reading Ints_per_sec,IntCalcStat,MatchStat
attr SCC_WS868 rfmode SlowRF
attr SCC_WS868 room Receiver
attr SCC_WS868 sendpool CUL_HM868,SCC_WS868
attr SCC_WS868 verbose 1

#neues STACKABLETS virtuelles IO device
define STACK_1 STACKABLETS SCC_WS868
attr STACK_1 verbose 1

#zweites SCC Modul
define SCC_HM868 TSCUL FHEM:DEVIO:STACK_1:38400 1034
attr SCC_HM868 event-on-change-reading cond
attr SCC_HM868 hmId F11034


Ergänzender Hinweis zu USB CULs: 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_08\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 1234
bzw.
define CUL_433 TSCUL /dev/CUL433_0@12000000 0000
definiert werden und es gibt keine Probleme mit wechselnder Schnittstelle mehr.
Die Seriennummer kann beim Compilieren der Firmware in der board.h festgelegt werden, so dass damit dann auch /dev/CUL868_1 etc. für mehrere gleiche CULs möglich sind.

Oder für CUNX
define CUNX_868 TSCUL /dev/CUNX868_0@12000000 0000
oder für PIGATOR an CUNX
define PIGATOR_433 TSCUL /dev/CUNXPIM_0@38400 0000
die Seriennummer wird aus der Seriennummer des XMEGA Chips des CUNX gebildet. Unter Linux lsusb nutzen!

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.

Bei nicht nativen USB CULs wie z.B. nanoCUL, miniCUL oder CUNO2, beträgt die Baudrate 38400, dementsprechend muss die Definition beispielsweise so aussehen:
define CUL_868 TSCUL /dev/CUL868@38400 1234
bzw.
define CUL_433 TSCUL /dev/CUL433@38400 0000

Und noch ein Beispiel für eine Definition eines Netzwerk CUNX:
define CUL_868 TSCUL 192.168.178.111:2323 0000
oder für PIGATOR an CUNX
define PIGATOR_433 TSCUL 192.168.178.111:2324 0000
beim PIGATOR sollten zuvor mit Anschluss an USB und öffnen der Schnittstelle mit gewünschten Kommunikationsparametern mit ps oder unter TSCUL mit set PIMstoreBaud die seriellen Kommunikationsparameter zum PIGATOR Modul gespeichert werden, falls sie vom default abweichen.

Oder Netzwerk CUNO2:
define CUNO2_868 TSCUL 192.168.178.110:2323 0000

Die aktuell eingestellte oder per DHCP erhaltene Netzwerkadresse kann mit Lc repektive in TSCUL mit get NetAdresses abgefragt werden. Mit Lp respektive in TSCUL mit get NetPHYlink kann der Linkzustand des Netzwerkanschlusses angezeigt werden.


In der Zip Datei sind ebenfalls die ergänzten Module zu finden, die zur Nutzung der Firmware erforderlich sind.

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
16_TSCUL_RFR.pm -> der 16_CUL_RFR.pm, aus CUL_RFR devices werden damit TSCUL_RFR devices in der fhem.cfg (händisch anzupassen)
16_STACKABLETS.pm -> statt der 16_STACKABLE.pm, aus STACKABLE werden damit STACKABLETS devices in der fhem.cfg (händisch anzupassen)
97_timerTS.pm           -> Austausch-Timerroutinen und fhemFork()

10_UNIRoll_TS.pm  -> statt der 10_UNIRoll.pm, mit TSCUL 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 IO-devices zu verwenden, aus TSKS300 wird dann TSKS300  in der fhem.cfg (händisch anzupassen). Obsolet, da 14_TSCUL_WS.pm nun KS300 unterstützt.
14_TSCUL_TX.pm    -> statt der 14_CUL_TX.pm, mit TSCUL 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 IO-devices zu verwenden, aus CUL_WS wird dann TSCUL_WS  in der fhem.cfg (händisch anzupassen)
14_TSCUL_NC7427.pm  -> NC7427 Unterstützung
15_TSCUL_EM.pm   -> statt der 15_CUL_EM.pm, mit TSCUL IO-devices zu verwenden, aus CUL_EM wird dann TSCUL_EM  in der fhem.cfg (händisch anzupassen)
12_TSHMS.pm        -> statt der 12_HMS.pm zu verwenden
CalcUtil.pm               -> Hilfsrechenroutinen für Taupunkt und Windstärkeindex
ReadingUtil.pm          -> Hilfsroutinen für Readings

Da diese Module ergänzt werden (müssen!), überleben sie auch ein Update von FHEM.

98_fhemdebug.pm     -> fhemdebug zur zwingenden Nutzung mit 97_timerTS.pm.
98_apptime.pm          -> apptime zur zwingenden Nutzung mit 97_timerTS.pm.
98_apptm.pm            -> apptime zur zwingenden Nutzung mit 97_timerTS.pm, mit geringerem Speicherverbrauch bei weniger Details
10_IT.pm                   -> vermeidet unnötiges busy waiting beim Senden. Wird ohne Schutz von FHEM update überschrieben

Außerdem:

98_TSCULflash.pm     -> Zum Flash von TSCUL_V3, TSPIGATOR (an CUNX) mit Datei in FHEM/firmware

10_CUL_HM.pm         -> angepasste Version zur Nutzung mit TSCUL/tsculfw. Die Nutzung dieses Moduls ist optional. Für CUL_V3, nanoCUL, miniCUL im Multio-HM-IO Betrieb jedoch empfohlen, da sie den EEPROM Verschleiss über das Attribut "rssiSwitchHyst" verringert. Nur diese Version bietet derzeit vollständige TSCUL/tsculfw Unterstützung. Zur Einsparung redundanter Events werden teilweise Readings (actuator, desired-temp, measured-temp) nicht mehr zusätzlich im HM-device, sondern nur noch in den jeweiligen Channels aktualisiert.
HMConfig.pm             -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden. Einstelllimits für HM-CC-RT-DN Regler P und I Anteil erweitert. Damit kann man mit R-regAdaptive offDeter deutlich mehr an den Regelparametern spielen.
98_HMinfo.pm           -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden. Spaltenbreiten in Tabelle von protoEvents variabel zu verbesserten Übersicht in der Darstellung.
98_HMtemplate.pm   -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden.
Die 4 Dateien entsprechen einem Stand von Anfang 09/2020. Derzeit sollten diese verwendet werden.

10_CULG.pm              -> optional, enthalten, da die Firmware es unterstützt

98_autocreate.pm       -> autocreate mit TSCUL Unterstützung

98_Cumulate               -> Kumulieren von Zählwerten, wie Strom, Regenmenge etc.
98_SAverage.pm         -> Mittelwertbildung von z.B. Temperaturen. Stunde, Tag, Monat und Jahr, sowie ein gleitender Mittelwert der letzten Stunde sind damit möglich.
98_IntervalTimer.pm   -> optional, Intervalltimer um FEHM-Timerbasiert Kommandos in möglichst konstanten Intervallen absetzen zu können.

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_STACKABLETS.pm DevIoTS.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.pm CalcUtil.pm 14_TSCUL_NC7427.pm ReadingUtil.pm 97_timerTS.pm 98_TSCULflash.pm 98_apptime.pm 98_apptm.pm 10_IT.pm 10_CULG.pm 10_CUL_HM.pm HMConfig.pm 98_HMinfo.pm 98_HMtemplate.pm ReadingUtil.pm 98_autocreate.pm 98_Cumulate.pm 98_SAverage.pm 98_fhemdebug.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 zwingend auszuführender 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` }

Noch ein Hinweis: TSCUL fragt auch die Firmwareversion der tsculfw auf 0.36 ab. Eine ältere Version wird also nicht unterstützt!

Frequenzoffset: Für HM ist ein Frequenzoffset von -20.6kHz im EEPROM als default in der tsculfw hinterlegt (das ist ein individuelles Optimum für meinen COC). Dieser Frequenzoffset kann mit set hmFreqOffs umgestellt werden. 0 ist default in der Standard-culfw.
Wenn also keine Antwort von angesprochenen HM devices kommt, dann hmFreqOffs von 0 ausgehend verstellen. CUNX z.B. geht eher in Richtung + mit dem Offset.
Wer das Frequenzspektrum sichtbar machen kann, kann sich die optimale Mitte aller devices ermitteln und mit dem Offset sein CUL dazu passend einstellen.

Noch ein Tip zur Haltbarkeit der CULs mit wenig SRAM (CUL V3, nanoCUL, miniCUL ...). Jedesmal, wenn einem HM-Device das IODev durch Roaming neu zugeordnet wird, führt das zu EEPROM Schreibvorgängen in den beteiligten CULs. Die Lebensdauer des EEPROMs ist begrenzt (100000 Schreibzyklen laut Datenblatt). Daher rate ich zur Nutzung des VorzugsIOs beim Device Attribut IOgrp. Also nicht einfach stumpf
attr HMdeviceName IOgrp VCCU
setzen, sondern
attr HMdeviceName IOgrp VCCU:CUL_mit_gutem_Empfang_fuer_Device
sofern die Roaming Funktionalität entsprechend RSSI für das jeweilige device nicht zwingend benötigt wird. Ein Fallback auf einen anderen CUL bleibt dennoch möglich.
Mit dem Attribut "rssiSwitchHyst", das in der beigefügten 10_CUL_HM.pm verfügbar ist, kann bei den HM-devices die Umschalthysterese für das Roaming von 10 bis auf 2 bei Bedarf für mobile devices verringert werden.
Mit dem Attribut "hmForceLzyCfg" kann wakeup und keep awake support bei solchen CULs aktiviert werden. Das erhöht den EEPROM Verschleiß beim Lesen oder Verändern von Registerwerten bei wakup und lazy config devices.

Ergänzt ist auch noch ein set TX3Send.
Damit lassen sich TX3 Sensordatentelegramme auf 433er CULs versenden.
Beispiel:

define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 TX3Send T:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." SID:23 U")}

define NF_HumOut notify Sen_Aussen:humidity.* {fhem("set TSCUL_WS433 TX3Send H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." SID:23 U")}


Ergänzt ist auch noch ein set KSSend.
Damit lassen sich WS Sensordatentelegramme versenden.
Beispiel:

define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 KSSend T:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." Code:2")}


Zum regelmäßigen Senden von Sensordaten kann der IntervalTimer genutzt werden.
Beispiel:
define AussenSend_WS11 IntervalTimer CUNO2_WS868 176.5
attr AussenSend_WS11 offCmd {fhem("set @ KSSend T: ".ReadingsVal("C_Aussen","temperature",0.0)." H: ".ReadingsVal("C_Aussen","humidity",0.0)." Code:21")}
attr AussenSend_WS11 onCmd {fhem("set @ KSSend T: ".ReadingsVal("C_Aussen","temperature",0.0)." H: ".ReadingsVal("C_Aussen","humidity",0.0)." Code:21")}


Hier geht es zur vorherigen Version https://forum.fhem.de/index.php/topic,24436.msg1098370.html#msg1098370 (https://forum.fhem.de/index.php/topic,24436.msg1098370.html#msg1098370).

Gruß, Ansgar.

Edit: zip aktualisiert auf Modulstand 00_64.
Edit2: zip aktualisiert auf Modulstand 00_65.
Edit3: zip aktualisiert auf Modulstand 00_66, neues TSCUL Attribut 'forceAlivePing'.
Edit4: zip aktualisiert auf Modulstand 00_68, verbessertes Pairing
Edit5: zip aktualisiert auf Modulstand 00_69
Edit6: zip aktualisiert auf Modulstand 00_70, TC statusRequest
Edit6: zip aktualisiert auf Modulstand 00_71, wakeup, lazy config Verbesserungen
Edit7: zip aktualisiert auf Modulstand 00_74, Korrekturen Registeread, Pairing, AES und IO Zuweisung
Edit8: zip aktualisiert auf Modulstand 00_75, nextSend Verbesserung
Edit9: zip aktualisiert auf Modulstand 00_76, IO Zuweisung und IOgrp 'none' Option
Edit10: zip aktualisiert auf Modulstand 00_77, kleine Änderungen für pairing
Edit11: zip aktualisiert auf Modulstand 00_78, IO Zuweisung und IOgrp 'none' Korrektur HMInfo
Edit12: zip aktualisiert auf Modulstand 00_79, Register Read Korrekturen
Edit13: zip aktualisiert auf Modulstand 00_80, Register Read Korrekturen
Edit14: zip aktualisiert auf Modulstand 00_81, IO Zuweisung nach Reading IODev. Bei physischen HM-devices bitte Attribut IODev händisch löschen, da sonst der Attributwert benutzt wird und ohne Save Config vor einem Restart ist der Attributwert veraltet, was unnötige Änderungen in der IO Zuweisung zur Folge hat. Ich bitte um Rückmeldung wenn ein Log Eintrag "CUL_HM hint: <HMdeviceName> first CUL_HM_assignIO differs from fhem.pl restore" beim FHEM Restart auftauchen sollte.
Edit15: zip aktualisiert auf Modulstand 00_82, Rauchmelderkommandos
Edit16: zip aktualisiert auf Modulstand 00_83, getConfig für config devices mit Anlernknopf https://forum.fhem.de/index.php/topic,120268.0.html (https://forum.fhem.de/index.php/topic,120268.0.html)
Edit17: zip aktualisiert auf Modulstand 00_84, IO Zuweisung
Edit18: zip aktualisiert auf Modulstand 00_85, IO Zuweisung Bug bei config message
Edit19: zip aktualisiert auf Modulstand 00_86, wakup Verbesserungen und HMInfo showTimer
Edit20: zip aktualisiert auf Modulstand 00_87, wakup Verbesserungen und HMInfo showTimer
Edit21: zip aktualisiert auf Modulstand 00_89, wakup Verbesserungen
Edit22: zip aktualisiert auf Modulstand 00_90, wakup Verbesserungen, CUL_HM fwupdate Verbesserung, IO Zuweisung
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.37
Beitrag von: Adimarantis am 15 Februar 2021, 16:00:40
Zitat von: noansi am 13 Februar 2021, 09:24:09
Das Modul öffnet da eine Zeile zuvor ein File, prüft aber nicht, ob die Aktion von Erfolg gekrönt ist, was zu dem Fehlerbild führt.
Das wirst Du wohl im 58_GPIO4.pm Modul debuggen müssen.

Da gibts denke ich nicht viel zu debuggen. Wie du schon sagst, fehlt der Test auf erfolgreiches "open" und das kann ja bei einem Kommunikationsverlust mit dem Sensor mal passieren.
Hab ich jetzt mal gefixed. Das hatte entweder gar nix mit dir zu tun, oder deine Änderung hat eine ohnehin vorhandene race condition getriggert.

Sind Contrib Module verwaist? Ich lasse meinen Fix jetzt mal laufen, aber ich denke das sollte man irgendwann einchecken. Ich zumindest nutze das extensiv.

Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 15 Februar 2021, 20:35:32
Hallo Jörg,

ZitatDas hatte entweder gar nix mit dir zu tun, oder deine Änderung hat eine ohnehin vorhandene race condition getriggert.
So ist es auch. TimerTS als Timerersatz ruft auch nur Funktionen auf, wie es auch Standard Timer tun und übergibt auch genauso den mitgegebenen Parameter.
Wenn eine Funktion mit Schwächen auf dem Timer-Weg aufgerufen wird, dann passiert in beiden Varianten das gleiche: die Funktion fällt auf die Nase.

Der Stacktrace sagt bei Timern noch nichts direktes zu Quelle eines Problems.

ZitatSind Contrib Module verwaist?
Wenn in der MAINTAINER.txt nix drin steht... dann bleibt Dir noch der Copyright Hinweis als Anlaufstelle zu Nachfrage.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 21 Februar 2021, 10:24:16
Hallo Testwillige,

ich habe den Modulstand hier https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415 (https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415) aktualisiert.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: Adimarantis am 22 Februar 2021, 11:16:38
Hi Ansgar,

nach dem letzten Update reagiert mein Raspi extrem träge (Klicks auf der Weboberfläche brauchen gerne mal 10s bevor etwas aktualisiert), obwohl die Gesamtbelastung vom Raspi (CPU%, load) ganz ok ist. Der FHEM Prozess hat aber immer 27-30% CPU (Raspi 1 ist nur Single Core, oder?). Die Fehlerrate ist auch hochgeschossen.
Ich wollte jetzt ausschliessen das das eine andere Ursache hat, leider habe ich die alten Testversionen gelöscht und im Thread hast du sie wohl auch aufgeräumt.
Kannst du das nachvollziehen? Kannst du mir nochmal eine ältere Version auschecken damit ich den Vergleich machen kann?

EDIT: Mir ist nach dem Schreiben dieser Zeilen noch eine andere Änderung eingefallen die ich zeitgleich gemacht hatte. Die habe ich jetzt mal zurückgenommen, mal sehen ob es das war.

Danke,
Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: Adimarantis am 24 Februar 2021, 17:24:54
Zitat von: Adimarantis am 22 Februar 2021, 11:16:38
EDIT: Mir ist nach dem Schreiben dieser Zeilen noch eine andere Änderung eingefallen die ich zeitgleich gemacht hatte. Die habe ich jetzt mal zurückgenommen, mal sehen ob es das war.

Ich denke ich kann Entwarnung geben, läuft jetzt ein paar Tage und das Problem ist nicht mehr aufgetreten.
Nichts für ungut.

Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 25 Februar 2021, 19:11:03
Hallo Jörg,

puhh, Glück gehabt, dass ich es spät genug gelesen habe.  ;)

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 04 März 2021, 20:13:37
Hallo Testwillige,

ich habe den Modulstand hier https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415 (https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415) aktualisiert.

Edit:
- TSCUL: alive Ping Interval für Netzwerk angebundene CULs etwas reduziert
- HMConfig: Martins Änderungen und TC StatusRequest Korrekturen
- CUL_HM: Martins Änderungen + Korrekturen, Alive Check für MultiChannel Devices nurn noch mit StatusRequest auf einem Channel
- was ich schon wieder vergessen habe...

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: Adimarantis am 04 März 2021, 20:46:38
Hi Ansgar,

gibt's eine kurze Zusammenfassung der Änderungen?

Danke,
Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: yersinia am 05 März 2021, 09:48:54
Hallo zusammen,

gibt es auch eine Kurzübersicht (for dummies  ;D) welche Vorteile die tsculfw für den CUL gegenüber aculfw hat?
Zu meinem Setup: ich nutze für eine reine HomeMatic classic Umgebung zwei nanoCULs mit aculfw 1.26.08 und habe nur wenig Probleme (eigentlich hängen sich 'nur' die nanoCULs unregelmässig und schlecht vorhersagbar auf, daher auch zwei und die VCCU) bisher. Siehe auch Signatur bezgl. der verwendeten Aktoren & Sensoren. Ich nutze keine originalen HM IOs.
Ich habe jetzt nicht alle Seiten dieses Threads gelesen - ist bei derzeit 80 Seiten auch etwas viel - und das Wiki (https://wiki.fhem.de/wiki/HomeMatic#FHEM_als_Zentrale) gibt auch nicht viel her. Den letzten Changelog (https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415) habe ich überflogen aber mir ist immernoch nicht klar, warum ich die tsculfw nutzen sollte.
Kann dies jemand kurz zusammenfassen - oder auf eine Doku stoßen (wenn es ein RTFM-PEBKAC Problem ist  ::))?

Besten Dank.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 06 März 2021, 13:50:44
Hallo yersinia,

Zitatgibt es auch eine Kurzübersicht (for dummies  ;D) welche Vorteile die tsculfw für den CUL gegenüber aculfw hat?
HM classic hat mit Bezug auf FHEM recht knappe Anforderungen bezüglich Antworttiming und Sendetiming. Insbesondere zu batteriebetriebenen devices kommt es zu Kommunikationsproblemen, wenn diese verletzt werden.
- a-culfw: reichhaltige Unterstützung für SlowRf Protokolle, Portierung auf nicht ATmega Hardwareplattformen. Für HM wenig geeignet mangels Unterstützung für HM-Timing und HM-AES Signierung -> starke Anfälligkeit für FHEM Laufzeitunterschiede und auch kurze FHEM freezes
- tsculfw: verbesserte Stabilität, Verbesserungen bezüglich SlowRf Empfang und Senden. Für HM Unterstützung für HM-Timing und HM-AES Signierung -> verringerte Anfälligkeit für FHEM Laufzeitunterschiede und kurze FHEM freezes. Angepasste und neue FHEM-Module zur Nutzung mit der tsculfw Firmware. Frequenzoffset einstellbar.

Zitateigentlich hängen sich 'nur' die nanoCULs unregelmässig und schlecht vorhersagbar auf
Wie äußert sich das? Was sagt uptime, wenn sie "hängen"?
Wenn die nanoCULs von schlechter Hardwarequalität sein sollten, kann die Firmware da vermuzlich nichts dran retten.

ser2net
Hoffentlich über LAN und nicht über WLAN.

Zitataber mir ist immernoch nicht klar, warum ich die tsculfw nutzen sollte.
Wenn Du Probleme bekommst und im Homematic Forum die Empfehlung bekommst diese Firmware zu nutzen oder ein originales HM-IO.

ZitatKann dies jemand kurz zusammenfassen - oder auf eine Doku stoßen
Post Nummer 1 plus 80 Seiten Thread, eventuell von hinten nach vorne durchgehen. Suchfunktion kann auch helfen.

Vor einem Test Rückweg vorbereiten. Backup FHEM. Alte Firmware nanoCULs als .hex bereit halten.

Wenn Deine nanoCULs eine abweichende Beschaltung aufweisen, board.h anpassen, compilieren und auf die nanoCULs flashen. Ansonsten TSnanoCUL.hex aus der zip auf die nanoCULs flashen.
Module durch Module aus zip austauschen. fhem.cfg anpassen. FHEM neu starten.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: pte am 06 März 2021, 14:14:40
Hallo noansi,

ich hatte gestern ein Update von TSCUL auf die Version 38 einschließlich der erforderlichen FHEM-Module (sowie auch deine 10_CUL_HM, 98_HMInfo, 98_HMtemplate und HMConfig) vorgenommen. Danach habe ich festgestellt, dass bei meinen HM-CC-RT-DN im Device die Readings actuator, desired-temp und measured-temp nicht mehr aktualisiert wurden. Die korrespondierenden Werte im Channel04 (ValvePosition, desired-temp und measured-temp) waren aktuell. Der Einsatz der Standard 10_CUL_HM,... behob das Problem wieder.
Ich kann nicht sicher sagen, ob das Problem schon in früheren Versionen deiner 10_CUL_HM auftrat, da ich bisher nur die zwingenden Dateien zum TSCUL genutzt hatte.

Viele Grüße pte
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 06 März 2021, 14:45:22
Hallo pte,

das ist kein Fehler (für Dich jetzt möglicherweise als Problem wahrzunehmen), sondern eine beabsichtigte Einsparung redundanter events.
Die Daten sind im Clima channel zu finden und werden dort auch aktualisiert, wie auch in Martins Standard 10_CUL_HM.pm (den Hinweis dazu gab's schon bei der V0.37, Edit: hab ich jetzt auch in den Hinweisen zur V0.38 zu 10_CUL_HM.pm ergänzt).
Sie machen dort auch logisch Sinn und nicht im device.

Da ich HM-CC-RT-DN auch selbst nutze, wird das in meiner Sonderversion auch definitv so bleiben.
Ggf. müßtest Du auf die entsprechenden Events im Clima Channel lauschen, statt auf die im device.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: pte am 06 März 2021, 14:59:53
Hallo noansi,

danke für die schnelle Rückmeldung. Den Hinweis habe ich dann wohl überlesen.
Wenn dies so beabsichtigt ist, kein Problem, das kann ich bei mir ändern.

Schönes WE
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: pte am 07 März 2021, 10:57:20
Hallo Ansgar,

doch noch eine Frage. Entfallen damit zukünftig auch die entsprechenden Readings im Device (actuator,..)? Ich habe feststellen müssen, dass der Änderungsaufwand bei mir doch umfangreicher ist und ich würde mir dann vorerst userReadings anlegen.

Gruß Peter
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 07 März 2021, 11:28:26
Hallo Peter,

Zitatdoch noch eine Frage. Entfallen damit zukünftig auch die entsprechenden Readings im Device (actuator,..)?
Ja. Tun sie ja jetzt schon, denn nicht Aktualisieren ist gleichbedeutend mit entfallen.

Mit userReadings kannst Du sie Dir selbst erzeugen. Ist natürlich kontraproduktiv zur eigentlichen Intention, redundante events zu vermeiden, aber wenn es bei Dir nicht stört, ist es eine Ausweichmöglichkeit.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: pte am 07 März 2021, 11:30:45
Hallo Ansgar,

also bei mir waren die Readings nach dem Update noch da. Muss man diese selbst löschen?
Betrifft es außer actuator, measured-temp und desired-temp noch weitere?

Peter
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 07 März 2021, 11:52:01
Hallo Peter,

actuator (entspricht ValvePosition im clima channel), desired-temp, measured-temp beim device eines HM-CC-RT-DN.

Ich lösche die Readings nicht automatisch (beim Neustart), könnte ich natürlich noch ergänzen, wenn notwendig. Für userReadings wäre das möglicherweise kontraproduktiv.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: pte am 07 März 2021, 13:06:30
Hallo Ansgar,

ich sehe das Löschen auch kontraproduktiv (auch in Hinblick auf meine Behelfslösung).
Ich bin bei meiner Überarbeitung noch auf eine Frage gestoßen (ich befürchte hier zwar out of Topic, stelle sie aber trotzdem mal).
Es betrifft das Zusammenspiel von HM-TC-IT-WM-W-EU und HM-CC-RT-DN bezüglich Wochenprogramme.
Gepeert sind ja die Channels 02, die Wochenprogramme im HM-CC-RT-DN liegen ja aber im Channel 04. Spielen diese bei Kopplung mit einem HM-TC-IT-WM-W-EU noch eine Rolle?

Peter
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 07 März 2021, 14:09:54
Hallo Peter,

ZitatEs betrifft das Zusammenspiel von HM-TC-IT-WM-W-EU und HM-CC-RT-DN bezüglich Wochenprogramme.

Ja, hier off Topic.
Und da ich keinen HM-TC-IT-WM-W-EU habe, habe ich mir darum auch noch keine Gedanken gemacht, was der so alles an gepeerte RTs überträgt.

Wäre wohl eine Frage im Homematic Forum, wenn die Anleitungen dazu keine Auskunft bieten, denke ich.
Respektive, führt eine Änderung am HM-TC-IT-WM-W-EU Programm zu einer Änderung am HM-CC-RT-DN (get config im HM-CC-RT-DN clima channel nach etwas Wartezeit)?
Schon mal probiert, die Batterien am HM-TC-IT-WM-W-EU zu entfernen und dann zu schauen, ob der RT nach einer Weile autonom mit seinem Wochenprogramm weiter macht?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: yersinia am 07 März 2021, 20:15:33
Zitat von: noansi am 06 März 2021, 13:50:44
Hallo yersinia,

HM classic hat mit Bezug auf FHEM recht knappe Anforderungen bezüglich Antworttiming und Sendetiming. Insbesondere zu batteriebetriebenen devices kommt es zu Kommunikationsproblemen, wenn diese verletzt werden.
- a-culfw: reichhaltige Unterstützung für SlowRf Protokolle, Portierung auf nicht ATmega Hardwareplattformen. Für HM wenig geeignet mangels Unterstützung für HM-Timing und HM-AES Signierung -> starke Anfälligkeit für FHEM Laufzeitunterschiede und auch kurze FHEM freezes
- tsculfw: verbesserte Stabilität, Verbesserungen bezüglich SlowRf Empfang und Senden. Für HM Unterstützung für HM-Timing und HM-AES Signierung -> verringerte Anfälligkeit für FHEM Laufzeitunterschiede und kurze FHEM freezes. Angepasste und neue FHEM-Module zur Nutzung mit der tsculfw Firmware. Frequenzoffset einstellbar.
[...]
Vor einem Test Rückweg vorbereiten. Backup FHEM. Alte Firmware nanoCULs als .hex bereit halten.

Wenn Deine nanoCULs eine abweichende Beschaltung aufweisen, board.h anpassen, compilieren und auf die nanoCULs flashen. Ansonsten TSnanoCUL.hex aus der zip auf die nanoCULs flashen.
Module durch Module aus zip austauschen. fhem.cfg anpassen. FHEM neu starten.
BESTEN DANK noansi für die gute Zusammenfassung. Irgendwo habe ich noch ein oder zwei nanoCULs rumliegen, die könnte ich testhalber flashen - der Tausch geht via Terminal-Modul (https://smile.amazon.de/dp/B01C2QKJ4G) recht gut.
Kann ich aculfw und tscuifw (jeweils ein nanoCUL) parallel betreiben? Aber wahrscheinlich ist das nicht sinnvoll.
Sende/Empfangsmodul (CC1101) ist nach Michael Heck (https://www.michael-heck.net/bilder/nanoCUL/Schema.jpg) angeschlossen - wie kann ich prüfen ob meine Beschaltung abweicht?

Ja, der ser2net (https://forum.fhem.de/index.php/topic,102014.0.html)-nanoCUL ist via LAN angebunden. WLAN ist Driss. Außer für die Geräte, die nicht anders können - oder nicht kritisch sind.

Bezgl. des Aufhängen des nanoCULs ist mir aufgefallen, dass es häufig den ser2net-nanoCUL betrifft. Der andere nanoCUL hängt direkt am FHEM-RasPi und wird beim FHEM Reboot mit neu initialisiert; der ser2net-nanoCUL nicht.
Zwischen der letzten neu-Initialisierung und dem letzten Aufhängen lagen weniger als 24 Stunden, Uptime seit dem liegt bei 3 Tagen und 5 Stunden. Ich beobachte.
Wenn sie hängen sagt uptime nichts mehr, die Kommunikation ist seitens FHEM nicht mehr möglich bis der CUL aus und wieder eingesteckt wird. Ansonsten wird das uptime-Reading nicht regelmässig aktualisiert.

Uih, und die ganzen Module tauschen bedeutet auch eine lange Liste an vom Update auszuschließende Dateien. Oder fhem die Rechte entziehen. Aber das ist ja kein Problem.

Vielen Dank nochmal für die Hilfe. :)
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 08 März 2021, 00:19:37
Hallo yersinia,

ZitatKann ich aculfw und tscuifw (jeweils ein nanoCUL) parallel betreiben? Aber wahrscheinlich ist das nicht sinnvoll.
Du kannst tun, was Du nicht lassen kannst. Allerdings brauchst Du mich bei HM-Mischbetrieb gar nicht erst fragen, wenn etwas nicht funktioniert.

ZitatSende/Empfangsmodul (CC1101) ist nach Michael Heck angeschlossen - wie kann ich prüfen ob meine Beschaltung abweicht?
Passt wohl.
Die nanos müssen außerdem 16MHz Takt haben, damit es mit der hex harmoniert.

Zitatwird beim FHEM Reboot mit neu initialisiert; der ser2net-nanoCUL nicht.
??? Initialisiert wird er sicherlich, aber es behebt wohl nicht Dein "Absturz"-Problem. Ist die ser2net Verbindung nicht stabil? Stromversorgung ausreichend?

ZitatZwischen der letzten neu-Initialisierung und dem letzten Aufhängen lagen weniger als 24 Stunden, Uptime seit dem liegt bei 3 Tagen und 5 Stunden. Ich beobachte.
Wenn sie hängen sagt uptime nichts mehr,
uptime am CUL (die interessiert) musst Du manuell auslösen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: yersinia am 08 März 2021, 09:40:39
Zitat von: noansi am 08 März 2021, 00:19:37Du kannst tun, was Du nicht lassen kannst. Allerdings brauchst Du mich bei HM-Mischbetrieb gar nicht erst fragen, wenn etwas nicht funktioniert.
Zum Einen wäre der Mischbetrieb im Fehlerfall der erste Analyse- sowie Ansatzpunkt für mich und zum Anderen deute ich deine Antwort als lass es lieber.

Zitat von: noansi am 08 März 2021, 00:19:37??? Initialisiert wird er sicherlich, aber es behebt wohl nicht Dein "Absturz"-Problem. Ist die ser2net Verbindung nicht stabil? Stromversorgung ausreichend?
uptime am CUL (die interessiert) musst Du manuell auslösen.
Der nanoCUL blinkt dann wild - und ist für FHEM nicht mehr zu erreichen. Das gilt auch für den nanoCUL direkt am RasPi auch wenn es wesentlich seltener auftritt.
Bisher habe ich keine Probleme bei der ser2net Verbindung feststellen können. Wenn der nanoCUL läuft, läuft er zufriedenstellend mit dem ihm zugeordneten Devices. LAN Verbindung ist stabil soweit ich das beurteilen kann (alle anderen Geräte im gleichen Netzwerk laufen stabil), der Router (Archer C7 v5 mit OpenWRT 19.07.7), an dem der nanoCUL am USB Port hängt, läuft auch stabil und der USB-Port liefert seine 500mA.
(Interessanterweise ignoriert die VCCU den nanoCUL Ausfall (der Status ist dann opened), die zugehörigen Devices werden trotzdem nicht auf den in Reichweite befindlichen anderen nanoCUL umgeroutet obwohl ich immer ein preferred IO (https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU#Dynamisches_IO) angegeben habe; ich nutze übrigens auch keine AES Verschlüsselung).
Wenn der nanoCUL sich aufhängt und ich ein get uptime versuche gibt es nur ein no answer. Aber das wird hier langsam OT.
EDIT: im OpenWRT Kernel ringbuffer finde ich folgende Laufzeiten für den nanoCUL: ~210,42 Stunden (~8,7 Tage), ~126,41 Stunden (~5,26 Tage), seit dem läuft dieser unauffällig.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 08 März 2021, 18:49:15
Hallo yersinia,

ZitatDer nanoCUL blinkt dann wild - und ist für FHEM nicht mehr zu erreichen.
was passiert denn, wenn Du ein raw B00 an die nanos schickst?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: yersinia am 09 März 2021, 08:41:27
Was bewirkt ein raw B00? Hab es gefunden (https://wiki.fhem.de/wiki/CUL#Hinweise_zum_Betrieb_mit_FHEM). Bisher habe ich immer ein set reopen versucht, was zumindest den Status von initialized auf opened ändert.
Kann ich gerne nachstellen wenn einer nanoCULs wieder hängt - dazu muss ich aber warten. :|

Und ich sehe gerade, dass mich das hier schreiben schon -bezgl Optionen und Information- etwas weitergebracht hat: https://wiki.fhem.de/wiki/CUL#Harter_Lockup_des_CUL (https://wiki.fhem.de/wiki/CUL#Harter_Lockup_des_CUL)



EDIT: falls es mal jemand benötigt - meine nanos habe ich 2017 bestellt, wahrscheinlich laufen die mit dem alten, suboptimalen bootloader wie die meisten clones oder ältere Originale. Auf yt gibt es ein sehr gutes Video wie man den neuen bootloader relativ einfach mit einem weiteren nano und der Arduino IDE draufschreibt: Arduino Bootloader Update or Install - Upgrade a Clone From Old Bootloader to New Optiboot! (https://www.youtube.com/watch?v=1TM-ADHb5Dk)
Wiring-diagram ist auf arduino.cc gut beschrieben (https://www.arduino.cc/en/Tutorial/BuiltInExamples/ArduinoISP/#how-to-wire-your-boards) (die Verbindungen sind identisch auch zwischen zwei nanos).

Optiboot unterstützt eine höhere Baudrate (alt: 57600; neu: 115200), um aculfw auf den nano zu flashen muss das entsprechend angepasst werden, zB:
avrdude -p atmega328p -c arduino -P [COMPORT] -b 115200 -D -Uflash:w:./nanoCUL868.hex:i



EDIT 2: ich habe jetzt zwei weitere nanos mit der TSnanoCUL.hex geflasht und FHEM entsprechend angepasst (https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415) und neu gestartet. Ich beobachte, wie es läuft. Als Reserve habe ich die zwei 'alten' nanos mit aculfw und natürlich backup von allem. ;)
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 09 März 2021, 20:11:19
Hallo yersinia,

ok, meine Vermutung zur Bootloader Loop nach Watchdog Reset hat wohl gepasst.  ;)
Schön, dass Du den Optiboot Hinweis schon gefunden hast.

Der Watchdog kann bei jeder Firmware Variante zuschlagen, wenn gleich ich versucht habe, dies für den Normalbetrieb nach Möglichkeit in der tsculfw zu vermeiden. Sprich Warten mit Timeout, statt warten, bis der Watchdog zuschlägt.

Dann gibt es auch noch die Möglichkeit des Pufferüberlaufs bei der seriellen Übertragung auf CUL Seite. Und da ASKSIN immer mit HEX Daten als Befehl versorgt wird, kann das prinzipiell im ungünstigen Fall zu Datensalat führen bei dem auch ein B00 statt des gewünschten Befehls ausgeführt wird -> auch ein Watchdog Reset. Gilt auch für jede Firmware Variante. Allerdings müssen dazu mehrere Befehle hintereinander ohne Pause an den seriell angebunden CUL gesendet werden.
In TSCUL gibt es aber Bremsmechanismen, so dass der Zustand nicht eintreten sollte.
Xon/Xoff für die serielle Übertragung war noch nie in einer der Firmware Varianten implementiert, so weit ich das gesehen habe (und möchte ich wegen SlowRf auch nicht in die tsculfw einbauen).

In beiden Fällen muss der CUL also diese Watchdog Reset "überleben", was bei einem problematischen Bootloader beim nano offenbar schief geht.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: yersinia am 10 März 2021, 07:51:26
Danke für die Details. :)

Gibt es eine Möglichkeit die tsculfw CULs zu überwachen?
Mit aculfw kann ich das Reading state via ReadingsAge überwachen, wenn der nanoCUL hängt, dann aktualisiert das Reading sich nicht.
Bei den tsculfw nanoCULs sehe ich nur das Reading scF welches regelmässig aktualisiert wird. Ich würde gern mitbekommen, wenn der nanoCUL hängt oder (im Falle von ser2net) nicht erreichbar ist - würde auch das VCCU-Handling vereinfachen. (bezgl. der VCCU hat das bei mir eigentlich nie funktioniert, dass auf ein anderes IODev umgeschwenkt wird wenn das eine ausfällt; möglicherweise weil die VCCU das gar nicht mitbekommen hat - das war aber auch mit dem alten nano Bootloader)

Btw, der HMclassic Betrieb hat jetzt eine Nacht (Rolläden runter und wieder rauf) überlebt, ich denke, bisher läuft es ganz gut. :)
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 10 März 2021, 20:05:06
Hallo yersinia,

das scF wird zwar aktualisiert, löst aber kein Event aus. Es ist nur ein Reading, weil es so einen FHEM restart überlebt, somit dann wieder genutzt werden kann.

Das Reading 'cond' kannst Du überwachen (erzeugt events). Wenn 900s lang nichts empfangen wird, dann wird ein C99 an den CUL gesendet, womit alle cc1101 Register zurückgeliefert werden. Wenn diese Antwort nicht kommt, dann geht der CUL auf 'cond' disconnected mit event.
Dann siehst Du ggf. auch 'Warning-HighLoad' oder 'ERROR-Overload'.

Für CULs, die via Netzwerk angebunden werden, also mit IP:Port definiert werden (außer localhost) wird alle knapp 60s ein ping an den CUL gesendet (wenn nicht gerade ohnehin Kommunikation im Gange ist). Bleibt die ping Antwort (nach Timeout) aus, wird der CUL ebenfalls auf 'cond' disconnected gesetzt.
In der nächsten Modulversion werde ich diesen Mechanismus auch noch mit einem 'forceAlivePing' Attribut für alle CULs erzwingbar machen. Dann könnte man so einen Bootloop nano auch etwas früher erkennen (aber auch nicht beheben, geht nur mit Bootloader Update).

Ein disconnected triggert auch ein 'DISCONNECTED' event für den CUL.

Mit folgenden reconnect Versuchen werden sie dann ggf. wieder auf 'ok' gesetzt, wenn dies erfolgreich ist.

Zitatwenn der nanoCUL hängt oder (im Falle von ser2net) nicht erreichbar ist - würde auch das VCCU-Handling vereinfachen
Sollte "out of the box" funktionieren, weil ich das condition Handling in TSCUL compatibel zu HMLAN gemacht habe (ohne Anspruch auf vollständige Fehlerfreiheit  ;) ).

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: yersinia am 11 März 2021, 12:10:05
Hallo noansi,

Danke, das hilft. Bisher brauch(t)e ich kein event, da ich periodisch (1x pro Stunde) ua die nanoCULs abfrage. Bei aculfw genügt es, state mit ReadingsAge zu prüfen - ich löse ein reopen aus wenn das Reading das letzte mal vor >900s aktualisiert worden ist. Wenn das dreimal fehlschlägt gibt das script auf. Es forciert aber den aculfw-nanoCUL-state auf opened zu zwingen.

Der VCCU geb' ich auch (erstmal) keine Schuld, da selbst FHEM nicht mitbekommen hat, dass die nanoCULs mit dem alten Bootloader nicht mehr reagieren - wie soll die VCCU das dann mitbekommen?
Ich beobachte mal wie gut der neue Optiboot Bootloader jetzt auch mit der tsculfw läuft. Hoffentlich schwenkt die VCCU um wenn ein nanoCUL ausfällt.

Aber, bisher, läuft die tsculfw echt unaufällig, so soll es ja auch sein. :)
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 11 März 2021, 18:40:02
Hallo yersinia,

ZitatHoffentlich schwenkt die VCCU um wenn ein nanoCUL ausfällt.
Reconnect, sofern möglich, soll "out of the box" funktionieren. Ansonsten soll es bei disconnected bleiben und die VCCU den noch lebenden nutzen, sofern IOList und IOgrp richtig konfiguriert sind.

Sende ein raw B00 (erzwingt einen Watchdog Reset) an die CULs und schau, was passiert (macht nur Sinn, wenn der Optiboot geflashed wurde. Wäre sonst nur duch USB Portreset zu retten, aber das macht TSCUL nicht).
Zieh die CULs ab und steck sie wieder an und schau was passiert.
Zieh das Netzwerkkabel am ser2net ab und wieder an und schau, was passiert.
Lass jeweils einen abgezogen und schau was passiert.
Jeweils mit Geduld.
Testen ist da besser als Beten. ;)

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 12 März 2021, 18:37:35
Hallo Testwillige,

ich habe den Modulstand hier https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415 (https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415) aktualisiert.

Das Attribut 'forceAlivePing' ist damit für TSCUL drin.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: yersinia am 13 März 2021, 15:43:05
Zitat von: noansi am 12 März 2021, 18:37:35ich habe den Modulstand hier https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415 (https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415) aktualisiert.

Das Attribut 'forceAlivePing' ist damit für TSCUL drin.
Danke. :)
Gibt es eine Übersicht, welche Dateien unter FHEM/ geändert worden sind? Dann kann ich mir sparen, alle Dateien zu sichern bzw. ersetzen. Nach dem Änderungsdatum vermute ich (im Vergleich zur 65):
00_TSCUL.pm
16_TSCUL_RFR.pm
DevIoTS.pm
Bezgl. Firmware scheint es keine Änderungen zu geben.

Ich sehe auch gerade, dass die angepasste 10_CUL_HM.pm auf dem Modustand der Revision 23856 (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/10_CUL_HM.pm?rev=23856) basiert, also aktueller (https://svn.fhem.de/trac/changeset?old=23856&old_path=trunk%2Ffhem%2FFHEM%2F10_CUL_HM.pm&new=23938&new_path=trunk%2Ffhem%2FFHEM%2F10_CUL_HM.pm) als 09/2020 ist. (Übrigens auch für HMConfig.pm (23857 (https://svn.fhem.de/trac/changeset/23857/)), 98_HMinfo.pm (23776 (https://svn.fhem.de/trac/changeset/23776/)) und 98_HMtemplate.pm (19079 (https://svn.fhem.de/trac/changeset/19079/)))  Danke dafür!
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 14 März 2021, 09:22:31
Hallo yersinia,

ZitatBezgl. Firmware scheint es keine Änderungen zu geben.
Modulstand ... geändert

ZitatGibt es eine Übersicht, welche Dateien unter FHEM/ geändert worden sind?
Macht es Sinn, andere, die von einem älteren Stand updaten, mit der von Dir gewünschten Information zu verwirren, mit dem Erfolg, Fehlfunktionen aus Mischzusammenstellungen entwirren zu müssen?

Aber Du hast ja schon den Informationsgehalt des Dateisystems und Revisionsnummern entdeckt und für Dich nutzbar gemacht.  ;)

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: yersinia am 14 März 2021, 15:02:51
Hallo noansi,
Zitat von: noansi am 14 März 2021, 09:22:31Modulstand ... geändert
pfff, als wenn ich das so genau lese (head->table). Ja, Leseverständnis ist manchmal etwas nicht vorhanden. ::)

Zitat von: noansi am 14 März 2021, 09:22:31Macht es Sinn, andere, die von einem älteren Stand updaten, mit der von Dir gewünschten Information zu verwirren, mit dem Erfolg, Fehlfunktionen aus Mischzusammenstellungen entwirren zu müssen?

Aber Du hast ja schon den Informationsgehalt des Dateisystems und Revisionsnummern entdeckt und für Dich nutzbar gemacht.  ;)
Jup, damit ist es für mich in Ordnung.

Übrigens, der Modulstand 66 läuft bisher unauffällig (gut). Bedankt.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 17 März 2021, 21:31:46
Hallo Testwillige,

ich habe den Modulstand hier https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415 (https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415) aktualisiert.

Pairing ist verbessert.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 21 März 2021, 14:14:01
Hallo Testwillige,

ich habe den Modulstand hier https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415 (https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415) aktualisiert.

Pflege Aktualisierungen CUL_HM und Co.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: pte am 22 März 2021, 09:52:30
Hallo Ansgar,

ich habe im Log gelegentlich nachfolgende Einträge:
2021.03.22 06:24:23.767 3: CUL_HM set EGHauslicht getConfig noArg
2021.03.22 06:24:28.921 3: LogHist KGHZCUNO:  06568799 A F101 08717108 00 16 0E A010 4AB43F F11234 038200003264009E00FF813363 -65dB
2021.03.22 06:24:28.921 3: LogHist KGHZCUNO:  06568920 A F103 08717204 01 0A 0E 8002 F11234 4AB43F 00 _CCAdly:4 _dhmSt:96
2021.03.22 06:24:28.921 3: LogHist KGHZCUNO:  06569048 A F101 08717352 00 0C 0F A010 4AB43F F11234 030000 -65dB
2021.03.22 06:24:28.922 3: LogHist KGHZCUNO:  06569166 A F103 08717448 01 0A 0F 8002 F11234 4AB43F 00 _CCAdly:4 _dhmSt:96
2021.03.22 06:24:28.922 3: LogHist KGHZCUNO:  06569275 A F103 08717552 01 10 10 A001 F11234 4AB43F 01044E61C60303 _CCAdly:4 _dhmSt:200
2021.03.22 06:24:28.923 3: LogHist KGHZCUNO:  06569438 A F101 08717712 00 16 10 A010 4AB43F F11234 030222300069005900FF813333 -65.5dB
2021.03.22 06:24:28.923 3: LogHist KGHZCUNO:  06569527 A F103 08717808 01 0A 10 8002 F11234 4AB43F 00 _CCAdly:4 _dhmSt:96
2021.03.22 06:24:28.923 3: LogHist KGHZCUNO:  06569662 A F101 08717964 00 16 11 A010 4AB43F F11234 03820000326400FF00FF201463 -65dB
2021.03.22 06:24:28.924 3: LogHist KGHZCUNO:  06569780 A F103 08718060 01 0A 11 8002 F11234 4AB43F 00 _CCAdly:4 _dhmSt:96
2021.03.22 06:24:28.924 3: LogHist KGHZCUNO:  06569826 A F101 08718128 00 0D 18 A410 54A14A F11234 06040000 -78.5dB
2021.03.22 06:24:28.924 3: LogHist KGHZCUNO:  06569907 A F101 08718212 00 0C 12 A010 4AB43F F11234 030000 -65dB
2021.03.22 06:24:28.924 3: LogHist KGHZCUNO:  06570083 A F101 08718252 00 0A 18 8002 F11234 54A14A 00 -86.5dB
2021.03.22 06:24:28.925 3: LogHist KGHZCUNO:  06570198 A F101 08718500 00 0C 12 A010 4AB43F F11234 030000 -65.5dB
2021.03.22 06:24:28.925 3: LogHist KGHZCUNO:  06570599 A F101 08718900 00 0C 12 A010 4AB43F F11234 030000 -66dB
2021.03.22 06:24:28.925 3: TSCUL_ParseTsHM: KGHZCUNO HM send message cleared while waiting for CCA to 4AB43F/EGHauslicht:  06570615 A F104 08718884 00 00 12 8002 F11234 4AB43F 00
:
:
2021.03.22 09:04:59.090 3: CUL_HM set Regensensor_Heating off noArg
2021.03.22 09:04:59.249 3: LogHist GASCCUL:  16157192 A F001 10365180 00 0F 63 8610 43F4DD 000000 0A28B10B0000 -78dB
2021.03.22 09:04:59.249 3: LogHist GASCCUL:  16158722 A F001 10366716 00 0C 15 8470 694D67 000000 00B428 -92dB
2021.03.22 09:04:59.250 3: LogHist GASCCUL:  16164154 A F001 10372136 00 0D C5 A610 4E6A52 F11234 06036600 -83dB
2021.03.22 09:04:59.250 3: LogHist GASCCUL:  16164968 A F001 10372948 00 0F 12 8610 6AD422 000000 0A88B40A0000 -83.5dB
2021.03.22 09:04:59.250 3: LogHist GASCCUL:  16174472 A F001 10382456 00 0C AE 865A 695053 000000 88AE29 -91dB
2021.03.22 09:04:59.251 3: LogHist GASCCUL:  16176032 A F001 10384016 00 0F 1C 8610 28B3C9 000000 0A5068090000 -95dB
2021.03.22 09:04:59.251 3: LogHist GASCCUL:  16180927 A F001 10388940 00 16 8B 8653 403AFA 000000 0041002142001B43000644FFFA -78.5dB
2021.03.22 09:04:59.251 3: LogHist GASCCUL:  16194472 A F001 10402456 00 0C AE 8470 695053 000000 00AE29 -91.5dB
2021.03.22 09:04:59.252 3: LogHist GASCCUL:  16200755 A F001 10408028 00 0D 11 A610 24582D F11234 06010000 -44dB
2021.03.22 09:04:59.252 3: LogHist GASCCUL:  16200756 A F103 10408124 01 0A 11 8002 F11234 24582D 00 _CCAdly:4 _dhmSt:96
2021.03.22 09:04:59.252 3: LogHist GASCCUL:  16200755 A F103 10408228 01 0E 12 A011 F11234 24582D 0202000000 _CCAdly:4 _dhmSt:200
2021.03.22 09:04:59.253 3: LogHist GASCCUL:  16200755 A F101 10408380 00 0E 12 8002 24582D F11234 0102000025 -43.5dB
2021.03.22 09:04:59.253 3: LogHist GASCCUL:  16200755 A F103 10408656 01 0E 12 A011 F11234 24582D 0202000000 _CCAdly:4 _dhmSt:276
2021.03.22 09:04:59.253 3: LogHist GASCCUL:  16200941 A F101 10408812 00 0E 12 8002 24582D F11234 0102000025 -44dB
2021.03.22 09:04:59.254 3: TSCUL_ParseTsHM: GASCCUL HM send message cleared while waiting for CCA to 24582D/Regensensor:  16200941 A F104 10408808 00 00 12 A011 F11234 24582D 0202000000


Firmwarestand für TSCUL ist 0.38, Modulstand ist 68.

Grundsätzliches Fehlverhalten der Geräte kann ich erst einmal nicht feststellen.
Ich betreibe 2 HMLAN, 1 CUNO V2 sowie einen CUL V3 über ser2net. Angebunden sind etwa 90 Homematic-Komponenten.

Was verbirgt sich dahinter und an welcher Ecke müsste ich anfangen zu suchen?

Gruß Peter
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 22 März 2021, 19:15:47
Hallo Peter,

per default wird vor dem Senden geprüft, ob der Kanal frei ist. In diesen Fällen war es nicht so und der jeweilige CUL hat aufgegeben, da der Wartetimeout zugeschlagen hat.
Es macht wenig Sinn zu senden, wenn gerade ein anderes Gerät plappert (ewig zu warten aber auch nicht). Andere Geräte können HM Geräte/CULs sein, aber auch SlowRf Geräte, die auf 868.3MHz senden. Wenn es selten vorkommt, dann wird das die Ursache sein. So lange Du keine Fehlfunktionen deswegen hast, sprich Wiederholungen das abfangen, einfach damit leben.

Es kann auch sein, dass beispielsweise das versorgende Schaltnetzteil oder ein anderes Gerät mit Störabstrahlung den Kanal "verseucht". In dem Fall wäre die erste Maßnahme, den Störenfried zu identifizieren (Ausschalttests) und zu eliminieren (abschalten, Abstand vergrößern, Entstörmaßnahmen, Geräte mit fast leeren Batterien als Störsender ausschließen etc.). Solche Störungen machen sich aber auch eher längerfristig bemerkbar (es sei denn im Vorbeigehen wird man gerade mal selber Reflektor für sonst schwache Störungen). Dauersender auf Grund fast leerer Batterien gab es schon (bei mir selber, aber auch hier im Forum).

Dann kannst Du die Einstellmöglichkeiten durchprobieren, um die CCA Erkennung unempfindlicher zu machen oder abzuschalten, CCAmode, csRelThr und csAbsThr.
csRelThr und csAbsThr bestimmen die RSSI Erkennungsschwelle für Signaländerungen bzw. Absolutsignalpegel.
CCAmode = 0 -> ganz aus
CCAmode = 1 -> nur RSSI entsprechend obiger Schwellen
CCAmode = 2 -> nur wenn gerade ein Paket empfangen wird ohne RSSI Betrachtung
CCAmode = 3 -> RSSI entsprechend obiger Schwellen oder wenn gerade ein Paket empfangen

Mit mehreren TSCULs, die sich auch gegenseitig "höhren" können, macht CCA auf jeden Fall Sinn, damit sie sich möglichst nicht gleichzeitig sendend stören (dann verlieren beide, wohingegen mit CCA wenigsten einer erfolgreich übertragen kann). Von daher besser an den Schwellen drehen und versuchen den besten Kompromiss zu finden, sofern es ein Funktionsproblem darstellt.

ZitatIch betreibe 2 HMLAN, 1 CUNO V2 sowie einen CUL V3 über ser2net. Angebunden sind etwa 90 Homematic-Komponenten.
Nutzt Du meine CUL_HM und Co. Sondermodule oder die Standard-HM-Module aus dem Update/SVN?
Wäre ja mal ein schönes aktuelles Feedback, wenn der Mischbetrieb mit HMLAN auch mit aktuellem Stand meiner Sondermodule problemlos funktioniert, da ich selber nur mit CULs lebe und teste. (HMLAN macht vermutlich kein CCA, dürfte also immer dazwischen plappern, wenn es was zu senden hat).

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: pte am 22 März 2021, 21:10:21
Hallo Ansgar,

danke für deine ausführlichen Erläuterungen. Die muss ich jetzt erst mal "verdauen".
Zu deiner Frage bezüglich CUL_HM-Modulen muss ich leider zugeben, diese aktuell nicht einzusetzen, da ich noch mit den Umstellungen infolge Wegfall von diversen "doppelten" Readings (actuator, measured-temp, desired-temp) beschäftigt bin (hatten wir vor kurzem hier diskutiert).
Ich hoffe aber, in den nächsten Tagen damit durch zu sein und dann werden ich auch deinen Modulstand zu 10_CUL_HM, HMInfo, HMConfig und 98_HMtemplate einspielen.

Da die Ereignisse ja relativ selten (heute waren es 3) und sowohl beim Cuno als auch beim CUL auftreten, glaube ich nicht so richtig an die Verseuchung durch Schaltnetzteile, auch wenn sich in der Nähe von beiden durchaus welche befinden. Der Cuno sitzt im betonierten und armierten Heizungskeller, der CUL im Garten in einem Schuppen, decken also auch sehr unterschiedliche Bereiche ab. SlowRf Geräte, die auf 868.3MHz senden, betreibe ich nicht. Beide überlappen sich jedoch mit den HMLAN's, was ich aus den RSSI-Werten von Geräten in der Nähe der Cuno/CUL im Vergleich zu denen der HMLAN ableite.

Aufgefallen ist mir noch, dass im log vor den Fehlern 3x der gleiche Befehl versucht wurde abzusetzen (hatte ich nicht mit kopiert).
2021.03.22 11:05:58.405 3: CUL_HM set Regensensor_Heating on noArg
2021.03.22 11:05:58.984 3: CUL_HM set Regensensor_Heating on noArg
2021.03.22 11:05:59.119 3: CUL_HM set Regensensor_Heating on noArg
2021.03.22 11:05:59.313 3: LogHist GASCCUL:  06635133 A F001 00843380 00 0E B1 8202 149DAC 18134A 010100004A -83dB


Kann man daraus noch etwas schlussfolgern?

Gruß Peter
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 23 März 2021, 20:44:23
Hallo Peter,

ZitatDie muss ich jetzt erst mal "verdauen"
Sorry für die harte Kost, aber das sind nun mal die Optionen.

Ich gehe auch eher davon aus, dass es sich auf Grund der geringen Häufigkeit um effektiv unkritische normale Kanalkollisionen handelt. D.h. Du könntest nur mal mit den Parametern spielen, um eventuell etwas unempfindlicher bezüglich weit entfernten devices zu werden.
Natürlich kannst Du auch mal vergleichen, ob CCAmode 0 problematischer, unproblematischer oder gleich ist, aber erkennbar dann nur an ggf. eher ausbleibenden Sensordaten und eher auftretenden Schaltfehlern.

ZitatKann man daraus noch etwas schlussfolgern?
Nein. Setzt Du die 3 mal so kurz hintereinander ab?

Gruß, Ansgar.

Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 23 März 2021, 21:41:21
Hallo Testwillige,

ich habe den Modulstand hier https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415 (https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415) aktualisiert.

TC statusRequest.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 04 April 2021, 14:35:32
Hallo Testwillige,

ich habe den Modulstand hier https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415 (https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415) aktualisiert.

Korrekturen Registeread, Pairing, AES und IO Zuweisung.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 04 April 2021, 23:42:51
Hallo Testwillige,

ich habe den Modulstand hier https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415 (https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415) aktualisiert.

Korrekturen IO Zuweisung und IOgrp 'none' Option.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: pte am 05 April 2021, 15:19:33
Hallo Ansgar,

kannst du mal eine Liste veröffentlichen, welche Readings in welchen Channels aktuell gepflegt werden.
Ich hatte nach den letzten Änderungen z.B. erwartet, dass measured-temp im Weather-Channel gepflegt wird. Dort wird es aber nicht mehr aktualisiert. Die Änderungen finden sich nur im Climate-Channel.

Gruß Peter
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 05 April 2021, 16:30:59
Hallo Peter,

für HM-CC-RT-DN:

Device:
motorErr
battery
batteryLevel

Clima Channel (04):
desired-temp
measured-temp
ValvePosition
boostTime
partyStart
partyEnd
partyTemp
controlMode

Ich hoffe, das macht es jetzt klar.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: pte am 05 April 2021, 16:36:48
Ok. Danke.
Dann mal noch schöne Ostern.

Gruß Peter
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: pte am 06 April 2021, 16:59:24
Hallo Ansgar,

ich möchte noch einmal zu Bedenken geben, ob die Entscheidung, measured-temp für die HM-CC-RT-DN nur noch im Climate-Channel zu aktualisieren, richtig ist. Sowohl bei den älteren HM-CC-TC als auch bei den HM-TC-IT-WM-W-EU werden die Werte für measured-temp und humidity zumindest aktuell noch in den Weather-Channel's aktualisiert, wo ich sie auch für richtiger finde.
Bitte noch einmal darüber nachdenken.

Gruß Peter
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 07 April 2021, 19:53:20
Hallo Peter,

mir ist wichtig, dass zur normalen Laufzeit nur einmal ein Event für die selbe Information erzeugt wird, denn jedes Event erzeugt Rechenbedarf. Der lässt sich nur über eine sinnvolle Wahl bei event-on-change-reading und event-on-update-reading verringern, aber nicht ganz vermeiden.

Im Clima Channel ist alles beisammen, was zur Regelung beiträgt.
Weather Channel ist beim RT ein Empfangskanal für Temperatur (ggf. und Luftfeuchtigkeit) eines externen Sensors. Da würde ich sie aktualisieren, wenn nur die von einem externen Sensor empfangenen Werte auf dem Channel signalisiert würden.
Leider sendet der RT nur die Temperatur, die er gerade zu Regelung verwendet. Wenn er von extern nichts empfängt, schaltet er um auf die interne Temperatur und sendet die.
Daher nach meinem Empfinden logisch richtiger im Clima Channel.

Wenn Du aber unbedingt Werte im Weather Channel haben willst, kannst Du Dir die 5 Zeilen Code im Quelltext auch wieder aktivieren. Ich habe sie nur auskommentiert. Such nach "#weather Chan".
Allerdings setze ich da für state auch peered/unpeered, analog zu anderen Channels.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: riker1 am 08 April 2021, 09:58:50
Hi,

eine Frage.

das Reading CommandAccepted

wird im filelog nicht geloggt und erzeugt keinen Event?

Habe ich da was übersehen?

Attribute ist gesetzt.

event-on-update-reading .*


Danke VG T







Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 08 April 2021, 18:53:43
Hallo T,

ja, es wird für das Reading CommandAccepted kein Event erzeugt.
Das ist in der Standard CUL_HM genauso. Also ein rein informatives Reading zum anschauen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: riker1 am 08 April 2021, 19:48:45
Zitat von: noansi am 08 April 2021, 18:53:43
Hallo T,

ja, es wird für das Reading CommandAccepted kein Event erzeugt.
Das ist in der Standard CUL_HM genauso. Also ein rein informatives Reading zum anschauen.

Gruß, Ansgar.

alles klar danke.

Habe das Problem das zuviele commands pending sind und die devices immer wieder missing sind.
Dachte könnte damit eine bessere Kontrolle über den Erfolg haben".

Denke mache das dann über das HM hauptdevice mit state CMDs_Pending und so.

Muss nochmal recherchieren warum so viele Fehler da sind.

Danke erstmal VG T

Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: yersinia am 30 April 2021, 09:30:48
Hier mal ein Feedback zu dem Thema Optiboot und alter Bootloader:
Zitat von: noansi am 09 März 2021, 20:11:19ok, meine Vermutung zur Bootloader Loop nach Watchdog Reset hat wohl gepasst.  ;)
Schön, dass Du den Optiboot Hinweis schon gefunden hast.

Der Watchdog kann bei jeder Firmware Variante zuschlagen, wenn gleich ich versucht habe, dies für den Normalbetrieb nach Möglichkeit in der tsculfw zu vermeiden. Sprich Warten mit Timeout, statt warten, bis der Watchdog zuschlägt.

Dann gibt es auch noch die Möglichkeit des Pufferüberlaufs bei der seriellen Übertragung auf CUL Seite. Und da ASKSIN immer mit HEX Daten als Befehl versorgt wird, kann das prinzipiell im ungünstigen Fall zu Datensalat führen bei dem auch ein B00 statt des gewünschten Befehls ausgeführt wird -> auch ein Watchdog Reset. Gilt auch für jede Firmware Variante. Allerdings müssen dazu mehrere Befehle hintereinander ohne Pause an den seriell angebunden CUL gesendet werden.
In TSCUL gibt es aber Bremsmechanismen, so dass der Zustand nicht eintreten sollte.
Xon/Xoff für die serielle Übertragung war noch nie in einer der Firmware Varianten implementiert, so weit ich das gesehen habe (und möchte ich wegen SlowRf auch nicht in die tsculfw einbauen).

In beiden Fällen muss der CUL also diese Watchdog Reset "überleben", was bei einem problematischen Bootloader beim nano offenbar schief geht.
Nach reiflicher Testzeit zeigt der ser2net-nanoCUL folgende uptime:
44 19:53:33
Der nanoCUL am RasPi wird mit jedem FHEM restart (1x wöchentlich) neu initialisiert, der ser2net-nanoCUL allerdings nicht. Von solchen Laufzeiten habe ich vorher mit altem Bootloader nur träumen können (ob die aculfw darauf Einfluss hatte, kann ich nicht beurteilen). 8)

EDIT 2021-07-27:
132 21:10:26
8)
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 04 Mai 2021, 21:08:38
Hallo Zusammen,

ich habe den Modulstand hier https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415 (https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415) aktualisiert.

Grund: IO Zuweisung nach Reading IODev.

Bei physischen HM-devices bitte Attribut IODev händisch löschen, da sonst der Attributwert benutzt wird und ohne Save Config vor einem Restart ist der Attributwert veraltet, was unnötige Änderungen in der IO Zuweisung zur Folge hat.
Ich bitte um Rückmeldung wenn ein Log Eintrag "CUL_HM hint: <HMdeviceName> first CUL_HM_assignIO differs from fhem.pl restore" beim FHEM Restart auftauchen sollte.
Dann bedürfte es hier https://forum.fhem.de/index.php/topic,120603.0.html (https://forum.fhem.de/index.php/topic,120603.0.html) weiterer Änderungen, weil verfrüht messages verarbeitet und beantwortet werden.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: yersinia am 05 Mai 2021, 08:18:16
Cool. :)
Ich bin jetzt wie folgt vorgegangen:
1. backup ;)
2. neue Modulversionen (https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415) eingespielt
3. reguläres fhem update (führt auch /usr/bin/perl ./contrib/commandref_join.pl -noWarnings aus ;))
4. attr IODev gelöscht
Zitat von: noansi am 04 Mai 2021, 21:08:38Bei physischen HM-devices bitte Attribut IODev händisch löschen, da sonst der Attributwert benutzt wird und ohne Save Config vor einem Restart ist der Attributwert veraltet, was unnötige Änderungen in der IO Zuweisung zur Folge hat.
Hab ich via gelöst (vorsicht: löscht das Attribut direkt):
deleteattr TYPE=CUL_HM:FILTER=DEF=......:FILTER=subType!=virtual:FILTER=IODev=.* IODev
Das die VCCU das Attribut behält, ist ok?
5. save
6. shutdown restart

Ergebnis: keine (auffälligen) Log-Einträge, kein motd-Eintrag. Bisher scheinen die devices auch angesprochen zu werden. Jetzt werde ich beobachten.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: riker1 am 05 Mai 2021, 08:51:42
Zitat von: noansi am 04 Mai 2021, 21:08:38
Hallo Zusammen,

ich habe den Modulstand hier https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415 (https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415) aktualisiert.

Grund: IO Zuweisung nach Reading IODev.

Bei physischen HM-devices bitte Attribut IODev händisch löschen, da sonst der Attributwert benutzt wird und ohne Save Config vor einem Restart ist der Attributwert veraltet, was unnötige Änderungen in der IO Zuweisung zur Folge hat.
Ich bitte um Rückmeldung wenn ein Log Eintrag "CUL_HM hint: <HMdeviceName> first CUL_HM_assignIO differs from fhem.pl restore" beim FHEM Restart auftauchen sollte.
Dann bedürfte es hier https://forum.fhem.de/index.php/topic,120603.0.html (https://forum.fhem.de/index.php/topic,120603.0.html) weiterer Änderungen, weil verfrüht messages verarbeitet und beantwortet werden.

Gruß, Ansgar.


Hallo Ansgar,

habe eine Meldung:
2021.05.05 08:48:44.257 0: CUL_HM hint: Smoke_TeamDEV first CUL_HM_assignIO differs from fhem.pl restore

VG T
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 05 Mai 2021, 18:05:27
Hallo Thomas,

hast Du das Attribut IODev bei dem device Smoke_TeamDEV noch gesetzt? Und wenn ja, unterscheidet es sich vom Reading IODev?
Wenn Du das Attribut IODev behalten möchtest, dann musst Du vor dem Neustart SaveConfig ausführen.
Wenn der Logeintrag immer noch kommen sollte, wenn vor einem Neustart entweder beide synchron sind (SaveConfig) oder das Attribut IODev nicht mehr existent ist (vor allem auch nicht in der config Datei), dann ist das eine Diskussionsgrundlage.

Gruß und Danke für die Rückmeldung, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 05 Mai 2021, 18:27:47
Hallo yersinia,

schöner Hinweis zum automatischen Entfernen des Attributs.  :)

Bei der VCCU gibt es drei Wege nach Rom.
Ist kein Attribut IODev und kein Reading IODev vorhanden, dann wird für die VCCU das erste IO aus Attribut IOList gewählt und sowohl in Reading, als auch Attribut IODev gesetzt.
Ist das Reading IODev zwar vorhanden, aber nicht in der IOList zu finden, wird wieder das erste IO aus Attribut IOList gewählt und sowohl Reading, als auch Attribut IODev danach gesetzt.
Ist das Reading IODev vorhanden und in der IOList zu finden oder die IOList leer, dann wird es beibehalten.

Via Autoassign kann es im laufenden Betrieb dann auch wechseln, dann auch nach Attribut IOgrp VorzugsIO.

Da kann man sich drin verlaufen, daher auch die Automatismen zur Aufrechterhaltung einer (ggf. suboptimalen) Funktion trotz Irrwegen bei der Konfiguration.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: pte am 05 Mai 2021, 21:17:09
Hallo Ansgar,
seit einem Neustart meines FHEM habe ich ein Problem mit meinem TSCUL. Er versucht in unregelmäßigen Abständen Daten an einen HM-CC-TC  zu senden, der für ihn aber nicht erreichbar ist, da nicht in seinem Sendebereich. Ich erhalte seitdem immer wieder Protokolleinträge:
2021.05.05 20:36:28.093 3: LogHist GASCCUL:  13651287 A F001 13668284 00 0F F9 8610 28B3C9 000000 0A508F090000 -92dB
2021.05.05 20:36:28.094 3: LogHist GASCCUL:  13652420 A F001 13669424 00 0B 43 A258 17A637 149E1C 0000 -77.5dB
2021.05.05 20:36:28.094 3: LogHist GASCCUL:  13652560 A F001 13669560 00 0E 43 8202 149E1C 17A637 0101000036 -72.5dB
2021.05.05 20:36:28.095 3: LogHist GASCCUL:  13652757 A F001 13669760 00 0F 11 8610 28B964 000000 0A508C090000 -83.5dB
2021.05.05 20:36:28.095 3: LogHist GASCCUL:  13657355 A F001 13674360 00 0F A8 8610 23B790 000000 0A90BB0B0000 -59dB
2021.05.05 20:36:28.095 3: LogHist GASCCUL:  13659537 A F001 13676548 00 0F 2C 8610 28B3C1 000000 0A5092090000 -69dB
2021.05.05 20:36:28.096 3: LogHist GASCCUL:  13665815 A F001 13682820 00 0B A4 A258 1B3E9F 149DAB 0000 -81dB
2021.05.05 20:36:28.096 3: LogHist GASCCUL:  13665924 A F001 13682956 00 0E A4 8202 149DAB 1B3E9F 010100002F -70dB
2021.05.05 20:36:28.096 3: LogHist GASCCUL:  13681793 A F001 13698804 00 0C 80 865A 695053 000000 B0DF2B -86.5dB
2021.05.05 20:36:28.096 3: LogHist GASCCUL:  13690567 A F001 13707588 00 0C D2 865A 694D67 000000 B0D92D -82dB
2021.05.05 20:36:28.097 3: LogHist GASCCUL:  13701787 A F001 13718804 00 0C 80 8470 695053 000000 00DF2B -86.5dB
2021.05.05 20:36:28.097 3: LogHist GASCCUL:  13705399 A F001 13722432 00 0F 8F 8610 43F4DD 000000 0A28BF0B0000 -83dB
2021.05.05 20:36:28.097 3: LogHist GASCCUL:  13706972 A F001 13724000 00 0C F9 8670 18134A 000000 00AE29 -99.5dB
2021.05.05 20:36:28.098 3: LogHist GASCCUL:  13707092 A F103 13724096 01 09 F9 A112 F11234 18134A  _CCAdly:4 _dhmSt:96
2021.05.05 20:36:28.098 3: TSCUL_ParseTsHM: GASCCUL HM repeat failed to 18134A/ReglerSZ:  13707323 A F109 13724360 00 09 F9 A112 F11234 18134A  _sfail _noAnsw
2021.05.05 20:43:48.103 3: LogHist GASCCUL:  14115430 A F001 14132460 00 0B 46 A258 17A637 149E1C 0000 -78.5dB
2021.05.05 20:43:48.104 3: LogHist GASCCUL:  14115565 A F001 14132596 00 0E 46 8202 149E1C 17A637 0101000036 -71dB
2021.05.05 20:43:48.104 3: LogHist GASCCUL:  14118819 A F001 14135844 00 0C A7 8670 1B3E9F 000000 00DD25 -83dB
2021.05.05 20:43:48.105 3: LogHist GASCCUL:  14121550 A F001 14138572 00 0F 2F 8610 28B3C1 000000 0A5092090000 -69.5dB
2021.05.05 20:43:48.105 3: LogHist GASCCUL:  14121768 A F001 14138816 00 0C 83 865A 695053 000000 B0DF2B -87dB
2021.05.05 20:43:48.105 3: LogHist GASCCUL:  14134603 A F001 14151632 00 0F AB 8610 23B790 000000 0A90BC0B0000 -59dB
2021.05.05 20:43:48.106 3: LogHist GASCCUL:  14137321 A F001 14154348 00 0C D5 865A 694D67 000000 B0D92C -82.5dB
2021.05.05 20:43:48.106 3: LogHist GASCCUL:  14138809 A F001 14155844 00 0B A7 A258 1B3E9F 149DAB 0000 -82.5dB
2021.05.05 20:43:48.106 3: LogHist GASCCUL:  14138947 A F001 14155980 00 0E A7 8202 149DAB 1B3E9F 010100002E -69.5dB
2021.05.05 20:43:48.107 3: LogHist GASCCUL:  14141787 A F001 14158816 00 0C 83 8470 695053 000000 00DF2B -88dB
2021.05.05 20:43:48.107 3: LogHist GASCCUL:  14142519 A F001 14159560 00 0A E7 8002 F11234 4E6A7D 00 -73dB
2021.05.05 20:43:48.107 3: LogHist GASCCUL:  14142787 A F001 14159828 00 0D E7 8002 F11234 4E6A7D 01014C00 -73.5dB
2021.05.05 20:43:48.108 3: LogHist GASCCUL:  14146996 A F001 14164024 00 0C FC 8670 18134A 000000 00AD29 -98.5dB
2021.05.05 20:43:48.108 3: LogHist GASCCUL:  14147109 A F103 14164120 01 09 FC A112 F11234 18134A  _CCAdly:4 _dhmSt:96
2021.05.05 20:43:48.109 3: TSCUL_ParseTsHM: GASCCUL HM repeat failed to 18134A/ReglerSZ:  14147333 A F109 14164384 00 09 FC A112 F11234 18134A  _sfail _noAnsw


Wie kann ich ihm das wieder abgewöhnen?
Modul- und Firmwarestand entspricht: TSCUL_fwcode_00_38_FHEM_Modules_00_77


Gruß Peter
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: frank am 05 Mai 2021, 21:59:30
hast du denn ein 2. io, das den tc erreichen kann?
dann setzt du "attr IOgrp vccu:io_gut,none", um nur dieses zu erlauben.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: riker1 am 06 Mai 2021, 07:23:50
Zitat von: noansi am 05 Mai 2021, 18:05:27
Hallo Thomas,

hast Du das Attribut IODev bei dem device Smoke_TeamDEV noch gesetzt? Und wenn ja, unterscheidet es sich vom Reading IODev?
Wenn Du das Attribut IODev behalten möchtest, dann musst Du vor dem Neustart SaveConfig ausführen.
Wenn der Logeintrag immer noch kommen sollte, wenn vor einem Neustart entweder beide synchron sind (SaveConfig) oder das Attribut IODev nicht mehr existent ist (vor allem auch nicht in der config Datei), dann ist das eine Diskussionsgrundlage.

Gruß und Danke für die Rückmeldung, Ansgar.

Hallo Ansgar,
hatte das Attribut nun nochmal gelöscht. Nach einem Restart - vorher save - ist der Log sauber.
sobald wieder was auftaucht melde ich mich. Danke  VG T
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: yersinia am 06 Mai 2021, 08:23:05
Zitat von: pte am 05 Mai 2021, 21:17:09
Wie kann ich ihm das wieder abgewöhnen?
Modul- und Firmwarestand entspricht: TSCUL_fwcode_00_38_FHEM_Modules_00_77
Das, was frank schreibt, und zusätzlich: der aktuelle Modulstand ist TSCUL_fwcode_00_38_FHEM_Modules_00_81 (https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415).
Wenn der (eine?) TSCUL den DN nicht erreicht, welcher CUL erreicht diesen sonst noch? Und wenn es noch (mind.) einen weiteren gibt, nutzt du eine VCCU (https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU)? Würde eine VCCU nicht dann genau dies verhindern?
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: riker1 am 06 Mai 2021, 16:46:50
Zitat von: riker1 am 06 Mai 2021, 07:23:50
Hallo Ansgar,
hatte das Attribut nun nochmal gelöscht. Nach einem Restart - vorher save - ist der Log sauber.
sobald wieder was auftaucht melde ich mich. Danke  VG T

Hallo Ansgar,

habe nun ein neues Problem mit dem Rauchmelder.
Irgendwie erkennt er die Befehle nicht mehr .

https://wiki.fhem.de/wiki/HM-SEC-SD_Rauchmelder

nun sind auf einmal Befehle wie
Unknown argument alarmOn, choose one of clear:msgErrors,noArg,readings,trigger,register,oldRegs,rssi,msgEvents,attack,all getConfig:noArg regBulk peerChan peerBulk getRegRaw statusRequest:noArg peerSmart:VCCU_Btn1 regSet

kann das durch deine Module kommen, oder wo muss ich denn da suchen?

hier noch list der Devices

Internals:
   DEF        497DAC01
   FUUID      5c633177-f33f-74bb-d61b-9a77e02293887fe7
   NAME       Rauchmelder_Kueche
   NOTIFYDEV  global
   NR         1192
   NTFY_ORDER 50-Rauchmelder_Kueche
   STATE      off
   TYPE       CUL_HM
   chanNo     01
   device     Smoke_TeamDEV
   READINGS:
     2021-05-06 07:34:56   cfgState        ok
     2021-05-06 16:14:47   level           0
     2021-05-06 16:14:47   recentStateType info
     2021-05-06 16:14:47   state           off
     2019-12-07 13:04:16   trigger_cnt     12
   helper:
     peerFriend peerSD
     peerIDsState complete
     peerOpt    p:smokeDetector
     regLst     
     cmds:
       TmplKey    :no:1620301162.64813
       TmplTs     1620301162.64813
       cmdKey     1:0:0::Smoke_TeamDEV:0042:01:
       cmdLst:
         clear      [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
         getConfig  noArg
         getRegRaw  (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
         peerBulk   -peer1,peer2,...- [({set}|unset)]
         peerChan   -btnNumber- -actChn- [({single})] [({set}|unset)] [({actor})]
         peerSmart  -peerOpt-
         regBulk    -list-.-peerChn- -addr1:data1- -addr2:data2-...
         regSet     [(prep|{exec})] -regName- -value- [-peerChn-]
         statusRequest noArg
         tplDel     -tplDel-
         tplSet_0   -tplChan-
       lst:
         condition  Smoke Alarm,no alarm,tone off
         peerOpt    VCCU_Btn1
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         list       [({normal}|full)]
         param      -param-
         reg        -addr- -list- [-peerChn-]
         regList    noArg
         regTable   noArg
         regVal     -addr- -list- [-peerChn-]
         saveConfig [-filename-]
         tplInfo    noArg
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     peerIDsH:
       00000000   broadcast
       497DAC01   self01
     role:
       chn        1
     tmpl:
Attributes:
   alias      Rauchmelder_Kueche_Team-Lead
   expert     defReg,rawReg
   icon       secur_smoke_detector
   model      HM-SEC-SD
   peerIDs    00000000,497DAC01
   room       1_Kueche,1_Wohnzimmer,4_Smoke,CUL_HM
   verbose    5
   webCmd     statusRequest:teamCall:alarmOff:alarmOn:press short:press long


Internals:
   DEF        497DAC
   FUUID      5c633177-f33f-74bb-3fc4-c6699abe13a7e43b
   IODev      cul_rpi_remote_ser2net_lan
   LASTInputDev cul_rpi_91_ser2net_lan
   MSGCNT     15
   NAME       Smoke_TeamDEV
   NOTIFYDEV  global
   NR         1185
   NTFY_ORDER 50-Smoke_TeamDEV
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 Rauchmelder_Kueche
   cul_rpi_91_ser2net_lan_MSGCNT 1
   cul_rpi_91_ser2net_lan_RAWMSG A0EE6A010497DACAABBCC0601000035::-97:cul_rpi_91_ser2net_lan:
   cul_rpi_91_ser2net_lan_RSSI -97
   cul_rpi_91_ser2net_lan_TIME 2021-05-06 16:45:48
   cul_rpi_remote_ser2net_lan_MSGCNT 7
   cul_rpi_remote_ser2net_lan_RAWMSG A0EE6A010497DACAABBCC0601000035::-53.5:cul_rpi_remote_ser2net_lan:
   cul_rpi_remote_ser2net_lan_RSSI -53.5
   cul_rpi_remote_ser2net_lan_TIME 2021-05-06 16:45:48
   cul_wohn_ser2net_rpi_MSGCNT 7
   cul_wohn_ser2net_rpi_RAWMSG A0EE6A010497DACAABBCC0601000035::-81:cul_wohn_ser2net_rpi:
   cul_wohn_ser2net_rpi_RSSI -81
   cul_wohn_ser2net_rpi_TIME 2021-05-06 16:45:48
   lastMsg    No:E6 - t:10 s:497DAC d:AABBCC 0601000035
   protLastRcv 2021-05-06 16:45:48
   protRcv    7 last_at:2021-05-06 16:45:48
   protSnd    14 last_at:2021-05-06 16:45:48
   protSndB   7 last_at:2021-05-06 16:45:48
   rssi_at_cul_rpi_91_ser2net_lan cnt:1 min:-97 max:-97 avg:-97 lst:-97
   rssi_at_cul_rpi_remote_ser2net_lan cnt:7 min:-53.5 max:-52 avg:-52.71 lst:-53.5
   rssi_at_cul_wohn_ser2net_rpi cnt:7 min:-82.5 max:-80 avg:-81.28 lst:-81
   rssi_from_cul_rpi_remote_ser2net_lan cnt:7 min:-53 max:-51 avg:-51.85 lst:-53
   READINGS:
     2021-05-06 13:49:21   Activity        alive
     2021-05-05 20:30:12   D-firmware      1.1
     2021-05-05 20:30:12   D-serialNr      NEQ0278115
     2021-05-06 13:39:20   IODev           cul_rpi_remote_ser2net_lan
     2021-05-06 07:33:55   PairedTo        0xAABBCC
     2019-12-07 11:38:47   R-pairCentral   0xAABBCC
     2021-05-06 07:33:55   RegL_00.        00:00 02:01 0A:AA 0B:BB 0C:CC
     2021-05-06 16:45:48   battery         ok
     2021-05-06 07:34:56   cfgState        ok
     2021-05-06 16:45:48   commState       CMDs_done
     2021-05-05 20:30:37   powerOn         2021-05-05 20:30:36
     2021-05-06 16:45:49   state           CMDs_done
     2019-10-26 16:13:31   trigger         Short_3
     2019-10-26 16:13:31   trigger_cnt     3
   helper:
     HM_CMDNR   230
     cSnd       
     mId        0042
     peerFriend -
     peerOpt    -:smokeDetector
     regLst     0
     rxType     2
     supp_Pair_Rep 0
     ack:
     cmds:
       TmplKey    :no:1620301162.64817
       TmplTs     1620301162.64817
       cmdKey     0:1:0::Smoke_TeamDEV:0042:01:
       cmdLst:
         assignHmKey noArg
         clear      [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
         deviceRename -newName-
         fwUpdate   -filename- [-bootTime-]
         getConfig  noArg
         getDevInfo noArg
         getRegRaw  (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
         raw        -data- [...]
         regBulk    -list-.-peerChn- -addr1:data1- -addr2:data2-...
         regSet     [(prep|{exec})] -regName- -value- [-peerChn-]
         reset      noArg
         statusRequest noArg
         tplDel     -tplDel-
         unpair     noArg
       lst:
         condition  Smoke Alarm,no alarm,tone off
         peerOpt   
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         list       [({normal}|full)]
         param      -param-
         reg        -addr- -list- [-peerChn-]
         regList    noArg
         regTable   noArg
         regVal     -addr- -list- [-peerChn-]
         saveConfig [-filename-]
         tplInfo    noArg
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       flgs       0
       lstRecType 10
       newChn     +497DAC,00,01,00
       nextSend   1620312348.8467
       nxtSndMcnt E6
       prefIO     
       rxt        0
       tgtDly     -57
       vccu       VCCU
       lRcTm:
         cul_rpi_91_ser2net_lan 11216484
         cul_rpi_remote_ser2net_lan 11237208
         cul_wohn_ser2net_rpi 11197660
         tnms       35936431
       p:
         497DAC
         00
         01
         00
     mRssi:
       mNo        E6
       io:
         cul_rpi_91_ser2net_lan:
           -97
           -97
         cul_rpi_remote_ser2net_lan:
           -43.5
           -43.5
         cul_wohn_ser2net_rpi:
           -81
           -81
     peerIDsH:
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
     rpt:
       IO         cul_wohn_ser2net_rpi
       flg        A
       ts         1620312348.86973
       ack:
         HASH(0x564523384eb0)
         E68002AABBCC497DAC00
     rssi:
       at_cul_rpi_91_ser2net_lan:
         avg        -97
         cnt        1
         lst        -97
         max        -97
         min        -97
       at_cul_rpi_remote_ser2net_lan:
         avg        -52.7142857142857
         cnt        7
         lst        -53.5
         max        -52
         min        -53.5
       at_cul_wohn_ser2net_rpi:
         avg        -81.2857142857143
         cnt        7
         lst        -81
         max        -80
         min        -82.5
       from_cul_rpi_remote_ser2net_lan:
         avg        -51.8571428571429
         cnt        7
         lst        -53
         max        -51
         min        -53
     tmpl:
Attributes:
   IOgrp      VCCU
   actCycle   099:00
   actStatus  alive
   alias      HM_SMK_Kueche_Virt
   autoReadReg 4_reqStatus
   expert     defReg,rawReg
   firmware   1.1
   model      HM-SEC-SD
   msgRepeat  1
   room       4_Smoke
   serialNr   NEQ0278115
   subType    smokeDetector
   verbose    5
   webCmd     virtual


Danke VG T
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: frank am 06 Mai 2021, 17:48:12
Zitatkann das durch deine Module kommen, oder wo muss ich denn da suchen?
wieso sind bei deinem sec-sd device und channel 2 getrennte entities?
hast du das absichtlich so konfiguriert?
und dieser rm ist mit sich selbst gepeert. soll das so sein?
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 06 Mai 2021, 18:35:18
Hallo Peter,

was sagt get PAtable1 bei(m) TSCUL?

Eventuell kommst Du mit set patable 9 weiter.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: pte am 06 Mai 2021, 19:02:23
Hallo Ansgar,

get PAtable1 sagt: GASCCUL PAtable1 => 0x81 => 5dBm

Um die Frage von yersinia noch zu beantworten: es gibt eine VCCU und meine HM-Devices werden noch von 2 HMLAN und einem CUNO mit TSCUL versorgt. Das ganze hatte jetzt auch wochenlang ohne Probleme funktioniert.

Gruß Peter
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: riker1 am 06 Mai 2021, 19:12:43
Zitat von: frank am 06 Mai 2021, 17:48:12
wieso sind bei deinem sec-sd device und channel 2 getrennte entities?
hast du das absichtlich so konfiguriert?
und dieser rm ist mit sich selbst gepeert. soll das so sein?

Hallo,

ich habe nur 1 Rauchmelder. Der sollte mich sich selbst gepeert sein. hatte das so wie im Wiki gemacht. Lange nicht geschaut. nun auf einmal geht AlarmON und AlarmOff nicht mehr.

Wegen TSCULW kann ich ja nicht die originalen HM Module laden.

sonst gibt es sicher Probleme mit den anderen HM devices.

Vielleicht lösche ich den nochmal und lege ihn neue an?

Aber kann das Thema mit den Entities die Befehle beeinflussen?

Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 06 Mai 2021, 19:37:02
Hallo Thomas,

versuch es bitte mal mit der angehängten CUL_HM und gib mir Rückmeldung.
Ich denke, ich habe das Problem gefunden.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 06 Mai 2021, 19:46:08
Hallo Peter,

dann versuch mal set patable 9 beim GASCCUL.
Danach ein get PAtable1 beim GASCCUL sollte Dir den Unterschied zeigen.
Ich hatte den Default bei der Firmware mal geändert.
Alternativ IO näher ran.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: riker1 am 06 Mai 2021, 19:59:19
Zitat von: noansi am 06 Mai 2021, 19:37:02
Hallo Thomas,

versuch es bitte mal mit der angehängten CUL_HM und gib mir Rückmeldung.
Ich denke, ich habe das Problem gefunden.

Gruß, Ansgar.
super mache ich .
Danke
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: riker1 am 06 Mai 2021, 20:29:56
Hallo

leider immer noch der gleiche Fehler.

habe das Modul reinkopiert , und restart.

Leider immer noch. Habe es 2 mal probiert.

Kann ich was checken?
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 06 Mai 2021, 20:59:29
Hallo Thomas,

bitte nochmal ein frishes list vom Rauchmelder channel und device.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: riker1 am 06 Mai 2021, 21:07:28
gerne

hier: Internals:
   DEF        497DAC01
   FUUID      5c633177-f33f-74bb-d61b-9a77e02293887fe7
   NAME       Rauchmelder_Kueche
   NOTIFYDEV  global
   NR         1192
   NTFY_ORDER 50-Rauchmelder_Kueche
   STATE      off
   TYPE       CUL_HM
   chanNo     01
   device     Smoke_TeamDEV
   READINGS:
     2021-05-06 20:30:22   cfgState        ok
     2021-05-06 19:14:33   commState       Info_Cleared
     2021-05-06 20:50:38   level           0
     2021-05-06 20:50:38   recentStateType info
     2021-05-06 20:50:38   state           off
   helper:
     peerFriend peerSD
     peerIDsRaw ,497DAC01,00000000
     peerIDsState complete
     peerOpt    p:smokeDetector
     regLst     
     cmds:
       TmplKey    :no:1620325093.79058
       TmplTs     1620325093.79058
       cmdKey     1:0:0::Smoke_TeamDEV:0042:01:
       cmdLst:
         clear      [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
         getConfig  noArg
         getRegRaw  (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
         peerBulk   -peer1,peer2,...- [({set}|unset)]
         peerChan   -btnNumber- -actChn- [({single})] [({set}|unset)] [({actor})]
         peerSmart  -peerOpt-
         regBulk    -list-.-peerChn- -addr1:data1- -addr2:data2-...
         regSet     [(prep|{exec})] -regName- -value- [-peerChn-]
         statusRequest noArg
         tplDel     -tplDel-
         tplSet_0   -tplChan-
       lst:
         condition  Smoke Alarm,no alarm,tone off
         peerOpt    VCCU_Btn1
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         list       [({normal}|full)]
         param      -param-
         reg        -addr- -list- [-peerChn-]
         regList    noArg
         regTable   noArg
         regVal     -addr- -list- [-peerChn-]
         saveConfig [-filename-]
         tplInfo    noArg
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     peerIDsH:
       00000000   broadcast
       497DAC01   self01
     role:
       chn        1
     tmpl:
Attributes:
   alias      Rauchmelder_Kueche_Team-Lead
   comment    peerIDs 00000000,497DAC01
   expert     defReg,rawReg
   icon       secur_smoke_detector
   model      HM-SEC-SD
   peerIDs    00000000,497DAC01
   room       1_Kueche,1_Wohnzimmer,4_Smoke,CUL_HM
   verbose    5
   webCmd     statusRequest:teamCall:alarmOff:alarmOn:press short:press long



und dev:
Internals:
   DEF        497DAC
   FUUID      5c633177-f33f-74bb-3fc4-c6699abe13a7e43b
   IODev      cul_rpi_remote_ser2net_lan
   LASTInputDev cul_rpi_remote_ser2net_lan
   MSGCNT     6
   NAME       Smoke_TeamDEV
   NOTIFYDEV  global
   NR         1185
   NTFY_ORDER 50-Smoke_TeamDEV
   STATE      unreachable
   TYPE       CUL_HM
   channel_01 Rauchmelder_Kueche
   cul_rpi_remote_ser2net_lan_MSGCNT 3
   cul_rpi_remote_ser2net_lan_RAWMSG A0E29A010497DACAABBCC060100003A::-57.5:cul_rpi_remote_ser2net_lan:
   cul_rpi_remote_ser2net_lan_RSSI -57.5
   cul_rpi_remote_ser2net_lan_TIME 2021-05-06 20:50:38
   cul_wohn_ser2net_rpi_MSGCNT 3
   cul_wohn_ser2net_rpi_RAWMSG A0E29A010497DACAABBCC060100003A::-81.5:cul_wohn_ser2net_rpi:
   cul_wohn_ser2net_rpi_RSSI -81.5
   cul_wohn_ser2net_rpi_TIME 2021-05-06 20:50:38
   lastMsg    No:29 - t:10 s:497DAC d:AABBCC 060100003A
   protLastRcv 2021-05-06 20:50:38
   protRcv    3 last_at:2021-05-06 20:50:38
   protSnd    6 last_at:2021-05-06 20:50:38
   protSndB   3 last_at:2021-05-06 20:50:37
   rssi_at_cul_rpi_remote_ser2net_lan cnt:3 min:-63 max:-54 avg:-58.16 lst:-57.5
   rssi_at_cul_wohn_ser2net_rpi cnt:3 min:-83.5 max:-79 avg:-81.33 lst:-81.5
   rssi_from_cul_rpi_remote_ser2net_lan cnt:2 min:-58 max:-53 avg:-55.5 lst:-58
   READINGS:
     2021-05-06 20:28:12   Activity        alive
     2021-05-05 20:30:12   D-firmware      1.1
     2021-05-05 20:30:12   D-serialNr      NEQ0278115
     2021-05-06 20:18:11   IODev           cul_rpi_remote_ser2net_lan
     2021-05-06 07:33:55   PairedTo        0xAABBCC
     2019-12-07 11:38:47   R-pairCentral   0xAABBCC
     2021-05-06 07:33:55   RegL_00.        00:00 02:01 0A:AA 0B:BB 0C:CC
     2021-05-06 20:50:38   battery         ok
     2021-05-06 20:30:22   cfgState        ok
     2021-05-06 20:50:38   commState       CMDs_done
     2021-05-05 20:30:37   powerOn         2021-05-05 20:30:36
     2021-05-06 20:51:37   state           unreachable
     2019-10-26 16:13:31   trigger         Short_3
     2019-10-26 16:13:31   trigger_cnt     3
   helper:
     HM_CMDNR   41
     cSnd       
     mId        0042
     peerFriend -
     peerOpt    -:smokeDetector
     regLst     0
     rxType     2
     supp_Pair_Rep 0
     ack:
     cmds:
       TmplKey    :no:1620325093.79062
       TmplTs     1620325093.79062
       cmdKey     0:1:0::Smoke_TeamDEV:0042:00:
       cmdLst:
         assignHmKey noArg
         clear      [(readings|trigger|register|oldRegs|rssi|msgEvents|{msgErrors}|attack|all)]
         deviceRename -newName-
         fwUpdate   -filename- [-bootTime-]
         getConfig  noArg
         getDevInfo noArg
         getRegRaw  (List0|List1|List2|List3|List4|List5|List6|List7) [-peerChn-]
         raw        -data- [...]
         regBulk    -list-.-peerChn- -addr1:data1- -addr2:data2-...
         regSet     [(prep|{exec})] -regName- -value- [-peerChn-]
         reset      noArg
         statusRequest noArg
         tplDel     -tplDel-
         unpair     noArg
       lst:
         condition  Smoke Alarm,no alarm,tone off
         peerOpt   
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         list       [({normal}|full)]
         param      -param-
         reg        -addr- -list- [-peerChn-]
         regList    noArg
         regTable   noArg
         regVal     -addr- -list- [-peerChn-]
         saveConfig [-filename-]
         tplInfo    noArg
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       flgs       0
       lstRecType 10
       newChn     +497DAC,00,01,00
       nextSend   1620327038.33342
       nxtSndMcnt 29
       prefIO     
       rxt        0
       tgtDly     -180
       vccu       VCCU
       lRcTm:
         cul_rpi_remote_ser2net_lan 2048060
         cul_wohn_ser2net_rpi 1956648
         tnms       50625917
       p:
         497DAC
         00
         01
         00
     mRssi:
       mNo        29
       io:
         cul_rpi_91_ser2net_lan:
         cul_rpi_remote_ser2net_lan:
           -47.5
           -47.5
         cul_wohn_ser2net_rpi:
           -81.5
           -81.5
     peerIDsH:
     prt:
       bErr       0
       sProc      0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       dev        1
     rpt:
       IO         cul_wohn_ser2net_rpi
       flg        A
       ts         1620327038.34844
       ack:
         HASH(0x561cbf4b6138)
         298002AABBCC497DAC00
     rssi:
       at_cul_rpi_remote_ser2net_lan:
         avg        -58.1666666666667
         cnt        3
         lst        -57.5
         max        -54
         min        -63
       at_cul_wohn_ser2net_rpi:
         avg        -81.3333333333333
         cnt        3
         lst        -81.5
         max        -79
         min        -83.5
       from_cul_rpi_remote_ser2net_lan:
         avg        -55.5
         cnt        2
         lst        -58
         max        -53
         min        -58
     tmpl:
Attributes:
   IOgrp      VCCU
   actCycle   099:00
   actStatus  alive
   alias      HM_SMK_Kueche_Virt
   autoReadReg 4_reqStatus
   expert     defReg,rawReg
   firmware   1.1
   model      HM-SEC-SD
   msgRepeat  1
   room       4_Smoke
   serialNr   NEQ0278115
   subType    smokeDetector
   verbose    5
   webCmd     virtual


Danke
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 06 Mai 2021, 21:43:36
Hallo Thomas,

neuer Anlauf im Anhang.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: riker1 am 07 Mai 2021, 06:20:21
Zitat von: noansi am 06 Mai 2021, 21:43:36
Hallo Thomas,

neuer Anlauf im Anhang.

Gruß, Ansgar.

Morgen Ansgar,

perfekt. Geht wieder.

Super Danke

VG Thomas
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 07 Mai 2021, 07:12:59
Hallo Thomas,

danke für die Rückmeldung.

Ich habe hier https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415 (https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415) den Modulstand aktualisiert.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 08 Mai 2021, 22:15:42
Hallo Zusammen,

ich habe den Modulstand hier https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415 (https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415) aktualisiert.

Grund: getConfig für config devices mit Anlernknopf https://forum.fhem.de/index.php/topic,120268.0.html (https://forum.fhem.de/index.php/topic,120268.0.html)

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 15 Mai 2021, 21:37:54
Hallo Zusammen,

ich habe den Modulstand hier https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415 (https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415) nochmal aktualisiert.

Grund: Verbesserungen für Wakeuphandling und HMInfo showTimer.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: alexmetz am 18 Mai 2021, 14:00:23
Hallo,

ich hatte vor langer Zeit mal meinen CUL868 V3.4 mit tsculsfw v0.26 geflasht und nutze das seitdem problemlos ausschließlich mit Homematic. Da ich nun neue Rolläden bekommen habe, die das Somfy RT-Protokoll unterstützen und ich gelesen habe, dass das auch im Homematic modus gehen soll (obwohl somfy ja auf 433 MHz sendet), wollte ich fragen, ob das auch mit der tsculfw und meinen CUL868 und/oder ob ich dazu ggf. die tsculfw updaten muss.

Hier mal ein Auszug vom CUL aus Fhem:
Internals:
   CMDS       ABCFGJKRUVWXYeilmtx
   CUL1_MSGCNT 21366
   CUL1_TIME  2021-05-18 13:51:11
   Clients    STACKABLETS:STACKABLE:CUL_HM:CUL_IR:HMS
   DEF        /dev/CUL868_0@12000000 1234
   DeviceName /dev/CUL868_0@12000000
   FD         9
   FHTID      1234
   FUUID      609edace-f33f-c40b-558d-dad29e3a96635740
   NAME       CUL1
   NR         14
   PARTIAL   
   RAWMSG     A0C12867019397800000080C638::-69:CUL1:
   RSSI       -69
   STATE      Initialized
   TYPE       TSCUL
   VERSION    VTS 0.26 CUL868
   VERSION_HW CUL_V3.4
   VERSION_TS yes AES ChTblSize:220
   XmitOpen   1
   assignUpdCntI 68
   assignedIDsCnt 33
   initString X21


Danke !
Alex
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 18 Mai 2021, 20:44:18
Hallo Alex,

1. Hast Du das Y unter CMDS bemerkt? Also es gibt da was.
2. Ich kann Dir nicht sagen, ob es funktioniert, da ich es nie habe testen können und auch noch niemand dazu Feedback gegeben hat.
3. Mit einem 868er CUL auf 433 zu senden reduziert auf jedenfall mal die Reichweite erheblich. Versuche können auch schon daran scheitern.
4. Während Du auf Somy senden würdest, würde mit dem CUL auf HM naturgemäß nichts empfangen. Mit den Nebenwirkungen brauchst Du nirgendwo nachfragen, was man dagegen tun kann.
5. Ein nanoCul zum probieren kostet nicht die Welt und wäre direkt für die passende Frequenz zu haben (sofern die Quelle(n) was vernünftiges liefer(n)). Das ging dann auch parallel (nur Oberwellen würden im Nahbereich eventuell HM ein wenig stören können). Und wer weiß, was Du auf 433 noch anderes empfangen oder ansteuern kannst.

Viel Glück und gib bitte Bescheid , ob es funktioniert, solltest Du es mit dem 868er umbedingt probieren wollen.   :)

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: alexmetz am 18 Mai 2021, 21:47:33
Also versucht hab ich es einfach mal auf blöd, aber da hat schon das koppeln mit den somfy-Rollos nicht geklappt. Bin mir aber nicht sicher worans liegt, weil der CUL im EG ist und fie Rollos im 2. OG. Mein nächster Versuch wäre gewesen, meinen Raspi mit dem cul mal direkt neben die Rollos zu stellen, deshalb wollte ich erst mal klären, ob es mit tscul geht. Aber ich werd mir einfach nen signalduino kaufen und es damit probieren. Kost echt nicht die Welt.
Danke jedenfalls für die Einschätzung!!
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: blue55 am 19 Mai 2021, 20:40:28
Hallo zusammen,

ich bin neu hier und habe die Firmware über diesen Thread https://forum.fhem.de/index.php?topic=81006.0 gefunden.

Ich habe mit meinem nanoCUL dasselbe Problem wie der Kollege aus dem anderen Thread. Daher wollte ich mal eure Firmware für den nanocul ausprobieren.
Das flashen hat auch super funktioniert. Allerdings habe ich ein großes Delay zwischen Senden des Kommands und z.B. Einschalten der Lampe.

Ich nutze den nanoCUL mit homegear und Openhab (Ich hoffe ich bekomme dafür hier keine Schelte ;-) ).

Mit der Firmware culfw 1.67 werden die Befehle immer direkt gesendet.

Habt ihr so ein Verhalten auch schon mal wahrgenommen?
Kann ich in den Defines dazu noch was einstellen?

Danke euch für die Unterstützung.

Viele Grüße
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 19 Mai 2021, 21:21:56
Hallo blue55,

die tsculfw läuft mit den zugehörigen TSCUL Modulen für FHEM. Ich wüßte nicht, dass homegear die tsculfw funktional richtig ansteuern könnte, falls Dir das vorschwebt.

Vielleicht helfen Dir diese beiden Beiträge von yersinia noch bezüglich bootloader Problematik und nicht erreichbarem nanoCUL:
https://forum.fhem.de/index.php/topic,24436.msg1138317.html#msg1138317 (https://forum.fhem.de/index.php/topic,24436.msg1138317.html#msg1138317)
https://forum.fhem.de/index.php/topic,24436.msg1153403.html#msg1153403 (https://forum.fhem.de/index.php/topic,24436.msg1153403.html#msg1153403)

Das hat aber nichts mit Schaltdelays zu tun.

Und kannst Du Delay mal in Zeiten mit Einheit fassen und dann im Homeatic Forumsbereich fragen? Da wirst Du wohl Vergleichsinfos bekommen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: blue55 am 20 Mai 2021, 20:51:52
Hallo Ansgar,

danke dir die Antworten und das raussuchen der Threads.
Ich update mal den Bootloader und schaue mal ob sich dann die Erreichbarkeit des nanoCULs verbessert.

Viele Grüße,
Fabian
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 30 Mai 2021, 14:33:08
Hallo Zusammen,

hier https://forum.fhem.de/index.php/topic,24436.msg853733.html#msg853733 (https://forum.fhem.de/index.php/topic,24436.msg853733.html#msg853733) ist der patch für das flash-ota tool aktualisiert, damit es auch mit VTS 0.34+ klappt. Außerdem ist es damit möglich, mit einem gestapelten CUL einen ota flash auszuführen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: Adimarantis am 22 Juli 2021, 22:32:36
Hallo,

mich würde interessieren, ob man diese Fernbedienung (wohl eine Art Garagentorsender) über nanoCUL ansteuern kann. Ich befürchte ja die sind verschlüsselt, wobei es diese Fernbedienungen generisch zu kaufen gibt und man sie ja auch anlernen kann (anscheinend sogar Fernbedienung zu Fernbedienung).
Meine NanoCUL 868 empfängt denke ich mit SlowRF etwas, ich kann die messages jetzt aber nicht exakt zuordnen da entweder auch gesendet wird, wenn man nichts auf der Fernbedienung drückt oder andere Sender in der Nachbarschaft reinfunken (oder triggert Homematic auch etwas auf SlowRF?)

Anbei mal Fotos von Fernbedienung und Packung sowie ein Ausschnitt aus meinem FHEM Log der TSCUL mit verbose=5
Wäre halt echt Klasse wenn sich das "knacken" liesse. Mein Ziel ist Sprachsteuerung über Google anstatt ewig die Fernbedienung zu drücken (die hat nämlich auch noch eine "Totmannschaltung", man muss den Knopf also ewig gedrückt halten.)

Gruß,
Jörg

Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: noansi am 23 Juli 2021, 22:24:47
Hallo Jörg,

zuallererst, Dir ist aufgefallen, dass Deine Geragentorfernbedienung eine Totmannfunktion mittels Drücken der Taste bis Abschluss der Torbewegung hat.
Damit ist sicherlich verbunden, dass die Torbedinungsautomatik keine sonstigen ausreichenden Sicherheitseinrichtungen bezüglich Auffahrt auf ein Hindernis, z.B. ein Lebewesen hat! Das bedeutet, Du bist die einzige und verantwortliche Sicherheitseinrichtung, um in einem solchen Fall die Torbewegung durch Loslassen der Taste zu stoppen! Bei einem normalen Garagentor mit Kippmechanik kommen an den Armen durch Hebelwirkung auch erheblich höhere Kräfte zusammen, als es auf den ersten Blick den Anschein haben mag!
Es ist keine gute Idee, so eine Sicherheitseinrichtung zu umgehen, um die Bequemlichkeit zu erhöhen.

Bezüglich Funkprotkoll, ich kenne die Fernbedienung nicht.
Zunächst wäre zu klären, ob das Ding pulsmoduliert oder frequenzmoduliert sendet.
Mit dem CUL auf SlowRf kann nur pulsmoduliert empfangen werden.
Mit X39 und verbose 4 würdest Du im Log High/Low Zeiten im µs und Empfangsstatus Infos zu sehen bekommen. Das müsstest Du erst mal einstellen und dann gezielt Senden und Loggen.
In Deinem Log war nur 2 mal was mit TX3 protokollähnlichem. Also bisher nichts verwertbares. Ein mehrstündiges Protokoll würde wohl auch niemand freiwillig nach zufälligen Empfangsdaten eines irgendwann mal sendenden, unbekannten Gerätes durchsuchen wollen.

Edit: Du kannst auch noch Native1, Native2 und Native3 ausprobieren, ob da was kommt. Das wäre dann frequenzmoduliert.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 25 Juli 2021, 21:32:44
Hallo Testwillige,

Hier geht es zur nächsten Version: https://forum.fhem.de/index.php?msg=1297324 (https://forum.fhem.de/index.php?msg=1297324)

hier eine neue Version 0.39 der Timestamp Firmware und der dazu benötigten FHEM Module.

Die Version 0.39 bietet einige Timingänderungen für HM. Außerdem ist das Commandref überarbeit. Bei TSCUL werden sets und gets nun abhängig von rfmode und unterstützten Firmwarebefehlen angeboten.

Die Version 0.38 verhindert repeats für TC und TH Messages, was für virtuelle TC und TH Sensoren sinnvoll ist.
Auszug aus de Changed:
- ASKSIN repeats for TC and TH messages set to 0
- ASKSIN Ag command added, allow setting ASKSIN non FUP AGCCTRL2 value in EEPROM
Außerdem Verbesserungen in Modulen, insbesondere für virtuelle TCs und TH Sensoren.
Beim Reboot nach dem Flashen werden alle EEPROM Einstellungen auf Default gesetzt. Also alle am CUL vorgenommenen Einstellungen notieren, um sie wieder einstellen zu können.

In Version 0.37 ist der Readout des Tranceiver RX Fifos insbesondere für ASKSIN verändert. Beim Reboot nach dem Flashen werden alle EEPROM Einstellungen auf Default gesetzt. Also alle am CUL vorgenommenen Einstellungen notieren, um sie wieder einstellen zu können.
RF_Router und fast_rf sind verändert und nicht kompatibel zu vorherigen Versionen.

Version 0.36 behebt ein Überlaufproblem des RX-FIFOs des Transceivers, der zum Empfangsausfall führen konnte (fiel nur beim reinen Empfangsbetrieb ohne regelmäßiges Senden auf). Danke Stefan für den Hinweis.

Auszug aus der Changed:
- little correction in rf_native, if slowrf monitoring is active
- lacrosse emu reworked
- SlowRf reception adapted for better ESA reception with still well E and HMS reception
- generic Manchester raw send added with Gm command
- ESA send added with 'S' command
- HMS send added with 'Q' command
- IT reception corrected
- RfRouter with repeat in FastRF packet, better send timing and reduced receive timeout
- for pure USB CULs blinking while waiting on watchdog reboot and during boot/bootloader reboot with different frequencies
- message finalization with \n on PIM receive buffer full
- ASKSIN, fastRF, RF-Router, moritz, rwe, RX-FIFO Overflow detection improved

Noch als Hinweis, für HMS und ESA scheint sens 12 eine ungünstige Einstellung für den Empfang  dieser Protokolle zu sein.

Diese Version bietet wakup support und keep awake Support. Für CULs mit wenig Speicher kann dies mit dem Attribut "hmForceLzyCfg" aktiviert werden, siehe auch der Hinweis zum EEPROM Verschleiß weiter unten.

Das RF-Router Ping Timing ist geändert, damit also auch nicht kompatibel mit Standard culffw oder a-culfw und auch nicht zur Version 0.32.
Ergänzt ist SlowRf Empfang von Pearl NC7427 Temperatur/Luftfeuchte Sensoren. Entsprechend Kanalwahlschalter können 3 Stück empfangen werden. Zum Anlernen mittels autocreate muss der TEST Taster am Sensor gedrückt werden.

Das EEPROM Layout ist geändert und daher werden nach dem Flashen alle Einstellungen auf default zurück gestellt. Also vor dem Flashen individuelle Einstellungen, z.B. Frequenzoffsets, notieren und nacher neu einstellen.

Auszug aus der Changed:
- FULL_PA_RAMPING bugs corrected
- CCA CS thresholds setable for ASKSIN, MORITZ, HAS_RWE, RFNATIVE and MBUS with XTxy, x=CARRIER_SENSE_REL_THR, y=CARRIER_SENSE_ABS_THR as in AGCCTRL1
- SlowRf receive timing limits corrected
- SlowRf lower filter switched off by define in rf_receive_timing.h
- RFR timing/timeout shortened, FastRF CCA disabled
- auto Ci interrupt counter messages
- XP command extended to switch on auto Ci messages, AP removed as all PLL messages switchable by XP
- improvement and corrections for CUNX RS485 PIG support
- CUNX: PIG RTS controllable by USB Host for serial foward and RS485 serial forward
- CUNX: DMX interupts changed to HI priority and CC1101 interrupts to MED priority
- CUNX: USB interrupts to LO priority
- GPIOR1 used for USB USB_DeviceState
- GPIOR1 used for SERIAL STACKING stacking_ST_state


Ein Peakfilter für SlowRF Empfang ist ergänzt und mit "peakfilter" einstellbar.
In dem Zusammenhang ist auch das RF-Router Ping Timing geändert, damit also auch nicht kompatibel mit Standard culffw oder a-culfw.
Außerdem kann das Senden von RF-Router Daten nach deren Empfang einstellbar verzögert werden (RfRdelay).

CCAMode wirkt nun auch auf IT-Senden und SOMY-Senden, sowie auf das Senden des RF-Router Pings. Mit fRfCCAMode kann auch das CCA Verhalten für RF-Router Senden und FastRF geändert werden.

Auszug aus der Changed:
- IT and SOMYFY use SlowRF EEPROM CCA setting now for sending
- changes in SlowRF reception for reset and sync start. IT V1 reception tested succsessfully.
- SlowRF filter and match adaption
- SlowRF spike filter improved, max. peak lenght settable with Xpxx, xx hex time in 8us units
- IR receive/transmit pause during send of SlowRF changed to not globally switching off all interrupts
- periodic RF-Router ping RSSI display as "Cuxx\r\n" with xx = RSSI Hex
- RF-Router ping timing changed for better distinguish from other protocols
- RF-Router pre silence before send settable with uRxx, xx hex time in 4ms units
- Xrrt commands bits:
  rr:
  report known protocol data                                                      Bit 0
  report repeated data                                                            Bit 1
  report received bits                                                            Bit 2
  report 'r' (rising) or 'f' (falling) edge, '.' (collect) or '?' (sync) timeout  Bit 3
  report edges, bit times and timeouts                                            Bit 4
  report S300 data with valid checksum only                                      Bit 5
  report FHT                                                                      Bit 6
  report 'l' RSSI decimal data continuosly                                        Bit 7
  t:
  report recorded SlowRF timing                                                  Bit 0
- corrections in interrupt flag clearing
- correction in delay function
- fastRF bug corrected, untested
- EEPROM layout changed for the new parameters


TSCUNX kann mit entsprechendem RS485 Modul nun auch DMX.
Auch HM485 ist für TXCUNX angepasst.
In dem Zuge ist auch die DMX Funktionalität bei CUNO2 etwas erweitert.
IR läuft nun auch richtig mit TSCONO2.
Außerdem läuft RF-Router auf der tsculfw, allerdings mit einer Änderung. Das 'U' ist durch '~' ersetzt. 'U' kollidierte mit dem Uniroll Senden.

Kurzer Auszug aus der CHANGED:
- IO optimizations CUNX, especially to/from PIM and Ethernet
- CUNX DHCP non blocking operation
- IO optimizations
- HM485 support for CUNX (like CUNO2) with RS485 PIM.
  HM485 switch off with Hx for CUNX. With CUNX after Hx RS485 PIM again accessible via PIM USB or Ethernet Interface
- CUNX support for DMX and HM485 with RS485 PIM (to be tested), a Dwxxxxyy switches to DMX via CUNX Interface, a Hsxxxxxxxxxxxxxxxxxx switches to HM485 via CUNX Interface
- DMX switch off with Dx. With CUNX after Dx RS485 PIM is again accessible via PIM USB- or Ethernet Interface
  DMX flexible channel usage. Channels are sent out upto the highest channel set (0 sent as default for unset channels). With switching off with Dx the highest channel is reset.
  DMX changed in timing and resting behaviour. Rests on IDLE if less then 24 device, only, to keep 1204µs min. BREAK to BREAK (to be tested)
  DMX Dt command to set/view timing of MarkAfterBreak and BREAK
  DMX less disturbed while sending SlowRF
- W function gives feedback after writing EEPROM
- clock timer unburdened, may impact onewire and fht (to be tested)
- corrections for IRTX
- IR base timings changed to 12500Hz or 20000Hz
- RF-Router working, but 'U' changed to '~' (definable in board.h, but 'U' disables HAS_UNIROLL)

Es ist eine Prüfung auf Stacküberlauf eingebaut. Am Anfang des heap werden zwei Byte mit einem Bitmuster beschrieben. Wird das verändert, dann ist der Speicher wahrscheinlich korrumpiert, was durch einen Stacküberlauf ausgelöst sein sollte. Sofern der CUL dann noch kann sendet er ein "C_M" an TSCUL, was zu einem entsprechenden Log Eintrag führt.
Damit kann man vorsichtig die Speichergrenzen ausloten. Ein langer Testzeitraum ist aber erforderlich, um einigermaßen sicher zu sein, dass der worst case auch mal durchlaufen worden ist.
Außerdem ist ein Kommando mU (je nach Firmware) eingebaut, mit dem man den vom Stack ungenutzen heap in etwa auslesen kann (auch als get unusedstack in TSCUL verfügbar). Auch hier gilt, nur nach langer Laufzeit einigermaßen sinnvoll. Es macht sicher keinen Sinn auf Grund des Wertes den Speicher bis auf das letzte Byte auszuquetschen, denn weiterhin hängt die Stacknutzung vom gewählten Protokoll und Einstellungen ab.

In TSCULflash ist Flashen auch von NanoCULs und MiniCULs ergänzt. Vor dem Flashen wird ein "B00" also Reset für die TSCUL Firmware an den nano/Mini geschickt, 1 Sekunde gewartet und dann versucht mit avrdude zu flashen.
Also erst die Firmware in den FHEM/Firmware Ordner kopieren und dann in FHEM mit
TSCULflash <nanodevicename> TSnanoCULbzw.
TSCULflash <minidevicename> TSminiCULversuchen zu Flashen. Im Log sollte danach (dauert etwas) die avrdude Ausgabe zu finden sein.

Ebenfalls (nur über USB Anschluss) möglich ist das Flashen eines PIGATOR Moduls an einem CUNX
TSCULflash <pigatordevicename>|<cunxdevicename> TSPIGATOR
AESCommReq wird unterstützt. Die Nutzung ist unverändert zu Standard CUL, sprich, beim gewünschten Gerät/Kanal aesCommReq auf 1 setzen und ggf. noch aesKey passend zum verteilten Key setzen.
Es werden von tsculfw nur die Keys 0 (Default Key) bis 3 unterstützt.

Diese Erweiterung erfordert jedoch auch zusätzliche Empfangspuffer im knappen Speicher des CULs. Ein CUL V3 nutzt bis zu 6 Empfangspuffer. Auch der FlashSpeicherbdarf ist angestiegen, so dass einige Protokolle nicht mehr gleichzeitig in ein Kompilat passen. Das sollte aber weniger tragisch sein, da im ASKSIN Modus ohnehin nur HM empfangen werden kann.

Bei CUL V2 reicht der verfügbare Speicher leider hinten und vorne nicht aus, um diese Version nutzen zu können.

Im Anhang ist in TSCUL_fwcode_00_xx_FHEM_Modules_00_xx.zip wieder die Timestamp Firmware zu finden. Getestet habe ich TSCUNX, TSPIGATOR , TSCUL_V3 , TSCUL_V3_RFR, TSCUNO2, TSCOC und TSSCC. (TSCUL_V3_RFR ist ohne HM Unterstützung, also nur SlowRF)

Die tsculfw Firmware kann für TSCUL_V3, TSCUL_V3_RFR (via USB), TSCUNO2, TSCOC, TSSCC, TSCUNX und TSPIGATOR (an CUNX) mit FHEM mit dem TSCULflash geflashed werden. Die anderen müssen mit dem jeweiligen Flash Programmer geflashed werden. Bei CUNO2 und SCC muss die Bootloadertaste gedrückt werden, bis der Flashvorgang anläuft.
So z.B. https://forum.fhem.de/index.php/topic,24436.msg631743.html#msg631743 kann es mit einem USB CUL Stick gehen, wenn man nicht TSCULflash verwendet.
TSCULflash ist erweitert auf COC, SCC, CCD, rpiaddon, CUNO2 und CUNO. Jedoch ist es nicht ganz so einfach zu handhaben, da zum einen teilweise die Taste zu drücken ist und bei Raspberry PI Modulen die Rechteproblematik für den Zugriff auf die IO-Pins überwunden werden muss. Tips dazu in der Command-Ref auch bei RPI_GPIO.
Bei einem Stapel aus SCC mit aufgesetztem COC, CCD oder (rpiaddon?) ist unbedingt beim SCC Flash darauf zu achten, die Taste am gewünschten Modul zu drücken. Sonst wird das oberste Nicht-SCC Modul mit der SCC Firmware geflashed.
Mit CUNO2 ist das flashen getestet (generell nur über USB!). Wichtig, aber auch hier, die Taste zu drücken.

Es gibt nicht den Luxus des Downloads beim TSCULflash, sondern die Firmware muss händisch in den FHEM/firmware Ordner kopiert werden. Der Typ ist dann z.B. TSCUL_V3.
Beispiel:
TSCULflash MeinCulV3Device TSCUL_V3
Wichtig für SCC Nutzer. TSSTACKED ist entfallen und wird nicht mehr unterstützt.
Statt dessen gibt es das neue Modul STACKABLETS (als Abwandlung von Rudolfs STACKABLE).
Dieses wird sozusagen zwischen die Stackteilnehmer eingebaut.

Beispiel für fhem.cfg:
#erstes SCC Modul als Basis
define SCC_WS868 TSCUL /dev/ttyAMA0@38400 0000
attr SCC_WS868 event-on-change-reading Ints_per_sec,IntCalcStat,MatchStat
attr SCC_WS868 rfmode SlowRF
attr SCC_WS868 room Receiver
attr SCC_WS868 sendpool CUL_HM868,SCC_WS868
attr SCC_WS868 verbose 1

#neues STACKABLETS virtuelles IO device
define STACK_1 STACKABLETS SCC_WS868
attr STACK_1 verbose 1

#zweites SCC Modul
define SCC_HM868 TSCUL FHEM:DEVIO:STACK_1:38400 1034
attr SCC_HM868 event-on-change-reading cond
attr SCC_HM868 hmId F11034

Ergänzender Hinweis zu USB CULs: 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_08\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 in der board.h festgelegt werden, so dass damit dann auch /dev/CUL868_1 etc. für mehrere gleiche CULs möglich sind.

Oder für CUNX
define CUNX_868 TSCUL /dev/CUNX868_0@12000000 0000oder für PIGATOR an CUNX
define PIGATOR_433 TSCUL /dev/CUNXPIM_0@38400 0000die Seriennummer wird aus der Seriennummer des XMEGA Chips des CUNX gebildet. Unter Linux lsusb nutzen!

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.

Bei nicht nativen USB CULs wie z.B. nanoCUL, miniCUL oder CUNO2, beträgt die Baudrate 38400, dementsprechend muss die Definition beispielsweise so aussehen:
define CUL_868 TSCUL /dev/CUL868@38400 1234bzw.
define CUL_433 TSCUL /dev/CUL433@38400 0000
Und noch ein Beispiel für eine Definition eines Netzwerk CUNX:
define CUL_868 TSCUL 192.168.178.111:2323 0000oder für PIGATOR an CUNX
define PIGATOR_433 TSCUL 192.168.178.111:2324 0000beim PIGATOR sollten zuvor mit Anschluss an USB und öffnen der Schnittstelle mit gewünschten Kommunikationsparametern mit ps oder unter TSCUL mit set PIMstoreBaud die seriellen Kommunikationsparameter zum PIGATOR Modul gespeichert werden, falls sie vom default abweichen.

Oder Netzwerk CUNO2:
define CUNO2_868 TSCUL 192.168.178.110:2323 0000
Die aktuell eingestellte oder per DHCP erhaltene Netzwerkadresse kann mit Lc repektive in TSCUL mit get NetAdresses abgefragt werden. Mit Lp respektive in TSCUL mit get NetPHYlink kann der Linkzustand des Netzwerkanschlusses angezeigt werden.


In der Zip Datei sind ebenfalls die ergänzten Module zu finden, die zur Nutzung der Firmware erforderlich sind.

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
16_TSCUL_RFR.pm -> der 16_CUL_RFR.pm, aus CUL_RFR devices werden damit TSCUL_RFR devices in der fhem.cfg (händisch anzupassen)
16_STACKABLETS.pm -> statt der 16_STACKABLE.pm, aus STACKABLE werden damit STACKABLETS devices in der fhem.cfg (händisch anzupassen)
97_timerTS.pm          -> Austausch-Timerroutinen und fhemFork()

10_UNIRoll_TS.pm  -> statt der 10_UNIRoll.pm, mit TSCUL 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 IO-devices zu verwenden, aus TSKS300 wird dann TSKS300  in der fhem.cfg (händisch anzupassen). Obsolet, da 14_TSCUL_WS.pm nun KS300 unterstützt.
14_TSCUL_TX.pm    -> statt der 14_CUL_TX.pm, mit TSCUL 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 IO-devices zu verwenden, aus CUL_WS wird dann TSCUL_WS  in der fhem.cfg (händisch anzupassen)
14_TSCUL_NC7427.pm  -> NC7427 Unterstützung
15_TSCUL_EM.pm  -> statt der 15_CUL_EM.pm, mit TSCUL IO-devices zu verwenden, aus CUL_EM wird dann TSCUL_EM  in der fhem.cfg (händisch anzupassen)
12_TSHMS.pm        -> statt der 12_HMS.pm zu verwenden
CalcUtil.pm              -> Hilfsrechenroutinen für Taupunkt und Windstärkeindex
ReadingUtil.pm          -> Hilfsroutinen für Readings

Da diese Module ergänzt werden (müssen!), überleben sie auch ein Update von FHEM.

98_fhemdebug.pm    -> fhemdebug zur zwingenden Nutzung mit 97_timerTS.pm.
98_apptime.pm          -> apptime zur zwingenden Nutzung mit 97_timerTS.pm.
98_apptm.pm            -> apptime zur zwingenden Nutzung mit 97_timerTS.pm, mit geringerem Speicherverbrauch bei weniger Details
10_IT.pm                  -> vermeidet unnötiges busy waiting beim Senden. Wird ohne Schutz von FHEM update überschrieben

Außerdem:

98_TSCULflash.pm    -> Zum Flash von TSCUL_V3, TSPIGATOR (an CUNX) mit Datei in FHEM/firmware

10_CUL_HM.pm        -> angepasste Version zur Nutzung mit TSCUL/tsculfw. Die Nutzung dieses Moduls ist optional. Für CUL_V3, nanoCUL, miniCUL im Multio-HM-IO Betrieb jedoch empfohlen, da sie den EEPROM Verschleiss über das Attribut "rssiSwitchHyst" verringert. Nur diese Version bietet derzeit vollständige TSCUL/tsculfw Unterstützung. Zur Einsparung redundanter Events werden teilweise Readings (actuator, desired-temp, measured-temp) nicht mehr zusätzlich im HM-device, sondern nur noch in den jeweiligen Channels aktualisiert.
HMConfig.pm            -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden. Einstelllimits für HM-CC-RT-DN Regler P und I Anteil erweitert. Damit kann man mit R-regAdaptive offDeter deutlich mehr an den Regelparametern spielen.
98_HMinfo.pm          -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden. Spaltenbreiten in Tabelle von protoEvents variabel zu verbesserten Übersicht in der Darstellung.
98_HMtemplate.pm  -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden.
Die 4 Dateien entsprechen einem Stand von Anfang 09/2020. Derzeit sollten diese verwendet werden.

10_CULG.pm              -> optional, enthalten, da die Firmware es unterstützt

98_autocreate.pm      -> autocreate mit TSCUL Unterstützung

98_Cumulate              -> Kumulieren von Zählwerten, wie Strom, Regenmenge etc.
98_SAverage.pm        -> Mittelwertbildung von z.B. Temperaturen. Stunde, Tag, Monat und Jahr, sowie ein gleitender Mittelwert der letzten Stunde sind damit möglich.
98_IntervalTimer.pm  -> optional, Intervalltimer um FEHM-Timerbasiert Kommandos in möglichst konstanten Intervallen absetzen zu können.

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_STACKABLETS.pm DevIoTS.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.pm CalcUtil.pm 14_TSCUL_NC7427.pm ReadingUtil.pm 97_timerTS.pm 98_TSCULflash.pm 98_apptime.pm 98_apptm.pm 10_IT.pm 10_CULG.pm 10_CUL_HM.pm HMConfig.pm 98_HMinfo.pm 98_HMtemplate.pm ReadingUtil.pm 98_autocreate.pm 98_Cumulate.pm 98_SAverage.pm 98_fhemdebug.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 zwingend auszuführender 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` }
Noch ein Hinweis: TSCUL fragt auch die Firmwareversion der tsculfw auf 0.38 ab. Eine ältere Version wird also nicht unterstützt!

Frequenzoffset: Für HM ist ein Frequenzoffset von -20.6kHz im EEPROM als default in der tsculfw hinterlegt (das ist ein individuelles Optimum für meinen COC). Dieser Frequenzoffset kann mit set hmFreqOffs umgestellt werden. 0 ist default in der Standard-culfw.
Wenn also keine Antwort von angesprochenen HM devices kommt, dann hmFreqOffs von 0 ausgehend verstellen. CUNX z.B. geht eher in Richtung + mit dem Offset.
Wer das Frequenzspektrum sichtbar machen kann, kann sich die optimale Mitte aller devices ermitteln und mit dem Offset sein CUL dazu passend einstellen.

Noch ein Tip zur Haltbarkeit der CULs mit wenig SRAM (CUL V3, nanoCUL, miniCUL ...). Jedesmal, wenn einem HM-Device das IODev durch Roaming neu zugeordnet wird, führt das zu EEPROM Schreibvorgängen in den beteiligten CULs. Die Lebensdauer des EEPROMs ist begrenzt (100000 Schreibzyklen laut Datenblatt). Daher rate ich zur Nutzung des VorzugsIOs beim Device Attribut IOgrp. Also nicht einfach stumpf
attr HMdeviceName IOgrp VCCUsetzen, sondern
attr HMdeviceName IOgrp VCCU:CUL_mit_gutem_Empfang_fuer_Devicesofern die Roaming Funktionalität entsprechend RSSI für das jeweilige device nicht zwingend benötigt wird. Ein Fallback auf einen anderen CUL bleibt dennoch möglich.
Mit dem Attribut "rssiSwitchHyst", das in der beigefügten 10_CUL_HM.pm verfügbar ist, kann bei den HM-devices die Umschalthysterese für das Roaming von 10 bis auf 2 bei Bedarf für mobile devices verringert werden.
Mit dem Attribut "hmForceLzyCfg" kann wakeup und keep awake support bei solchen CULs aktiviert werden. Das erhöht den EEPROM Verschleiß beim Lesen oder Verändern von Registerwerten bei wakup und lazy config devices.

Ergänzt ist auch noch ein set TX3Send.
Damit lassen sich TX3 Sensordatentelegramme auf 433er CULs versenden.
Beispiel:
define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 TX3Send T:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." SID:23 U")}

define NF_HumOut notify Sen_Aussen:humidity.* {fhem("set TSCUL_WS433 TX3Send H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." SID:23 U")}

Ergänzt ist auch noch ein set KSSend.
Damit lassen sich WS Sensordatentelegramme versenden.
Beispiel:
define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 KSSend T:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." Code:2")}

Zum regelmäßigen Senden von Sensordaten kann der IntervalTimer genutzt werden.
Beispiel:
define AussenSend_WS11 IntervalTimer CUNO2_WS868 176.5
attr AussenSend_WS11 offCmd {fhem("set @ KSSend T: ".ReadingsVal("C_Aussen","temperature",0.0)." H: ".ReadingsVal("C_Aussen","humidity",0.0)." Code:21")}
attr AussenSend_WS11 onCmd {fhem("set @ KSSend T: ".ReadingsVal("C_Aussen","temperature",0.0)." H: ".ReadingsVal("C_Aussen","humidity",0.0)." Code:21")}

Hier geht es zur vorherigen Version https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415 (https://forum.fhem.de/index.php/topic,24436.msg1132415.html#msg1132415).

Gruß, Ansgar.

Edit: Module aktualisiert auf 00_92 bezgl. Warnings in CUL_HM
Edit2: Module aktualisiert auf 00_93 bezgl. verbesserter Koexistenz mit CUL, HMLAN, HMUARTLGW
Edit3: megaCUL ergänzt, ungetested
Edit4: HMinfo patch eingebaut nach Wunsch https://forum.fhem.de/index.php/topic,24436.msg1198460.html#msg1198460 (https://forum.fhem.de/index.php/topic,24436.msg1198460.html#msg1198460)
Edit5: 00_TSCUL.pm bezüglich WriteTranslate korrigiert https://forum.fhem.de/index.php/topic,24436.msg1235516.html#msg1235516 (https://forum.fhem.de/index.php/topic,24436.msg1235516.html#msg1235516)
Edit6: Module aktualisiert auf 00_97, CUL_HM prep Update https://forum.fhem.de/index.php/topic,24436.msg1240628.html#msg1240628 (https://forum.fhem.de/index.php/topic,24436.msg1240628.html#msg1240628) und https://forum.fhem.de/index.php/topic,24436.msg1240791.html#msg1240791 (https://forum.fhem.de/index.php/topic,24436.msg1240791.html#msg1240791)
Edit7: Module aktualisiert auf 00_98, TSCUL https://forum.fhem.de/index.php/topic,24436.msg1265842.html#msg1265842 (https://forum.fhem.de/index.php/topic,24436.msg1265842.html#msg1265842)
Edit8: Module aktualisiert auf 00_99, CUL_HM, HMinfo https://forum.fhem.de/index.php?topic=134891.0 (https://forum.fhem.de/index.php?topic=134891.0)
und leider ist die erlaubte Dateigröße jenseits des Firmware Codes. Und er vorherige Stand ist leider schon gelöscht. Firmware in Teilen hier https://forum.fhem.de/index.php?msg=1286381 (https://forum.fhem.de/index.php?msg=1286381) und hier https://forum.fhem.de/index.php?msg=1286383 (https://forum.fhem.de/index.php?msg=1286383)
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: yersinia am 27 Juli 2021, 12:11:00
Danke. Läuft erst einmal soweit mit zwei nanoCULs. Einige Warnings bekomm' ich:
2021.07.27 11:56:15 1: PERL WARNING: substr outside of string at ./FHEM/10_CUL_HM.pm line 11434.
2021.07.27 11:56:15 1: PERL WARNING: Use of uninitialized value in hex at ./FHEM/10_CUL_HM.pm line 11434.
2021.07.27 11:56:15 1: PERL WARNING: Use of uninitialized value $a[2] in uc at ./FHEM/10_CUL_HM.pm line 663.
2021.07.27 12:05:39 1: PERL WARNING: Use of uninitialized value $name in hash element at ./FHEM/10_CUL_HM.pm line 12128
2021.07.27 12:05:19 1: PERL WARNING: Use of uninitialized value $name in hash element at ./FHEM/10_CUL_HM.pm line 9202.
2021.07.27 12:05:19 1: PERL WARNING: Use of uninitialized value $name in hash element at ./FHEM/10_CUL_HM.pm line 9579.
2021.07.27 12:05:19 1: PERL WARNING: Use of uninitialized value $name in string eq at ./FHEM/10_CUL_HM.pm line 9581.
2021.07.27 12:05:19 1: PERL WARNING: Use of uninitialized value $name in pattern match (m//) at ./FHEM/10_CUL_HM.pm line 9582.
2021.07.27 12:05:19 1: PERL WARNING: Use of uninitialized value $name in pattern match (m//) at ./FHEM/10_CUL_HM.pm line 9583.
2021.07.27 12:05:19 1: PERL WARNING: Use of uninitialized value $name in hash element at ./FHEM/10_CUL_HM.pm line 9235.
2021.07.27 12:05:19 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4537.
2021.07.27 12:05:19 1: PERL WARNING: Use of uninitialized value $name in hash element at ./FHEM/10_CUL_HM.pm line 9628.
2021.07.27 12:05:19 1: PERL WARNING: Use of uninitialized value $name in hash element at ./FHEM/10_CUL_HM.pm line 9439.
2021.07.27 12:05:19 1: PERL WARNING: Use of uninitialized value in list assignment at ./FHEM/10_CUL_HM.pm line 9662.
2021.07.27 12:05:19 1: PERL WARNING: Use of uninitialized value $name in hash element at ./FHEM/10_CUL_HM.pm line 9663.
2021.07.27 12:05:19 1: PERL WARNING: Use of uninitialized value within @_ in list assignment at ./FHEM/10_CUL_HM.pm line 11266.

CUL_HM Version:
# $Id: 10_CUL_HM.pm 24374m 2021-07-10 18:16:52Z noansi $

Interessanterweise bekomm ich auch diese Meldung
2021.07.27 11:56:15 1: define VCCU_Btn0 CUL_HM : wrong syntax: define <name> CUL_HM 6-digit-hex-code [Raw-Message]
dabei habe ich bewusst bei der Einrichtung der VCCU keinen Button angelegt gehabt. (Müsste der code nicht 8-stellig sein? Also hhhhhhnn wobei hh der hex-code, nn die Kanalnummer wäre, oder?)
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.38
Beitrag von: Adimarantis am 27 Juli 2021, 13:59:40
Zitat von: noansi am 23 Juli 2021, 22:24:47
zuallererst, Dir ist aufgefallen, dass Deine Geragentorfernbedienung eine Totmannfunktion mittels Drücken der Taste bis Abschluss der Torbewegung hat.
Es handelt nicht um ein Garagentor sondern um eine sehr langsam fahrende horizontale Abdeckung, natürlich muss man trotzdem aufpassen, aber selbst bei Sprachsteuerung würde man normalerweise danebenstehen.

Zitat
Ein mehrstündiges Protokoll würde wohl auch niemand freiwillig nach zufälligen Empfangsdaten eines irgendwann mal sendenden, unbekannten Gerätes durchsuchen wollen.
War auch nicht so gedacht. Eher für den Fall, das du sowas schon gesehen hast. Ich kann im Log leider keinen direkten zeitlichen Zusammenhang herstellen - verzögert landet da nichts, oder? Sonst schauts wohl schlecht aus mit dem Normalmodus.

Zitat
Edit: Du kannst auch noch Native1, Native2 und Native3 ausprobieren, ob da was kommt. Das wäre dann frequenzmoduliert.
Wo stelle ich das ein?

Danke,
Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 27 Juli 2021, 20:32:20
Hallo Jörg,

ZitatWo stelle ich das ein?
Attribut rfmode.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 27 Juli 2021, 22:58:05
Hallo yersinia,

ok, kein VCCU Peering, das erklärt wohl die Warnings. Danke für den Hinweis.

Edit:Verschwinden die Warnings mit der im Anhang?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: yersinia am 28 Juli 2021, 09:23:23
Zitat von: noansi am 27 Juli 2021, 22:58:05ok, kein VCCU Peering, das erklärt wohl die Warnings. Danke für den Hinweis.
Ja, habe ich irgendwie keinen Bedarf für.

Zitat von: noansi am 27 Juli 2021, 22:58:05Edit:Verschwinden die Warnings mit der im Anhang?
Mit der angehängten Version
# $Id: 10_CUL_HM.pm 24374n 2021-07-27 18:16:52Z noansi $
habe ich keine Warnings bisher.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 28 Juli 2021, 20:14:30
Hallo yersinia,

dank für das Feedback, ich habe oben den Modulstand entsprechend aktualisiert.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: Adimarantis am 01 August 2021, 14:35:46
Zitat von: noansi am 27 Juli 2021, 20:32:20
Hallo Jörg,
Attribut rfmode.

Gruß, Ansgar.

Geht das mit der nanoCUL nicht? Habe jetzt extra deine neuste Firmware geflashed und die neusten Module installiert aber es kommt ein Fehler (..not supported...wrong firmware?)
VERSION=VTS 0.39 CSM868
VERSION_HW=nanoCUL_V1.x_0014
VERSION_TS=yes AES ChTblSize:209


Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 01 August 2021, 15:55:12
Hallo Jörg,

native ist in TSnanoCUL_NAT.hex unter untested hex drin. Der Flash Speicher und SRAM des NANO reicht nicht für alle unterstützte Protokolle.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 01 August 2021, 19:16:41
Hallo Zusammen,

ich habe hier https://forum.fhem.de/index.php/topic,24436.msg1167796.html#msg1167796 (https://forum.fhem.de/index.php/topic,24436.msg1167796.html#msg1167796) die Module nochmal aktualisiert.

Grund: bessere Koexistenz mit anderen IOs.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: Adimarantis am 02 August 2021, 16:47:47
Zitat von: noansi am 01 August 2021, 15:55:12
native ist in TSnanoCUL_NAT.hex unter untested hex drin. Der Flash Speicher und SRAM des NANO reicht nicht für alle unterstützte Protokolle.
Danke. Also unter allen drei Native Modes ist Funkstille. (Bei Native1 hat er mal was empfangen aber noch bevor ich überhaupt meinen Test gemacht hatte - dann nichts mehr).
Nochmal mit SlowRF getestet und da dachte ich erst etwas zu empfangen, aber ein zweiter Versuch brachte dann wieder kein Ergebnis, also wahrscheinlich ein "Querschläger".

Dann mit X39 und SlowRF (immer noch mit der NAT Firmware, aber die kann auch SlowRF?) und dann fing das log nachvollziehbar an wie wild zu scrollen, wenn ich die Taste gedrückt habe.
Ich kann jetzt nicht garantieren ob da noch "Störer" mit drin sind, aber da die Aktivität sonst eher niedrig ist und durch das "Taste runterhalten" (habe "vor" und "zurück" probiert) massig gefunkt wird, gehe ich mal davon aus das dies so ziemlich alles von meiner Fernbedienung kommt.
Kannst du damit irgendwas anfangen?

Jörg

Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 02 August 2021, 22:04:27
Hallo Jörg,

ZitatKannst du damit irgendwas anfangen?
Vermutlich nicht. FM sollte es nach diesem Katalog sein:
https://www.niceforyou.com/sites/default/files/upload/catalogues-brochures/nice_era_one_de.pdf (https://www.niceforyou.com/sites/default/files/upload/catalogues-brochures/nice_era_one_de.pdf)

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: Adimarantis am 05 August 2021, 12:20:38
Zitat von: noansi am 02 August 2021, 22:04:27
Vermutlich nicht.

Schade. Ich muss mal sehen - alternativ kann das Teil auch Bluetooth - gibt aber nur eine iPhone App (und ich bin in der Android Fraktion). Vielleicht kann man sich ja auch da einklinken.

Btw. welche CUL würdest du eigentlich empfehlen? (meine Nano schränkt ja wohl doch etwas ein) Wenns geht mit Link zu einer Bauanleitung.

Danke,
Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 05 August 2021, 19:28:07
Hallo Jörg,

den CUNX gibt es anscheinend bei Busware leider nicht mehr.

Ein interessantes Bastelprojekt könnte https://github.com/damianmelson/megaCUL-868MHz (https://github.com/damianmelson/megaCUL-868MHz) sein. Der Prozessor hat viel Flash und SRAM (der gleiche, wie bei SCC).
WLAN würde ich aber für HM gar nicht erst drauf löten, um nicht in die Versuchung des Ärgers durch gestörte Verbindung zu kommen.
Falls überhaupt noch alle Teile zu bekommen sind...
Noch schöner wäre USB nativ seitens ATMEGA Prozessor, aber dazu kenne ich bisher kein Bastelprojekt.

Hex dazu zum testen ist im gerade aktualisierten zip zu finden.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: Adimarantis am 06 August 2021, 18:54:52
Zitat von: noansi am 05 August 2021, 19:28:07
Ein interessantes Bastelprojekt könnte https://github.com/damianmelson/megaCUL-868MHz (https://github.com/damianmelson/megaCUL-868MHz) sein. Der Prozessor hat viel Flash und SRAM (der gleiche, wie bei SCC).
SMD löten übersteigt meine Fähigkeiten leider. Ich bin ja schon froh wenn ich Homematic Bausätze zusammen kriege.

Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: Adimarantis am 06 August 2021, 19:39:34
Was ganz anderes:
Ich habe zwei LEDs die über 433Mhz gesteuert werden.
Über die RFXTRX433 funktionierte das im ausgebauten Betrieb wunderbar - aber an der Zielposition ist der Empfang einfach so mies, dass es gar nicht geht.
Daher wollte ich meine 433 CUL reaktivieren, da einer meiner Raspberries ziemlich nah dran sitzt.

Mit TRX_LIGHT ist das als "PT2262" mit der Adresse "12100113" definiert. Da werden dann noch die Steuercodes, z.B. "0201" für "auf Blau schalten" angehängt.
Kann ich das mit TSCUL ansteuern? bzw. mit der aktuellen Firmware die drauf ist: "V 1.67 nanoCUL433"?

Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: riker1 am 05 Oktober 2021, 08:49:31
Hallo, hätte ne Frage.

Eventuell verstehe ich es falsch.

wenn ich set HMXXXX controlManu 22 mache,

kommt als Trigger nur

2021-10-05 08:43:31.603 CUL_HM HMxxxx controlMode: set_manual

mir fehlt dort der Temp Value also eventpart1

Oder woher bekomme ich den Temperturvalue?

Ein Event set_desired-temp sehe ich dazu nicht?

Danke für die Hilfe.

VG T

Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 05 Oktober 2021, 20:18:23
Hallo riker1,

wenn Du von einem HM-CC-RT-DN schreibst, dann kommt das desired-temp event später mit der Statusmeldung vom device.

Ob das was Du Dir vorstellst sein sollte, müsstest Du im HM Bereich mit Martin diskutieren.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 05 Oktober 2021, 20:27:48
Hallo Jörg,

sorry, sehe ich jetzt erst.

"PT2262" kannst Du mit dem IT Modul probieren.
Wenn Du es auf anderem Wege schon senden kannst, dann bestehen auch Chancen, dass Du es mit dem 433er CUL empfangen kannst, was bezüglich Code auch der einfachste Weg zum Einrichten wäre.
Neben dem Code muss auch noch die IT Frequenz oder ITfreqOffs und der ITclock passend gewählt werden, damit Du auch richtig senden kannst. Mit Erhöhung der Repetitions kannst Du auch noch die Empfangchancen der Sendedaten erhöhen.

Edit: Senden kannst Du das mit der Standardfirmware, a-culfw und tsculfw. Für tsculfw musst Du aber das beigepackte IT Modul verwenden, für die anderen beiden das IT Modul aus dem FHEM Standard.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: Adimarantis am 29 Oktober 2021, 20:25:45
Hi Ansgar,

danke für die Antwort. Ich war jetzt "faul" und hab mir einfach eine zweite RFXTRX433 gekauft.

Noch eine andere Frage: Mein HM-CC-VD hat neuerdings das Problem das er auf ~97% hängen bleibt (motorErr=blocked) (obwohl ich ihn eigentlich nur zwischen 0 und 25 hin und her fahre). Stromlos machen bringt das er sich wieder fängt. Kann man so einen "Reset" auch senden? Oder eine Idee warum er da überhaupt hin fährt (Entkalkungsfahrt?)

Ich hab auch mal auf deine neuste TSCUL geupdated und bekomme jetzt dauern Fehlermeldungen im Log:
2021.10.29 20:23:18.858 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4681.
2021.10.29 20:23:18.862 1: stacktrace:
2021.10.29 20:23:18.865 1:     main::__ANON__                      called by fhem.pl (4681)
2021.10.29 20:23:18.869 1:     main::AttrVal                       called by ./FHEM/00_TSCUL.pm (1382)
2021.10.29 20:23:18.873 1:     main::TSCUL_ParseTsHM               called by ./FHEM/00_TSCUL.pm (707)
2021.10.29 20:23:18.877 1:     main::TSCUL_Parse                   called by ./FHEM/00_TSCUL.pm (643)
2021.10.29 20:23:18.880 1:     main::TSCUL_Read                    called by fhem.pl (3895)
2021.10.29 20:23:18.883 1:     main::CallFn                        called by fhem.pl (773)


Irgendeine Idee?

EDIT: Ich hab mir den Fehler jetzt mal "weggepatched". Du machst ein AttrVal für ein Attribut "sndThrRep" das es nirgendwo gibt, womit m.E. immer der Defaultwert genommen wird. Also nehme ich den jetzt immer (in 1377 und 1382):
$mh{thrRpt} = $RepSndActive;

Hab natürlich keine Ahnung wozu das gedacht war. Zumindest kommen jetzt keine Meldungen mehr und meine Ventile funktionieren noch.

Gruß,
Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 29 Oktober 2021, 21:19:46
Hallo Jörg,

ZitatIrgendeine Idee?
Ja, ist nur eine Warnung.
Aus meiner Sicht gibt die fhem.pl Funktion AttrVal in dem Fall, dass der erste Parameter (devicename) nicht definiert ist, zwar den Ersatzwert $default zurück, aber es tritt die obige Warnung auf, weil der Parameter ungeprüft für einen Hash Zugriff verwendet wird.
Das wäre durch Rudolf in der fhem.pl zu verbessern.
Z.B. in dieser Art:
sub
AttrVal($$$)
{
  my ($d,$n,$default) = @_;
  if (defined($d)) {
    my $a = $attr{$d};
    if (defined($a) && defined($n)) {
      $n = resolveAttrRename($d, $n);
      return $a->{$n} if(defined($a->{$n}));
    }
  }
  return $default;
}


Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: yersinia am 26 November 2021, 12:53:54
Hi noansi,

ich hatte es schon unter SlowRF (https://forum.fhem.de/index.php/topic,124377.0.html) kurz angefragt weil ich die Fehlermeldung in mit bezug auf FS20 vermutete. Ich habe eine Fehlermeldung nach einem normalen FHEM-Update mit Bezug auf FS20:
2021.11.26 11:20:06 0: ERROR: Cannot autoload FS20V
2021.11.26 11:20:06 1: PERL WARNING: Illegal hexadecimal digit 'm' ignored at ./FHEM/10_FS20.pm line 439.

Da ich verbose auf 3 und ohne stacktrace fahre, sind die Zeilen wahrscheinlich wenig aussagekräftig:
2021.11.26 10:41:12 3: CUL_HM set KellerfensterGarten getConfig noArg
2021.11.26 10:41:44 2: HMinfo hm get:configCheck :-f,^(KellerfensterGarten|KellerfensterGarten)$
2021.11.26 11:20:06 0: ERROR: Cannot autoload FS20V
2021.11.26 11:20:06 1: PERL WARNING: Illegal hexadecimal digit 'm' ignored at ./FHEM/10_FS20.pm line 439.
2021.11.26 12:18:19 3: HMinfo hm get:update :
2021.11.26 12:18:19 3: CUL_HM set ActionDetector update noArg
2021.11.26 12:18:19 3: CUL_HM set VCCU update noArg


rudolfkoenig vermutet (https://forum.fhem.de/index.php/topic,124377.msg1189425.html#msg1189425) dies eher hier zu adressieren. Bis jetzt kann ich keine Funktionseinbußen feststellen.
Ich nutze deine tsculfw v39 und v94 der Module von dir (also imho aktueller Stand).

Bevor ich mit stacktrace und verbose 5 anfange würde ich das gern weiter eingrenzen um die Fehler besser nachstellen zu können.

Hast du eine Idee, wie ich der Fehlermeldung weiter nachgehen könnte?
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 26 November 2021, 21:58:11
Hallo yersinia,

Antwort hier https://forum.fhem.de/index.php/topic,124377.msg1189533.html#msg1189533 (https://forum.fhem.de/index.php/topic,124377.msg1189533.html#msg1189533) weil hier nach derzeitigem Informationsstand falsch.  ;)

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: gamauf am 06 Dezember 2021, 14:43:32
Hallo!
Hat es die, hier besprochene, "Timestamp Option" inzwischen in die reguläre, aktuelle CUL-FW (http://culfw.de/culfw-1.67.tar.gz) (und 00_CUL.pm)geschafft?
Bzw. welche CUL-FW wäre für HomeMatic, nach heutigem Stand, zu empfehlen?
Danke!
LG
Rainer
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: hmtec99 am 12 Dezember 2021, 12:26:31
Hallo noansi!

Kannst du bitte die Version 0.37 noch einmal bereitstellen? Leider wurde der Anhang aus dem entsprechenden Beitrag entfernt...  :(

Ich wollte mal wieder mutig sein und habe die 0.39 installiert. Danach ging gar nix mehr. Keine Verbindung mehr zu Geräten.
CUL (Original V3) auf Overload und nach ca. 20- 30 Sekunden Absturz FHEM. Reproduzierbar.

Also die 0.38 geflashed und installiert. Funktion wieder da, allerdings nur Empfang und kein Senden mehr. Dafür ständig folgende Log-
Einträge:

TSCUL_ParseTsHM: CUL_HM HM CCA channel busy error to 1AC751/FD:  05904510 A F004 02506440 00 0C 1B A011 F11234 1AC751 800903 _sfail

Ich hatte das ganze schon einmal versucht mit gleichem Ergebnis und nach endlosem Suchen und "Fummeln" gings plötzlich wieder. Ursache unbekannt. Leider kriege ich es dieses Mal nicht wieder hingefummelt.

Ich weiß leider nicht mehr ob ich vorher auf 0.37 war, aber ein Versuch ist es wert.

Folgende Frage habe ich noch. In der Anleitung finde ich immer folgende Hinweis zum originalen USB CUL V3:

define CUL_868 TSCUL /dev/CUL868_0@12000000 1234

Ich habe mehrfach den Test gemacht diese hohe Baudrate einzustellen. Danach geht nix mehr mit dem CUL. Nur bei 38400 funktiert das Ganze. Irgendeine Idee? Habe ich dadurch Nachteile?

Gruß, Oli
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: hmtec99 am 16 Dezember 2021, 08:09:21
Letzter Eintrag kann komplett ignoriert werden.

Es war der berühmte letzte Tropfen, der das Fass zum überlaufen gebracht (oder gebraucht) hat.

Ich vermute das mein CUL irgendwie nicht mehr ganz richtig funktioniert hat...

Ich habe mir eine gebrauchte CCU2 geschossen, in ein LAN-Gateway verwandet und zumindest die
Beobachtung eines Tages zeigt mir, daß der Empfang um Welten (!) besser ist.

Lustigerweise funktioniert nun auch der Empfang meiner LaCrosse-Sensoren wieder fehlerfrei. Irgend-
wann ohne erkennbaren Grund wurde manche Sensoren kaum noch empfangen und irgendwann später
betraf das mehr oder weniger alle (aber nur manchmal, was weiß ich?!). Komischerweise auch, wenn der
CUL gar nicht eingesteckt war?! Mysteriös!  :o

Trotzdem danke für die Entwicklungsleistung, die hier und auch in anderen Bereichen erbracht wird!

Gruß, Oli

P.S. Die Module von TSCUL sind immer noch in Benutzung, da ich außer VCCU und Lan-Gateway nichts geändert
habe. Macht das Sinn, oder sollte ich wieder die originalen Module verwenden?

Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: yersinia am 06 Januar 2022, 11:24:01
Hi noansi,

siehst du dich in der Lage, die Änderungen der 98_HMinfo.pm (https://svn.fhem.de/trac/log/trunk/fhem/FHEM/98_HMinfo.pm) auch in deinem fw Paket bereitzustellen?
Es scheint als würde die mitgelieferte Version (https://forum.fhem.de/index.php/topic,24436.msg1167796.html#msg1167796) nicht mit der neusten HMinfoTools.js zu laufen (https://forum.fhem.de/index.php/topic,112825.msg1198435.html#msg1198435) (bzw andersherum ::)).

EDIT:
Nach franks Hinweis (https://forum.fhem.de/index.php/topic,112825.msg1198462.html#msg1198462) auf den Patch (https://forum.fhem.de/index.php/topic,124095.0.html) (ab Zeile 431) scheint es zu funktionieren.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: LamerMmc am 10 Februar 2022, 21:32:14
Hallo,

ich habe heute meinen alten nanoCUL gegen einen neuen ausgetauscht (beim alten ist der USB Port kaputt).
Ich habe den neuen erfolgreich auf die aktuelle Firmware 0.39 geflasht. (Habe auch die Module aktualisiert)
Fhem erkennt ihn auch sofort.
Problem ist dass der cul/vccu mit keinen Gerät mehr Kommunizieren kann.

Logs:
2022.02.10 21:08:46 3: LogHist cul:  036724                 As 0B E9 B001 AABBCC 5F7837 010E
2022.02.10 21:08:46 3: LogHist cul:  04231430 A FB03 00058936 01 0B E9 B001 AABBCC 5F7837 010E _bst _CCAdly:4
2022.02.10 21:08:46 3: LogHist cul:  04232118 A FA03 00059636 01 0B E9 B001 AABBCC 5F7837 010E _bst _CCAdly:4
2022.02.10 21:08:46 3: LogHist cul:  04232823 A FA03 00060336 01 0B E9 B001 AABBCC 5F7837 010E _bst _CCAdly:4
2022.02.10 21:08:46 3: LogHist cul:  038579                 As 0B 8D A001 AABBCC 5F6895 010E
2022.02.10 21:08:46 3: LogHist cul:  04233142 A FA09 00061032 00 0B E9 B001 AABBCC 5F7837 010E _bst _sfail _noAnsw
2022.02.10 21:08:46 3: LogHist cul:  04233175 A FA03 00061036 01 0B 8D A001 AABBCC 5F6895 010E _CCAdly:4
2022.02.10 21:08:46 3: LogHist cul:  04233430 A FA03 00061300 01 0B 8D A001 AABBCC 5F6895 010E _CCAdly:4
2022.02.10 21:08:46 3: LogHist cul:  04233702 A FA03 00061564 01 0B 8D A001 AABBCC 5F6895 010E _CCAdly:4
2022.02.10 21:08:46 3: LogHist cul:  04233926 A FA09 00061824 00 0B 8D A001 AABBCC 5F6895 010E _sfail _noAnsw
2022.02.10 21:08:46 3: LogHist cul:  041534                 As 0B 54 A001 AABBCC 60C2ED 010E
2022.02.10 21:08:46 3: LogHist cul:  04235878 A FA03 00063748 01 0B 54 A001 AABBCC 60C2ED 010E _CCAdly:4
2022.02.10 21:08:46 3: LogHist cul:  04236149 A FA03 00064016 01 0B 54 A001 AABBCC 60C2ED 010E _CCAdly:4
2022.02.10 21:08:46 3: LogHist cul:  04236517 A FA03 00064388 1C 0B 54 A001 AABBCC 60C2ED 010E _CCAdly:112
2022.02.10 21:08:46 3: TSCUL_ParseTsHM: cul HM repeat failed to 60C2ED/lr_light:  04236757 A FA09 00064652 00 0B 54 A001 AABBCC 60C2ED 010E _sfail _noAnsw


an der config des cul und der vccu habe ich nichts geändert.

Internals:
   CMDS       ABCFGJKRUVWXYeiltx
   Clients    STACKABLETS:STACKABLE:CUL_HM:CUL_IR:TSHMS
   DEF        /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0@38400 1234
   DeviceName /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0@38400
   FD         15
   FHTID      1234
   FUUID      5dc1e594-f33f-f320-25c7-c2e5ca541e8ef70c
   FVERSION   00_TSCUL.pm:0.001380/2021-08-04
   NAME       cul
   NR         31
   PARTIAL   
   RAWMSG     
   STATE      Initialized
   TYPE       TSCUL
   VERSION    VTS 0.39 CSM868
   VERSION_HW nanoCUL_V1.x_0014
   VERSION_TS yes AES ChTblSize:209
   XmitOpen   1
   assignUpdCntI 64
   assignedIDsCnt 27
   devioNoSTATE 1
   initString XP0C
X21
Ar
AM5
AHAABBCC
   msgLoadCurrent 80
   owner_CCU  vccu
   MatchList:
     A:CUL_HM   ^A....................
     B:CUL_IR   ^I............
     C:TSHMS    ^810e04......a001
     Y:STACKABLETS ^\*
     Z:STACKABLE ^\*
   READINGS:
     2022-02-10 21:18:09   Xmit-Events     disconnected:1 ok:3 ERROR-Overload:3 non-HM:1 Warning-HighLoad:4
     2022-02-10 21:07:45   cmds             A B C F G J K R U V W X Y e i l t x
     2022-02-10 21:18:09   cond            ok
     2022-02-10 21:13:02   prot_ERROR-Overload last
     2022-02-10 21:13:13   prot_Warning-HighLoad last
     2022-02-10 21:07:41   prot_disconnected last
     2022-02-10 21:07:47   prot_non-HM     last
     2022-02-10 21:18:09   prot_ok         last
     2022-02-10 21:03:13   scF             0.999427619856769
     2022-02-10 21:13:13   state           Initialized
     2022-02-10 19:18:13   version         V 1.67 nanoCUL868
   helper:
     CUrun      1
     ChkPart    0
     RA_Timeout 0
     SVTS       1
     VTS        1
     VTS_ACK    1
     VTS_AES    1
     assIdCnt   27
     assIdRep   27
     nRec       0
     recAlive   1
     recd       0
     DEVIOTS:
       RXfailTO   
     HM:
       ChTblSize  209
       FUP        0
       HMactive   1
       hmCrdts    8
       hmSbusy    0
       ChTbl:
         59FEDC00   00
         5ED0F400   00
         5F316C00   00
         5F31A500   00
         5F689500   00
         5F68AB00   00
         5F68B200   00
         5F68B700   00
         5F68D200   00
         5F71BF00   00
         5F783500   00
         5F783700   00
         60C2ED00   00
         60C41600   00
         62F7E700   00
         62F7EB00   00
         63AA6500   00
         687F1B00   00
         687FA500   00
         687FA900   00
         687FB500   00
         687FDB00   00
         687FEB00   00
         690AC700   00
         725DB900   00
         725F0F00   00
         72600700   00
       msgCNT:
         0x02       71
         0x03       112
         0x09       28
       unknwn:
     cnd:
       0          3
       2          4
       250        1
       253        1
       4          3
     hmLog:
       IDs:
     hmLogHist:
        04888536 A F803 00716772 01 0B 46 8470 AABBF1 000000 00E4 _CCAdly:4
        04889329 A F802 00717596 00 34 AA00112200000049AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
        04896798 A F802 00725064 00 34 AA00112200000048AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
        178920                 As 0B 46 8470 AABBF2 000000 00DD
        04897555 A F803 00725804 01 0B 46 8470 AABBF2 000000 00DD _CCAdly:4
        04911274 A F802 00739560 00 34 AA00112200000047AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
        04924711 A F802 00752988 00 34 AA00112200000046AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
        04935698 A F802 00763996 00 34 AA00112200000045AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
        04949375 A F802 00777676 00 34 AA00112200000044AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
        04957451 A F802 00785760 00 34 AA00112200000043AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
        04969303 A F802 00797616 00 34 AA00112200000042AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
        251296                 As 0B 46 8470 AABBF3 000000 00CA
        04969932 A F803 00798220 01 0B 46 8470 AABBF3 000000 00CA _CCAdly:4
        04980388 A F802 00808708 00 34 AA00112200000041AA001122AA001122AA001122AAAA001122AA001122AA001122AA001122AA001122AA001122AA001122AA0011 _ping
     hmQ:
       000000:
       5F6895:
       5F68AB:
       5F68B7:
       5F68D2:
       5F71BF:
       5F7835:
       5F7837:
       60C2ED:
       60C416:
     ids:
       59FEDC:
         cfg        +59FEDC,00,00,00
         name       hw_pushbutton_ap
       5ED0F4:
         cfg        +5ED0F4,00,00,00
         name       st_smoke
       5F316C:
         cfg        +5F316C,00,00,00
         name       hw_pushbutton_up
       5F31A5:
         cfg        +5F31A5,00,00,00
         name       br_pushbutton_up
       5F6895:
         cfg        +5F6895,00,00,00
         name       ki_light
       5F68AB:
         cfg        +5F68AB,00,00,00
         name       ba_light_mirror
       5F68B2:
         cfg        +5F68B2,00,00,00
         name       st_light
       5F68B7:
         cfg        +5F68B7,00,00,00
         name       br_light
       5F68D2:
         cfg        +5F68D2,00,00,00
         name       hw_light
       5F71BF:
         cfg        +5F71BF,00,00,00
         name       hw_smoke
       5F7835:
         cfg        +5F7835,00,00,00
         name       br_smoke
       5F7837:
         cfg        +5F7837,00,00,00
         name       lr_smoke
       60C2ED:
         cfg        +60C2ED,00,00,00
         name       lr_light
       60C416:
         cfg        +60C416,00,00,00
         name       ba_light_fan
       62F7E7:
         cfg        +62F7E7,02,00,00
         name       br_thermostat
       62F7EB:
         cfg        +62F7EB,02,00,00
         name       st_thermostat
       63AA65:
         cfg        +63AA65,02,00,00
         name       lr_thermostat
       687F1B:
         cfg        +687F1B,00,00,00
         name       st_window
       687FA5:
         cfg        +687FA5,00,00,00
         name       br_window
       687FA9:
         cfg        +687FA9,00,00,00
         name       hw_door
       687FB5:
         cfg        +687FB5,00,00,00
         name       lr_window_1
       687FDB:
         cfg        +687FDB,00,00,00
         name       ba_window
       687FEB:
         cfg        +687FEB,00,00,00
         name       lr_window_2
       690AC7:
         cfg        +690AC7,00,00,00
         name       ki_window
       725DB9:
         cfg        +725DB9,02,00,00
         name       ki_thermostat
       725F0F:
         cfg        +725F0F,02,00,00
         name       ba_thermostat
       726007:
         cfg        +726007,02,00,00
         name       hw_thermostat
     loadLvl:
       bl         40
     q:
       ATrNo      0
       HMcndN     0
       InQueues   0
       RQLSt      0
       RQLt       0
       XRpCnt     0
       XRpTm      1644523673.95052
       answerPend 0
       hmLanQlen  1
       apIDs:
     ref:
       Sdly       19
       TmBmCnt    1
       ioBR       3840
       ioBRMax    3726.7281278245
       ioBRMean   3351.78798628167
       ioBRMeas   3418.54482218327
       ioBRn      41
       ioBRnC     59
       ioBRs      197755.491190618
       lHMt       670504
       lSys       625599262
       pTTu       1024
       pndAs      0
       pndCUAp    0
       pndTuP     1
       pngLm      16
       pngRef     4
       scErr      0
       scF        0.999427619856769
       scFN       9
       scHT       19620
       scST       624948743
       scpTm      1644523681.2826
Attributes:
   group      cul
   hmId       AABBCC
   icon       cul_cul
   rfmode     HomeMatic
   room       system
   sortby     2


Internals:
   DEF        AABBCC
   FUUID      62056fa5-f33f-f320-8b82-ea8a2cf57f432afd
   FVERSION   10_CUL_HM.pm:0.243740/2021-05-02
   IODev      cul
   NAME       vccu
   NOTIFYDEV  global
   NR         221
   NTFY_ORDER 50-vccu
   STATE      cul:ok
   TYPE       CUL_HM
   assignedIOs cul
   chanNo     01
   READINGS:
     2022-02-10 21:07:49   IODev           cul
     2022-02-10 21:18:09   IOopen          1
     2022-02-10 21:06:13   cfgState        IOGrpVirt
     2022-02-10 21:18:09   state           cul:ok
   helper:
     HM_CMDNR   168
     peerFriend peerSD,peerSens,peerAct
     peerOpt    -:virtual
     regLst     0
     rxType     1
     cmds:
       TmplKey    :no:1644523669.3957
       TmplTs     1644523669.3957
       cmdKey     1:1:1::vccu::01:
       cmdLst:
         assignHmKey noArg
         assignIO   -IO- [({set}|unset)]
         clear      [(readings|rssi|msgEvents|attack|{msgErrors}|unknownDev)]
         defIgnUnknown noArg
         deviceRename -newName-
         fwUpdate   -filename- [-bootTime-]
         getDevInfo noArg
         hmPairForSec [-sec-]
         hmPairSerial -serial-
         peerChan   -btnNumber- -actChn- [({single}|dual|reverse)] [({set}|unset)] [(actor|remote|{both})]
         peerSmart  -peerOpt-
         postEvent  -condition-
         press      [(long|{short})] [(-peer-|{all})] [(noBurst|{Burst})] [(-repCount-|{0})] [(-repDelay-|{0.25})]
         pressL     [(-peer-|{all})]
         pressS     [(-peer-|{all})]
         raw        -data- [...]
         reset      noArg
         tplSet_0   -tplChan-
         unpair     noArg
         update     noArg
         virtual    [(1..50;1|{1})]
       lst:
         condition  0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135,136,137,138,139,140,141,142,143,144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,160,161,162,163,164,165,166,167,168,169,170,171,172,173,174,175,176,177,178,179,180,181,182,183,184,185,186,187,188,189,190,191,192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,207,208,209,210,211,212,213,214,215,216,217,218,219,220,221,222,223,224,225,226,227,228,229,230,231,232,233,234,235,236,237,238,239,240,241,242,243,244,245,246,247,248,249,250,251,252,253,254,255
         peerOpt    ba_fan,ba_light,ba_light_mirror,ba_temp_virtual_ch,ba_thermostat_WindowRec,ba_thermostat_remote,ba_window,br_light,br_pushbutton_up_Btn_01,br_pushbutton_up_Btn_02,br_pushbutton_up_Btn_03,br_pushbutton_up_Btn_04,br_smoke,br_temp_virtual_ch,br_thermostat_WindowRec,br_thermostat_remote,br_window,hw_door,hw_light,hw_pushbutton_ap_Btn_01,hw_pushbutton_ap_Btn_02,hw_pushbutton_up_Btn_01,hw_pushbutton_up_Btn_02,hw_pushbutton_up_Btn_03,hw_pushbutton_up_Btn_04,hw_smoke,hw_temp_virtual_ch,hw_thermostat_WindowRec,hw_thermostat_remote,ki_light,ki_temp_virtual_ch,ki_thermostat_WindowRec,ki_thermostat_remote,ki_window,lr_light_big,lr_light_small,lr_smoke,lr_temp_virtual_ch,lr_thermostat_WindowRec,lr_thermostat_remote,lr_window_1,lr_window_2,st_light,st_smoke,st_temp_virtual_ch,st_thermostat_WindowRec,st_thermostat_remote,st_window,team_smoke
         tplChan   
         tplDel     
         tplPeer   
       rtrvLst:
         cmdList    [({short}|long)]
         deviceInfo [({short}|long)]
         list       [({normal}|full)]
         listDevice noArg
         param      -param-
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       prefIO     
       vccu       vccu
       ioList:
         cul
     mRssi:
       mNo       
       io:
         cul:
           100
           100
     peerIDsH:
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
       vrt        1
     tmpl:
Attributes:
   IODev      cul
   IOList     cul
   expert     defReg,rawReg
   group      cul
   icon       cul_cul
   model      CCU-FHEM
   room       system
   sortby     1
   subType    virtual
   webCmd     virtual:update


komischerweise bringt HMinfo mir jetzt folgende Meldung beim Config Check:

IOgrp: missing or incomplete for virtual device
    vccu:


In der config bisher war in der vccu das attribute IOgrp nicht gesetzt (hab im backup nachgeschaut)
Wenn ich das Attribut setze auf vccu (wie im Wiki beschrieben), bringt es auch keinen Erfolg.

Den alten kann ich leider mit der 0.39 nicht testen, da er kaputt ist, Aber er hatte die 0.37 drauf.

Habe ich hier was falsch gemacht?

mfg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 23 März 2022, 20:24:34
Hallo yersinia,

ich habe den HMinfo Patch 1:1 ergänzt.
Neuer Stand hier https://forum.fhem.de/index.php/topic,24436.msg1167796.html#msg1167796 (https://forum.fhem.de/index.php/topic,24436.msg1167796.html#msg1167796).

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 23 März 2022, 20:50:31
Hallo LamerMmc,

Dein CUL sendet, aber er empfängt kein einziges HM device.

Entweder
- ist das nanoCUL Empfangsmodul empfangsseitig defekt
- oder es wird massiv gestört weil neben einer Störquelle positioniert
- oder das nanoCUL Empfangsmodul hat einen größeren Empfangsfrequenzoffset was Du mit Try & Error via Änderung mit set hmFreqOffs zu optimieren versuchen könntest

Und IOgrp hast Du bei de VCCU nicht gesetzt, worauf Dich der Hinweis seit dem Update auf meine letzte Modulversion von HMinfo aufmerksam macht.
vccu:cul wäre passend für das Attribut bei Dir.
Aber primär musst Du erst mal das Empfangsproblem Deines nanoCUL lösen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 23 März 2022, 21:06:20
Hallo Oli,

ZitatTSCUL_ParseTsHM: CUL_HM HM CCA channel busy error to 1AC751/FD:  05904510 A F004 02506440 00 0C 1B A011 F11234 1AC751 800903 _sfail
Sagt, dass Dein CUL ständig was empfängt und damit der Meinung ist, dass der Kanal belegt ist.
Vermutlich ist es nah an einer Störquelle positioniert worden.

ZitatIch hatte das ganze schon einmal versucht mit gleichem Ergebnis und nach endlosem Suchen und "Fummeln" gings plötzlich wieder. Ursache unbekannt. Leider kriege ich es dieses Mal nicht wieder hingefummelt.
Vermutlich hast Du es da von der Störquelle entfernt.  :)

ZitatIch habe mehrfach den Test gemacht diese hohe Baudrate einzustellen. Danach geht nix mehr mit dem CUL. Nur bei 38400 funktiert das Ganze. Irgendeine Idee? Habe ich dadurch Nachteile?
Wenn es ein original USB CUL V3 ist, dann sollte das gehen, zumindest habe ich das mit Linux an meinem Raspi ausgiebig so am laufen. Nachteile betreffen ein wenig das Sendetiming.
Aber wenn es ein nanoCUL ist, dann geht nur 38400.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: yersinia am 24 März 2022, 12:39:49
Zitat von: noansi am 23 März 2022, 20:24:34ich habe den HMinfo Patch 1:1 ergänzt.
Neuer Stand hier https://forum.fhem.de/index.php/topic,24436.msg1167796.html#msg1167796 (https://forum.fhem.de/index.php/topic,24436.msg1167796.html#msg1167796).
Schön, dass du wieder da bist. Hab ich übernommen und läuft unauffällig. Danke. :)
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: exocet01 am 03 April 2022, 22:27:07
Hallo,

habe die tsculfw 0.39 auf meinen Busware CUL 433 MHz geflashed. Die IT Steckdose kann einwandfrei angesteuert werden. Meine SOMFY Rolläden reagieren jedoch nicht. Gibt es etwas bei SOMFY Geräten zu beachten?
Hatte das bestehende CUL Device (mit CULFW) gelöscht und nach dem Flashen mit tsculfw unter gleichem Namen neu angelegt.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 29 April 2022, 20:05:54
Hallo exocet01,

Somfy hat bisher offenbar noch niemand getestet. Daher danke für das Feedback zu einem Bug in der Firmware bezüglich Somfy Frame Gap Länge der bisher nicht aufgefallen ist.

Im Anhang neue (HEXes) zum Testen. Ich habe diverse HEX files für unterschiedliche CUL Hardware angehangen, falls noch jemand mit testen möchte.
Bitte gib Feedback, ob es damit funktioniert. Ich habe leider selbst keine Somfy Hardware, um es testen zu können.

Nebenbei bietet diese Version auch die Möglichkeit, für Somfy einen +/- Sendefrequenzoffset (nicht remanent) mittels YoXX am CUL einzustellen. XX ist dabei eine zweistellige HEX Zahl für den Offset entsprechend cc1101 Doku nutzbar.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: Flanders am 08 Juni 2022, 07:53:40
Guten Morgen,

ich nutze seit Jahren diese Firmware mit Erfolg und bin sehr zufrieden.
Seit einigen Tagen/ Wochen bemerke ich aber, dass sich alle AES-Homematic-Geräte nicht mehr steuern lassen.
Ist da ein Bug bekannt?
Schalte ich aesCommReq aus oder setzte den HMLAN als sendendes Gerät, geht es!
Es muss also am CUL liegen?!

Wäre für Hilfe sehr dankbar, da ich ungerne AES abschalten möchte.

Greets

Flanders
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 08 Juni 2022, 19:36:09
Hallo Flanders,

nein, ein derartiger Bug ist nicht bekannt.

Mehr Infos wären schon sinnvoll.

Welche CUL Hardware, welche Version der tsculfw, Nutzung der Module hier aus dem Thread oder Nutzung der Module aus dem FHEM Update?
List von CUL, VCCU und einem der nicht mehr mit AES funktionierenden Devices.

Ist das hmKey Attribut noch passend gesetzt? Wurde der CUL EEPROM Inhalt eventuell mal zurück gesetzt (z.B. auch durch Firmware Update), dann wäre eventuell ein FHEM Neustart nötig, um den Key wieder im CUL zu setzen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: Flanders am 11 Juni 2022, 08:52:21
Danke für die schnelle Antwort.
Das reiche ich bei Gelegenheit nach. Aktuell habe ich den CUL außer betrieb genommen, da ich sehr viele Geräte mit AES habe und einen reibungslosen Betrieb haben möchte...

Habe die aktuelle Firmware und FHEM-Module aus dem ZIP genommen und natürlich die FHEM-Update-Ausschlussdaten gesetzt.
Wie gesagt, es lief seit mehreren Jahren ohne Probleme...
Sobald die Kommunikation über den HMLAN Läuft (Änderung der Attribute) ist AES kein Problem mehr. Also augenscheinlich macht der CUL das Problem.
FHEM hatte ich nach dem Kopieren der aktuellen Dateien aus dem ZIP und danach einige Male neu gestartet.
Da der CUL einige Devices akzeptierte und die, die nicht mehr funktionierten aber mit dem HMLAN funktionieren, gehe ich von einem CUL Problem aus.
CUL und HMLAN hängen an einer VCCU.


Greets

Byte
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 12 Juni 2022, 01:58:35
Hallo Byte,

also wenn's ein CUL V3 ist, wie ich derzeit vermute, und der mit HMLAN zusammen lief und häufige IODev Wechsel bei HM Devices stattgefunden haben, dann könnte auch das EEPROM des CUL inzwischen verschlissen sein. Das hätte dann zur Folge, dass die Tabelle mit den zugewiesenen Devices nicht mehr richtig im CUL EEPROM gespeichert würde und er damit mangels Info die Automatismen für seine HM devices/channels nicht mehr ausführen würde.
Mit get raw AL kann die Liste vom CUL gelesen werden.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: Flanders am 12 Juni 2022, 08:37:09
Hallo,

was sagt dieser Wert aus?
CUL0 raw => AL 27829101:01

CUL0 version => VTS 0.39 CUL868


Was sind häufige IODev-Wechsel? Bewusst habe ich keine Zuordnung von Geräten zum CUL oder HMLAN geändert.

Greets

Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 12 Juni 2022, 09:51:13
Hallo Byte,

AL 27829101:01
sagt, dass das Device mit der ID 278291 dem CUL bekannt ist und er ihm automatische Acks antwortet und mit Channel 1 mit Key 1 AES ComRequest Signierung von dem Channel angefordert wird.

Wenn das das einzige Element der Antwort war, dann dann war dem CUL zu dem Zeitpunkt des Auslesens nur diese eine Zuordnung bekannt.

Wenn Du nicht IOgrp mit VorzugsIO bei den HM devices verwendet hast, dann macht die VCCU ständig eine automatische IO Zuordnung anhand des RSSI empfangener Pakete. Damit wird dann das IO immer wieder mal gewechselt, was im CUL V3 (oder auch nanoCUL) dann zu EEPROM Schreibzugriffen führt.
Mit VorzugsIO passiert das erst bei Ausfall des VorzugsIOs.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: Flanders am 12 Juni 2022, 10:48:50
Es war mit vorzugsio definiert.
Hatte jetzt natürlich alles auf vorzugsio hmlanv gestellt, da der cul zickt...
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 12 Juni 2022, 11:27:33
Hallo Byte,

was auch schon mal einfach so aufgetreten ist, dass einem CUL eine Störquelle zu Seite gestellt wurde und er damit devices nicht mehr sauber empfangen konnte oder nicht mehr gesendet wurde, da Kanalbelegung detektiert wurde.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: frank am 12 Juni 2022, 12:26:40
falls der hmlan öfter disconnected hat (wird ja nicht selten von einigen usern berichtet), hätte die vccu ggf doch das io gewechselt, trotz konfiguration als prefered io.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: Flanders am 12 Juni 2022, 13:02:20
Danke für die Info, das habe ich aber ein notify drauf. Da kam nichts an...
Ich denke, im Ergebnis ist mir die cul Geschichte zu fehlerangällig. Ich werde das wohl ausbauen...
Auf aes möchte ich nicht verzichten.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: Bastel-Frank am 23 August 2022, 08:05:08
Hallo Ansgar,

da ich schon seit langem sehr zufrieden mit deiner Firmware war/bin, bin ich auf dem Stand V0.29 stehengeblieben  :-[. Nun stellt sich heraus, dass es Probleme mit dem Modul 97_timerTS gibt, siehe https://forum.fhem.de/index.php/topic,128858.0.html.

Frage: Haben sich seit "damals" Änderungen im timerTS-Modul ergeben, die mir helfen könnten?

Viele Grüße
Frank
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 23 August 2022, 10:37:56
Hallo Frank,

Du bist mit einem alten 97_timerTS.pm unterwegs. Darin ist es noch nicht abgefangen, dass ein undefinierter Funktionsaufruf in der PrioQueues zu so einem Absturz führen kann.

In der aktuellen ist es abgefangen. Steig auf die aktuelle Version um.

Vermutlich würde es erst mal reichen, nur die 97_timerTS.pm auszutauschen, um Dein aktuelles Problem zu lösen, vermutlich.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: Bastel-Frank am 23 August 2022, 14:15:49
Zitat von: noansi am 23 August 2022, 10:37:56
Hallo Frank,

Du bist mit einem alten 97_timerTS.pm unterwegs. Darin ist es noch nicht abgefangen, dass ein undefinierter Funktionsaufruf in der PrioQueues zu so einem Absturz führen kann.

In der aktuellen ist es abgefangen. Steig auf die aktuelle Version um.

Vermutlich würde es erst mal reichen, nur die 97_timerTS.pm auszutauschen, um Dein aktuelles Problem zu lösen, vermutlich.

Gruß, Ansgar.

Ich habe das Modul aktualisiert, wie von Dir beschrieben und läuft  :). Ich danke Dir mal wieder für deinen Support.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: exocet01 am 05 September 2022, 16:45:39
Zitat von: noansi am 29 April 2022, 20:05:54
Hallo exocet01,

Somfy hat bisher offenbar noch niemand getestet. Daher danke für das Feedback zu einem Bug in der Firmware bezüglich Somfy Frame Gap Länge der bisher nicht aufgefallen ist.

Im Anhang neue (HEXes) zum Testen. Ich habe diverse HEX files für unterschiedliche CUL Hardware angehangen, falls noch jemand mit testen möchte.
Bitte gib Feedback, ob es damit funktioniert. Ich habe leider selbst keine Somfy Hardware, um es testen zu können.

Nebenbei bietet diese Version auch die Möglichkeit, für Somfy einen +/- Sendefrequenzoffset (nicht remanent) mittels YoXX am CUL einzustellen. XX ist dabei eine zweistellige HEX Zahl für den Offset entsprechend cc1101 Doku nutzbar.

Gruß, Ansgar.

Hallo Ansgar, sorry für die verspätete (5 Monate  ::) ) Rückmeldung:
Habe es heute getestet. Leider funktiniert es immer noch nicht. Im Log finde ich nichts auffälliges:
2022.09.05 15:31:59 5: TSCUL_Read CUL_0: /Ci000900000000C7D3000330D200007A8D0000F3A900000256390905

2022.09.05 15:32:31 5: TSCUL/RAW CUL_0 ReadAnswer: /C 00=0D 01=2E 02=2D 03=47 04=D3 05=91 06=FF 07=00 08=32 09=00 0A=00 0B=0D 0C=00 0D=10 0E=B0 0F=71 10=56 11=8D 12=30 13=03 14=FF
2022.09.05 15:32:31 5: TSCUL/RAW CUL_0 ReadAnswer: C 00=0D 01=2E 02=2D 03=47 04=D3 05=91 06=FF 07=00 08=32 09=00 0A=00 0B=0D 0C=00 0D=10 0E=B0 0F=71 10=56 11=8D 12=30 13=03 14=FF /15=00 16=07 17=10 18=18 19=14 1A=6C 1B=07 1C=27 1D=92 1E=FF 1F=FF 20=FB 21=B6 22=11 23=EF 24=2B 25=1A 26=1F 27=41 28=00 29=59 2A
2022.09.05 15:32:31 5: TSCUL/RAW CUL_0 ReadAnswer: C 00=0D 01=2E 02=2D 03=47 04=D3 05=91 06=FF 07=00 08=32 09=00 0A=00 0B=0D 0C=00 0D=10 0E=B0 0F=71 10=56 11=8D 12=30 13=03 14=FF 15=00 16=07 17=10 18=18 19=14 1A=6C 1B=07 1C=27 1D=92 1E=FF 1F=FF 20=FB 21=B6 22=11 23=EF 24=2B 25=1A 26=1F 27=41 28=00 29=59 2A/=7F 2B=3F 2C=81 2D=35 2E=09 2F=00 30=00 31=17 32=00 33=80 34=CB 35=0D 36=00 37=00 38=B4 39=FD 3A=00 3B=00 3C=00 3D=00

2022.09.05 15:32:31 2: TSCUL_ReceiveDelayed: CUL_0 No data received for long time: C 00=0D 01=2E 02=2D 03=47 04=D3 05=91 06=FF 07=00 08=32 09=00 0A=00 0B=0D 0C=00 0D=10 0E=B0 0F=71 10=56 11=8D 12=30 13=03 14=FF 15=00 16=07 17=10 18=18 19=14 1A=6C 1B=07 1C=27 1D=92 1E=FF 1F=FF 20=FB 21=B6 22=11 23=EF 24=2B 25=1A 26=1F 27=41 28=00 29=59 2A=7F 2B=3F 2C=81 2D=35 2E=09 2F=00 30=00 31=17 32=00 33=80 34=CB 35=0D 36=00 37=00 38=B4 39=FD 3A=00 3B=00 3C=00 3D=00
2022.09.05 15:35:12 5: TSCUL_Read CUL_0: /Ci000DA73500011FC00004B6390000BB790001587000000591390E05

2022.09.05 15:38:27 5: TSCUL_Read CUL_0: /Ci0013000000017579000660CF0001056B0001C70800000A77390905

2022.09.05 15:39:00 5: /dev/ttyACM0 closed by CUL_0
2022.09.05 15:39:00 2: TSCUL_condUpdateHM: CUL_0 new condition disconnected
2022.09.05 15:39:00 3: Opening CUL_0 device /dev/ttyACM0
2022.09.05 15:39:00 3: Setting CUL_0 serial parameters to 9600,8,N,1
2022.09.05 15:39:00 5: TSCUL/RAW CUL_0 select timeout ReadAnswer: Clear
2022.09.05 15:39:00 5: TSCUL/RAW CUL_0 ReadAnswer: /VTS 0.40 CUL433

2022.09.05 15:39:00 5: dummy V CUL_0 VTS 0.40 CUL433
2022.09.05 15:39:00 5: TSCUL/RAW CUL_0 select timeout ReadAnswer: Clear
2022.09.05 15:39:00 5: TSCUL/RAW CUL_0 ReadAnswer: /? (? is unknown) Use one of A B C F G J K R U V W X Y e i l t x

2022.09.05 15:39:00 5: CUL_0: Possible commands: ABCFGJKRUVWXYeiltx
2022.09.05 15:39:00 5: TSCUL/RAW CUL_0 select timeout ReadAnswer: Clear
2022.09.05 15:39:00 5: TSCUL/RAW CUL_0 ReadAnswer: /CUL_V3.4_0017

2022.09.05 15:39:00 5: VH CUL_0 CUL_V3.4_0017
2022.09.05 15:39:00 5: TSCUL/RAW CUL_0 ReadAnswer: /A?At1

2022.09.05 15:39:01 5: TSCUL/RAW CUL_0 select timeout ReadAnswer: Clear
2022.09.05 15:39:01 5: TSCUL/RAW CUL_0 select timeout ReadAnswer: Clear
2022.09.05 15:39:01 5: TSCUL/RAW CUL_0 ReadAnswer: /AF1020006DFE80004TiMeStAmP80

2022.09.05 15:39:01 5: TSCUL/RAW CUL_0 select timeout ReadAnswer: Clear
2022.09.05 15:39:01 5: TSCUL/RAW CUL_0 ReadAnswer: /AL

2022.09.05 15:39:01 5: TSCUL/RAW CUL_0 ReadAnswer: /AS00/D1

2022.09.05 15:39:01 5: TSCUL_DoInit CUL_0 {ids} built
2022.09.05 15:39:01 1: CUL_0 is VERSION_TS, VTS 0.40 CUL433, CUL_V3.4_0017
2022.09.05 15:39:01 5: TSCUL/RAW CUL_0 ReadAnswer: /A?At0

2022.09.05 15:39:01 5: TSCUL/RAW CUL_0 select timeout ReadAnswer: Clear
2022.09.05 15:39:01 5: TSCUL/RAW CUL_0 select timeout ReadAnswer: Clear
2022.09.05 15:39:01 5: TSCUL/RAW CUL_0 ReadAnswer: /AF1020006E0800004TiMeStAmP80

2022.09.05 15:39:01 2: TSCUL_condUpdateHM: CUL_0 new condition non-HM
2022.09.05 15:39:02 5: TSCUL/RAW CUL_0 ReadAnswer: /AHF11034

2022.09.05 15:39:02 5: TSCUL/RAW CUL_0 select timeout ReadAnswer: Clear
2022.09.05 15:39:02 5: TSCUL/RAW CUL_0 select timeout ReadAnswer: Clear
2022.09.05 15:39:02 3: CUL_0 device opened

Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 07 September 2022, 00:08:48
Hallo exocet01,

in Deinem Log Auszug ist außer der Initialisierung des CUL kein Sendebefehl zu sehen.
Ein Y Kommando sollte auftauchen, ohne wird auf jeden Fall nichts gesendet.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: hackepeter am 11 September 2022, 17:55:14
Hallo,

welche der unterstützten Hardware-Module kann denn für einen Selbstbau-cul empfolen werden? 
Gibts auch was mit LAN unterstützung? Ansonsten USB.

Von wo kann man aktuell einen funktionierenden CC1101 beziehen?

Ich nutzte die letzten Jahre einen Nano, allerdings habe ich mir den soeben zerschossen - incl CC1101.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 13 September 2022, 22:14:56
Hallo Hackepeter,

wenn Du die TSCUL Firmware und HM nutzen möchtest, ist viel SRAM sinnvoll, da dann nicht das EEPROM als Listenspeicher herhalten muss, wie beim nano.

Was ATMEGA1284P basiertes passt also gut. Und dazu habe ich bisher nur das megaCUL Projekt gesichtet https://github.com/damianmelson/megaCUL-868MHz (https://github.com/damianmelson/megaCUL-868MHz).
Für HM würde ich WLAN aber gleich weg lassen, um gar nicht erst in die Versuchung zu geraten, in WLAN Delay bedingte Probleme/Enttäuschung zu geraten. Damit also nur USB.

Die Bastelausstattung muss so weit reichen, auch den Bootloader auf den ATMEGA flashen zu können, nebst richtigem setzen der FUSE Bits.
Und in der dort vorgestellten kleinen Bauform mit SMD Bestückung natürlich auch entsprechendes Lötwerkzeug und eine ruhige Hand und gute Augen vorrausgesetzt.  ;)

Eine Device Config für megaCUL hatte ich mal im Source integriert, aber es gibt bisher kein Feedback dazu. Meinerseits ist sie ungetestet (bis auf kompilieren).

Mit mehr Hirnschmalz anhand des Schaltplans sicherlich auch in Lochraster realisierbar. Dann könnte man mit einem ENC28J60 basiertem Ethernet Modul auch eine LAN Schnitstelle dazu basteln, wie es bei CUNO2 genutzt wird. Somit also softwareseitig mit etwas Zusatzkonfigurationsaufwand und Hirnschmalz in der board.h auch LAN möglich wäre.

SCC auf RPi ist für deutlich weniger Bastelleidenschaft auch noch möglich (am besten mit abgesetzter Antenne), aber das hat dann nichts mit USB zu tun.

Für Quick, billigst und Dirty (und langweilig  ;) ) landest Du vermutlich wieder bei einem nanoCUL.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: presskopf am 14 September 2022, 10:34:37
Zitat von: noansi am 13 September 2022, 22:14:56

Für HM würde ich WLAN aber gleich weg lassen, um gar nicht erst in die Versuchung zu geraten, in WLAN Delay bedingte Probleme/Enttäuschung zu geraten. Damit also nur USB.


Hi Ansgar,
hältst Du die Kombination aus TSCUL und WLAN wirklich für so kritisch?
Ich habe z.B. einen Rasperry per WLAN im Netzwerk, welcher über ser2net einen nanoTScul bereitstellt. Der funktioniert eigentlich ganz gut.
Nur ab und zu verliert er den Kontakt. Ein Reopen fixt es dann in der Regel. Wobei der Empfang aber auch solala ist.

Mein Gedankengang war aktuell auch mal eine Bereitstellung des nanoTScul per esp8266 (Wemos D1 Mini) aufzusetzen. Da gibt es ja bereits einige gute Erfolge (z.B. minicul, Signalduino-Wemos).
(https://forum.fhem.de/index.php/topic,42998.msg349938.html#msg349938
https://forum.fhem.de/index.php/topic,69042.msg1017164.html#msg1017164)

LG
Matthias
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: MadMax-FHEM am 14 September 2022, 10:40:01
Homematic ist halt sehr kritisch bzgl. Timing, deshalb ja diese spezielle FW inkl. fhem-Module, um das so gut wie möglich auszugleichen (v.a. Laufzeiten in fhem, wenn ich das richtig verstanden habe).

Wenn dann noch Netzwerk-/WLAN-Latenzen dazu kommen, wird es nicht besser (bzw. weiß ich nicht, ob das die TSCUL-FW/Module ausgleichen können)...

Es gibt auch ESP mit dem HMOD-PCB ("Original-Homematic-Funkplatine", die ja schon einiges macht, z.B. autom. ACKs, soweit ich weiß) wo es sogar damit manchmal hakt.

Gruß, Joachim
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: frank am 15 September 2022, 12:44:53
hallo ansgar,

in deiner cul_hm ab zeile 3465:
      if ($mh{md} =~ m/^(HM-SEC-SC.*|ROTO_ZEL-STG-RM-FFK)$/s){# SCs - depending on FW version - do not accept ACK only. Especially if peered
        if (DOTRIGGERSTATEACK) {
          push @ack,$mh{shash},$mh{mNo}.'8002'.$ioId.$mh{src}.'0101'.((hex($mI[0])&1)?'C8':'00').'00';
        }
      }


damit wird das "zusätzliche" ack immer mit status 0xC8 gesendet, wenn der channel ungerade ist!!!
also immer falsch (da es 1-channel devices sind), wenn der status eigentlich 0x00 ist.
was soll hier dieser bit vergleich? was hab ich übersehen?

ich habe bei mir jetzt einfach
push @ack,$mh{shash},$mh{mNo}.'8002'.$ioId.$mh{src}.'0101'.$mI[2].'00';
gesetzt und die folgende log meldung ebenfalls angepasst
      Log3 $mh{devN},5,'CUL_HM '.$mh{devN}.' prep ACK for '.$mI[2];
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 15 September 2022, 22:10:33
Hallo Frank,

ich habe mal in meiner "Historie" geschaut.

Zitatpush @ack,$mh{shash},$mh{mNo}.'8002'.$ioId.$mh{src}.'0101'.((hex($mI[0])&1)?'C8':'00').'00';
stammte in Semantik nicht von mir.
Ursprünglich lautete die Zeile:
        push @ack,$mh{shash},$mh{mNo}."8002".$mh{dst}.$mh{src}."0101".((hex($mI[0])&1)?"C8":"00")."00";

Ich habe nur den Hashzugriff ein bischen optimiert. Ansonsten zu dem Zeitpunkt nicht über Sinn oder Unsinn der Bit 0 Unterscheidung nachgedacht, zumal ich es nicht testen konnte und dem Kommentar bezüglich Version nach auch nicht kann.
Ich weiss auch nicht, ob die betroffenen devices/FW Versionen was gesendet haben/senden, was diese Unterscheidung sinnvoll erscheinen ließ. Da müsstest Du bei Martin nachfragen.

Nach Deiner Begründung erscheint es merkwürdig???
Du kannst ansonsten wohl nur beobachten, ob Deine Änderung in der Usermasse auf Probleme stößt und dann ggf. mit Logging Beobachtungsdaten untersuchen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 15 September 2022, 22:34:17
Hallo Matthias,

mit WLAN fügst Du dem Zufallsprozess HM Empfang den weiteren Zufallsprozess WLAN Empfang hinzu.

Die tsculfw kann (ebenso wie auch andere HM IOs) nur begrenzt automatisch Antworten an devices senden, um von sich aus "in time" bleiben. Antworten von FHEM müssen auch rechtzeitig gesendet werden. Insbesondere Batterie betriebene devices schlafen sonst (zu) schnell wieder ein.

Wenn es nur darum geht, den Status von Sensoren, wie Temperatursensoren, zu empfangen und an FHEM zu schicken, mag die WLAN Lösung zufriedenstellend arbeiten.
Wenn es um Schalten oder Config geht, zeigen sich erst WLAN bedingte Verzögerungsprobleme auf dem Weg vom/zum IO.

Ich habe nichts dagegen, wenn Du mit Deiner WLAN-Anbindung für Dich zufriedenstellende Ergebnisse erzielst. (Für mich persönlich wären schon die von Dir genannten gelegentlichen Verbindungsverluste ein No Go.)

Supporten möchte ich es aber nicht, da der rechtzeitige Versand von HM Paketen ans IO nochmals problematischer wird. Die Info, dass WLAN im Spiel ist, kommt vom User dann ebenfalls zufällig. Und zu erwarten nach Analyse von Timingdaten nicht durch den User, nebst sinnlosen Grübeln, welchen Fehler denn der Programmierer gemacht haben könnte. Denn auch FHEM selbst kann Quelle von Timing Problemen sein.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 16 September 2022, 21:19:23
Hallo Frank,

ich habe Deine Änderung mal getestet und wie erwartet, ist es meinen HM-SEC-SC-2 mit Firmware 2.4 völlig schnuppe, ob ein 0101C800 Ack oder der zum Kontakt-Status passende gesendet wird.
Beim vorherigen Auto-Ack werden sie schon aufhören zu lauschen.

Hast Du ein zum Kommentar passendes Problem device oder anderes Logging zur Frage?

Gruß, Ansgar.

Edit: Die Log Zeile würde ich ganz eliminieren.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 17 September 2022, 08:56:16
Hallo Frank,

Martin hat den Code
      if ($md =~ m/HM-SEC-SC/){
        push @ack,$shash,$mNo."8002".$dst.$src."0101".((hex($mI[0])&1)?"C8":"00")."00";
      }
      else{
        push @ack,$shash,$mNo."8002$dst$src"."00";
      }

in Revision 5678 manifestiert.
In der Revision 5640 noch angedacht, weil auskommentiert:
#      if($mFlgH & 0x02){
        push @ack,$shash,$mNo."8002$dst$src"."00";
#      }
#      else{
#        push @ack,$shash,$mNo."8002".$dst.$src."0101".((hex($mI[0])&1)?"C8":"00")."00";
#      }

Das war gegen Ende April 2014.

Und ist wohl hierraus entstanden, was kurz davor war:
  elsif($ioId eq $dst){# if fhem is destination check if we need to react
    if($mTp =~ m/^4./ && $p =~ m/^(..)/ &&  #Push Button event
       (hex($mFlg)&0x20)){  #response required Flag
      my ($recChn) = (hex($1));# button number/event count
                # fhem CUL shall ack a button press
#      push @ack,$shash,$mNo."8002".$dst.$src."0101".(($recChn&1)?"C8":"00")."00";
      push @ack,$shash,$mNo."8002$dst$src"."00";
      Log3 $name,5,"CUL_HM $name prep ACK for $recChn";
    }
  }

in diesem Zusammenhang https://forum.fhem.de/index.php/topic,22571.0.html (https://forum.fhem.de/index.php/topic,22571.0.html) oder diesem https://forum.fhem.de/index.php/topic,22337.0.html (https://forum.fhem.de/index.php/topic,22337.0.html) und bestimmt diesem https://forum.fhem.de/index.php/topic,22688.0.html (https://forum.fhem.de/index.php/topic,22688.0.html).

Hier https://forum.fhem.de/index.php/topic,22688.msg163155.html#msg163155 (https://forum.fhem.de/index.php/topic,22688.msg163155.html#msg163155) kommt wohl der Kommentar her.
Und hier https://forum.fhem.de/index.php/topic,22688.msg189688.html#msg189688 (https://forum.fhem.de/index.php/topic,22688.msg189688.html#msg189688) der ROTO_ZEL-STG-RM-FFK.

Anscheinend ein Überbleibsel aus Stochern im Nebel.

Dein Vorschlag sieht sinnvoller aus, wurde offenbar nicht getestet.
Was sagt Dein Vergleichslogging?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: frank am 17 September 2022, 10:41:02
hallo ansgar,
ich verspüre tatendrang bei dir.  :)

nur mal kurz:
- echte probleme hatte ich wohl damit nicht.
- es war eher ein zufallsfund auf der suche nach einer erklärung für den ausfall der verbindung meines cul https://forum.fhem.de/index.php/topic,129073.msg1234142.html#msg1234142 (https://forum.fhem.de/index.php/topic,129073.msg1234142.html#msg1234142)

vorher, nachher über cul:
2022.09.15 10:19:53.067 4 : CUL_Parse: cul868 A 0C 1F A441 1DE620 1ACE1F 0104C80F -66.5
2022.09.15 10:19:53.070 5 : cul868: dispatch A0C1FA4411DE6201ACE1F0104C8::-66.5:cul868
2022.09.15 10:19:53.109 5 : cul868 sending As0A1F80021ACE1F1DE62000
2022.09.15 10:19:53.110 5 : CUL 1DE620 dly:58ms
2022.09.15 10:19:53.170 5 : DevIo_SimpleWrite cul868: As0A1F80021ACE1F1DE62000
2022.09.15 10:19:53.198 5 : cul868 sending As0D1F80021ACE1F1DE6200101C800
2022.09.15 10:19:53.199 5 : CUL 1DE620 dly:30ms
2022.09.15 10:19:53.230 5 : DevIo_SimpleWrite cul868: As0D1F80021ACE1F1DE6200101C800
2022.09.15 10:19:53.264 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 2F msg: 1F A4 41 1DE620 1ACE1F 0104C8
2022.09.15 10:19:53.267 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 1D msg: 1F 80 02 1ACE1F 1DE620 00
2022.09.15 10:19:53.272 0 : HMLAN_Parse: hmlan1 R:E1DE620   stat:0000 t:2FFE4855 d:FF r:FFC3     m:1F A441 1DE620 1ACE1F 0104C8
2022.09.15 10:19:53.275 0 : HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:2FFE48D8 d:FF r:FFD6     m:1F 8002 1ACE1F 1DE620 00
2022.09.15 10:19:53.278 0 : HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:2FFE4916 d:FF r:FFD6     m:1F 8002 1ACE1F 1DE620 0101C800
2022.09.15 10:19:53.284 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 1D msg: 1F 80 02 1ACE1F 1DE620 0101C800
2022.09.15 10:19:53.320 4 : CUL_Parse: cul868 A 0C 20 A041 1DE620 1A164B 0104C812 -65
2022.09.15 10:19:53.321 5 : cul868: dispatch A0C20A0411DE6201A164B0104C8::-65:cul868
2022.09.15 10:19:53.399 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 2F msg: 20 A0 41 1DE620 1A164B 0104C8
2022.09.15 10:19:53.403 0 : HMLAN_Parse: hmlan1 R:E1DE620   stat:0000 t:2FFE4950 d:FF r:FFC2     m:20 A041 1DE620 1A164B 0104C8
2022.09.15 10:19:53.445 4 : CUL_Parse: cul868 A 0E 20 8002 1A164B 1DE620 0101C8403208 -70
2022.09.15 10:19:53.446 5 : cul868: dispatch A0E2080021A164B1DE6200101C84032::-70:cul868
2022.09.15 10:19:53.495 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 42 msg: 20 80 02 1A164B 1DE620 0101C84032
2022.09.15 10:19:53.563 0 : HMLAN_Parse: hmlan1 R:E1A164B   stat:0000 t:2FFE49CE d:FF r:FFBE     m:20 8002 1A164B 1DE620 0101C84032
2022.09.15 10:19:53.645 4 : CUL_Parse: cul868 A 0D 21 A410 1A164B 1ACE1F 0601C84008 -70
2022.09.15 10:19:53.646 5 : cul868: dispatch A0D21A4101A164B1ACE1F0601C840::-70:cul868
2022.09.15 10:19:53.699 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 42 msg: 21 A4 10 1A164B 1ACE1F 0601C840
2022.09.15 10:19:53.703 0 : HMLAN_Parse: hmlan1 R:E1A164B   stat:0000 t:2FFE4A96 d:FF r:FFBE     m:21 A410 1A164B 1ACE1F 0601C840
2022.09.15 10:19:53.766 4 : CUL_Parse: cul868 A 0A 21 8002 1ACE1F 1A164B 0052 -33
2022.09.15 10:19:53.768 5 : cul868: dispatch A0A2180021ACE1F1A164B00::-33:cul868
2022.09.15 10:19:53.773 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 1A msg: 21 80 02 1ACE1F 1A164B 00
2022.09.15 10:19:55.318 4 : CUL_Parse: cul868 A 0C 21 A441 1DE620 1ACE1F 0105000C -68
2022.09.15 10:19:55.321 5 : cul868: dispatch A0C21A4411DE6201ACE1F010500::-68:cul868
2022.09.15 10:19:55.369 5 : cul868 sending As0A2180021ACE1F1DE62000
2022.09.15 10:19:55.370 5 : CUL 1DE620 dly:50ms
2022.09.15 10:19:55.421 5 : DevIo_SimpleWrite cul868: As0A2180021ACE1F1DE62000
2022.09.15 10:19:55.453 5 : cul868 sending As0D2180021ACE1F1DE6200101C800
2022.09.15 10:19:55.454 5 : CUL 1DE620 dly:26ms
2022.09.15 10:19:55.481 5 : DevIo_SimpleWrite cul868: As0D2180021ACE1F1DE6200101C800
2022.09.15 10:19:55.515 0 : HMLAN_Parse: hmlan1 R:E1DE620   stat:0000 t:2FFE511F d:FF r:FFC4     m:21 A441 1DE620 1ACE1F 010500
2022.09.15 10:19:55.520 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 30 msg: 21 A4 41 1DE620 1ACE1F 010500
2022.09.15 10:19:55.524 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 1D msg: 21 80 02 1ACE1F 1DE620 00
2022.09.15 10:19:55.528 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 1D msg: 21 80 02 1ACE1F 1DE620 0101C800
2022.09.15 10:19:55.539 0 : HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:2FFE51E2 d:FF r:FFD6     m:21 8002 1ACE1F 1DE620 0101C800
2022.09.15 10:19:55.663 4 : CUL_Parse: cul868 A 0C 22 A041 1DE620 1A164B 01050017 -62.5
2022.09.15 10:19:55.665 5 : cul868: dispatch A0C22A0411DE6201A164B010500::-62.5:cul868
2022.09.15 10:19:55.748 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 2F msg: 22 A0 41 1DE620 1A164B 010500
2022.09.15 10:19:55.751 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 42 msg: 22 80 02 1A164B 1DE620 0101000031
2022.09.15 10:19:55.792 0 : HMLAN_Parse: hmlan1 R:E1DE620   stat:0000 t:2FFE521B d:FF r:FFC0     m:22 A041 1DE620 1A164B 010500
2022.09.15 10:19:55.794 0 : HMLAN_Parse: hmlan1 R:E1A164B   stat:0000 t:2FFE5299 d:FF r:FFBF     m:22 8002 1A164B 1DE620 0101000031
2022.09.15 10:19:55.869 4 : CUL_Parse: cul868 A 0E 22 8002 1A164B 1DE620 01010000310B -68.5
2022.09.15 10:19:55.871 5 : cul868: dispatch A0E2280021A164B1DE6200101000031::-68.5:cul868

######################### repariert

2022.09.15 12:35:12.467 4 : CUL_Parse: cul868 A 0C 25 A441 1DE620 1ACE1F 0106C821 -57.5
2022.09.15 12:35:12.469 5 : cul868: dispatch A0C25A4411DE6201ACE1F0106C8::-57.5:cul868
2022.09.15 12:35:12.502 5 : cul868 sending As0A2580021ACE1F1DE62000
2022.09.15 12:35:12.504 5 : CUL 1DE620 dly:64ms
2022.09.15 12:35:12.569 5 : DevIo_SimpleWrite cul868: As0A2580021ACE1F1DE62000
2022.09.15 12:35:12.596 5 : cul868 sending As0D2580021ACE1F1DE6200101C800
2022.09.15 12:35:12.597 5 : CUL 1DE620 dly:31ms
2022.09.15 12:35:12.629 5 : DevIo_SimpleWrite cul868: As0D2580021ACE1F1DE6200101C800
2022.09.15 12:35:12.662 0 : HMLAN_Parse: hmlan1 R:E1DE620   stat:0000 t:307A3259 d:FF r:FFCE     m:25 A441 1DE620 1ACE1F 0106C8
2022.09.15 12:35:12.664 0 : HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:307A32DD d:FF r:FFD6     m:25 8002 1ACE1F 1DE620 00
2022.09.15 12:35:12.670 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 2F msg: 25 A4 41 1DE620 1ACE1F 0106C8
2022.09.15 12:35:12.673 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 1D msg: 25 80 02 1ACE1F 1DE620 00
2022.09.15 12:35:12.676 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 1D msg: 25 80 02 1ACE1F 1DE620 0101C800
2022.09.15 12:35:12.681 0 : HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:307A331B d:FF r:FFD6     m:25 8002 1ACE1F 1DE620 0101C800
2022.09.15 12:35:12.717 4 : CUL_Parse: cul868 A 0C 26 A041 1DE620 1A164B 0106C821 -57.5
2022.09.15 12:35:12.718 5 : cul868: dispatch A0C26A0411DE6201A164B0106C8::-57.5:cul868
2022.09.15 12:35:12.798 0 : HMLAN_Parse: hmlan1 R:E1DE620   stat:0000 t:307A3354 d:FF r:FFCD     m:26 A041 1DE620 1A164B 0106C8
2022.09.15 12:35:12.801 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 2E msg: 26 A0 41 1DE620 1A164B 0106C8
2022.09.15 12:35:12.843 4 : CUL_Parse: cul868 A 0E 26 8002 1A164B 1DE620 0101C8403705 -71.5
2022.09.15 12:35:12.845 5 : cul868: dispatch A0E2680021A164B1DE6200101C84037::-71.5:cul868
2022.09.15 12:35:12.945 0 : HMLAN_Parse: hmlan1 R:E1A164B   stat:0000 t:307A33D2 d:FF r:FFBD     m:26 8002 1A164B 1DE620 0101C84037
2022.09.15 12:35:12.970 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 43 msg: 26 80 02 1A164B 1DE620 0101C84037
2022.09.15 12:35:13.210 4 : CUL_Parse: cul868 A 0D 27 A410 1A164B 1ACE1F 0601C84004 -72
2022.09.15 12:35:13.211 5 : cul868: dispatch A0D27A4101A164B1ACE1F0601C840::-72:cul868
2022.09.15 12:35:13.268 0 : HMLAN_Parse: hmlan1 R:E1A164B   stat:0000 t:307A3540 d:FF r:FFBD     m:27 A410 1A164B 1ACE1F 0601C840
2022.09.15 12:35:13.288 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 43 msg: 27 A4 10 1A164B 1ACE1F 0601C840
2022.09.15 12:35:13.330 4 : CUL_Parse: cul868 A 0A 27 8002 1ACE1F 1A164B 0051 -33.5
2022.09.15 12:35:13.331 5 : cul868: dispatch A0A2780021ACE1F1A164B00::-33.5:cul868
2022.09.15 12:35:13.337 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 1A msg: 27 80 02 1ACE1F 1A164B 00
2022.09.15 12:35:17.716 4 : CUL_Parse: cul868 A 0C 27 A441 1DE620 1ACE1F 01070022 -57
2022.09.15 12:35:17.719 5 : cul868: dispatch A0C27A4411DE6201ACE1F010700::-57:cul868
2022.09.15 12:35:17.755 5 : cul868 sending As0A2780021ACE1F1DE62000
2022.09.15 12:35:17.757 5 : CUL 1DE620 dly:61ms
2022.09.15 12:35:17.819 5 : DevIo_SimpleWrite cul868: As0A2780021ACE1F1DE62000
2022.09.15 12:35:17.845 5 : cul868 sending As0D2780021ACE1F1DE62001010000
2022.09.15 12:35:17.846 5 : CUL 1DE620 dly:31ms
2022.09.15 12:35:17.879 5 : DevIo_SimpleWrite cul868: As0D2780021ACE1F1DE62001010000
2022.09.15 12:35:17.912 0 : HMLAN_Parse: hmlan1 R:E1DE620   stat:0000 t:307A46DC d:FF r:FFCA     m:27 A441 1DE620 1ACE1F 010700
2022.09.15 12:35:17.915 0 : HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:307A4760 d:FF r:FFD6     m:27 8002 1ACE1F 1DE620 00
2022.09.15 12:35:17.921 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 2E msg: 27 A4 41 1DE620 1ACE1F 010700
2022.09.15 12:35:17.924 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 1D msg: 27 80 02 1ACE1F 1DE620 00
2022.09.15 12:35:17.927 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 1D msg: 27 80 02 1ACE1F 1DE620 01010000
2022.09.15 12:35:17.932 0 : HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:307A479E d:FF r:FFD6     m:27 8002 1ACE1F 1DE620 01010000
2022.09.15 12:35:17.967 4 : CUL_Parse: cul868 A 0C 28 A041 1DE620 1A164B 01070024 -56
2022.09.15 12:35:17.969 5 : cul868: dispatch A0C28A0411DE6201A164B010700::-56:cul868
2022.09.15 12:35:18.046 0 : HMLAN_Parse: hmlan1 R:E1DE620   stat:0000 t:307A47D8 d:FF r:FFCA     m:28 A041 1DE620 1A164B 010700
2022.09.15 12:35:18.050 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 2E msg: 28 A0 41 1DE620 1A164B 010700
2022.09.15 12:35:18.094 4 : CUL_Parse: cul868 A 0E 28 8002 1A164B 1DE620 010100003907 -70.5
2022.09.15 12:35:18.095 5 : cul868: dispatch A0E2880021A164B1DE6200101000039::-70.5:cul868
2022.09.15 12:35:18.188 0 : HMLAN_Parse: hmlan1 R:E1A164B   stat:0000 t:307A4856 d:FF r:FFBE     m:28 8002 1A164B 1DE620 0101000039
2022.09.15 12:35:18.214 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 42 msg: 28 80 02 1A164B 1DE620 0101000039




jetzt fehlt noch ein ausfiltern anderer io, da diese das zusätzliche ack nicht senden, zb hmuart:
2022.09.15 09:32:29.015 4 : CUL_Parse: cul868 A 0C 1B A441 1DE620 1ACE1F 0102C842 -41
2022.09.15 09:32:29.016 5 : cul868: dispatch A0C1BA4411DE6201ACE1F0102C8::-41:cul868
2022.09.15 09:32:29.076 0 : HMLAN_Parse: hmlan1 R:E1DE620   stat:0000 t:2FD2E0C8 d:FF r:FFD5     m:1B A441 1DE620 1ACE1F 0102C8
2022.09.15 09:32:29.081 0 : HMUARTLGW hmuart1 recv: 01 05 01 00 27 msg: 1B A4 41 1DE620 1ACE1F 0102C8
2022.09.15 09:32:29.224 0 : HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:2FD2E143 d:FF r:FFCE     m:1B 8002 1ACE1F 1DE620 00
2022.09.15 09:32:29.229 4 : CUL_Parse: cul868 A 0A 1B 8002 1ACE1F 1DE620 0048 -38
2022.09.15 09:32:29.230 5 : cul868: dispatch A0A1B80021ACE1F1DE62000::-38:cul868
2022.09.15 09:32:29.265 4 : CUL_Parse: cul868 A 0C 1C A041 1DE620 1A164B 0102C840 -42
2022.09.15 09:32:29.266 5 : cul868: dispatch A0C1CA0411DE6201A164B0102C8::-42:cul868
2022.09.15 09:32:29.318 0 : HMUARTLGW hmuart1 send: 01 02 00 00 00 msg: 1B 80 02 1ACE1F 1DE620 0101C800
2022.09.15 09:32:29.321 0 : HMLAN_Parse: hmlan1 R:E1DE620   stat:0000 t:2FD2E1C3 d:FF r:FFD5     m:1C A041 1DE620 1A164B 0102C8
2022.09.15 09:32:29.324 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 26 msg: 1C A0 41 1DE620 1A164B 0102C8
2022.09.15 09:32:29.391 4 : CUL_Parse: cul868 A 0E 1C 8002 1A164B 1DE620 0101C84030F8 -78
2022.09.15 09:32:29.393 5 : cul868: dispatch A0E1C80021A164B1DE6200101C84030::-78:cul868
2022.09.15 09:32:29.474 0 : HMLAN_Parse: hmlan1 R:E1A164B   stat:0000 t:2FD2E241 d:FF r:FFBE     m:1C 8002 1A164B 1DE620 0101C84030
2022.09.15 09:32:29.498 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 40 msg: 1C 80 02 1A164B 1DE620 0101C84030
2022.09.15 09:32:29.522 4 : CUL_Parse: cul868 A 0D 1B 8002 1ACE1F 1DE620 0101C80048 -38
2022.09.15 09:32:29.523 5 : cul868: dispatch A0D1B80021ACE1F1DE6200101C800::-38:cul868


oder weisst du, wie man hmuart, hmlan überreden kann, ein ack zu senden, dass sie von selbst nicht senden?
sowas könnte ich an anderer stelle nämlich gut gebrauchen.  8)

eigentlich war mir ja dieses zusätzliche ack schon immer ein dorn im auge.
umso mehr, wenn nur der cul es kann und dieser sowieso nur wie ein 5. rad am wagen gemobt wird.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 17 September 2022, 13:38:05
Hallo Frank,

wäre es nicht noch logischer mit
          push @ack,$mh{shash},$mh{mNo}.'8002'.$ioId.$mh{src}.'01'$mI[1].$mI[2].'00';
zu reparieren? Das würde komplett den Status spiegeln.
Testest Du mit einem SC-2 Fimware 2.2? Sonst ist die Testaussage anscheinend nichtig.

Zitatjetzt fehlt noch ein ausfiltern anderer io, da diese das zusätzliche ack nicht senden, zb hmuart:
In sub HMUARTLGW_Write($$$) gibt es
if    ($mtype eq "02" && defined($hash->{Peers}{$dst}) &&
   length($msg) == 24 && $src eq $hash->{owner}) {
# Acks are generally send by HMUARTLGW autonomously
# Special
Log3($hash, 5, "HMUARTLGW ${name}: Skip ACK");
return;
}
elsif ($mtype eq "02" && defined($hash->{Peers}{$dst}) &&
   $src ne $hash->{owner}) {
Log3($hash, 0, "HMUARTLGW ${name}: Can't send ACK not originating from my hmId (firmware bug), please use a VCCU virtual device!");
return;
}


Auch in sub HMLAN_Write($$$)
    if (   $mtype eq "02" && $src eq $hash->{owner} && length($msg) == 24
        && defined $hash->{helper}{ids}{$dst}){
      # Acks are generally send by HMLAN autonomously
      # Special
      Log3 $hash, 5, "HMLAN: Skip ACK";
      return;
    }


Damit kannst Du ergebnisoffen experimentieren, wenn Du einfache Acks doppelt senden möchtest. Aber eben nur von der IO eigenen HMID.
Den InfoAck hat der hmuart1 ja anscheinend gesendet, nur eben viel zu spät:
2022.09.15 09:32:29.522 4 : CUL_Parse: cul868 A 0D 1B 8002 1ACE1F 1DE620 0101C80048 -38

denn das device hat schon vorher den nächsten gesendet:
2022.09.15 09:32:29.324 0 : HMUARTLGW hmuart1 recv: 01 05 00 00 26 msg: 1C A0 41 1DE620 1A164B 0102C8


Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 17 September 2022, 22:23:21
Hallo Frank,

bei motionDetector und motionAndBtn gibt es auch den merkwürdigen AckInfo im Code.

Bei meinem HM-SEN-MDIR-SM FW V1.6 ist AckInfo überflüssig, bzw. das device ist nach LED grün Status mit einfachem Ack glücklich. Und wiederholt auch nicht.
Er ist mit einem VCCU Button gepeert. Das Verhalten ist auch unabhängig von aesCommReq.
Mehr Testkandidaten habe ich jedoch nicht.

Wie ist Deine Erfahrungslage bei motionDetector und motionAndBtn devices?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: exocet01 am 18 September 2022, 12:45:09
Zitat von: noansi am 07 September 2022, 00:08:48
Hallo exocet01,

in Deinem Log Auszug ist außer der Initialisierung des CUL kein Sendebefehl zu sehen.
Ein Y Kommando sollte auftauchen, ohne wird auf jeden Fall nichts gesendet.

Gruß, Ansgar.

Hallo Ansgar,

habe jetzt nochmal getestet:
Einmal habe ich versucht das Rollo über das Somfy Gerät zu steuern und einmal direkt über RAW Message. Geht beides nicht. Woraufhin ich mal eine Gegenüberstellun der TSCUL FW (funktioniert nicht) und CUL FW (funktioniert) erstellt habe:

Somfy Log (TS_CULV3):

2022.09.18 11:09:13 4: SOMFY_set: Rollo_1 -> entering with mode :send: cmd :on:  arg1 ::  pos :0:
2022.09.18 11:09:13 4: SOMFY_set: handled command on --> move :on:  newState :0:
2022.09.18 11:09:13 5: SOMFY_set: handled for drive/udpate:  updateState :200:  drivet :0: updatet :27:
2022.09.18 11:09:13 4: SOMFY_UpdateState: Rollo_1 enter with  newState:0:   updatestate:200:   move:on:
2022.09.18 11:09:13 4: SOMFY_UpdateState: Rollo_1 after conversions  newState:0:  rounded:0:  stateTrans:open:
2022.09.18 11:09:13 4: SOMFY_sendCommand: Rollo_1 -> cmd :on:
2022.09.18 11:09:13 4: SOMFY_send Rollo_1 on: sAB4008C8000001
2022.09.18 11:09:13 5: SOMFY_send Rollo_1 enc key : AB  rolling code : 08C8
2022.09.18 11:09:13 4: SOMFY_set: Rollo_1 -> update state in 27 sec
2022.09.18 11:09:16 4: SOMFY_TimedUpdate

Somfy Log (CULV3):
2022.09.18 01:39:29 4: SOMFY_set: Rollo_1 -> entering with mode :send: cmd :on:  arg1 :200:  pos :0:
2022.09.18 01:39:29 4: SOMFY_set: handled command on --> move :on:  newState :0:
2022.09.18 01:39:29 5: SOMFY_set: handled for drive/udpate:  updateState :200:  drivet :0: updatet :27:
2022.09.18 01:39:29 4: SOMFY_UpdateState: Rollo_1 enter with  newState:0:   updatestate:200:   move:on:
2022.09.18 01:39:29 4: SOMFY_UpdateState: Rollo_1 after conversions  newState:0:  rounded:0:  stateTrans:open:
2022.09.18 01:39:29 4: SOMFY_sendCommand: Rollo_1 -> cmd :on:
2022.09.18 01:39:29 4: SOMFY_send Rollo_1 on 200: sA74008C4000001
2022.09.18 01:39:29 5: SOMFY_send Rollo_1 enc key : A7  rolling code : 08C4
2022.09.18 01:39:29 4: SOMFY_set: Rollo_1 -> update state in 27 sec
2022.09.18 01:39:30 4: SOMFY Parse: Rollo_1 msg: YsA74808C4010000  --> 40-on   --> io is CUL
2022.09.18 01:39:32 4: SOMFY_TimedUpdate


RAW Message:
Der Befehl funktionierte nicht mit TSCUL FW. Nachdem ich aber auf CUL FW zurück flashte funktionierte er:

TSCUL Log:
ZitatTSCUL Log:
2022-09-18_11:16:04 CUL_0 raw YsAB4008C8000001
2022-09-18_11:31:48 CUL_0 Ints_per_sec: SI: 267.36030  TI: 30.12951  S: 81.89291  L: 11.94423  F: 17.18771  M: 2.77147

Global Log:
2022.09.18 11:16:05 4: SOMFY Parse: Rollo_1 msg: YsAB4808C8010000  --> 40-on   --> io is TSCUL

Ich hänge auch nochmal ein Bild von der Device Konfiguration an.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 18 September 2022, 14:19:44
Hallo exocet01,

wenn Du loggst, dann bitte auch mit dem CUL auf verbose 5. Sonst kann ich nicht sehen, was an den CUL raus gegangen ist und was von ihm kommt.

Dann fällt mir noch auf, dass Du relativ viele Interrupts/s hast und damit relativ viel Störfeuer oder Rauschen empfängst.
Versuch mal, beim TSCUL CCAmode auf 0 zu setzen, nicht, dass es an Kanalbelegungserkennung scheitert.
Dafür würde auch sprechen, dass in Deinem SOMFY Log keine Rückmeldung zur Sendenachricht zu sehen ist.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 18 September 2022, 15:11:26
Hallo exocet01,

versuch es bitte mal mit der 00_TSCUL.pm aus dem Anhang.
Das Y "verschwindet" bereits in der alten, so dass der CUL schon nur s... statt Ys... zu sehen bekommt.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: exocet01 am 19 September 2022, 21:22:26
jetzt sieht das Log so aus (das Y kommt jetzt) und CCAmode ist auf 0:
Global Log:
2022.09.19 21:02:23 4: WEB_192.168.178.33_55697 POST /fhem?cmd.Rollo_1=set%20Rollo_1%20auf&XHR=1&fwcsrf=csrf_164952049103182&fw_id=99; BUFLEN:0
2022.09.19 21:02:23 5: Cmd: >set Rollo_1 auf<
2022.09.19 21:02:23 4: SOMFY_set: Rollo_1 -> entering with mode :send: cmd :off:  arg1 ::  pos :200:
2022.09.19 21:02:23 4: SOMFY_set: handled command off --> move :off:  newState :200:
2022.09.19 21:02:23 5: SOMFY_set: handled for drive/udpate:  updateState :0:  drivet :0: updatet :29:
2022.09.19 21:02:23 4: SOMFY_UpdateState: Rollo_1 enter with  newState:200:   updatestate:0:   move:off:
2022.09.19 21:02:23 4: SOMFY_UpdateState: Rollo_1 after conversions  newState:200:  rounded:200:  stateTrans:closed:
2022.09.19 21:02:23 5: Starting notify loop for Rollo_1, 4 event(s), first is closed
2022.09.19 21:02:23 5: createNotifyHash
2022.09.19 21:02:23 5: Starting notify loop for Rolladenautomatik, 1 event(s), first is Rollo_1_PosValue: 200
2022.09.19 21:02:23 5: End notify loop for Rolladenautomatik
2022.09.19 21:02:23 5: Starting notify loop for Rolladenautomatik, 1 event(s), first is manual
2022.09.19 21:02:23 5: End notify loop for Rolladenautomatik
2022.09.19 21:02:23 5: Compute sunrise/sunset for latitude 48.30725403298442 , longitude 11.935535784027014
2022.09.19 21:02:23 5: Compute sunrise/sunset for latitude 48.30725403298442 , longitude 11.935535784027014
2022.09.19 21:02:23 5: End notify loop for Rollo_1
2022.09.19 21:02:23 4: SOMFY_sendCommand: Rollo_1 -> cmd :off:
2022.09.19 21:02:23 4: SOMFY_send Rollo_1 off: sA62008D3000001
2022.09.19 21:02:23 5: SOMFY_send Rollo_1 enc key : A6  rolling code : 08D3
2022.09.19 21:02:23 4: TSCUL_Write: CUL_0 sending YsA62008D3000001
2022.09.19 21:02:23 4: SOMFY_set: Rollo_1 -> update state in 29 sec
2022.09.19 21:02:23 4: WEB: /fhem?cmd.Rollo_1=set%20Rollo_1%20auf&XHR=1&fwcsrf=csrf_164952049103182&fw_id=99 / RL:20 / text/plain; charset=UTF-8 / Content-Encoding: gzip
/ Cache-Control: no-cache, no-store, must-revalidate
2022.09.19 21:02:23 5: Starting notify loop for Rollo_1, 2 event(s), first is ASC_ShuttersLastDrive: manual
2022.09.19 21:02:23 5: End notify loop for Rollo_1
2022.09.19 21:02:24 5: Starting notify loop for myReadings, 3 event(s), first is kernel: 5.10.103-v7+
2022.09.19 21:02:24 5: End notify loop for myReadings
2022.09.19 21:02:24 5: TSCUL_Read CUL_0: /YsA62908D3010000
2022.09.19 21:02:24 4: TSCUL_Parse: CUL_0 YsA62908D3010000
2022.09.19 21:02:24 5: CUL_0: dispatch YsA62908D3010000
2022.09.19 21:02:24 4: SOMFY Parse: Rollo_1 msg: YsA62908D3010000  --> 20-off   --> io is TSCUL
2022.09.19 21:02:24 5: Starting notify loop for Rollo_1, 4 event(s), first is received: 20
2022.09.19 21:02:24 5: End notify loop for Rollo_1
2022.09.19 21:02:26 4: SOMFY_TimedUpdate


Aber trotz Verbose auf 5 wird im CUL Log kaum etwas geschrieben:
2022-09-19_20:57:46 CUL_0 Xmit-Events: disconnected:1
2022-09-19_20:57:46 CUL_0 prot_disconnected: last
2022-09-19_20:57:48 CUL_0 cond: non-HM
2022-09-19_20:57:48 CUL_0 Xmit-Events: non-HM:1 disconnected:1
2022-09-19_20:57:48 CUL_0 prot_non-HM: last
2022-09-19_20:57:48 CUL_0 Initialized
2022-09-19_20:57:48 CUL_0 CONNECTED
2022-09-19_20:57:58 CUL_0 cond: non-HM
2022-09-19_20:57:58 CUL_0 Xmit-Events: non-HM:2 disconnected:1
2022-09-19_20:57:58 CUL_0 prot_non-HM: last
2022-09-19_20:59:05 CUL_0 CONNECTED

Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: frank am 20 September 2022, 12:32:31
hallo ansgar,

Zitat von: noansi am 17 September 2022, 13:38:05
wäre es nicht noch logischer mit
          push @ack,$mh{shash},$mh{mNo}.'8002'.$ioId.$mh{src}.'01'$mI[1].$mI[2].'00';
zu reparieren? Das würde komplett den Status spiegeln.
im ackinfo ist das 2. byte aber hauptsächlich der channel => cul_hm_parsecommon/ackinfo.
ist meinem sc-1/fw2.0 aber auch egal, was da kommt.

ZitatDamit kannst Du ergebnisoffen experimentieren, wenn Du einfache Acks doppelt senden möchtest. Aber eben nur von der IO eigenen HMID.
danke fürs aufspüren der code abschnitte. die io eigene hmid ist an der stelle, die mich interessiert, leider nicht immer angesagt. deshalb mache ich es zur zeit nur mit cul.

ZitatDen InfoAck hat der hmuart1 ja anscheinend gesendet, nur eben viel zu spät:
oh ja, habe ich überssehen. der ack kommt wirklich spät, auch über hmlan.

wenn ich die timestamps vom hmlan nehme (t: ...), kommt das 1.ack 123ms nach dem trigger und das ackinfo weitere 278ms nach dem 1. ack, total 401ms nach dem trigger.
auch den send eintrag vom hmuart finde ich schon zu spät. bei "normalen" cmds kommt das "sofort" nach dem auslöser und hmlan/hmuart verzögern dann das senden bis die autonomen acks beendet sind.
ist diese verzögerung auch bei deinem hmuart zu sehen? diese verzögerung muss doch durch fhem kommen, oder?
2022.09.19 11:06:53.856 0 : HMLAN_Parse: hmlan1 R:E1DE620   stat:0000 t:44C3B420 d:FF r:FFD2     m:38 A441 1DE620 1ACE1F 010EC8
2022.09.19 11:06:53.859 0 : HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:44C3B49B d:FF r:FFD0     m:38 8002 1ACE1F 1DE620 00
2022.09.19 11:06:54.011 0 : HMUARTLGW hmuart1 send: 01 02 00 00 00 msg: 38 80 02 1ACE1F 1DE620 010EC800
2022.09.19 11:06:54.157 0 : HMLAN_Parse: hmlan1 R:E1ACE1F   stat:0000 t:44C3B5B1 d:FF r:FFD0     m:38 8002 1ACE1F 1DE620 010EC800



ZitatWie ist Deine Erfahrungslage bei motionDetector und motionAndBtn devices?
motion devices habe ich leider nicht.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 21 September 2022, 22:02:51
Hallo exocet01,

ok, Ys... wird jetzt an den CUL geschickt, wie in Deinem oberen Log zu sehen ist.
2022.09.19 21:02:23 4: TSCUL_Write: CUL_0 sending YsA62008D3000001
Und auch die Antwort kommt, vom CUL.
2022.09.19 21:02:24 5: TSCUL_Read CUL_0: /YsA62908D3010000
2022.09.19 21:02:24 4: TSCUL_Parse: CUL_0 YsA62908D3010000

Demnach hat er auch was gesendet.

Aber das Rollo reagiert nicht, weil mir noch ein Fehler beim Senden des letzten Bytes aufgefallen ist.

Im Anhang eine neue Firmwaredatei und die geänderten FHEM Module, damit Du für den SlowRf Test auf Stand kommst.

Versuch es damit bitte nochmal.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 21 September 2022, 22:58:49
Hallo Frank,

Zitatdanke fürs aufspüren der code abschnitte. die io eigene hmid ist an der stelle, die mich interessiert, leider nicht immer angesagt. deshalb mache ich es zur zeit nur mit cul.
An Einschränkungen in der HMUARTLGW kann ich leider nichts ändern. HMID ständig anpassen? Ob das gut geht?

Zitatdiese verzögerung muss doch durch fhem kommen, oder?
In 00_HMUARTLGW.pm gibt es in HMUARTLGW_Parse($$$$)
if ($modules{CUL_HM}{defptr}{$src}) {
my $flgh = hex($flags);
my $wait = 0.100;
$wait += 0.200 if ($flgh & (1 << 5) && # BIDI
   $modules{CUL_HM}{defptr}{$src}->{IODev}->{TYPE} =~ m/^(?:TSCUL|HMUARTLGW)$/s);
$wait -= 0.044 if ($flgh & (1 << 6)); # received from Repeater

$wait -= $hash->{Helper}{RoundTrip}{Delay}
if (defined($hash->{Helper}{RoundTrip}{Delay}));

if ($wait > 0) {
my $nextSend = $recvtime + $wait;
$modules{CUL_HM}{defptr}{$src}{helper}{io}{nextSend} = $nextSend
if (!defined($modules{CUL_HM}{defptr}{$src}{helper}{io}{nextSend})   ||
$nextSend < $modules{CUL_HM}{defptr}{$src}{helper}{io}{nextSend} ||
($recvtime - $modules{CUL_HM}{defptr}{$src}{helper}{io}{nextSend}) > 0.09); # not allready set by previous IO
}
}

Was ich als Verzögerungsquelle verstanden habe. Also 300ms + sonstiger Verzögerungen bis dahin vom Trigger Empfang + weitere Verarbetung des {nextSend} bis Senden nach dem Auto-Ack..

Zitatist diese verzögerung auch bei deinem hmuart zu sehen?
Mein Pi ist derzeit und normalerweise mit SCC bestückt. Ich teste/nutze lieber meine Firmware. Daran kann ich was ändern. ;)

Zitatim ackinfo ist das 2. byte aber hauptsächlich der channel => cul_hm_parsecommon/ackinfo.
Stimmt auffallend. Aber der AckInfo müsste sich ja eigentlich auf einen ggf. gepeerten Channel der VCCU beziehen. Warum soll konstant 1 richtig sein?
Lässt sich nur mit einer der Problem FW Versionen genauer experimentell bestimmen, womit sie zufrieden wäre.

Zitatist meinem sc-1/fw2.0 aber auch egal, was da kommt.
Ich hatte V2.2 als die problematischste aus der Historie verstanden.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: exocet01 am 23 September 2022, 20:07:25
Zitat von: noansi am 21 September 2022, 22:02:51
Hallo exocet01,

ok, Ys... wird jetzt an den CUL geschickt, wie in Deinem oberen Log zu sehen ist.
2022.09.19 21:02:23 4: TSCUL_Write: CUL_0 sending YsA62008D3000001
Und auch die Antwort kommt, vom CUL.
2022.09.19 21:02:24 5: TSCUL_Read CUL_0: /YsA62908D3010000
2022.09.19 21:02:24 4: TSCUL_Parse: CUL_0 YsA62908D3010000

Demnach hat er auch was gesendet.

Aber das Rollo reagiert nicht, weil mir noch ein Fehler beim Senden des letzten Bytes aufgefallen ist.

Im Anhang eine neue Firmwaredatei und die geänderten FHEM Module, damit Du für den SlowRf Test auf Stand kommst.

Versuch es damit bitte nochmal.

Gruß, Ansgar.
Funktioniert leider nicht. Rollos reagieren nicht
Aus dem CUL log kommt immer noch nichts und das ander log zeigt:
2022.09.23 19:45:59 4: SOMFY_set: Rollo_1 -> entering with mode :send: cmd :on:  arg1 ::  pos :200:
2022.09.23 19:45:59 4: SOMFY_set: handled command on --> move :on:  newState :200:
2022.09.23 19:45:59 5: SOMFY_set: handled for drive/udpate:  updateState ::  drivet :0: updatet :0:
2022.09.23 19:45:59 4: SOMFY_UpdateState: Rollo_1 enter with  newState:200:   updatestate:<undef>:   move:on:
2022.09.23 19:45:59 4: SOMFY_UpdateState: Rollo_1 after conversions  newState:200:  rounded:200:  stateTrans:closed:
2022.09.23 19:45:59 4: SOMFY_sendCommand: Rollo_1 -> cmd :on:
2022.09.23 19:45:59 4: SOMFY_send Rollo_1 on: sA04008DD000001
2022.09.23 19:45:59 5: SOMFY_send Rollo_1 enc key : A0  rolling code : 08DD
2022.09.23 19:45:59 4: TSCUL_Write: CUL_0 sending YsA04008DD000001
2022.09.23 19:46:00 5: TSCUL_Read CUL_0: /YsA04708DD010000

2022.09.23 19:46:00 4: TSCUL_Parse: CUL_0 YsA04708DD010000
2022.09.23 19:46:00 5: CUL_0: dispatch YsA04708DD010000
2022.09.23 19:46:00 4: SOMFY Parse: Rollo_1 msg: YsA04708DD010000  --> 40-on   --> io is TSCUL
2022.09.23 19:48:19 5: TSCUL_Read CUL_0: /CiE717221A56B3039B09C5024D391304FF

2022.09.23 19:51:42 3: set CUL_0 raw YsA04008DD000001
2022.09.23 19:51:43 5: TSCUL_Read CUL_0: /YsA04708DD010000

2022.09.23 19:51:43 4: TSCUL_Parse: CUL_0 YsA04708DD010000
2022.09.23 19:51:43 5: CUL_0: dispatch YsA04708DD010000
2022.09.23 19:51:43 4: SOMFY Parse: Rollo_1 msg: YsA04708DD010000  --> 40-on   --> io is TSCUL


Auffällig ist das mein 868 MHz CUL (TSCUL) FWV0.39 jetzt disconnected anzeigt

Gruß
Eckart
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 23 September 2022, 21:05:38
Hallo Eckart,

ok, danke für den Test. Da muss ich wohl nochmal über SOMFY intensiver drüber schauen. Vermutlich liegts noch am letzten Bit, mal sehen.

ZitatAus dem CUL log kommt immer noch nichts und das ander log zeigt:
Dein CUL Log zeigt auch nur Events von Readings (für das aktuelle Problem derzeit nicht von Bedeutung). Nicht aber Log Einträge, die im Code erzeugt werden. Die landen im fhem log.
Ich sehe in Deinen "anderen" Log Daten, was ich zur CUL Kommunikation sehen will, das ist ok.

ZitatAuffällig ist das mein 868 MHz CUL (TSCUL) FWV0.39 jetzt disconnected anzeigt
Das ist korrekt. Die TSCUL aus der zip mag V0.40 bis V0.42. Jedoch nicht mehr die V0.39. Leider hast Du zu spät Feedback gegeben, als dass ich das noch mit meinen alten Ständen hätte in Einklang bringen können. War mir nich klar, dass Du auch einen 868 MHz CUL parallel hast.

Geh erst mal wieder auf die vorherigen Dateien und Standard culfw für den 433 Testkandidaten zurück.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 24 September 2022, 21:57:54
Hallo Eckart,

im Anhang eine neue Testfirmware. Ich habe ihr eine VTS 0.40 verpasst, obwohl sie eigentlich eine VTS 0.41 ist, damit Du mit den älteren FHEM Modulen Somfy testen kannst. Also bitte auch nur dafür verwenden und nicht etwa für Deinen 868er.

Ich bin diesmal optimistischer, dass es besser klappt. Die Manchesterumsetzung hatte ihre Tücken.

Nebenbei habe ich noch bemerkt, dass sowohl in der Standard culfw, als auch in der a-culfw die frame-Pause zwischen den Wiederholungen viel zu kurz ausfällt, wegen fehlender Klammern in der betreffenden Sourcecode Zeile.
my_delay_us(30415 + ((frame[6] >> 7) & 1) ? 0 : somfy_rts_interval_half);
Macht nicht in somfy_rts.c das von
my_delay_us(30415 + (((frame[6] >> 7) & 1) ? 0 : somfy_rts_interval_half));
erwartete (falls Rudolf und Björn hier mal rein schauen).
Scheint, Deine Rollos aber anscheinend wenig zu stören.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: exocet01 am 24 September 2022, 22:51:47
Hallo Ansgar,

  :) Es funktioniert einwandfrei! Super!
Bin total Happy

Viele Grüße
Eckart
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 24 September 2022, 23:01:57
Hallo Eckart,

schön. :) Du bist wohl einer der wenigen, der jetzt noch die Rolläden laufen lässt.  ;D

Danke für's geduldige Testen.

Berichte bitte, ob es über einen längeren Testzeitraum Unterschiede in der Schaltzuverlässigkeit oder auch Reichweite gibt.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 25 September 2022, 16:12:33
Hallo Eckart,

im Anhang noch eine neue als V0.40 "getarnte" Version der Firmware, damit auch der IT Empfang wieder klappt.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: exocet01 am 25 September 2022, 18:51:45
Hallo Ansgar,

Funktioniert leider nicht. Habe mal Autocreate aktiviert und meine IT STeckdose per Handsender eingeschaltet/ausgeschaltet. Das Device wurde in FHEM nicht angelegt.

Gruß
Eckart
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 25 September 2022, 19:25:06
Hallo Eckart,

kennst Du das IT Protokoll und clock des IT Handsenders?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: exocet01 am 25 September 2022, 20:14:40
Hi,

nicht genau, aber ich hatte mich vor einiger Zeit mal hingesetzt und alle Codes ausprobiert. Folgender Config (siehe Bild) funktioniert bei mir. Also: Wenn ich händisch definiere kann ich auch das Gerät über deine FW ansprechen.

Gruß
Eckart
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 27 September 2022, 22:16:19
Hallo Eckart,

prinzipiell hat der IT V1 Empfang im letzten Stand funktioniert. Allerdings gibt es einen Verwechslungsbereich mit IT V3 und HEEU, abhängig vom Timing der Fernbedienung.

Im Anhang eine neue als VTS 0.40 "getarnte" Version zum Testen.

Wäre schön, wenn Du auch IT V3 und HEEU Geräte hättest, denn ich habe für die die Timing Tolereanz deutlich eingeengt und Zusatzcode, um ggf. doch noch IT V1 zu interpretiern.

Der Zusatzcode dafür hat natürlich das Flash Limit gerissen und ich habe XLED deswegen weg gelassen. Damit ist LED Blinken nur noch "langweilig".  ;)

Nur mit den neueren FHEM Modulen und raw X29, sowie verbose 4 könntest Du auch noch das Timing raus bekommen. Dann kommt so was in das fhem Log:
2022.09.27 21:00:26.922 4: TSCUL_Parse: PIG2_WS433 raw SlowRf:
H 0 - s0
H 376 L896 s0
H 880 L328 s0
H 264 L880 s1
H 304 L864 s0
H 304 L872 s1
H 912 L312 s1
H 264 L920 s1
H 896 L256 s0
H 328 L872 s1
H 296 L864 s0
H 304 L904 s1
H 304 L856 s1
H 304 L912 s1
H 296 L872 s1
H 296 L880 s1
H 904 L320 s1
H 264 L912 s3
H 896 L264 s3
H 320 L872 s3
H 880 L296 s3
H 296 L912 s3
H 304 L856 s3
H 304 L912 s3
H 840 L312 s3.
2022.09.27 21:00:26.973 4: TSCUL_Parse: PIG2_WS433 raw SlowRf:
H 320 L9160 s0
H 312 L864 s2
H 880 L312 s5
H 320 L872 s5
H 304 L864 s5
H 304 L872 s5
H 904 L320 s5
H 264 L912 s5
H 896 L264 s5
H 320 L872 s5
H 296 L864 s5
H 304 L912 s5
H 296 L864 s5
H 296 L912 s5
H 296 L872 s5
H 296 L880 s5
H 904 L320 s5
H 256 L920 s5
H 896 L264 s5
H 320 L872 s5
H 896 L296 s5
H 288 L864 s5
H 304 L912 s5
H 296 L864 s5
H 888 L312 s5.
2022.09.27 21:00:26.984 4: TSCUL_Parse: PIG2_WS433 i4501513A -45

Die zweite Nachricht wird an der darin enthaltenen Pause erkannt.
itclock wäre dann aus der Pause
H 320 L9160 s0
als Summe von H und L geteilt durch 32 relativ genau rauszulesen. In diesem Fall also (320+9160)/32 = 296.xx, was ich auch zum Senden verwendet habe.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: exocet01 am 28 September 2022, 22:04:22
Hi Ansgar,

also jetzt funktioniert es öfter mit der Erkennung, jedoch nur sehr sporadisch. Bekomme im Log immer wieder die Fehlermeldung:
2022-09-28_21:53:19 CUL_0 UNKNOWNCODE i050514
2022-09-28_21:53:19 CUL_0 UNKNOWNCODE i0575d5
2022-09-28_21:53:21 CUL_0 UNKNOWNCODE i050514
2022-09-28_21:53:21 CUL_0 UNKNOWNCODE i0575d5
2022-09-28_21:53:22 CUL_0 UNKNOWNCODE i050515
2022-09-28_21:53:23 CUL_0 UNKNOWNCODE i0575d5


Ein einziges mal habe ich es geschafft es anscheinend vollständig anzulegen (siehe Bild). Timing habe ich noch nicht geprüft. Evtl. macht es Sinn einfach eine IT V3 Dose zu kaufen...
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 28 September 2022, 23:03:23
Hallo Eckart,

die Interrupts/s beim CUL können auch noch ein Indikator sein. Versuch mal bei dem CUL set agcMaxDVGA 2 statt der Default 0.

Übrigens, statt der Bilder wäre es besser, ein list vom device in Code Tags zu posten, also list IT_00FF00FF0F für Dein IT device.

Ein list vom CUL wäre dann auch mal ganz gut.

Hast Du mit dem angelegten Device auch mal gesendet?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: exocet01 am 29 September 2022, 19:56:05
Hi,

mein IT Device hatte ich wieder gelöscht um wieder zu testen ob es nochmal erkannt wird. Aber irgendwie geht jetzt gar nichts mehr.
Hier mein list CUL_=:
Internals:
   CMDS       ABCFGJKRUVWXYehiltx
   CUL_0_MSGCNT 420
   CUL_0_TIME 2022-09-29 19:47:43
   Clients    STACKABLETS:STACKABLE:TSCUL_WS:TSCUL_NC7427:IT:CUL_FHTTK:CUL_HOERMANN:TSCUL_TX:CUL_IR:SOMFY:Revolt:ESA2000:TSCUL_RFR:TSCUL_EM:BS:USF1000:FS20:FHT.*:TSKS300:TSHMS:FS20V:UNIRoll:CUL_TCM97001:CUL_REDIRECT
   DEF        /dev/ttyACM0@12000000 1034
   DeviceName /dev/ttyACM0@12000000
   FD         4
   FHTID      1034
   FUUID      632f6ca9-f33f-d1ce-0914-e78649c00cf14b92
   NAME       CUL_0
   NR         89
   PARTIAL   
   RAWMSG     i0575d5
   RSSI       -27.5
   ReReadTO   0.002
   STATE      Initialized
   TYPE       TSCUL
   VERSION    VTS 0.40 CUL433
   VERSION_HW CUL_V3.4_0017
   VERSION_TS yes AES ChTblSize:209
   XmitOpen   0
   devioNoSTATE 1
   eventCount 408
   initString XP1C
X21
AM5
AHF11034
   MatchList:
     A:TSCUL_WS ^K[\dA-F]....
     B:TSCUL_NC7427 ^n..........
     C:IT       ^i.(?::.|.....)
     D:CUL_FHTTK ^T[\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F]
     E:CUL_HOERMANN ^R..........
     F:TSCUL_TX ^TX[A-F89].........
     G:CUL_IR   ^I............
     H:SOMFY    ^Y[r|t|s]:?[\dA-F]+
     I:Revolt   ^r......................$
     J:ESA2000  ^S................................$
     K:TSCUL_RFR ^[\dA-F][\dA-F][\dA-F][\dA-F]~
     L:TSCUL_EM ^E0.0[\dA-F]......
     M:FS20V    ^81..(?:04|0c)..0101a001......00[89a-f]...
     N:BS       ^81..(?:04|0c)..0101a001a5cf
     O:USF1000  ^81..(?:04|0c)..0101a001a5ceaa00....
     P:FS20     ^81..(?:04|0c)..0101a001
     Q:FHT      ^81..(?:04|09|0d)..(?:0909a001|83098301|c409c401)..
     R:TSKS300  ^810d04..4027a001
     T:TSHMS    ^810e04......a001
     U:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     V:CUL_TCM97001 ^s[\dA-F]+
     W:CUL_REDIRECT ^o
     Y:STACKABLETS ^\*
     Z:STACKABLE ^\*
   READINGS:
     2022-09-29 19:48:52   SlowRfconf      freq:433.920MHz freqOffs:0.000kHz bWidth:325kHz freqIF:203.12kHz rAmpl:42dB sens:12dB dRate:2.461kBit/s
agcPrio:0 agcWait:16 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:0 AGC_FREEZE:0
CCAmode:0 csRelThr:10dB csAbsThr:7dB  peakfilter:88
     2022-09-29 19:48:52   Xmit-Events     non-HM:12 disconnected:3
     2022-09-29 19:48:52   ccconf          freq:433.920MHz freqOffs:0.000kHz bWidth:325kHz freqIF:203.12kHz rAmpl:42dB sens:12dB dRate:2.461kBit/s
agcPrio:0 agcWait:16 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:0 AGC_FREEZE:0
CCAmode:0 csRelThr:10dB csAbsThr:7dB
     2022-09-29 19:47:22   cmds             A B C F G J K R U V W X Y e h i l t x
     2022-09-29 19:48:52   cond            non-HM
     2022-09-29 19:48:52   peakfilter      88 µs
     2022-09-29 19:47:07   prot_disconnected last
     2022-09-29 19:48:52   prot_non-HM     last
     2022-09-29 19:47:24   state           Initialized
   helper:
     ChkPart    0
     RA_Timeout 0
     SVTS       1
     VTS        1
     VTS_ACK    1
     VTS_AES    1
     nRec       0
     recAlive   1
     recd       1
     DEVIOTS:
       RXfailTO   
     HM:
       ChTblSize  209
       HMactive   0
       hmCrdts    9
       ChTbl:
     cnd:
       250        12
       253        3
     hmLog:
       Resolve    1
       IDs:
     q:
       HMcndN     250
       answerPend 0
       hmLanQlen  1
     ref:
       ioBR       3840
       lHMt       4294967295
       lSys       1750793717.38055
       pngLm      80
       scF        1
Attributes:
   icon       cul_cul
   rfmode     SlowRF
   verbose    0


Habe den Handsende mal umgestellt (von A auf B) ohne dass ich eine entsprechende Steckdose dran habe und habe auf den an und aus Knopf gedrückt: Es wurden von Autocreate 2 devices angelegt:

Internals:
   00         f0
   CFGFN     
   DEF        F0FF00FF0F FF F0
   FUUID      6335de37-f33f-d1ce-d208-494c467524056dcb
   NAME       IT_F0FF00FF0F
   NR         584
   STATE      ???
   TYPE       IT
   XMIT       f0ff00ff0f
   XMITdimdown 00
   XMITdimup  00
   XMITon     ff
   CODE:
     1          f0ff00ff0f
   READINGS:
     protocol:
       VAL        V1
Attributes:
   room       IT


Internals:
   00         f0
   CFGFN     
   DEF        F0FFF1FF1F FF F0
   FUUID      6335de37-f33f-d1ce-f3cc-df9ac817944b0dc4
   NAME       IT_F0FFF1FF1F
   NR         585
   STATE      ???
   TYPE       IT
   XMIT       f0fff1ff1f
   XMITdimdown 00
   XMITdimup  00
   XMITon     ff
   CODE:
     1          f0fff1ff1f
   READINGS:
     protocol:
       VAL        V1
Attributes:
   room       IT


und hier ein Log für das eigendliche Geräte das nicht angelegt wurde:
2022.09.29 20:36:18 4: TSCUL_Parse: CUL_0 i0575D523 -56.5
2022.09.29 20:36:18 5: CUL_0: dispatch i0575d5
2022.09.29 20:36:18 4: CUL_0 IT: message "i0575d5" (7)
2022.09.29 20:36:18 4: CUL_0 IT: msgcode "00FFF1FF1FFF" (12) bin = 000001010111010111010101
2022.09.29 20:36:18 5: CUL_0 IT: V1 housecode = 00FFF1FF1F  onoffcode = FF
2022.09.29 20:36:18 3: CUL_0: Unknown code i0575d5, help me!
2022.09.29 20:36:24 5: TSCUL_Read CUL_0: /Ci5800E102DDBC048898E82286441304FD
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 29 September 2022, 23:15:00
Hallo Eckart,

ist Dir klar, dass Du für autocreate beim IT device 2 mal innerhalb von 30 Sekunden die On Taste an der Fernbedienung drücken musst?

Du scheinst auch recht dicht am CUL zu drücken, meint der RSSI. Nimm mal was mehr Abstand.

agcMaxDVGA hast Du beim CUL nicht auf 2 umgestellt.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: exocet01 am 01 Oktober 2022, 12:08:01
Hallo Ansgar,

Nein, dass mit den 30 sec. wusste ich nicht, aber ich hatte eh aus Verzweiflung öfters drauf gedrückt.
Die agsMaxDVGA Einstellung hatte ich auch auf 2 gestellt.
Gersten wurde ein Gerät mal erkannt, welches ich dann gelöscht habe um festzustellen ob es nochmal klappt. Aber seitdem geht wieder nichts mehr. Kann das eventuell an Autocreate liegen? Bei den IT Devices habe ich zudem festgestellt dass es nur noch IODevList gibt, aber kein IODev.
Ich habe es auch mit mehr Abstand und weniger Abstand versucht. Ich finde einfach kein Muster.

Mit freundlichen Grüßen
Eckart
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 02 Oktober 2022, 09:16:51
Hallo Eckart,

im Anhang nochmal eine neue "Tarnversion" der Firmware zum testen. Ich habe damit den IT V1 Empfang im clock Bereich von 120us bis 672us erfolgreich durchgetestet.

Dein Problem liegt aber vermutlich beim Löschen des alten zuvor angelegten devices.
Du führst vermutlich nur ein delete xxxxxxxxxx in fhem aus.
Das löscht das für Dich sichtbare device.
Aber es bleiben anscheinend anschließend Reste oder die Reste werden durch das delete via DELETE notify wieder erzeugt.
Damit meint das IT Modul, dass das gelöschte device noch existiert und das erzeugt so ein Log Verhalten.

Starte fhem nach dem Löschen nochmal neu und versuch es dann mit dem autocreate.

Edit: Im Anhang auch noch ein 10_IT.pm das eine entsprechend korrigierte undef Funktion enthält. Damit sollte es ohne fhem Neustart gehen, zumindest, wenn das neu erstellte device nicht umbenannt wurde, was ich nicht getestet habe.

ZitatBei den IT Devices habe ich zudem festgestellt dass es nur noch IODevList gibt, aber kein IODev.
Ja, das ist anders und aus meiner Sicht gut so. Wenn Du mehrere IOs zum Senden in der Liste hast und eines davon (für fhem erkennbar) ausfällt. Dann wird das nächste aus der Liste gewählt.
Die Doku zum Modul beschreibt es auch entsprechend und auch, dass IODevList vor einem Sendeversuch vom User gesetzt werden muss.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: exocet01 am 03 Oktober 2022, 00:03:28
Hallo Ansgar,

jetzt werden gleich 2 devices angelegt. Hier nochmal die Config:
CUL_0:
Internals:
   CMDS       ABCFGJKRUVWXYehiltx
   CUL_0_MSGCNT 89
   CUL_0_TIME 2022-10-02 23:55:29
   Clients    STACKABLETS:STACKABLE:TSCUL_WS:TSCUL_NC7427:IT:CUL_FHTTK:CUL_HOERMANN:TSCUL_TX:CUL_IR:SOMFY:Revolt:ESA2000:TSCUL_RFR:TSCUL_EM:BS:USF1000:FS20:FHT.*:TSKS300:TSHMS:FS20V:UNIRoll:CUL_TCM97001:CUL_REDIRECT
   DEF        /dev/ttyACM0@12000000 1034
   DeviceName /dev/ttyACM0@12000000
   FD         9
   FHTID      1034
   FUUID      632f6ca9-f33f-d1ce-0914-e78649c00cf14b92
   NAME       CUL_0
   NR         86
   PARTIAL   
   RAWMSG     i0575d5
   RSSI       -76.5
   STATE      Initialized
   TYPE       TSCUL
   VERSION    VTS 0.40 CUL433
   VERSION_HW CUL_V3.4_0017
   VERSION_TS yes AES ChTblSize:209
   XmitOpen   0
   devioNoSTATE 1
   eventCount 3
   initString XP1C
X21
AM5
AHF11034
   MatchList:
     A:TSCUL_WS ^K[\dA-F]....
     B:TSCUL_NC7427 ^n..........
     C:IT       ^i.(?::.|.....)
     D:CUL_FHTTK ^T[\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F]
     E:CUL_HOERMANN ^R..........
     F:TSCUL_TX ^TX[A-F89].........
     G:CUL_IR   ^I............
     H:SOMFY    ^Y[r|t|s]:?[\dA-F]+
     I:Revolt   ^r......................$
     J:ESA2000  ^S................................$
     K:TSCUL_RFR ^[\dA-F][\dA-F][\dA-F][\dA-F]~
     L:TSCUL_EM ^E0.0[\dA-F]......
     M:FS20V    ^81..(?:04|0c)..0101a001......00[89a-f]...
     N:BS       ^81..(?:04|0c)..0101a001a5cf
     O:USF1000  ^81..(?:04|0c)..0101a001a5ceaa00....
     P:FS20     ^81..(?:04|0c)..0101a001
     Q:FHT      ^81..(?:04|09|0d)..(?:0909a001|83098301|c409c401)..
     R:TSKS300  ^810d04..4027a001
     T:TSHMS    ^810e04......a001
     U:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     V:CUL_TCM97001 ^s[\dA-F]+
     W:CUL_REDIRECT ^o
     Y:STACKABLETS ^\*
     Z:STACKABLE ^\*
   READINGS:
     2022-09-30 20:10:51   ITSndFreq       433.920MHz +0.000kHz
     2022-10-02 23:27:28   SlowRfconf      freq:433.920MHz freqOffs:0.000kHz bWidth:325kHz freqIF:203.12kHz rAmpl:42dB sens:12dB dRate:2.461kBit/s
agcPrio:0 agcWait:16 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:2 AGC_FREEZE:0
CCAmode:1 csRelThr:10dB csAbsThr:7dB  peakfilter:88
     2022-10-02 23:27:28   Xmit-Events     disconnected:1 non-HM:2
     2022-10-02 23:27:28   ccconf          freq:433.920MHz freqOffs:0.000kHz bWidth:325kHz freqIF:203.12kHz rAmpl:42dB sens:12dB dRate:2.461kBit/s
agcPrio:0 agcWait:16 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:2 AGC_FREEZE:0
CCAmode:1 csRelThr:10dB csAbsThr:7dB
     2022-10-02 23:16:33   cmds             A B C F G J K R U V W X Y e h i l t x
     2022-10-02 23:27:28   cond            non-HM
     2022-10-02 23:27:28   peakfilter      88 µs
     2022-10-02 23:16:33   prot_disconnected last
     2022-10-02 23:27:28   prot_non-HM     last
     2022-10-02 23:16:35   state           Initialized
   helper:
     ChkPart    0
     RA_Timeout 0
     SVTS       1
     VTS        1
     VTS_ACK    1
     VTS_AES    1
     nRec       0
     recAlive   1
     recd       1
     DEVIOTS:
       RXfailTO   
     HM:
       ChTblSize  209
       HMactive   0
       hmCrdts    9
       ChTbl:
     cnd:
       250        2
       253        1
     hmLog:
       Resolve    1
       IDs:
     q:
       HMcndN     250
       answerPend 0
       hmLanQlen  1
     ref:
       ioBR       3840
       lHMt       4294967295
       lSys       1751145393.54448
       pngLm      80
       scF        1
Attributes:
   icon       cul_cul
   rfmode     SlowRF
   verbose    0


Und hier die angelegten Geräte (obwohl ich nur An/Aus auf der Fenrbedienung gedrückt habe . IODevList habe ich gefüllt und die Funktion getestet. Das erste Device schaltet die Dose zuverlässig ein, aber nicht mehr aus. Das zweite Gerät funktioniert gar nicht:
Gerät 1:
Internals:
   00         f0
   CFGFN     
   CUL_0_MSGCNT 5
   CUL_0_RAWMSG i050514
   CUL_0_RSSI -73.5
   CUL_0_TIME 2022-10-02 23:53:42
   DEF        00FF00FF0F FF F0
   FUUID      633a07cb-f33f-d1ce-d4c3-dda0bed9d0616d5f
   IODev      CUL_0
   LASTInputDev CUL_0
   MSGCNT     5
   NAME       IT_00FF00FF0F
   NR         241
   STATE      off
   TYPE       IT
   XMIT       00ff00ff0f
   XMITdimdown 00
   XMITdimup  00
   XMITon     ff
   eventCount 22
   CODE:
     1          00ff00ff0f
   READINGS:
     2022-10-02 23:51:43   protocol        V1
     2022-10-02 23:56:10   state           off
Attributes:
   IODevList  CUL_0
   room       IT


Gerät 2:
Internals:
   00         f0
   CFGFN     
   CUL_0_MSGCNT 4
   CUL_0_RAWMSG i0575d5
   CUL_0_RSSI -76.5
   CUL_0_TIME 2022-10-02 23:55:29
   DEF        00FFF1FF1F FF F0
   FUUID      633a07cd-f33f-d1ce-c382-34184ffd39f9cb32
   IODev      CUL_0
   LASTInputDev CUL_0
   MSGCNT     4
   NAME       IT_00FFF1FF1F
   NR         243
   STATE      off
   TYPE       IT
   XMIT       00fff1ff1f
   XMITdimdown 00
   XMITdimup  00
   XMITon     ff
   eventCount 20
   CODE:
     1          00fff1ff1f
   READINGS:
     2022-10-02 23:51:43   protocol        V1
     2022-10-02 23:56:11   state           off
Attributes:
   IODevList  CUL_0
   room       IT
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 03 Oktober 2022, 21:53:17
Hallo Eckart,

im Anhang nochmal eine Tarnversion zum testen.
Wenn Du mit
set CUL_0 raw X25den CUL auf Bitausgabe erweiterst, dann erscheint im fhem Log so was:
2022.10.03 21:28:52.252 4: TSCUL_Parse: PIG2_WS433 i0575D53C -44
2022.10.03 21:28:52.268 4: TSCUL_Parse: PIG2_WS433 p05 272 9176 312 880 896 296 312 0 3 0 -44 0575D5
2022.10.03 21:28:52.354 4: PIG2_WS433 IT: message "i0575d5" (7)
2022.10.03 21:28:52.357 4: PIG2_WS433 IT: msgcode "00FFF1FF1FFF" (12) bin = 000001010111010111010101
Bitte dies mit der Information, welche Taste dazu gedrückt wurde.

Denn das
2022.10.03 21:28:52.268 4: TSCUL_Parse: PIG2_WS433 p05 272 9176 312 880 896 296 312 0 3 0 -44 0575D5
nach dem ixxxxxx enthält die Timing Information und roh die empfangenen "Bits".

Außerdem war beim CUL das Ints_per_sec Reading noch nicht wieder enthalten, dauert was, ist aber von Interesse.

Ich kann das, was Du offenbar regelmäßig empfängst senden und auch wieder empfangen. Von daher gehe ich derzeit weniger von einem CUL Softwareproblem aus. Sofern dein Handsender nicht was anderes als IT V1 sendet.

Ich bin auch etwas erstaunt, denn "Gerät 1:" entspricht doch der von Dir vormals als funktionierend genannten Konfiguration https://forum.fhem.de/index.php/topic,24436.msg1236512.html#msg1236512 (https://forum.fhem.de/index.php/topic,24436.msg1236512.html#msg1236512)?!?

Hast Du mit der Code Verstellung ggf. Probleme? Handsender und Dose müssen den gleichen Code haben.

Wenn der Handsender bei ein und derselben Codeeinstellung zu den beiden Geräten bei On bzw. Off führt, dann verhält es sich anders, als das IT Modul es erwartet, denn es wird bei Off dann ein anderer Gerätecode vom Handsender gesendet.
Entweder ist dann der Codewähler elektrisch wacklig oder eventuell die Batterie schon ermattet, so dass es zu merkwürdigem Verhalten beim Handsender kommt. Oder es ist ein merkwürdiges IT V1 Verhalten. Kannst Du mit dem Handsender noch die Dose schalten?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: exocet01 am 06 Oktober 2022, 19:44:37
Hi Ansgar,

die Dose und Handsender sind immer auf den gleichen Code eingestellt. Da habe ich nichts verstellt. Mit dem Handsender kann ich die Dose immer zuverlässig ein- und ausschalten.

Hier mal die Logs:
Handsender Taste ON:
2022.10.06 19:35:10 5: TSCUL_Read CUL_0: /P03 376 984 272 1008 920 376 240 5 2 2 -45 414540

2022.10.06 19:35:10 4: TSCUL_Parse: CUL_0 P03 376 984 272 1008 920 376 240 5 2 2 -45 414540
2022.10.06 19:35:10 5: TSCUL_Read CUL_0: /i0505153B

2022.10.06 19:35:10 4: TSCUL_Parse: CUL_0 i0505153B -44.5
2022.10.06 19:35:10 5: TSCUL_Read CUL_0: /p04 240 9936 280 1008 912 368 288 0 3 0 -45 050515

2022.10.06 19:35:10 4: TSCUL_Parse: CUL_0 p04 240 9936 280 1008 912 368 288 0 3 0 -45 050515
2022.10.06 19:35:10 5: CUL_0: dispatch i050515
2022.10.06 19:35:10 4: CUL_0 IT: message "i050515" (7)
2022.10.06 19:35:10 4: CUL_0 IT: msgcode "00FF00FF0FFF" (12) bin = 000001010000010100010101
2022.10.06 19:35:10 5: CUL_0 IT: V1 housecode = 00FF00FF0F  onoffcode = FF
2022.10.06 19:35:10 4: CUL_0 IT: 00FF00FF0F not defined (Switch code: FF), msg:i050515
2022.10.06 19:35:10 5: TSCUL_Read CUL_0: /i0575D53C

2022.10.06 19:35:10 4: TSCUL_Parse: CUL_0 i0575D53C -44
2022.10.06 19:35:10 5: TSCUL_Read CUL_0: /p04 248 9928 280 1000 904 376 272 0 3 0 -44 0575D5

2022.10.06 19:35:10 4: TSCUL_Parse: CUL_0 p04 248 9928 280 1000 904 376 272 0 3 0 -44 0575D5
2022.10.06 19:35:10 5: CUL_0: dispatch i0575d5
2022.10.06 19:35:10 4: CUL_0 IT: message "i0575d5" (7)
2022.10.06 19:35:10 4: CUL_0 IT: msgcode "00FFF1FF1FFF" (12) bin = 000001010111010111010101
2022.10.06 19:35:10 5: CUL_0 IT: V1 housecode = 00FFF1FF1F  onoffcode = FF
2022.10.06 19:35:10 4: CUL_0 IT: 00FFF1FF1F not defined (Switch code: FF), msg:i0575d5


Handsender Taste OFF:
2022.10.06 19:36:39 5: TSCUL_Read CUL_0: /P03 296 1024 288 992 888 400 272 5 2 2 -47 414500

2022.10.06 19:36:39 4: TSCUL_Parse: CUL_0 P03 296 1024 288 992 888 400 272 5 2 2 -47 414500
2022.10.06 19:36:39 5: TSCUL_Read CUL_0: /i05051436

2022.10.06 19:36:39 4: TSCUL_Parse: CUL_0 i05051436 -47
2022.10.06 19:36:39 5: TSCUL_Read CUL_0: /p04 272 9904 272 1008 920 360 320 0 3 0 -47 050514

2022.10.06 19:36:39 4: TSCUL_Parse: CUL_0 p04 272 9904 272 1008 920 360 320 0 3 0 -47 050514
2022.10.06 19:36:39 5: CUL_0: dispatch i050514
2022.10.06 19:36:39 4: CUL_0 IT: message "i050514" (7)
2022.10.06 19:36:39 4: CUL_0 IT: msgcode "00FF00FF0FF0" (12) bin = 000001010000010100010100
2022.10.06 19:36:39 5: CUL_0 IT: V1 housecode = 00FF00FF0F  onoffcode = F0
2022.10.06 19:36:39 4: CUL_0 IT: 00FF00FF0F not defined (Switch code: F0), msg:i050514
2022.10.06 19:36:39 3: CUL_0 IT: For autocreate please use the on button.
2022.10.06 19:36:39 5: TSCUL_Read CUL_0: /i0575D539

2022.10.06 19:36:39 4: TSCUL_Parse: CUL_0 i0575D539 -45.5
2022.10.06 19:36:39 5: TSCUL_Read CUL_0: /p04 272 9888 264 1008 920 376 256 0 3 0 -46 0575D5

2022.10.06 19:36:39 4: TSCUL_Parse: CUL_0 p04 272 9888 264 1008 920 376 256 0 3 0 -46 0575D5
2022.10.06 19:36:39 5: CUL_0: dispatch i0575d5
2022.10.06 19:36:39 4: CUL_0 IT: message "i0575d5" (7)
2022.10.06 19:36:39 4: CUL_0 IT: msgcode "00FFF1FF1FFF" (12) bin = 000001010111010111010101
2022.10.06 19:36:39 5: CUL_0 IT: V1 housecode = 00FFF1FF1F  onoffcode = FF
2022.10.06 19:36:39 4: CUL_0 IT: 00FFF1FF1F not defined (Switch code: FF), msg:i0575d5


Jetzt klappt es!!! Ich denke der Fehler lag bei mir. Die Logs haben mir dabei geholfen :-). Der Handsender hat 2 An- und Aus-Schalter und die "Kanalwahl A,B,C,D". Wenn ich auf dem Handsender auch nur eine Dose an- oder ausschalten will, sendet er aber trotzdem auch für die zweite Dose. Nur so kann ich mir erklären das 2 Geräte angelegt werden. Außerdem habe ich die Dose direkt neben dem Raspi eingesteckt, wodurch anscheinend das Signal zu stark war und manchmal der Schaltwunsch vermutlich durch Übersteuerung nicht erkannt wurde.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 06 Oktober 2022, 21:11:08
Hallo Eckart,

schön, dass es jetzt besser ausschaut.  :)

Wenn Du noch das Attribut ITclock für die zu diesem Handsender gehörenden Dosen auf 312 oder 320 einstellst, dann sollte es vom CUL aus noch etwas besser klappen. Denn derzeit sendest Du mit dem Default von 416.

Der i0575d5 ist bei on und off gleich. Möglicherweise eine Art Abschlusscode für das oder ein transienter Code bei dem Taste Loslassen.

Mit set raw X27 beim CUL werden auch Wiederholungen des Handsenders geliefert. So lange Du eine Taste drückst, sollte der Code dazu kommen und wenn Du loslässt der i0575d5 Code, wenn die Vermutung zutrifft.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: yersinia am 07 Oktober 2022, 07:50:54
Hallo noansi,

ich les' immer, dass die V0.39 sowas von völlig veraltet zu sein scheint, ua hier:
Zitat von: noansi am 25 September 2022, 16:12:33im Anhang noch eine neue als V0.40 "getarnte" Version der Firmware, damit auch der IT Empfang wieder klappt.

Habe ich irgendwas verpasst? Zumindest für meine nanoCULs finde ich nur die V0.39, und nichts neueres - mein letzter Stand ist immer noch der Anhang von #1264 (https://forum.fhem.de/index.php/topic,24436.msg1167796.html#msg1167796). Was hab ich übersehen? ???

Danke vorab. :)
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: Bastel-Frank am 07 Oktober 2022, 16:23:36
Hallo Ansgar,
Ich setze deine Firmware seit Jahren erfolgreich mit mehreren Cul's ein. Bisher habe ich diese per Raspi und Ser2net angebunden.
Da der Raspi immer schlechter verfügbar ist und mir schon mehrere ausgefallen sind, suche ich nach einer Lösung, deinen Cul direkt ins WLAN zu bringen, z.B. als Idee mit einem ESP. Hast du dazu eine Lösungsidee oder einen Vorschlag für mich?

Viele Grüße
Frank
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 07 Oktober 2022, 19:55:39
Hallo yersinia,

nein, Du hast nichts verpasst.
Meine Zählung unveröffentlicher Zwischenstände ist nur weiter fortgeschritten.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 07 Oktober 2022, 20:07:56
Hallo Frank,

meine Meinung zu WLAN Anbindung habe ich hier https://forum.fhem.de/index.php/topic,24436.msg1234919.html#msg1234919 (https://forum.fhem.de/index.php/topic,24436.msg1234919.html#msg1234919) und hier https://forum.fhem.de/index.php/topic,24436.msg1235192.html#msg1235192 (https://forum.fhem.de/index.php/topic,24436.msg1235192.html#msg1235192) bereits kund getan.

Ist Ser2net auf den RasPi begrenzt? Ist doch eine Linux Lösung.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: frank am 20 Oktober 2022, 11:15:13
hallo ansgar,
soweit ich sehe, hast du in deiner cul_hm auch folgendes problem, siehe https://forum.fhem.de/index.php/topic,129777.0.html (https://forum.fhem.de/index.php/topic,129777.0.html)

du hast doch sicher eine idee.  ;)

gruss frank
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 20 Oktober 2022, 23:02:45
Hallo Frank,

prep, ein Feature, dass ich noch nie benutzt habe.  ;)

Zitatsoweit ich sehe, hast du in deiner cul_hm auch folgendes problem
Ja, kann ich nachvollziehen.

Zitatdu hast doch sicher eine idee.
Ja, nicht neu berechnen, sondern merken in einem Zusatzhelper in CUL_HM_pushConfig(), genau wie die shadowRegs.

  $sdH->{helper}{shadowReg}{$regLNp} = $regs; # update shadow
  $sdH->{helper}{shadowRegChn}{$regLNp} = $chn; #noansi: save chn for later use, even with prep
#  Log 0,"CUL_HM_pushConfig $regs";
  my @changeList;
  if ($prep eq "exec"){#update complete registerset
    @changeList = keys%{$sdH->{helper}{shadowReg}};
  }
  elsif ($prep eq "prep"){
    return; #prepare shadowReg only. More data expected.
  }
  else{
    push @changeList,$regLNp;
  }
  my $changed = 0;# did we write
  foreach my $nrn(@changeList){
    my $change;
    my $nrRd = ReadingsVal($chnhash->{NAME},$regPre.$nrn,"");
    foreach (sort split " ",$sdH->{helper}{shadowReg}{$nrn}){
      $change .= $_." " if ($nrRd !~ m/$_/);# filter only changes
    }
    next if (!$change);#no changes
    $change =~ s/00:00//;
    $change =~ s/(\ |:)//g;
    if ($nrRd){
      $chnhash->{READINGS}{$regPre.$nrn}{VAL} =~ s/00:00//; #mark incomplete as we go for a change;
    }
    my $pN;
    $changed = 1;# yes, we did
    ($list,$pN) = ($1,$2) if($nrn =~ m/RegL_(..)\.(.*)/);
    if ($pN){($peerAddr,$peerChn) = unpack('A6A2', CUL_HM_name2Id($pN,$hash));}
    else       {($peerAddr,$peerChn) = ('000000','00');}

    if (AttrVal($chnhash->{NAME},"peerIDs","") =~ m/${peerAddr}00/){$peerChn = "00"}# if device we are not sure about device or channel. Check peers

    CUL_HM_updtRegDisp($hash,$list,$peerAddr.$peerChn);
    ############partition
#   my @chSplit = unpack('(A28)*',$change);
    $chn = $sdH->{helper}{shadowRegChn}{$nrn}; #noansi: use correct chn
    my @chSplit = unpack('(A1120)*',$change);# makes max 40 lines, 280 byte

Ob es sich lohnt, die helper dann auch wieder zu löschen, wenn die shadow Regs gelöscht werden...?

Gruß und Danke für den Hinweis, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: frank am 21 Oktober 2022, 09:45:56
moin ansgar,

einfach, elegant und funktioniert.
endlich laufen die templates (wieder?) durch, danke.

Zitat von: noansi am 20 Oktober 2022, 23:02:45
prep, ein Feature, dass ich noch nie benutzt habe.  ;)
das glaube ich nicht.  :)
bei HMdeviceTools.js nutzt du es im hintergrund automatisch beim zusammenklicken von registeränderungen (ist anschliessend auch in fhem.log zu sehen).
bei templates kommt es auch zum einsatz.

ZitatOb es sich lohnt, die helper dann auch wieder zu löschen, wenn die shadow Regs gelöscht werden...?
zumindest sollten verbleibende helper keinen ärger machen, da die gespeicherten werte konstant bleiben.


hast du rt oder tc-it?
mich verwundert nämlich, dass die drei cmds so absurd unterschiedlich behandelt werden.
Zitatforeach my $chSpl(@chSplit){
      my $mch = CUL_HM_lstCh($chnhash,$list,$chn);
      CUL_HM_PushCmdStack($hash, "++".$flag.'01'.$src.$dst.$mch.'05'.
                                          $peerAddr.$peerChn.$list);
      $tl = length($chSpl);
      for(my $l = 0; $l < $tl; $l+=28) {
        my $ml = $tl-$l < 28 ? $tl-$l : 28;
        CUL_HM_PushCmdStack($hash, "++A001".$src.$dst.$chn."08".
                                       substr($chSpl,$l,$ml));
      }
      CUL_HM_PushCmdStack($hash,"++A001".$src.$dst.$mch."06");
    }
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 21 Oktober 2022, 21:18:22
Hallo Frank,

Zitatdas glaube ich nicht.  :)
OK, nur Templisten für 2 RTs habe ich damit tatsächlich mal gesetzt. Bin aber dem Code nicht nachgekrochen, in welchen Funktionen das umgesetzt wird, da es geklappt hatte.

Zitatmich verwundert nämlich, dass die drei cmds so absurd unterschiedlich behandelt werden.
In CUL_HM_updateConfig($) gibt es die Vorbereitung für CUL_HM_lstCh als
    if    ($md =~ m/^HM-CC-RT-DN/s){
      $hash->{helper}{shRegR}{'07'} = '00' if ($chn eq '04');# Reg List 7 read/write from/to device CH 0
      $hash->{helper}{shRegW}{'07'} = '04' if ($chn eq '00');# Reg List 7 write to CH 4 for display and use in fhem
    }
    elsif ($md =~ m/^HM-TC-IT-WM-W-EU/s){
      $hash->{helper}{shRegR}{'07'} = '00' if ($chn eq '02');# Reg List 7 read/write from/to device CH 0
      $hash->{helper}{shRegW}{'07'} = '02' if ($chn eq '00');# Reg List 7 write to CH 2 for display and use in fhem
    }

Hast Du da Protokollprobleme entdeckt?

Gruß, Ansgar.

Edit: Komentare korrigiert
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: frank am 22 Oktober 2022, 10:42:24
ZitatHast Du da Protokollprobleme entdeckt?
nein, habe keine rt/tc.
ich hatte nur das gefühl, dass beim 08'er cmd eventuell auch $mch genutzt werden müsste.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: presskopf am 22 Oktober 2022, 12:01:31
Zitat von: noansi am 07 Oktober 2022, 20:07:56
Hallo Frank,

meine Meinung zu WLAN Anbindung habe ich hier https://forum.fhem.de/index.php/topic,24436.msg1234919.html#msg1234919 (https://forum.fhem.de/index.php/topic,24436.msg1234919.html#msg1234919) und hier https://forum.fhem.de/index.php/topic,24436.msg1235192.html#msg1235192 (https://forum.fhem.de/index.php/topic,24436.msg1235192.html#msg1235192) bereits kund getan.

Ist Ser2net auf den RasPi begrenzt? Ist doch eine Linux Lösung.

Gruß, Ansgar.

Hi Ansgar,

ich komme nochmal auf das Thema LAN / WLAN-Anbindung des TSCUL zurück.
Probleme hatte ich ja mit der WLAN-Anbindung über einen Raspi, der über ser2net den TSCUL bereitstellt. Warum auch immer. Vielleicht ist der Wlan-Dongle einfach nur schrottig, I dont know.

Jedenfalls versuchte ich es nun über einen esp32 mittels Tasmota und TCPBridge, welcher über LAN- und WLAN-Funktionalität verfügt (Olimex esp32-poe-iso), um beides zu testen.
Heute, nach knappen zwei Wochen, kann ich -> für mein Setup <- sagen, dass es über beide Kanäle stabil läuft. Über LAN hatte ich es quasi erwartet. Der Ort des Geschehens ist über WLAN gar nicht so schlecht versorgt (40%, -80 dBm); der Ping ist natürlich mit einem avg von 86 ms deutlich höher als im LAN. Aber alle zugewiesenen HM-Geräte (drei Rolladen, ein Rauchmelder, zwei Bewegungsmelder, zwei Fensterkontakte) laufen anstandslos (kein Ausfall, keine Fehler im genannten Zeitraum).

Ich danke Dir für Deine Entwicklungsarbeit und Deine Meinung zur WLAN-Anbindung. Anscheinend ist mein Setup im "stabilen Timing-Bereich" der recht robusten TS-Firmware. Wie es bei schlechterem WLAN-Empfang aussieht, muss dann jeder für sich testen.

Dennoch werde ich den Anschluss über LAN vornehmen, was aber eher daran liegt, dass ich den Olimex über POE galant versorgen kann - da ich mittlerweile eine Strippe gezogen habe.

Viele Grüße
Matthias


Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 22 Oktober 2022, 13:53:36
Hallo Frank,

Zitatich hatte nur das gefühl, dass beim 08'er cmd eventuell auch $mch genutzt werden müsste.
Kommt mir auch komisch vor, zumal es mit RT und IT ohnehin immer auf ch 00 beim templisten Setzen rausläuft.
Habe ich mal mit geändert.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 22 Oktober 2022, 14:37:34
Hallo Matthias,

danke für Dein Feedback, insbesondere im Namen derer, die es doch mal mit WLAN ausprobieren wollen.
Freut mich, wenn es bei Dir mit Deinem Setup zufriedenstellen funktioniert hat.

Ich hoffe, Du berätst auch, wenn hier Probleme mit WLAN Anbindung auf den Tisch kommen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: yersinia am 11 November 2022, 16:32:03
Hallo noansi,
in den letzten Tagen hatte ich mehrfach Probleme mit meinen tsculfw nanoCULs, vermute als Grund eher ein Kernelupgrade bzw den USB-Port des RasPis (andere USB Devices sind ebenso betroffen). Ich hab' nur eine Bitte: ist es möglich, dass wenn der nanoCUL nicht erreichbar ist oder unplausible Daten ausgibt wie zB
2022.11.11 07:34:45 1: TSCUL_SendPingHM nanoCUL_868_1 fatal: ApC0 timed out! Failsafe release.
2022.11.11 07:43:04 1: TSCUL_SendPingHM nanoCUL_868_1 fatal: ApC0 timed out! Failsafe release.
2022.11.11 07:48:08 1: TSCUL_RecoverHMQlen: nanoCUL_868_1 recovered from Qlen lock
2022.11.11 07:48:39 1: TSCUL_SendPingHM nanoCUL_868_1 fatal: ApC0 timed out! Failsafe release.
2022.11.11 07:58:44 1: TSCUL_SendPingHM nanoCUL_868_1 fatal: ApC0 timed out! Failsafe release.
2022.11.11 08:00:43 2: TSCUL_ReceiveDelayed: nanoCUL_868_1 No data received for long time: Timeout reading answer for get RDl
2022.11.11 08:02:56 1: TSCUL_SendPingHM nanoCUL_868_1 fatal: ApC0 timed out! Failsafe release.
2022.11.11 08:15:47 2: TSCUL_ReceiveDelayed: nanoCUL_868_1 No data received for long time: Timeout reading answer for get RDl
2022.11.11 08:30:51 2: TSCUL_ReceiveDelayed: nanoCUL_868_1 No data received for long time: Timeout reading answer for get RDl
2022.11.11 08:45:55 2: TSCUL_ReceiveDelayed: nanoCUL_868_1 No data received for long time: Timeout reading answer for get RDl
2022.11.11 08:47:15 1: TSCUL_SendPingHM nanoCUL_868_1 fatal: ApC0 timed out! Failsafe release.
2022.11.11 09:00:59 2: TSCUL_ReceiveDelayed: nanoCUL_868_1 No data received for long time: Timeout reading answer for get RDl
2022.11.11 09:02:41 1: TSCUL_SendPingHM nanoCUL_868_1 fatal: ApC0 timed out! Failsafe release.
2022.11.11 09:16:03 2: TSCUL_ReceiveDelayed: nanoCUL_868_1 No data received for long time: Timeout reading answer for get RDl

es ein reading in dem TSCUL-Device gibt, welches auch das reading cond (oder irgendein anderes) auf was anderes als ok setzt?

Hintergrund: ich prüfe periodisch verschiedene Devices und ua auch diesen nanoCUL und kann bei Bedarf ein set reset automatisch ausführen. (ist noch ein Überbleibsel vom alten Bootloader...)

TSCUL Version 0.39
VERSION_TS, VTS 0.39 CSM868, nanoCUL_V1.x_0014
FHEM-Module sind auf dem mir aktuellen Stand von 0.97 (https://forum.fhem.de/index.php/topic,24436.msg1167796.html#msg1167796).

Anbei noch ein list vom nanoCUL (hmId duch ###### ersetzt und ausgabe gekürzt):
Internals:
   CMDS       ABCFGJKRUVWXYeiltx
   Clients    STACKABLETS:STACKABLE:CUL_HM:CUL_IR:TSHMS
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A94H5T9K-if00-port0@38400 0000
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A94H5T9K-if00-port0@38400
   FD         10
   FHTID      0000
   FUUID      5c443cea-f33f-3151-cc84-d7ba10e1ebdcec87
   NAME       nanoCUL_868_1
   NR         22
   PARTIAL   
   RAWMSG     A144F845E2D478700000080E3F300000000000951FF::-76:nanoCUL_868_1:
   RSSI       -76
   STATE      2022-11-11 09:25:19 Initialized
   TYPE       TSCUL
   VERSION    VTS 0.39 CSM868
   VERSION_HW nanoCUL_V1.x_0014
   VERSION_TS yes AES ChTblSize:209
   XmitOpen   1
   assignUpdCntI 55
   assignedIDsCnt 26
   devioNoSTATE 1
   eventCount 12
   initString XP0C
X21
Ar
AM5
AH######
   msgLoadCurrent 0
   nanoCUL_868_1_MSGCNT 17008
   nanoCUL_868_1_TIME 2022-11-11 16:25:42
   owner_CCU  VCCU
   .attraggr:
   .attreocr:
     .*
   .attrminint:
   .clientArray:
     CUL_HM
   MatchList:
     A:CUL_HM   ^A....................
     B:CUL_IR   ^I............
     C:TSHMS    ^810e04......a001
     Y:STACKABLETS ^\*
     Z:STACKABLE ^\*
   READINGS:
     2022-09-09 08:23:43   Initialized     
     2022-11-11 09:25:23   Xmit-Events     ok:6 non-HM:1 disconnected:2
     2022-11-11 09:25:17   cmds             A B C F G J K R U V W X Y e i l t x
     2022-11-11 09:25:23   cond            ok
     2022-11-09 10:11:35   disconnected   
     2022-11-11 09:25:12   prot_disconnected last
     2021-04-30 09:06:45   prot_init       last
     2022-11-09 10:11:51   prot_non-HM     last
     2022-11-11 09:25:23   prot_ok         last
     2022-11-10 01:16:50   scF             0.999673925227026
     2022-11-11 09:25:19   state           Initialized
     2022-11-11 09:33:10   uptime          0 00:07:57
     2022-11-11 09:33:06   version         VTS 0.39 CSM868
   helper:
     CUrun      1
     ChkPart    0
     RA_Timeout 0
     SVTS       1
     VTS        1
     VTS_ACK    1
     VTS_AES    1
     assIdCnt   26
     assIdRep   26
     nRec       0
     recAlive   1
     recd       1
     DEVIOTS:
       RXfailTO   
     HM:
       ChTblSize  209
       FUP        0
       HMactive   1
       hmCrdts    0
       hmSbusy    0
       ChTbl:
         1B39F300   00
         3C775B00   00
         3C95EB00   00
         3E804200   00
         3F464200   00
         40AA4F00   00
         4930EC00   00
         4ADAF500   00
         4B3FE700   00
         50CDF000   00
         5389B700   00
         538A7800   00
         564A8300   00
         567A3600   00
         567A3800   00
         5683FF00   00
         56840900   00
         56842200   00
         58ADFB00   00
         59795B00   00
         59F7C500   00
         5C179800   00
         5C1CA000   00
         5C912900   00
         5ED64C00   00
         5ED76B00   00
       msgCNT:
         0x01       17008
         0x02       461
         0x03       643
       unknwn:
         3B5ADA:
           nextSend   1668076043.77502
           lRcTm:
             mcnt       02
             nanoCUL_868_1 16015948
             tnms       554991003
             type       11
         40D9AF:
           nextSend   1668177201.6565
           lRcTm:
             mcnt       10
             nanoCUL_868_1 22095532
             tnms       656148885
             type       8E
         451818:
           nextSend   1668171353.90928
           lRcTm:
             mcnt       10
             nanoCUL_868_1 16245880
             tnms       650301137
             type       8E
         4BEEC8:
           nextSend   1668179701.18435
           lRcTm:
             mcnt       9C
             nanoCUL_868_1 24595860
             tnms       658648412
             type       10
         4BEEC9:
           nextSend   1668120414.70759
           lRcTm:
             mcnt       97
             nanoCUL_868_1 60401528
             tnms       599361936
             type       10
         677759:
           nextSend   1668179836.39099
           lRcTm:
             mcnt       10
             nanoCUL_868_1 24731116
             tnms       658783619
             type       8E
         AF761B:
           nextSend   1668180161.12973
           lRcTm:
             mcnt       12
             nanoCUL_868_1 25055960
             tnms       659108358
             type       83
         B56FD3:
           nextSend   1668174399.34079
           lRcTm:
             mcnt       10
             nanoCUL_868_1 19292296
             tnms       653346569
             type       8E
     cnd:
       0          6
       250        1
       253        2
     hmLog:
       IDs:
     hmLogHist:
        146370                 As 0D 7F 8002 ###### 59F7C5 0101C800
        04865060 A F103 08346868 01 0A 7F 8002 ###### 59F7C5 00 _CCAdly:4 _dhmSt:96
        04865155 A F103 08346964 01 0D 7F 8002 ###### 59F7C5 0101C800 _CCAdly:4 _dhmSt:192
        04866834 A F101 08348672 00 0F E7 8610 5683FF 000000 0A80BBC70000 -53.5dB
        04875842 A F001 08357684 00 0F 5E 8610 567A36 000000 0A98CA090000 -38.5dB
        04896600 A F001 08378436 00 0F CE 8610 567A38 000000 0A98CAC80500 -57dB
        04906230 A F001 08388084 00 0F 86 8610 568422 000000 0A98C70E0200 -52.5dB
        04914424 A F001 08396272 00 0F A7 8610 568414 000000 0A98CF090000 -70.5dB
        04926889 A F001 08408748 00 0F 55 8610 568409 000000 0AA0E00C0000 -57dB
        04948558 A F001 08430416 00 0C D8 865A 3C95EB 000000 98C43D -61.5dB
        04962159 A F001 08444032 00 0C A0 865A 3C775B 000000 98C844 -61dB
        04968560 A F001 08450424 00 0C D8 8470 3C95EB 000000 00C43D -59.5dB
        04975554 A F001 08457420 00 0C 2A 865A 40AA4F 000000 A0DE3F -72dB
        04978350 A F001 08460216 00 14 4F 845E 2D4787 000000 80E3F300000000000951FF -76dB
     hmQ:
       000000:
       3C775B:
       3C95EB:
       3F4642:
       40AA4F:
       4930EC:
       5389B7:
       538A78:
       567A36:
       567A38:
       5683FF:
       568409:
       568422:
       58ADFB:
       59795B:
       59F7C5:
       5C1798:
       5C9129:
       5ED64C:
       5ED76B:
     ids:
       [...]
     loadLvl:
       bl         40
     q:
       ATrNo      0
       HMcndN     0
       InQueues   0
       RQLSt      0
       RQLt       0
       XRpCnt     0
       XRpTm      1668153701.7581
       answerPend 0
       hmLanQlen  1
     ref:
       Sdly       12
       TmBmCnt    1
       ioBR       3840
       ioBRMax    3780.95735595249
       ioBRMean   3352.48190506548
       lHMt       25221248
       lSys       659273583
       pTTu       16
       pndAs      0
       pndCUAp    1
       pndTuP     1
       pngFrc     1
       pngLm      70
       pngRef     -100000000
       scErr      0
       scF        0.999673925227026
       scFN       1
       scHT       88221780
       scST       627172874
       scpTm      1668040433.88637
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 11 November 2022, 19:56:25
Hallo yersinia,

erst mal Bordmittel.

Hast Du mal versucht, das Attribut 'forceAlivePing' auf 1 zu setzen?

Dann wird alle 59 Sekunden ein spezielles "ping" an den nano gesendet und wenn er nicht antwortet, wird die Verbindung getrennt und sie sollte neu aufgebaut werden. Eigentlich für Netzwerk HM IOs gedacht, aber auch bei anderer Verbindungsart nutzbar.

Richtig wäre natürlich, das Übel bei der Wurzel zu packen und den buggy Unterbau zu reparieren, in dem Fall auf den älteren funktionierenden Stand.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: yersinia am 12 November 2022, 13:45:12
Zitat von: noansi am 11 November 2022, 19:56:25Hast Du mal versucht, das Attribut 'forceAlivePing' auf 1 zu setzen?
Neee, das war mir gar nicht bekannt. Aber guter Hinweis, ich setz' es mal und beobachte.
Erstaunlicherweise habe ich mit dem via Netzwerk angebundenen nanoCUL keinerlei Probleme. Aber da schadet das Attribut forceAlivePing ja auch nicht.

ZitatRichtig wäre natürlich, das Übel bei der Wurzel zu packen und den buggy Unterbau zu reparieren, in dem Fall auf den älteren funktionierenden Stand.
Ja, ich werde es beobachten. Weil sonst läuft alles - und andere RasPis (gleiches OS, gleicher Kernel mit USB Geräten) haben keine Probleme (derzeit).
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: exocet01 am 19 Dezember 2022, 19:36:22
Zitat von: noansi am 24 September 2022, 21:57:54
Hallo Eckart,

im Anhang eine neue Testfirmware. Ich habe ihr eine VTS 0.40 verpasst, obwohl sie eigentlich eine VTS 0.41 ist, damit Du mit den älteren FHEM Modulen Somfy testen kannst. Also bitte auch nur dafür verwenden und nicht etwa für Deinen 868er.

Ich bin diesmal optimistischer, dass es besser klappt. Die Manchesterumsetzung hatte ihre Tücken.

Nebenbei habe ich noch bemerkt, dass sowohl in der Standard culfw, als auch in der a-culfw die frame-Pause zwischen den Wiederholungen viel zu kurz ausfällt, wegen fehlender Klammern in der betreffenden Sourcecode Zeile.
my_delay_us(30415 + ((frame[6] >> 7) & 1) ? 0 : somfy_rts_interval_half);
Macht nicht in somfy_rts.c das von
my_delay_us(30415 + (((frame[6] >> 7) & 1) ? 0 : somfy_rts_interval_half));
erwartete (falls Rudolf und Björn hier mal rein schauen).
Scheint, Deine Rollos aber anscheinend wenig zu stören.

Gruß, Ansgar.

Hallo Ansgar,

seit kurzem funktioniert die Steuerung der Somfy Rollos nicht mehr. Sie sind langsam nacheinander ausgefallen. Jetzt funktionieren nurn noch 2. Ich habe keine Änderungen vorgenommen und auch an dem CUL nichts geändert. Die IT V1 Steckdose funktioniert noch einwandfrei (Nur die IT V3 funktioniert nicht richtig). Kann es sein dass es an dem Code oben liegt? Der Handsender funktioniert noch immer einwandfrei und die Rolling codes können es eigentlich auch nicht sein, weil ich diese immer automatisch Backuppe (Also im Falle eines Stromausfalls....hatte ich mal)

Gruß
Eckart
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 22 Dezember 2022, 10:40:25
Hallo Eckart,

Zitatseit kurzem funktioniert die Steuerung der Somfy Rollos nicht mehr. Sie sind langsam nacheinander ausgefallen.
Gegenfrage: Wie lange hat es problemlos funktioniert?
Denn Du hast lange keine weitere Rückmeldung gegeben.

ZitatKann es sein dass es an dem Code oben liegt?
Glaube ich nicht. Sonst hättest Du Dich schon früher gemeldet.

ZitatIch habe keine Änderungen vorgenommen und auch an dem CUL nichts geändert.
Vielleicht irgendwas in den Funkweg gestellt?
Was sagt ein get PAtable1 beim CUL?
Sendet irgendwas häufig gleichzeitig auf der gleichen Frequenz (433.42)? Z.B. ein Funkthermometer?

Gruß, Ansgar.

Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 23 Dezember 2022, 11:54:35
Hallo Eckart,

ZitatDer Handsender funktioniert noch immer einwandfrei und die Rolling codes können es eigentlich auch nicht sein
Benutzt Du den Handsender immer mal wieder zur Steuerung der Rollos?
Der Handsender zählt seinen eigenen Rolling Code.

CUL empfängt keine SOMFY Telegramme -> synchronisiert FHEM damit nicht auf den Handsender Rolling Code. Was Du vom CUL als Ys siehst, sind nur die Rückmeldungen gesendeter Telegramme.

Wenn FHEM und Handsender damit weit genug auseinander laufen, bricht die reguläre Steuerung via FHEM (oder Handsender?) zusammen, weil das Rollo einen anderen gültigen Rolling Code Bereich erwartet.
-> Steuerung der Rollos nur über FHEM und nicht über Handsender, wenn es via FHEM funktionieren soll

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: exocet01 am 24 Dezember 2022, 10:30:50
Hallo Ansgar,

nachdem auch die IT Dose nicht mehr funktionierte und ich somit einen HW Defekt vermutete, habe ich einen neuen CUL gekauft.
Jetzt funktioniert es wieder.

Vielen Dank und frohe Weihnachten!!!!
Eckart
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: Adimarantis am 26 Februar 2023, 23:07:00
Hi Ansgar,

ich bekomme im Logfile nahezu im Sekundenabstand folgendes:
2023.02.26 22:57:56.997 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4766.
2023.02.26 22:57:57.007 1: stacktrace:
2023.02.26 22:57:57.012 1:     main::__ANON__                      called by fhem.pl (4766)
2023.02.26 22:57:57.015 1:     main::AttrVal                       called by ./FHEM/00_TSCUL.pm (1382)
2023.02.26 22:57:57.019 1:     main::TSCUL_ParseTsHM               called by ./FHEM/00_TSCUL.pm (707)
2023.02.26 22:57:57.023 1:     main::TSCUL_Parse                   called by ./FHEM/00_TSCUL.pm (643)
2023.02.26 22:57:57.026 1:     main::TSCUL_Read                    called by fhem.pl (3976)
2023.02.26 22:57:57.030 1:     main::CallFn                        called by fhem.pl (784)

Scheint was mit Repeatern zu tun zu haben? Sowas habe ich tatsächlich im Haus, aber nicht über die CUL konfiguriert.

Desweiteren verzweifele ich gerade ein weiteres HM-CC-VD Ventil einzubinden. Sieht so als könnte ich zwar vom Ventil empfangen, wodurch ein Pairing erstmal möglich ist. Aber meine Befehle werden nicht empfangen/bearbeitet. Das einzig seltsame ist, dass die peerList mit einem FHEM unbekannten Gerät belegt ist - kann das ein Überbleibsel sein, dass nun stört?
Sonst habe ich schon mit dem Frequenzoffset gespielt - aber da erreiche ich nur, dass irgendwann meine beiden anderen Ventile auch nicht mehr funktionieren.

Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 27 Februar 2023, 20:16:20
Hallo Jörg,

ZitatPERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 4766.
Das ist (meiner Meinung nach) eine Schwäche in AttrVal($$$) in fhem.pl, da ein undefinierter Name mit übergeben wird, in der Funktion nicht überprüft wird, ob er nicht definiert ist und dann damit auf hashes zugeriffen wird, statt nur den ebenfalls übergebenen Default Wert zurück zu liefern.

Das der Name undefiniert ist, liegt vermutlich an einem noch nicht oder nicht richtig angelernten device, was einen kaputten device hash erzeugt hat.

ZitatDesweiteren verzweifele ich gerade ein weiteres HM-CC-VD Ventil einzubinden.
Passt also zu Deinem weiteren Problem mit dem Ventil.

Ist das HM-CC-VD Ventil noch an einer anderen Zentrale angemeldet, sprich, nicht abgemeldet oder nicht auf Werkseinstellungen zurück gesetzt?
Dann würde es die Zusammenarbeit verweigern.
Wenn das Ventil kaputt sein sollte, kann es eventuell nicht empfangen aber noch senden.

Ein raw logging, mit verbose 4 beim CUL, eines Pairing Versuchs zeigt vielleicht Hinweise.
Weiterhin ein list des Deiner Meinung nach gepairten Ventils.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: Adimarantis am 28 Februar 2023, 10:47:10
Zitat von: noansi am 27 Februar 2023, 20:16:20
Das ist (meiner Meinung nach) eine Schwäche in AttrVal($$$) in fhem.pl, da ein undefinierter Name mit übergeben wird, in der Funktion nicht überprüft wird, ob er nicht definiert ist und dann damit auf hashes zugeriffen wird, statt nur den ebenfalls übergebenen Default Wert zurück zu liefern.
Wäre trotzdem schön das irgendwie so zu handhaben, dass es keine Warning gibt. Mit der "Schwäche" müssen wir halt als Entwickler aktuell leben.

Zitat von: noansi am 27 Februar 2023, 20:16:20
Ist das HM-CC-VD Ventil noch an einer anderen Zentrale angemeldet, sprich, nicht abgemeldet oder nicht auf Werkseinstellungen zurück gesetzt?
Dann würde es die Zusammenarbeit verweigern.
Das wollte ich nochmal probieren (an "echter" CCU anmelden und Werkseinstellungen). Bisher hatte ich es nur abgemeldet. Mach ich wenn ich wieder daheim bin.
Ein HW Defekt ist denke ich mal unwahrscheinlich, da ich das selbe Problem mit zwei verschiedenen Ventilen habe.

Ich habe allerdings festgestellt, dass sich FHEM die Ventile ungefragt einverleibt (ohne das pairForSec gesetzt wurde).
Da meine CCU und HM_CUL beide die Geräte empfangen können, ist es teilweise gar nicht so einfach sie an der CCU anzumelden, da FHEM meist schneller ist.
Mache ich da was falsch, oder ist das ein Fehler in HM_CUL?

Gruß,
Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 28 Februar 2023, 21:47:49
Hallo Jörg,

ZitatWäre trotzdem schön das irgendwie so zu handhaben, dass es keine Warning gibt. Mit der "Schwäche" müssen wir halt als Entwickler aktuell leben.
Ich habe die Funktion abgewandelt:

sub
AttrVal($$$)
{
#  my ($d,$n,$default) = @_;
  if (defined($_[0])) {
    my $a = $attr{$_[0]};
    if (defined($a)) {
      my $n = resolveAttrRename($_[0], $_[1]);
      return $a->{$n} if(defined($a->{$n}));
    }
  }
  return $_[2];
}

Natürlich sehe ich damit einen undef übergebenen Devicenamen nicht in gezeigter Form im Log. Das Verhalten ist aber bezüglich Rückgabe das gleiche, wie in Rudolfs Original (auch Rückgabe des Defaulwertes beabsichtigt(!) geliefert). Von daher vermute ich, dass der Fall des undefinierten Namens nur nicht vollständig bezüglich Nebenwirkungen bedacht wurde.

ZitatIch habe allerdings festgestellt, dass sich FHEM die Ventile ungefragt einverleibt (ohne das pairForSec gesetzt wurde).
Welche CUL_HM verwendest Du und hast Du autocreate aktiv?

Das "einverleiben" bedeutet nicht, dass gepairt wird, sondern nur, dass ein Device auf Grund einer empfangenen Anlernmessage angelegt wird.
Bei deaktiviertem autocreate geschieht dies jedoch nicht in meinen Versionen (so der Plan), weil ich nicht Nachbars oder zufällig empfangene devices aus dem System räumen müssen möchte.

Martin hatte da mal eine andere Vorstellung zu usabilty, um bei daktiviertem autocreate dennoch pairen zu können.

Ohne pairForSec sollte CUL_HM aber kein pairing durchziehen, sprich nicht die hmid im device setzen.
Nebenwirkung des angelegten devices dürfte aber autoack des (verzögert) zugewiesenen IOs zu dem device sein. get assignIDs beim CUL würde Dir das aufzeigen.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: Adimarantis am 03 März 2023, 09:16:38
Hi Ansgar,

in fhem.pl werde ich nichts patchen. Da möchte ich ja weiter updates machen können. Habs jetzt erstmal in TSCUL auskommentiert und da ich keinen Repeater habe setze ich das Flag einfach immer fest auf 0.
Mal sehen - wahrscheinlich brauchts das nicht mehr, wenn die Config wieder konsistent ist.

Mit Werksreset, pairen, getConfig, Ventil nochmal in pairing Modus hat er es jetzt akzeptiert.
Seltsam finde ich aber schon, dass die Devices in FHEM auftauchen und auch gepaired aussehen (in PairedTo stand immer schon die korrekte ID). Da denkt man es hat alles geklappt und trotzdem geht nix. Vielleicht kann man da noch was verbessern, damit es dem Anwender klar wird, dass es nicht gehen kann.

Unmittelbares Problem auf jeden Fall erstmal gelöst.

Danke,
Jörg
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 03 März 2023, 19:40:04
Hallo Jörg,

ZitatMit Werksreset, pairen, getConfig, Ventil nochmal in pairing Modus hat er es jetzt akzeptiert.
Schön, dass es doch noch geklappt hat.

ZitatSeltsam finde ich aber schon, dass die Devices in FHEM auftauchen und auch gepaired aussehen (in PairedTo stand immer schon die korrekte ID).
??? Wieso immer schon? War es schon mal mit FHEM gepairt und existierte noch?

Ansonsten sollte es frühestens mit dem pair Versuch gesetzt werden, eventuell zu früh, also schon beim Setzversuch und nicht erst beim Rücklesen der RegL_00.

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: Adimarantis am 03 März 2023, 20:37:05
Zitat von: noansi am 03 März 2023, 19:40:04
Ansonsten sollte es frühestens mit dem pair Versuch gesetzt werden, eventuell zu früh, also schon beim Setzversuch und nicht erst beim Rücklesen der RegL_00.
Das wäre was ich vermute habe. Gerade nochmal versucht das mit einem zweiten Ventil nachzustellen, aber kläglich gescheitert. Evtl. waren die Ventile bis zum Werksreset in einem seltsamen Zustand.
Habs sogar erst an der CCU angelernt, wieder abgelernt (aber ohne reset) und dann versucht am HM_CUL anzulernen - ohne Erfolg - aber auch ohne dass HM_CUL mehr als Version und Seriennummer angezeigt hätte.
Dann Werksreset und pairing erfolgreich und getConfig erfolgreich.

Eine Vermutung: Das Gerät war bei meinen Versuchen recht weit von der CUL weg. Ich hab es zwar nach dem vermeintlich erfolgreichen Pairing in die Nähe getragen, aber vielleicht ist beim Pairing selbst aufgrund der Entfernung was fehlgeschlagen, dass die ganze Sache aus dem Tritt gebracht hat.

Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 05 März 2023, 09:40:17
Hallo Jörg,

ich habe die Module hier aktualisiert https://forum.fhem.de/index.php/topic,24436.msg1167796.html#msg1167796 (https://forum.fhem.de/index.php/topic,24436.msg1167796.html#msg1167796)

Der Stacktrace sollte an der Stelle nicht mehr auftreten.
Kannst Du das bitte nochmal testen, sprich dabei auch den ursprünglichen Stacktrace Fall nachstellen?

Gruß, Ansgar.
Titel: Antw:Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: Adimarantis am 05 März 2023, 11:10:57
Danke. Schaut gut aus. Hab die 0.97 wiederhergestellt und es kamen wieder die Stacktraces. Dann die 0.98 eingespielt und es war Ruhe.

Gruß,
Jörg
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: exocet01 am 07 April 2023, 12:23:51
Hallo Ansgar,

ich hatte damals eine für Somfy angepasste CULFW für meinen CULV3 von dir bekommen. Jetzt habe ich aber einen nanoCUL433 gekauft. Könntest Du mir die FW auch für diesen posten?

Frohe Ostern  ;D
Eckart
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 11 April 2023, 21:19:29
Hallo Eckart,

im Anhang eine als VTS 0.40 "getarnte" Version für einen 433er nanoCUL.
Ungetestet, da ich keine Testhardware dafür habe.

Gruß, Ansgar.
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: exocet01 am 16 April 2023, 20:54:10
Hi Ansgar,

funktioniert leider nicht :-(
Rollos bewegen sich nicht
2023.04.16 20:41:11 4: SOMFY_sendCommand: Rollo_3 -> cmd :on:
2023.04.16 20:41:11 4: SOMFY_send Rollo_3 on: sA64008E3000008
2023.04.16 20:41:11 5: SOMFY_send Rollo_3 enc key : A6  rolling code : 08E3
2023.04.16 20:41:11 4: TSCUL_Write: CUL_0 sending YsA64008E3000008
2023.04.16 20:41:11 5: GET /fhem?detail=Rollo_3&fw_id= HTTP/1.1
2023.04.16 20:41:13 5: TSCUL_Read CUL_0: /NOCCA
2023.04.16 20:41:13 1: TSCUL_Parse: CUL_0 channel busy: NOCCA
2023.04.16 20:41:13 4: TSCUL_Parse: CUL_0 NOCCA
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 17 April 2023, 20:33:50
Hallo Eckart,

2023.04.16 20:41:13 1: TSCUL_Parse: CUL_0 channel busy: NOCCA
CUL_0 meint, etwas zu empfangen und sendet daher nicht.

List vom CUL_0 fehlt.

Setz mal CCAmode auf 0 und probiere es nochmal.

Gruß, Ansgar.
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: exocet01 am 22 April 2023, 16:20:12
Hi Ansgar,
setzen von CCAmode 0 und ein reboot des Raspberry haben geholfen. DANKE!

PS.: Hier trotzdem mal die List von CUL_0  ;)  :
Internals:
   CFGFN     
   CMDS       ABCFGJKRUVWXYehiltx
   Clients    STACKABLETS:STACKABLE:TSCUL_WS:TSCUL_NC7427:IT:CUL_FHTTK:CUL_HOERMANN:TSCUL_TX:CUL_IR:SOMFY:Revolt:ESA2000:TSCUL_RFR:TSCUL_EM:BS:USF1000:FS20:FHT.*:TSKS300:TSHMS:FS20V:UNIRoll:CUL_TCM97001:CUL_REDIRECT
   DEF        /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0@38400 1034
   DeviceName /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0@38400
   FD         24
   FHTID      1034
   FUUID      6443ead1-f33f-d1ce-5401-510706f751e4875c
   NAME       CUL_0
   NR         997
   PARTIAL   
   RAWMSG     
   STATE      Initialized
   TYPE       TSCUL
   VERSION    VTS 0.40 CSM433
   VERSION_HW nanoCUL_V1.x_0014
   VERSION_TS yes AES ChTblSize:209
   XmitOpen   0
   devioNoSTATE 1
   eventCount 5
   initString XP1C
X21
AM5
AHF11034
   MatchList:
     A:TSCUL_WS ^K[\dA-F]....
     B:TSCUL_NC7427 ^n..........
     C:IT       ^i.(?::.|.....)
     D:CUL_FHTTK ^T[\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F][\dA-F]
     E:CUL_HOERMANN ^R..........
     F:TSCUL_TX ^TX[A-F89].........
     G:CUL_IR   ^I............
     H:SOMFY    ^Y[r|t|s]:?[\dA-F]+
     I:Revolt   ^r......................$
     J:ESA2000  ^S................................$
     K:TSCUL_RFR ^[\dA-F][\dA-F][\dA-F][\dA-F]~
     L:TSCUL_EM ^E0.0[\dA-F]......
     M:FS20V    ^81..(?:04|0c)..0101a001......00[89a-f]...
     N:BS       ^81..(?:04|0c)..0101a001a5cf
     O:USF1000  ^81..(?:04|0c)..0101a001a5ceaa00....
     P:FS20     ^81..(?:04|0c)..0101a001
     Q:FHT      ^81..(?:04|09|0d)..(?:0909a001|83098301|c409c401)..
     R:TSKS300  ^810d04..4027a001
     T:TSHMS    ^810e04......a001
     U:UNIRoll  ^[0-9A-F]{5}(B|D|E)
     V:CUL_TCM97001 ^s[\dA-F]+
     W:CUL_REDIRECT ^o
     Y:STACKABLETS ^\*
     Z:STACKABLE ^\*
   READINGS:
     2023-04-22 16:12:18   SlowRfconf      freq:433.920MHz freqOffs:0.000kHz bWidth:325kHz freqIF:203.12kHz rAmpl:42dB sens:12dB dRate:2.461kBit/s
agcPrio:0 agcWait:16 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:0 AGC_FREEZE:0
CCAmode:0 csRelThr:10dB csAbsThr:7dB  peakfilter:88
     2023-04-22 16:12:18   Xmit-Events     disconnected:1 non-HM:2
     2023-04-22 16:12:18   ccconf          freq:433.920MHz freqOffs:0.000kHz bWidth:325kHz freqIF:203.12kHz rAmpl:42dB sens:12dB dRate:2.461kBit/s
agcPrio:0 agcWait:16 agcHyst:2 agcMaxLNA:0.0dB agcMaxDVGA:0 AGC_FREEZE:0
CCAmode:0 csRelThr:10dB csAbsThr:7dB
     2023-04-22 16:10:29   cmds             A B C F G J K R U V W X Y e h i l t x
     2023-04-22 16:12:18   cond            non-HM
     2023-04-22 16:12:18   peakfilter      88 µs
     2023-04-22 16:10:25   prot_disconnected last
     2023-04-22 16:12:18   prot_non-HM     last
     2023-04-22 16:10:31   state           Initialized
   helper:
     ChkPart    0
     RA_Timeout 0
     SVTS       1
     VTS        1
     VTS_ACK    1
     VTS_AES    1
     nRec       0
     recAlive   1
     recd       0
     DEVIOTS:
       RXfailTO   
     HM:
       ChTblSize  209
       hmCrdts    9
       ChTbl:
     cnd:
       250        2
       253        1
     hmLog:
       Resolve    1
       IDs:
     q:
       HMcndN     250
       answerPend 0
       hmLanQlen  1
     ref:
       ioBR       3840
       lHMt       4294967295
       lSys       1768572625.11227
       pngLm      80
       scF        1
Attributes:
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: exocet01 am 15 August 2023, 17:11:46
Hallo Ansgar,

ich habe jetzt einen Mischverbau und würde gerne die Scripte alle gleichziehen damit ich den Empfang etwas optimieren kann. Hierzu habe ich verstanden dass die Scripte auf dem neuesten Stand sein müssen um in den Logs die Info zu finden. Diese funktionieren ja aber nur mit der Version >0.4
Ich habe aktuell:
Könntest Du mir bitte die gleiche oder größere TSCULFW für den CUL868 und die Scripte bereitstellen?
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 15 August 2023, 19:44:19
Hallo Eckart,

ZitatKönntest Du mir bitte die gleiche oder größere TSCULFW für den CUL868 und die Scripte bereitstellen?
warum nimmst Du nicht die CUL_V3 Firmare, die Du schon hast?
Siehe https://forum.fhem.de/index.php?msg=1237832 (https://forum.fhem.de/index.php?msg=1237832)

Gruß, Ansgar.
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: exocet01 am 20 August 2023, 17:36:22
 ::) Oh Mann. Gute Frage  :))
Die FW ist nicht Frequenzabhängig, oder?
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 21 August 2023, 21:41:05
Hallo Eckart,

ZitatDie FW ist nicht Frequenzabhängig, oder?
Die mir bekannten busware CULs haben eine Kodierung für die Frequenz des Funkmoduls, die mittels Lötbrücken entsprechend gesetzt ist.
In der board.h kann man vor dem Compilieren einstellen, welches Verhalten man haben will.
Bei der tsculfw für den CUL V3 wird der Code für 868.3MHz und 433.92MHz meinerseits eincompiliert.
Somit dann beim boot über Eingänge abgefragt, wird die Frequenz dann entsprechend von der tsculfw eingestellt.

Beim nanoCUL compiliere ich normalerweise ebenfalls den Kodierungscode ein, für 868.3MHz, 433.92MHz und 915MHz. Board Pin A0 bzw. Prozessor Pin C0 (nach Masse verbunden) ist für 433.92MHz und Board Pin A1 bzw. Prozessor Pin C1 (nach Masse verbunden) ist für 915MHz. Beide Pins offen ist für 868.3MHz.

Da die Bauplanvorlagen für nanos dies jedoch nicht vorsehen, habe ich Dir die nanoCUL Firmware für fest 433.92MHz (enstprechend Deiner Hardwareinformation) compiliert (ebenfalls in der board.h wählbar).

Kommt also drauf an...

Selbstverständlich liegt es in der Nutzerverantwortung, sich über die Zulässigkeit der Nutzung der verschiedenen Funkfrequenzen landesspezifisch zu informieren und die Nutzung ggf. zu unterlassen!

Gruß, Ansgar.
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: Space_Teddy am 29 August 2023, 11:27:24
Servus,
ich muss leider nochmal nach den Basics fragen.
Also ich habe die TSCUL schon sein ca. 2 Jahren im Einsatz (V0.29) und seit paar Tagen bekomme ich von allen meinen HM Geräten keinen response mehr. Immer MISSING ACK oder ähnlichen. Keine Ahnung ob ein update irgendwas zerhauen hat, aber altiv irgendwas geändert habe ich nciht.
Jedenfalls habe ich auf V0.39 hochgezogen und bin mir nicht mehr sicher, was ich mit den *.pm files genau machen soll. War das a) einfach in das FHEM Verzeichnis kopieren? b) die files mit den äquivalenten "originale" ersetzen ,also umbenennen? c) etwas anderes damit anstellen?!?!?

Danke schön nochmal für die Aufklärung.

BTW: ein einfaches update auf V039 hat bei mir keine Veränderung gebracht. Entweder ist der Nano CUL mitlerweile EndOfLife, oder wie schon erwähnt ein FHEM update hat was verändert.

lg,
Chris
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 29 August 2023, 20:26:43
Hallo Chris,

Zitatwas ich mit den *.pm files genau machen soll.
1. Backup der vorhandenen .pm Dateien im fhem/FHEM Ordner erstellen.
2. Backup der fhem.cfg erstellen.
3. Die .pm Dateien aus der zip (https://forum.fhem.de/index.php?msg=1167796 (https://forum.fhem.de/index.php?msg=1167796)) in den fhem/FHEM Ordner kopieren, vorhandene überschreiben.
4. FHEM neu starten.

Zitatund seit paar Tagen bekomme ich von allen meinen HM Geräten keinen response mehr.
Mit null Infos zum Zustand (list von CUL, VCCU, Problemdevice etc.) und ggf. vorhandenen Log Daten bleibt die Glaskugel leider ziemlich ratlos.

Nur keinen response mehr und schalten angesprochene Aktoren noch? Werden regelmäßig sendende Geräte (z.B. Temperatursensoren) noch empfangen?

Ein Babbling Idiot im Empfangsbereich kann den Empfang aller Geräte durch CUL stören, sprich z.B. ein amoklaufender Sensor oder ein Aktor auf Dauersenden mit 868.3MHz.

Gruß, Ansgar.
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: Space_Teddy am 29 August 2023, 22:13:49
Hallo Ansgar,
besten Dank für die schnelle Antwort.
Da in der Beschreibung etwas von "händischer Bearbeitung der fhem.cfg" stand, habe ich lieber nochmal nachgefragt, aber mit dem kopieren/überschreiben der files lag ich ja schon mal gar nicht so falsch.
Bezüglich meines no response Problems schaue ich erstmal nach dem NanoCUL. Danach setze ich alle HM devices außer betrieb (danke für den Tip). Wenn das alles nichts hilfs rufe ich hier nochmal um Hilfe :)

schönen Abend,

Chris
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 30 August 2023, 22:45:41
Hallo Chris,

ZitatDa in der Beschreibung etwas von "händischer Bearbeitung der fhem.cfg" stand, habe ich lieber nochmal nachgefragt
Ich habe Dich so verstanden, dass Du das schon mal für Deinen vorherigen Stand gemacht hast?!?

ZitatDanach setze ich alle HM devices außer betrieb
Es kommen grundsätzlich auch andere auf 868.3Mhz sendende Geräte als Babbling Idiot in Frage. Bei mir war es mal ein WS Sensor, der mit leer werdenden Batterien auf Dauersenden ging und damit auch HM blockiert hat.

Gruß, Amsgar.
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: Space_Teddy am 03 September 2023, 14:39:27
Hi Amsgar,
kurze Rückmeldung. Also nach Update aller Devices mit leerer Batterie und Neueinstellung der CUL settings (Bandbreite, parable, etc.) läuft es wieder stabil. Keine Ahnung ob es am NanoCul oder an den Devices gelegen hat, vermute aber am CUL, da ich mit einem Ersatzstick keine übermäßigen Nachrichten gesehen habe und mein LimeSDR auch keinen Dauerträger erkannt hat.
Besten Dank schon mal für deine Hilfe.
;)
Chris
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: exocet01 am 06 September 2023, 16:08:02
Zitat von: noansi am 27 September 2022, 22:16:19Hallo Eckart,

prinzipiell hat der IT V1 Empfang im letzten Stand funktioniert. Allerdings gibt es einen Verwechslungsbereich mit IT V3 und HEEU, abhängig vom Timing der Fernbedienung.

Im Anhang eine neue als VTS 0.40 "getarnte" Version zum Testen.

Wäre schön, wenn Du auch IT V3 und HEEU Geräte hättest, denn ich habe für die die Timing Tolereanz deutlich eingeengt und Zusatzcode, um ggf. doch noch IT V1 zu interpretiern.

Der Zusatzcode dafür hat natürlich das Flash Limit gerissen und ich habe XLED deswegen weg gelassen. Damit ist LED Blinken nur noch "langweilig".  ;)

Nur mit den neueren FHEM Modulen und raw X29, sowie verbose 4 könntest Du auch noch das Timing raus bekommen. Dann kommt so was in das fhem Log:
2022.09.27 21:00:26.922 4: TSCUL_Parse: PIG2_WS433 raw SlowRf:
H 0 - s0
H 376 L896 s0
H 880 L328 s0
H 264 L880 s1
H 304 L864 s0
H 304 L872 s1
H 912 L312 s1
H 264 L920 s1
H 896 L256 s0
H 328 L872 s1
H 296 L864 s0
H 304 L904 s1
H 304 L856 s1
H 304 L912 s1
H 296 L872 s1
H 296 L880 s1
H 904 L320 s1
H 264 L912 s3
H 896 L264 s3
H 320 L872 s3
H 880 L296 s3
H 296 L912 s3
H 304 L856 s3
H 304 L912 s3
H 840 L312 s3.
2022.09.27 21:00:26.973 4: TSCUL_Parse: PIG2_WS433 raw SlowRf:
H 320 L9160 s0
H 312 L864 s2
H 880 L312 s5
H 320 L872 s5
H 304 L864 s5
H 304 L872 s5
H 904 L320 s5
H 264 L912 s5
H 896 L264 s5
H 320 L872 s5
H 296 L864 s5
H 304 L912 s5
H 296 L864 s5
H 296 L912 s5
H 296 L872 s5
H 296 L880 s5
H 904 L320 s5
H 256 L920 s5
H 896 L264 s5
H 320 L872 s5
H 896 L296 s5
H 288 L864 s5
H 304 L912 s5
H 296 L864 s5
H 888 L312 s5.
2022.09.27 21:00:26.984 4: TSCUL_Parse: PIG2_WS433 i4501513A -45
Die zweite Nachricht wird an der darin enthaltenen Pause erkannt.
itclock wäre dann aus der Pause
H 320 L9160 s0als Summe von H und L geteilt durch 32 relativ genau rauszulesen. In diesem Fall also (320+9160)/32 = 296.xx, was ich auch zum Senden verwendet habe.

Gruß, Ansgar.

Anscheinend senden mehrerer IT Geräte in der Umgebung. Ich habe jetzt im log so viele Einträge dass ich sie nicht mehr Eindeutig meinem Handsender zuordnen kann. Gibt es da eine Möglichkeit?

Und eine weitere Frage: Somfy sendet ja auf 433.42 MHz und IT auf 433.92. Kann man die Frequenz beim Somfy Device zuordnen? Gibt es eine Möglichkeit auch das Senden bei Somfy zu optimieren? Ich habe jetzt mal den CCA Mode 3 verwendet, weiß aber nicht was der macht und ob es was bringt.
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 06 September 2023, 23:38:02
Hallo Eckart,

ZitatAnscheinend senden mehrerer IT Geräte in der Umgebung.
Eher weniger IT Geräte, aber Du zeichnest so eben auch Rauschen auf.

ZitatIch habe jetzt im log so viele Einträge dass ich sie nicht mehr Eindeutig meinem Handsender zuordnen kann. Gibt es da eine Möglichkeit?
Nun, Deine Uhr sekundengenau mit der Uhr Deines FHEM Servers synchronisieren und auf die Uhr schauen, wann Du den Taster an dem Handsender drückst, Zeit merken/notieren und mit der Zeit im Log vergleichen. Mehrfach wiederholen mit gleicher Taste und dann siehst Du ähnliche Blöcke.
Methode des mühsamen Hinschauens.

ZitatKann man die Frequenz beim Somfy Device zuordnen?
Was meinst Du damit?
Beim Empfang gar nicht.
ZitatGibt es eine Möglichkeit auch das Senden bei Somfy zu optimieren?
Die Sendefrequenz ist im CUL vorgegeben und wird so genau gesendet, wie der CUL Toleranzen hat.
Bei der tsculfw habe ich noch die Möglichkeit eingebaut, mit YoXX (XX = hex Frequenzoffset, vgl. cc1101 Doku) das Frequenzoffsetbyte zu ändern und somit kann man die Sendefrequenz in Grenzen anpassen. Das SOMFY Modul müsste darauf angepasst werden.
Das Optimum zu finden wäre dann Probieren. Messmittel vorraus gesetzt, wäre zumindest ein Angleich auf die Handsenderfrequenz schneller möglich.

ZitatIch habe jetzt mal den CCA Mode 3 verwendet
Mehr als CCA Mode 1 macht bei Somfy keinen Sinn, weil die paket handling Funktionen des cc1101 dabei nicht zum Zuge kommen.
Damit (CCA Mode 1) schaut dann der CUL vor dem Senden, ob ein Trägersignal empfangen wird und wartet dann ggf., bis der Kanal frei ist.
csRelThr und csAbsThr bestimmen die Limits für die Signalerkennung. Wird der Kanal innerhalb von 2s nicht frei erkannt, wird gar nicht gesendet, sondern eine NOCCA Fehlermedung vom CUL zurück gegeben.
CCA Mode 0 sendet sofort ohne Prüfung.

Gruß, Ansgar.
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: exocet01 am 07 September 2023, 09:23:02
Hallo Ansgar,

OK, dann gehe ich mal den mühsamen Weg die IT clock zu bestimmen  ;)

Mit dem Zuordnen einer Frequenz zu einem Device Typ meine ich, ob man die Sendefrequenz abhängig vom Gerät ändern kann. Dies habe ich bei den IT Geräten gesehen, bei denen die Frequenz mit dem Parameter ITfrequency zuordnen kann.
Da ich an dem gleichen CUL 2 Gerätearten habe (Somfy mit 433,42 MHz und IT mit 433,92) MHz, hatte ich mir eine automatische Umschaltung vorgestellt.
Wenn ich den Offset am CUL ändere, dann beeinflusst das ja wahrscheinlich auch wieder die IT Steckdose.

Den CCA Mode habe ich mal auf 0 gesetzt. Bei CCA Mode 1 und der Meldung NOCCA wird nicht versucht den Befehl erneut zu senden, oder?

Viele Grüße,
Eckart
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 07 September 2023, 19:57:35
Hallo Eckart,

ZitatMit dem Zuordnen einer Frequenz zu einem Device Typ meine ich, ob man die Sendefrequenz abhängig vom Gerät ändern kann.
Bis jetzt nicht, mit dem angehängten Modul und tsculfw 0.40 schon. Mit Attribut SOMFYfreqOffs in kHz (Offset Bereich +/-202kHz) kann man damit die vorgegebene 433.42MHz Sendefrequenz per SOMFY device etwas fein tunen, wie bei IT mit ITfreqOffs.

ZitatDa ich an dem gleichen CUL 2 Gerätearten habe (Somfy mit 433,42 MHz und IT mit 433,92) MHz, hatte ich mir eine automatische Umschaltung vorgestellt.
Wenn ich den Offset am CUL ändere, dann beeinflusst das ja wahrscheinlich auch wieder die IT Steckdose.
Nein, bei IT wird ein andere Frequenzeinstellung und Offset verwendet.

ZitatDen CCA Mode habe ich mal auf 0 gesetzt. Bei CCA Mode 1 und der Meldung NOCCA wird nicht versucht den Befehl erneut zu senden, oder?
Korrekt.

Gruß, Ansgar.
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 09 September 2023, 18:19:25
tsculfw 0.39 Teil1
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 09 September 2023, 18:21:07
tsculfw 0.39 Teil2
Sorry aber Forum Limits erzwingen die Aufteilung.
perl module sind hier im Anhang: https://forum.fhem.de/index.php?msg=1167796 (https://forum.fhem.de/index.php?msg=1167796)
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: exocet01 am 11 September 2023, 20:51:48
ZitatMit dem Zuordnen einer Frequenz zu einem Device Typ meine ich, ob man die Sendefrequenz abhängig vom Gerät ändern kann.
Bis jetzt nicht, mit dem angehängten Modul und tsculfw 0.40 schon. Mit Attribut SOMFYfreqOffs in kHz (Offset Bereich +/-202kHz) kann man damit die vorgegebene 433.42MHz Sendefrequenz per SOMFY device etwas fein tunen, wie bei IT mit ITfreqOffs.

Vielen Dank!
So komme ich ja zumindestens mal fast an die 433.42 MHz ran. Vielleicht reicht das ja schon :-)
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 11 September 2023, 22:08:36
Hallo Eckart,

ZitatSo komme ich ja zumindestens mal fast an die 433.42 MHz ran. Vielleicht reicht das ja schon
Möglicherweise hast Du mich nicht richtig verstanden.
Für Somfy wird in der Firmware 433.42 MHz Sendefrequent verwendet. Mit dem Offset kannst Du einen Frequenzfehler des Sendemoduls korrigieren.
Ohne Messmöglichkeit der Sendefrequenz allerdings nur ein Stochern im Nebel.

Gruß, Ansgar
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: exocet01 am 12 September 2023, 23:38:25
Hallo Ansgar,

OK, verstehe. Das habe ich wirklich falsch verstanden. Ich muss mal schauen ob ich so ein Messmittel irgendwo auftreiben kann.
Da ich einen Handsender von SOMFY habe: Ist es ggf. möglich mit dem CUL die Frequenz dieses Senders zu prüfen und dann so einen Offset zu ermitteln?

Viele Grüße,
Eckart
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 14 September 2023, 22:09:58
Hallo Eckart,

ZitatDa ich einen Handsender von SOMFY habe: Ist es ggf. möglich mit dem CUL die Frequenz dieses Senders zu prüfen und dann so einen Offset zu ermitteln?
Nicht wirklich gut, da keine direkte Frequenzinfo ausgegeben wird.
Also nur mit SlowRf Empfangsfrequenz auf 433.42MHz einstellen, Offset variieren und den Offset mit bestem RSSI zum Senden verwenden. Die Fehlereinflüsse sind aber groß: Abstand Handsender zu CUL, Deine eigene Position beim Senden mit Handsender oder auch anderer Personen, andere gleichzeitig empfangene Signale und und und.

Mit z.B. HDSDR und einem passenden DVBT-Stick mit RTL2832 Chip kannst Du den interessanten Frequenzbereich visualisieren.
Damit dann Handsender- und CUL-Sendesignale vergleichen und CUL auf gleiche Sendefrequenz mit Offset korrigieren.

Das bedeutet jedoch noch nicht zwingend, dass Du damit auch das Optimium des/der Empfänger triffst, da auch die Toleranzen unterliegen dürften.

Bei IT macht der Zustand der Handsenderbatterie einen deutlichen Frequenzeinfluss, daher der Hinweis zu frischen Batterien, falls dies auch auf Somfy Handsender zutrifft.

Gruß, Ansgar.
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: Ralf9 am 06 Dezember 2023, 21:58:37
Hallo,

ich bin gerade dabei meine alternative Version des "00_SIGNALduino.pm" Moduls in "SIGNALduinoAdv.pm" umzubenennen.
Dadurch passt u.a. im 10_IT.pm Modul bei set die folgende Abfrage nicht mehr:
if ($io->{TYPE} ne "SIGNALduino") {eine Möglichkeit wäre
if ($io->{TYPE} !~ m/^SIGNALduino/) {
Ich habe gesehen, daß es für TSCUL ein angepasstes IT Modul gibt.
Wird auch das IT Modul vom fhem update für TSCUL verwendet?
Falls für TSCUL nur das angepasstes IT Modul verwendet wird, kann ich die Abfrage im IT Modul wie folgt ändern:
if ($io->{TYPE} eq "CUL") {Bei Bedarf kann ich noch folgendes einfügen und dann eine log Ausgabe und Rückmeldung machen, daß für TSCUL nicht die passende Version des IT MODUL verwendet wird
elsif ($io->{TYPE} eq "TSCUL") {
Gruß Ralf
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 07 Dezember 2023, 22:45:34
Hallo Ralf,

verdammt lang her... aber danke der Nachfrage!

ZitatWird auch das IT Modul vom fhem update für TSCUL verwendet?
Zunächst nein, ich hatte extra eine angepasste Version unter meine Module gepackt.

Auf die Schnelle und ohne Anspruch auf Vollständigkeit mal wesentliche Änderungen. Vielleicht möchtest Du auch mehr übernehmen.  ;)

Folgende Attributsfunktionalität kann bei Set ganz nützlich sein
# erstes aktives IODev ermitteln
  my @ionames = split(/,/, AttrVal($name, 'IODevList', ''));
  my $ioh;
  foreach my $ioname (@ionames) {
    $ioh = $defs{$ioname};
    if (   defined($ioh)
        && DevIoTS_getState($ioh) ne 'disconnected'
        && !IsDummy($ioname)) {
      AssignIoPort($hash, $ioname) if (   !defined($hash->{IODev})
                                       || ($hash->{IODev}->{NAME} ne $ioname));
      last if (defined($hash->{IODev}));
    }
  }

  my $io = $hash->{IODev};
  return 'no IODev available, adapt attribute IODevList' if (!defined($io));

Statt DevIoTS_getState geht auch DevIo_getState.

Attribute zur Ergänzung:
  $hash->{AttrList}  = 'IODevList dummy:1,0 '.
                       'ITfrequency '.
                       'ITfreqOffs '.
                       'ITrepetition '.
                       'ITclock '.
                       'protocol:V1,V3,HE_EU,SBC_FreeTec,HE800 '.
                       'userV1setCodes '.
                       'switch_rfmode:1,0 '.
                       'do_not_notify:1,0 '.
                       'ignore:0,1 '.
                       'SIGNALduinoProtocolId '.
                       'unit '.
                       'group '.
                       'model:'.join(',', sort keys %models).' '.
                       $readingFnAttributes;

    <a id="IT-attr-IODevList"></a>
    <li>IODevList<br>
        Sets a ',' seperated list of usable IOs or physical devices
        which should be used for sending signals for this "logical" device.
        The first active from the list is used. An example for the physical device is a CUL.<br>
        Note: On startup, fhem DOES NOT assign an InterTechno device to an
        IO-Device! The attribute IODevList needs to be used ALWAYS!</li><br>


    <a id="IT-attr-IODevList"></a>
    <li>IODevList<br>
        Spezifiziert eine ',' sparierte Liste von physischen Ger&auml;ten, die die Ausstrahlung der Befehle f&uuml;r das
        "logische" Ger&auml;t ausf&uuml;hren. Das erste aktive aus der Liste wird genutzt.
        Ein Beispiel f&uuml;r ein physisches Ger&auml;t ist ein CUL.<br>
        Anmerkung: Beim Start weist fhem einem InterTechno-Ger&auml;t kein IO-Ger&auml;t zu.
        Das Attribut IODevList ist IMMER zu setzen.</li><br>


tscul unterstützt auch ITfreqOffs in kHz, also einen Offset zur Sendefrequenz entsprechend dem cc1101 Offset Register.
Vor dem Senden sieht es bei mir so aus:
    ## Do we need to change RFMode to SlowRF??
    if (AttrVal($name, 'switch_rfmode', '0')) {            # do we need to change RFMode of IODev
      $oldIOMode = $attr{$io->{NAME}}{rfmode} ? $attr{$io->{NAME}}{rfmode} : 'SlowRF';
      CallFn($io->{NAME}, 'AttrFn', 'set', ($io->{NAME}, 'rfmode', 'SlowRF'));
    }

    ## Do we need to change ITClock ??
    if (defined($sndmsg = AttrVal($name, 'ITclock', undef))) {
      CallFn($io->{NAME}, 'SetFn', $io, ($io->{NAME}, 'ITClock', $sndmsg));
#      Log3 $name, 1, "IT set ITclock: $sndmsg for $io->{NAME}";
    }

    ## Do we need to change ITrepetition ??
    if (   ($sndmsg = AttrVal($name, 'ITrepetition', 0))
        || $dimrep) {
      my $itrep = $dimrep ? $dimrep+3 : $sndmsg;
      $itrep = 144 if ($itrep > 144); # tsculfw sends ITrepetition+1 times, 8-bit value, 144 max.
      $sndmsg = "isr$itrep";
      CallFn($io->{NAME}, 'SetFn', $io, ($io->{NAME}, 'raw', $sndmsg)); # if not set before send the tsculfw default is 3 and reverts to it after send
#      Log3 $name,1, "IT set ITrepetition: $sndmsg for $io->{NAME}";
    }

    ## Do we need to change ITfrequency ??
    if (defined($sndmsg = AttrVal($name, 'ITfrequency', undef))) {
      my $f = int($sndmsg*65536/26+0.5);
      my $f2 = sprintf('%02x', int($f / 65536));
      my $f1 = sprintf('%02x', int(($f % 65536) / 256));
      my $f0 = sprintf('%02x', $f % 256);

      #my $arg = sprintf('%.3f', (hex($f2)*65536+hex($f1)*256+hex($f0))*26/65536*26);
      #Log3 $name, 3, "Setting ITfrequency (0D,0E,0F) to 0x$f2 0x$f1 0x$f0 = $arg MHz";
      CallFn($io->{NAME}, 'SetFn', $io, ($io->{NAME}, 'raw', "if$f2$f1$f0"));
    }

    ## Do we need to change ITfreqOffs ??
    if (defined($sndmsg = AttrVal($name, 'ITfreqOffs', undef))) {
      my $o = int(($sndmsg * (1 << 14) / 26000) + (($sndmsg >= 0)?0.5:-0.5));
      $o += 256 if ($o < 0);
      $o = 0   if ($o < 0);
      $o = 255 if ($o > 255);
      $o = sprintf('%02x', $o);

#      my $arg = hex($o);
#      $arg -= 256 if ($arg >= 128);
#      $arg *= 26000 / (1 << 14);
 #     Log3 $name, 1, "Setting ITfreqOffs (0C) to 0x$o = $arg kHz";
      CallFn($io->{NAME}, 'SetFn', $io, ($io->{NAME}, 'raw', "io$o"));
    }
  }

nach dem Senden schrumpft es zusammen zu:
    # das IODev ist kein SIGNALduino
    ## Send Message to IODev
    CallFn($io->{NAME}, 'SetFn', $io, (' ', 'raw', $sndmsg));  # tsculfw VTS0.32+ resets frequency, offset, ITrepetition and ITclock back to firmware default values after send

    ## Do we need to change RFMode back to HomeMatic??
    if (AttrVal($name, 'switch_rfmode', '0')) {            # do we need to change RFMode of IODev
      CallFn($io->{NAME}, 'AttrFn', 'set', ($io->{NAME}, 'rfmode', $oldIOMode));
    }
Die Rückmeldung wird nicht ausgewertet.

Dein Vorschlag zu einem Hinweis auf falsches Modul ist natürlich auch schon hilfreich.  :)

Viele Grüße, Ansgar.
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: Ralf9 am 08 Dezember 2023, 19:34:53
Ich habe beim Senden anpassungen für TSCUL eingebaut
https://github.com/Ralf9/10_IT/commit/e1220e96139dc90e05d08b6643a13289ee5ba6a3
https://github.com/Ralf9/10_IT/blob/master/FHEM/10_IT.pm
bitte mal drüber schauen und testen ob damit das IT Modul auch mit dem TSCUL verwendet werden kann.

Zitattscul unterstützt auch ITfreqOffs in kHz, also einen Offset zur Sendefrequenz entsprechend dem cc1101 Offset Register.
Log3 $name, 1, "Setting ITfreqOffs (0C) to 0x$o = $arg kHz";
CallFn($io->{NAME}, 'SetFn', $io, ($io->{NAME}, 'raw', "io$o"));
Wird der raw Befehl "io" auch von der a-culw und culw Firmware unterstützt?

Gruß Ralf
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 08 Dezember 2023, 23:10:40
Hallo Ralf,

ZitatWird der raw Befehl "io" auch von der a-culw und culw Firmware unterstützt?
Nicht, dass es mir bekannt wäre.

Zitatbitte mal drüber schauen ob damit das IT Modul auch mit dem TSCUL verwendet werden kann.

    return 'IODev does not support IT' if (defined($io->{CMDS}) && $io->{CMDS} !~ m/i/); #CUL muss das i Kommando kennen
war korrekter, da sowohl bei CUL (culfw und a-culfw), als auch bei TSCUL das 'i' Kommando optional zu compilieren ist.

return 'IODev does not support IT' if ($io->{TYPE} !~ m/^(?:TS)?CUL$/ || (defined($io->{CMDS}) && $io->{CMDS} !~ m/i/)); # TSCUL/CUL wird unterstützt und muss das i Kommando kennenwürde es wohl besser treffen?

Für ITrepetition gibt es bei tsculfw eine Einschränkung bei der Anzahl und es gibt kein feedback, also nur set statt get (hier hakt es dann mangels feedback):
    ## Do we need to change ITrepetition ??
    if (   ($message = AttrVal($name, 'ITrepetition', 0))
        || $dimrep) {
      my $itrep = $dimrep ? $dimrep+3 : $message;
      $itrep = 144 if ($itrep > 144); # tsculfw sends ITrepetition+1 times, 8-bit value, 144 max.
      $message = "isr$itrep";
      CallFn($io->{NAME}, 'SetFn', $io, ($io->{NAME}, 'raw', $message)); # if not set before send the tsculfw default is 3 and reverts to it after send
#      Log3 $name,1, "IT set ITrepetition: $message for $io->{NAME}";
    }
Einen Wert > 144 bis 255 kannst Du aber setzen, jedoch begrenzt die Firmware intern auf 144.

auch beim setzen der Frequenz gibt es kein feedback von der tsculfw, wozu auch? Also hakt es auch hier.
    ## Do we need to change ITfrequency ??
    if (defined($sndmsg = AttrVal($name, 'ITfrequency', undef))) {
      my $f = int($sndmsg*65536/26+0.5);
      my $f2 = sprintf('%02x', int($f / 65536));
      my $f1 = sprintf('%02x', int(($f % 65536) / 256));
      my $f0 = sprintf('%02x', $f % 256);

      #my $arg = sprintf('%.3f', (hex($f2)*65536+hex($f1)*256+hex($f0))*26/65536*26);
      #Log3 $name, 3, "Setting ITfrequency (0D,0E,0F) to 0x$f2 0x$f1 0x$f0 = $arg MHz";
      CallFn($io->{NAME}, 'SetFn', $io, ($io->{NAME}, 'raw', "if$f2$f1$f0"));
    }

rfMode setzen habe ich allgemeiner gehalten, da es nicht nur homematic als mode gibt:

  my $oldIOMode;...
    ## Do we need to change RFMode to SlowRF??
    if (AttrVal($name, 'switch_rfmode', '0')) {            # do we need to change RFMode of IODev
      $oldIOMode = $attr{$io->{NAME}}{rfmode} ? $attr{$io->{NAME}}{rfmode} : 'SlowRF';
      CallFn($io->{NAME}, 'AttrFn', 'set', ($io->{NAME}, 'rfmode', 'SlowRF'));
    }
...
    ## Do we need to change RFMode back to HomeMatic??
    if (AttrVal($name, 'switch_rfmode', '0')) {            # do we need to change RFMode of IODev
      CallFn($io->{NAME}, 'AttrFn', 'set', ($io->{NAME}, 'rfmode', $oldIOMode));
    }

ist das Ergebnis des "Trockenlaufs", also Code anschauen.

Gruß, Ansgar.
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: Ralf9 am 08 Dezember 2023, 23:30:34
ZitatEinen Wert > 144 bis 255 kannst Du aber setzen, jedoch begrenzt die Firmware intern auf 144.
So hohe Werte machen aber sowiso keinen Sinn

ZitatFür ITrepetition ... und es gibt kein feedback, also nur set statt get (hier hakt es dann mangels feedback):
auch beim setzen der Frequenz gibt es kein feedback von der tsculfw, wozu auch? Also hakt es auch hier.
Dann muß ich da wo es ein "CallFn($io->{NAME}, "GetFn"" gibt, eine Abfrage machen:
if (Type gleich Cul) {
 CallFn($io->{NAME}, "GetFn"...
else
 CallFn($io->{NAME}, "SetFn"...

Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 09 Dezember 2023, 12:42:30
Hallo Ralf,

wenn ich es richtig gesehen und verstanden habe, dann hast Du HE800 und HE_EU zum Senden mit SIGNALduino ergänzt, richtig?

Ich habe mal meine Variante dahingehend angepasst und CUL als CUL behandelt, wie Du es machen willst inklusive SIGNALduinoadv Toleranz, siehe Anhang.

So hohe Werte machen aber sowiso keinen SinnKommt drauf an. es gibt auch Dimmer, die während gedrückter Taste Dimmen. Wenn man damit spielen will, dann werden mehr Wiederholungen gebraucht. Automatisiert vernüftig dimmen läßt sich damit leider nicht wirklich, aber da kommt das 144er Limit bei mir her.

Gruß, Ansgar.
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 10 Dezember 2023, 18:32:02
Hallo Ralf,

ich habe nochmal einige Korrekturen und Verbesserungen eingepflegt, die mir noch aufgefallen sind.

Gruß, Ansgar.
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: Ralf9 am 10 Dezember 2023, 21:21:48
Ich hab mal drüber geschaut, Du hast Da einiges geändert.
Ich werde nur ein Teil übernehmen, vieles verstehe ich nicht.

Wo in welchem Fall wird das $hash->{OLDDEF} definiert?
  if ($hash->{OLDDEF}) {
    delete($hash->{CODE}{1});
    my @b = split(/[ \t]+/, $hash->{OLDDEF}, 2);
    delete($modules{IT}{defptr}{lc($b[0])}{$name});
    delete($hash->{READINGS}{protocol});
    delete($hash->{READINGS}{mode});
    delete($hash->{READINGS}{unit});
    delete($hash->{READINGS}{group});
    for my $c (keys(%it_c2b)) {
      delete($hash->{$c});
    }
  }

Zitatmy $ioTsculfw        = ($io->{TYPE} eq 'TSCUL' && $io->{helper}{SVTS});
Damit wird es als CUL behandelt, wenn $io->{helper}{SVTS} nicht definiert ist.
Ich werde es ohne das $io->{helper}{SVTS} einbauen.
my $ioTsculfw        = ($io->{TYPE} eq 'TSCUL');
Gruß Ralf
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 11 Dezember 2023, 06:32:47
Hallo Ralf,

Wo in welchem Fall wird das $hash->{OLDDEF} definiert?Das wird bei CommandModify definiert. In der fhem.pl findest Du es.

Damit wird es als CUL behandelt, wenn $io->{helper}{SVTS} nicht definiert ist.$io->{helper}{SVTS} ist eine Info, dass es eine tsculfw bedient, die SlowRf hat. Es beruht auf der Abfrage, dass die Firmware Version mit VTS anfängt.
Wenn es nicht existiert, dann wurde ein CUL mit cufw oder a-culfw als TSCUL definiert. Und dann würde sich das i Kommando entsprechend anders verhalten, wie bei CUL.

Gruß, Ansgar.
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: Ralf9 am 12 Dezember 2023, 22:46:12
Hallo Ansgar,

ich habe ein Teil Deiner änderungen übernommen, nun müsste das set auch mit dem TSCUL funktionieren.

https://github.com/Ralf9/10_IT/commit/a1b24db77cddc4c00bc76223e4680ba6e0a77b85
https://github.com/Ralf9/10_IT/blob/master/FHEM/10_IT.pm

ZitatDas wird bei CommandModify definiert. In der fhem.pl findest Du es.
Danke, damit ist es klar.

Gruß Ralf
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 13 Dezember 2023, 12:08:50
Hallo Ralf,

Zitatich habe ein Teil Deiner änderungen übernommen, nun müsste das set auch mit dem TSCUL funktionieren.
Ich habe nicht nur über die Code Änderungen geschaut, sondern auch real getestet.
Es wird damit mit TSCUL und tsculfw gesendet.  :)

Was mir jedoch aufgefallen ist.
Im Code bist Du meinem Hinweis zum notwendigen Check auf das i-Kommando auch für CUL nicht gefolgt. Warum?
return "IODev $io->{NAME} does not support IT" if ($ioTsculfw && defined($io->{CMDS}) && $io->{CMDS} !~ m/i/); # TSCUL muss das i Kommando kennen
Auch CUL muss das i Kommando kennen. Man kann beim Compilieren das Senden von IT in der board.h weg lassen (HAS_INTERTECHNO nicht definieren -> kein i Kommando). Mit HAS_IT kann man dennoch den IT Empfang in die Firmware compilieren.

Dann fällt mir weiter auf, dass gesendete IT HE und HEEU Telegramme mit Hinweis auf Längenfehler nicht dekodiert werden können.
Hier mal ein Log Auszug dazu. Gesendet wurde über CUNO2_WS868 und empfangen über PIG_WS433, jeweils mit tsculfw, mal mit Deiner Version 20839 2023-12-12 18:00:00Z Ralf9 gesendet und dekodiert und mal mit meiner 10_IT.pm 18090k 2023-12-10 00:00:00Z noansi gesendet und dekodiert.
Version Ralf9 HE
2023.12.13 08:14:41.348 4: TSCUL_Parse: PIG_WS433 ihD9D0E6101B -60.5
2023.12.13 08:14:41.491 4: TSCUL_Parse: CUNO2_WS868 ish1101100111010000111001100001
2023.12.13 08:14:41.497 3: PIG_WS433 IT: message "ihd9d0e610" (10) too short!
2023.12.13 08:14:42.903 4: TSCUL_Parse: PIG_WS433 ihD9C114501B -60.5
2023.12.13 08:14:43.005 3: PIG_WS433 IT: message "ihd9c11450" (10) too short!
2023.12.13 08:14:43.026 4: TSCUL_Parse: CUNO2_WS868 ish1101100111000001000101000101
Version noansi HE
2023.12.13 08:44:44.498 4: TSCUL_Parse: PIG_WS433 ihD9D0E6101D -59.5
2023.12.13 08:44:44.636 4: PIG_WS433 IT: msgcode "1101100111010000111001100001" (28) bin = 11011001110100001110011000010000
2023.12.13 08:44:44.638 4: receiverID: 1 OFF/ON/DIM: 1 Rolling-Code: 1 Transmitter-ID: 1234
2023.12.13 08:44:44.680 4: TSCUL_Parse: CUNO2_WS868 ish1101100111010000111001100001
2023.12.13 08:44:45.509 4: TSCUL_Parse: PIG_WS433 ihD9C114501D -59.5
2023.12.13 08:44:45.648 4: TSCUL_Parse: CUNO2_WS868 ish1101100111000001000101000101
2023.12.13 08:44:45.652 4: PIG_WS433 IT: msgcode "1101100111000001000101000101" (28) bin = 11011001110000010001010001010000
2023.12.13 08:44:45.654 4: receiverID: 1 OFF/ON/DIM: 0 Rolling-Code: 2 Transmitter-ID: 1234

Version Ralf9 HEEU
2023.12.13 08:15:38.349 4: TSCUL_Parse: PIG_WS433 ih3CCF33CCF33EC20018 -62
2023.12.13 08:15:38.452 3: PIG_WS433 IT: message "ih3ccf33ccf33ec200" (18) too short!
2023.12.13 08:15:38.475 4: TSCUL_Parse: CUNO2_WS868 ise001111001100111100110011110011001111001100111110110000100
2023.12.13 08:15:39.899 4: TSCUL_Parse: PIG_WS433 ih3CCF33CCF33DC20019 -61.5
2023.12.13 08:15:40.001 3: PIG_WS433 IT: message "ih3ccf33ccf33dc200" (18) too short!
2023.12.13 08:15:40.024 4: TSCUL_Parse: CUNO2_WS868 ise001111001100111100110011110011001111001100111101110000100
Version noansi HEEU
2023.12.13 08:44:48.272 4: TSCUL_Parse: PIG_WS433 ih3CCF33CCF33EC2001A -61
2023.12.13 08:44:48.413 4: TSCUL_Parse: CUNO2_WS868 ise001111001100111100110011110011001111001100111110110000100
2023.12.13 08:44:48.417 4: PIG_WS433 IT: msgcode "001111001100111100110011110011001111001100111110110000100" (57) bin = 001111001100111100110011110011001111001100111110110000100000
2023.12.13 08:44:49.539 4: TSCUL_Parse: PIG_WS433 ih3CCF33CCF33DC2001A -61
2023.12.13 08:44:49.642 4: PIG_WS433 IT: msgcode "001111001100111100110011110011001111001100111101110000100" (57) bin = 001111001100111100110011110011001111001100111101110000100000
2023.12.13 08:44:49.682 4: TSCUL_Parse: CUNO2_WS868 ise001111001100111100110011110011001111001100111101110000100

Hier noch die Definition des Test HE devices:
define ITSteckdose433_ITHE IT HE800 1234 1
attr ITSteckdose433_ITHE IODevList CUNO2_WS868
attr ITSteckdose433_ITHE protocol HE800
attr ITSteckdose433_ITHE room Tests
und des HEEU Test devices:
define ITSteckdose433_ITHEEU IT 0011110011001111001100111100110011110011001111 0 0000100
attr ITSteckdose433_ITHEEU IODevList CUNO2_WS868
attr ITSteckdose433_ITHEEU protocol HE_EU
attr ITSteckdose433_ITHEEU room Tests

Da ich den Empfang nur mit dem testen kann, was ich via tsculfw sende weil ich kein itV3, itHE oder itHEEU Gerät besitze, erhebe ich keinen Anspruch auf Richtigkeit.
Logisch wäre es aber schon, dass das gesendete Telegramm auch wieder empfangen und dekodiert werden kann, sollten die realen Geräte ja auch damit können.
Wenn die Fernbedienung sendet, sollte der neue Status beim fhem IT device entsprechend Empfang auch angezeigt werden können.
Vielleicht kannst Du mir den Widerspruch auch erklären?

Gruß, Ansgar.
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: Ralf9 am 13 Dezember 2023, 17:04:04
Hallo Ansgar,

ZitatIm Code bist Du meinem Hinweis zum notwendigen Check auf das i-Kommando auch für CUL nicht gefolgt. Warum?
Ich kann nicht abschätzen wie zuverlässig die Abfrage der CMDS in der 00_cul DoInit funktioniert.
Falls es mal Probleme bei der Abfrage der CMDS geben sollte, würde das Senden eines i-Kommando nicht funktionieren.

ZitatDann fällt mir weiter auf, dass gesendete IT HE und HEEU Telegramme mit Hinweis auf Längenfehler nicht dekodiert werden können.
Ich habe mal mit einer Homeeasy Fernbedienung IT HE gesendet, das wurde problemlos vom sduino und nanocul empfangen.

Beim senden vom nanocul zum sduino konnte ich auch keine Probleme erkennen
2023.12.13 16:26:52.342 3: CULnano IT_set: IT_HE800_1234_1 on
2023.12.13 16:26:52.347 5: CULnano IT_set: Type=CUL Protocol=HE800
2023.12.13 16:26:52.351 5: mode is 1
2023.12.13 16:26:52.351 4: msg 228396641 - bin1 1101100111010000111001100001
2023.12.13 16:26:52.637 5: IT_Set: GetFn(raw): message = ish1101100111010000111001100001 Antwort =   raw => ish1101100111010000111001100001
2023.12.13 16:26:52.638 4: sduinoA/msg READredu: MS;P0=-1008;P2=-4970;P3=331;P4=1014;P5=-317;D=3230304530304545303030453045454545303030454530304545454530;CP=3;SP=2;R=119;O;b=89;s=1;m0;
2023.12.13 16:26:52.638 4: sduinoA: Matched MS Protocol id 35 -> HomeEasy HE800, bitLen=28
2023.12.13 16:26:52.638 5: sduinoA: Starting demodulation at Position 2
2023.12.13 16:26:52.638 5: sduinoA: dispatching bits: 1 1 0 1 1 0 0 1 1 1 0 1 0 0 0 0 1 1 1 0 0 1 1 0 0 0 0 1
2023.12.13 16:26:52.638 5: sduinoA: applying postDemodulation , value before : 1 1 0 1 1 0 0 1 1 1 0 1 0 0 0 0 1 1 1 0 0 1 1 0 0 0 0 1
2023.12.13 16:26:52.638 5: sduinoA: rcode=1, modified after postDemodulation: 1 1 0 1 1 0 0 1 1 1 0 1 0 0 0 0 1 1 1 0 0 1 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0
2023.12.13 16:26:52.638 4: sduinoA: Decoded MS Protocol id 35 dmsg ihD9D0E61000 length 40 RSSI = -14.5
2023.12.13 16:26:52.639 5: sduinoA: dispatch ihD9D0E61000
2023.12.13 16:26:52.639 4: sduinoA IT: message "ihD9D0E61000" (12)
2023.12.13 16:26:52.639 4: sduinoA IT: msgcode "1101100111010000111001100001" (28) bin = 11011001110100001110011000010000
2023.12.13 16:26:52.639 4: sduinoA IT: msg:ihD9D0E61000 msgcode:D9D0E610
2023.12.13 16:26:52.639 4: sduinoA IT: HEX:ihD9D0E61000 DEC:3654346256
2023.12.13 16:26:52.639 4: sduinoA IT: DEC:40038814
2023.12.13 16:26:52.639 4: sduinoA IT: DEC:160155256
2023.12.13 16:26:52.639 4: sduinoA IT: mn: 8 7 6 12 11 8 0
2023.12.13 16:26:52.639 4: sduinoA IT: mn: 1 6 2 13 4 0 0
2023.12.13 16:26:52.639 4: receiverID    : 1
2023.12.13 16:26:52.639 4: OFF/ON/DIM    : 1
2023.12.13 16:26:52.639 4: Rolling-Code  : 1
2023.12.13 16:26:52.639 4: Transmitter-ID: 1234
2023.12.13 16:26:52.639 3: sduinoA IT: IT_HE800_1234_1 on->on
2023-12-13 16:26:52.344 IT IT_HE800_1234_1 on
2023-12-13 16:26:52.348 IT IT_HE800_1234_1 lastDimValue:
2023-12-13 16:26:52.637 CUL CULnano raw: ish1101100111010000111001100001
2023-12-13 16:26:52.640 IT IT_HE800_1234_1 on
2023-12-13 16:26:52.640 IT IT_HE800_1234_1 RAWMSG: MS;P0=-1008;P2=-4970;P3=331;P4=1014;P5=-317;D=3230304530304545303030453045454545303030454530304545454530;CP=3;SP=2;R=119;O;b=89;s=1;m0;
2023-12-13 16:26:52.640 IT IT_HE800_1234_1 DMSG: ihD9D0E61000
2023-12-13 16:26:52.640 IT IT_HE800_1234_1 Protocol_ID: 35
2023-12-13 16:26:52.640 IT IT_HE800_1234_1 RSSI: -14.5

Vom sduino zum nanocul wars auch problemlos
2023.12.13 16:30:15.818 3: sduinoA IT_set: IT_HE800_1234_1 on
2023.12.13 16:30:15.823 5: sduinoA IT_set: Type=SIGNALduinoAdv Protocol=HE800
2023.12.13 16:30:15.828 5: mode is 1
2023.12.13 16:30:15.828 4: msg 228396641 - bin1 1101100111010000111001100001
2023.12.13 16:30:15.828 4: sduinoA IT_set: sendMsg=P35#1101100111010000111001100001#R6
2023.12.13 16:30:15.828 5: sduinoA: sendmsg Preparing rawsend command for protocol=35, repeats=6, clock=280 bits=1101100111010000111001100001
2023.12.13 16:30:15.829 4: sduinoA/set: sending via SendMsg: SR;R=6;P0=280;P1=-5040;P2=-1120;P3=952;P4=-280;D=0102023402023434020202340234343434020202343402023434343402;
2023-12-13 16:30:15.823 IT IT_HE800_1234_1 on
2023-12-13 16:30:15.828 IT IT_HE800_1234_1 lastDimValue:
2023.12.13 16:30:15.942 4: sduinoA SendrawFromQueue: msg=SR;R=6;P0=280;P1=-5040;P2=-1120;P3=952;P4=-280;D=0102023402023434020202340234343434020202343402023434343402;
2023.12.13 16:30:16.048 4: CUL_Parse: CULnano ihD9D0E61071
2023.12.13 16:30:16.049 4: CULnano IT: message "ihd9d0e61071" (12)
2023.12.13 16:30:16.049 4: CULnano IT: msgcode "1101100111010000111001100001" (28) bin = 11011001110100001110011000010000
2023.12.13 16:30:16.049 4: CULnano IT: msg:ihd9d0e61071 msgcode:d9d0e610
2023.12.13 16:30:16.049 4: CULnano IT: HEX:ihd9d0e61071 DEC:3654346256
2023.12.13 16:30:16.049 4: CULnano IT: DEC:40038814
2023.12.13 16:30:16.049 4: CULnano IT: DEC:160155256
2023.12.13 16:30:16.049 4: CULnano IT: mn: 8 7 6 12 11 8 0
2023.12.13 16:30:16.049 4: CULnano IT: mn: 1 6 2 13 4 0 0
2023.12.13 16:30:16.049 4: receiverID    : 1
2023.12.13 16:30:16.049 4: OFF/ON/DIM    : 1
2023.12.13 16:30:16.049 4: Rolling-Code  : 1
2023.12.13 16:30:16.049 4: Transmitter-ID: 1234
2023.12.13 16:30:16.049 3: CULnano IT: IT_HE800_1234_1 on->on
2023-12-13 16:30:16.052 IT IT_HE800_1234_1 on

Gruß Ralf
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 13 Dezember 2023, 18:06:30
Hallo Ralf,

ZitatIch kann nicht abschätzen wie zuverlässig die Abfrage der CMDS in der 00_cul DoInit funktioniert.
Falls es mal Probleme bei der Abfrage der CMDS geben sollte, würde das Senden eines i-Kommando nicht funktionieren.
Dann darfst Du die Abfrage gar nicht machen.

Zur Zuverlässigkeit kann ich nur für Rf-Router angebundene TSCULs sagen, dass die CMDs Abfrage mal scheitern kann, weil das Protokoll ohne Rückmeldung läuft, damit also die Abfrage oder Antwort auf die Cmds-Abfrage verloren gehen kann.
Ich würde allerdings auf diesem Weg auch nichts einschalten, eben genau deswegen. Rf-Router ist nur geeignet, um verlustbehaftet Sensordaten von weiter entfernten Sensoren zu empfangen.

ZitatVom sduino zum nanocul wars auch problemlos
Ahhh, ich sehe das Problem. In 00_CUL.pm wird in CUL_Parse der RSSI für die ih messages nicht abgetrennt.
  if($dmsg =~ m/^[AFTKEHRStZrib]([A-F0-9][A-F0-9])+$/) { # RSSI

Bei TSCUL in TSCUL_Parse dagegen schon, wie es (aus meiner Sicht) richtig ist.

Deswegen siehst Du zusätzlich immer 2 HEX Zeichen vom RSSI mehr am Ende bei ih messages.
Also noch ein Unterschied mehr bei TSCUL, den Du diesmal beim Parse berücksichtigen musst.

Daher hatte ich seinerzeits beide Längenvarianten für ih messages in 10_IT.pm zugelassen.
Die RSSI Codierung ist prinzipell zunächst CUL spezifisch und sollte daher auch in 00_CUL.pm dekodiert werden.

Gruß, Ansgar.
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: Ralf9 am 13 Dezember 2023, 19:09:00
Dann muß ich am Anfang vom IT_Parse noch die Abfrage "if ($hash->{TYPE} eq 'TSCUL' .." einbauen
  if ((substr($msg, 0, 1)) ne 'i') {
    Log3 $hash,4,"$ioname IT: message not supported by IT \"$msg\"!";
    return '';
  }
  if ($hash->{TYPE} eq 'TSCUL' && substr($msg, 1, 1) eq 'h') {
    $msg .= '00';
    Log3 $hash,4,"$ioname IT: TYPE=TSCUL, add 00 at then end";
  }

Warum werden bei der TSCUL nur bei den ih messages die 2 HEX Zeichen vom RSSI entfernt und nicht auch bei IT V1 und V3?
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 13 Dezember 2023, 23:35:29
Hallo Ralf,

ZitatWarum werden bei der TSCUL nur bei den ih messages die 2 HEX Zeichen vom RSSI entfernt und nicht auch bei IT V1 und V3?
Bei TSCUL werden die RSSI Zeichen sowohl bei IT V1 als auch bei IT V3 als auch bei ih messages (und auch im messages) ausgwertet und entfernt. Damit funktioniert dann auch die RSSI Anzeige zum Empfang von IT HE/HEEU von verschiedenen IOs via Dispatch.

Bei CUL dagegen nur bei IT V1 und bei IT V3, was an der schon gezeigten Abfrage vor RSSI Abspaltung und Auswertung in CUL_Parse liegt.
Ich vermute, das wurde bei der 10_IT.pm Entwicklung/Erweiterung übersehen/nicht verstanden und daher nicht von Rudolf an der 00_CUL.pm zur Änderung angefordert???

ZitatDann muß ich am Anfang vom IT_Parse noch die Abfrage "if ($hash->{TYPE} eq 'TSCUL' .." einbauen
Ich will Dich nicht in Deiner Kreativität einschränken, aber Du benötigst für das dekodieren von HE/HEEU Protokolldaten eigentlich nur jeweils 2 Zeichen weniger und RSSI kann dran hängen oder nicht, wäre also als optionaler Zusatz zu verstehen.
Der RSSI ist nicht Bestandteil des Protokolls, sondern wird vom Empfangs-IO nach Vermögen und Gusto anghangen. Kein CC1101 -> u.U. kein RSSI verfügbar -> kein RSSI wird angehangen.

Gruß, Ansgar.
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: Ralf9 am 14 Dezember 2023, 22:55:54
Hallo Ansgar,

ich habe den Code in der IT_Parse nun angepasst, so ähnlich wie es Du auch gemacht hast.
Bei HomeEasy HE800 können nun Längen von 9,10 und 12 verarbeitet werden.
Bei HomeEasy EU können nun Längen von 17,18 und 20 verarbeitet werden.
Da bei HE800 nur 28 Bit gesendet werden, erfolgt nun bei der kommenden 00_SIGNALduinoAdv.pm auch der Dispatch mit nur 9 Zeichen "ih1234567"
Bei HE EU ist es ähnlich.

Anscheinend gibts bei HE800 auch eine alte Version, bei IT_Set wurde dies zwar vorbereitet, aber nicht fertig programmiert.

https://github.com/Ralf9/10_IT/commit/9d4b397e497833ec06afcc3b04daf3b50d39e99a

Gruß Ralf
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 16 Dezember 2023, 09:06:00
Hallo Ralf,

ich habe Deinen letzten Stand mit TSCUL und tsculfw getestet und kann senden und empfangen, was gesendet wurde.  :)

ZitatDa bei HE800 nur 28 Bit gesendet werden, erfolgt nun bei der kommenden 00_SIGNALduinoAdv.pm auch der Dispatch mit nur 9 Zeichen "ih1234567"
Ich habe es in meinem neuen Stand berücksichtigt, etwas anders, als Du und etwas klarer kommentiert.
Von culfw und tsculfw kommen ganze angefangene Bytes, daher ergibt sich das zusätzliche Nibble bei HE800 und HE EU.

Gruß, Ansgar.
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 16 Dezember 2023, 11:07:02
Hallo Ralf,

ZitatAnscheinend gibts bei HE800 auch eine alte Version, bei IT_Set wurde dies zwar vorbereitet, aber nicht fertig programmiert.
Ich vermute eher, nicht ganz richtig programmiert trifft es besser.

Ich mutmaße mal, dass in der Vergangenheit für jeden count ein on bzw. off Reading existierte.

Mit neuer Kodierung sollte vermutlich dann das alte noch genutzt werden können, so lange das jeweilige Reading da war???

Jedoch wurde im Code direkt bis VAL gelesen, was die Readings leer erzeugt, wenn sie nicht existieren. Ich habe es mal mit ReadingsVal gemacht und dann klappt das, was vermutlich gedacht war.

Gruß, Ansgar.
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.39
Beitrag von: noansi am 18 Dezember 2023, 19:40:20
Hallo Ralf,

ich habe nochmal weiter in meiner Variante aufgeräumt.

Das Attribut protocol wird nicht genutzt, von daher überflüssig und entfernt.

userV1setCodes habe ich mal intern mit userV1Code2set zur Rückwärtssuche ergänzt und beim Parsen hinten dran gehängt. Damit kann man dann bestehende Kommandos durch userV1setCodes mit gleichem Code aber anderem Namen im state beim Empfang sichtbar machen.

Das model 'ev1527' habe ich aus der Attributsauswahl raus geworfen. Macht eigentlich nur Probleme und ich erkenne keinen Nutzwert. Das Reading protocol 'ev1527' reicht aus define und bringt kein zusätzliches Codes durcheinander. Irgend jemand würde sicherlich weinen...

Parse habe ich mal etwas geradliniger strukturiert. Ist so auch verständlicher, meine ich. Ob die Interpretation insbesondere mit autocreate so klappt, muss jemand mit Hardware testen.
Die Dimmer Prozente habe ich für v3 verändert, damit es einerseits noch zu den Dim Icons passt und andererseits Schieberegler weniger oder falsch springen.

Gruß, Ansgar.

PS: Über die Testerei ist mir dann aufgefallen, das tsculfw noch kein ITV1 'D' senden kann und daher kein EV1527. Kommt in der nächsten Version. Bei HE werde ich im TSCUL Modul die überflüssige 0 am Ende enfernen, wie Du es vorhast.
Titel: Aw: Firmware zu CUL, CUNX und Co. mit Timestamp Option ASKSIN tsculfw V0.41
Beitrag von: noansi am 19 Dezember 2023, 11:58:13
Hallo Testwillige,

hier eine neue Version 0.41 der Timestamp Firmware und der dazu benötigten FHEM Module.

Die Version hat einige Verbesserungen erhalten, Auszug aus der Changed:
Version VTS 0.41
- CC1101_FSCTRL1 default settings adapted to frequency bands
- marker handling configuration at compile time enhanced
- reduced interrupt disabled times
- CUNX, resolved possible Ethernet connect problems, if connected to a host via USB
- CUNX, speed enhancement in Ethernet connection
- SPI transfer little optimized
- HOERMANN send added
- SOMFY send corrected and optimized
- changed USB currents for CUL and CUNX
- ASKSIN for B112/A112 to multible devices better keep of send order for command after
- fswrapper, qfs, df adapted to reversed buffer access, to be tested
- RFR_SHADOW removed
- serial IO and stacking serial IO interrupt routines done in assembler for ATMEGA
- Analog in function 'a' added, allows read of processor temp voltage for CULV3 or allows analog in on one analog input for ATMEGA (done for CUNO2 and nanoCUL/miniCUL)
- Digital in/out function 'd' added, allows digital input or output on upto 8 digital I/O pins for ATMEGA (done for CUNO2 and nanoCUL/miniCUL)
- added Intertechno V1 send of 'D'. 'D' is sent, if not '0', '1' or 'F' is character

Version VTS 0.40
- HOERMANN receive corrected

Beschreibung 'a' Firmware Kommando für Analoge Eingabe auf einem ADC Pin oder CPU Temperature Voltage:
aiTTT: TTT dezimal. Setzt das Abfrage und Reporting Intervall in Sekunden, 0 schaltet es ab.
        Ist es eingeschaltet, dann kommt im Intervall eine aHHHH Message mit dem Analogwert in 16 Bit HEX

acC:  C Buchstabe. Auswahl der Spannungquelle. Wird kein Buchstabe angegeben, dann wird die aktuelle Einstellung ausgegeben als acX oder aXX hex Code.
        acp wählt den analogen Eingabe Pin, vgl. board.h
        acg wählt Analog GMD
        acr wählt die Vbg Referenzspannung
        act wählt den Temperatursensor (so in der CPU vorhanden)

arC:  C Buchstabe. Auswahl des Referenzwertes. Wird kein Buchstabe angegeben, dann wird die aktuelle Einstellung ausgegeben als acX oder aXX hex Code.
        arA wählt AREF
        ar3 wählt VACC
        ar2 wählt 2.56V interne Referenz
        ar1 wählt Vbg

TSCUL zeigt den Spannungswert im Reading VoltAnIn an. Dazu gibt es noch die Attribute AInVref_AVCC_Volt, AInVref_2_56_Volt und AInVref_Vbg_Volt mit denen die Referenzspannungswerte für die Auswertung kalibriert werden können.
Der CPU Temperaturwert wird im Reading Temperature angezeigt. Jedoch muss dieser für jeden CUL indivudell kalibriert werden. Dazu gibt es das Attribut AInTempCalib zur Einstellung einer linearen Kalibrierung.

Bisher nur kompiliert für CUL V3 (nur interne Temperatur), CUNO2, nanoCUL und miniCUL.
Da direkt an die CPU angeschlossen wird, ist natürlich entsprechende Vorsicht walten zu lassen, um den Eingang nicht mit unzulässigen Spannungen zu zerstören.

Beschreibung 'd' Firmware Kommando für Digitale Ein- und Ausgabe auf bis zu 8 digital I/O Pins.
diTTT: TTT dezimal. Setzt das Abfrage und Reporting Intervall für die Pins in Sekunden, 0 schaltet es ab.
        Ist es eingeschaltet, dann kommt im Intervall eine dHH Message mit den Pin Stati in 8 Bit HEX

doHH:  HH hex. Setzt die in HH mit binär 1 gesetzten Pins auf Ausgang, mit binär 0 gweählten Pins auf Eingang.
        Ist ein Pin auf Eingang geschaltet, so werden keine Pullup oder Pulldown Widerstände aktivert. Der Eingang ist also unbeschaltet floatened und liefert demensprechend wechselnde Statuswerte.
        Wird kein Hex Wert angegeben, wird die aktuelle Auswahl als doXX als 6 Bit HEX ausgegeben

dr:    Liest den aktuellen Pin Status als dHH, wie beim Intervall.
drII:  Liest den aktuellen Pin Status des mit II (hex, 0-7) gewählten Pins als dII0 oder dII1. Eine ungültige Pinnummer II liefert ein ?.

dsVV:  setzt alle gewählten Ausgänge auf den Wert im übergebenen 8 Bit HEX Wert VV
dsOOvv: setzt den mit OO (hex, 0-7) gewählten Pin auf 1 wenn vv ungleich 0 oder auf 0, wenn vv gleich 0.
        Ist der Pin nicht mit do auf Ausgabe gewählt, dann passiert nichts.  Eine ungültige Pinnummer OO liefert ein ?.
        Es wird abschließend der aktuelle Pinstatus als dHH ausgegeben, wie bei Intervall.

TSCUL zeigt den Pin Status als Reading DigIn 0xXX hex an.

Bisher nur kompiliert für CUNO2, nanoCUL und miniCUL.
Da direkt an die CPU angeschlossen wird, ist natürlich entsprechende Vorsicht walten zu lassen, um den Eingang nicht mit unzulässigen Spannungen zu zerstören.
Beim do Kommando muss natürlich darauf geachtet werden, den Ausgang nicht zu überlasten, z.B. durch schalten auf eine Spannungsquelle...

CUNO2 Pins auf Jp1:
Pin 1 (CPU PC2)  Digital Ein- oder Ausgang 0
Pin 2 (CPU PA0)  Analogeingang
Pin 3 VDD
Pin 4 GND
Pin 5 (CPU PC3)  Digital Ein- oder Ausgang 1
Pin 6 +5V von USB

nanoCUL:
Board pin A4 (CPU PC4)  Digital Ein- oder Ausgang 0
Board pin A5 (CPU PC5)  Digital Ein- oder Ausgang 1
Board pin A7 (CPU ASC7) Analogeingang


Die Version 0.39 bietet einige Timingänderungen für HM. Außerdem ist das Commandref überarbeit. Bei TSCUL werden sets und gets nun abhängig von rfmode und unterstützten Firmwarebefehlen angeboten.

Die Version 0.38 verhindert repeats für TC und TH Messages, was für virtuelle TC und TH Sensoren sinnvoll ist.
Auszug aus de Changed:
- ASKSIN repeats for TC and TH messages set to 0
- ASKSIN Ag command added, allow setting ASKSIN non FUP AGCCTRL2 value in EEPROM
Außerdem Verbesserungen in Modulen, insbesondere für virtuelle TCs und TH Sensoren.
Beim Reboot nach dem Flashen werden alle EEPROM Einstellungen auf Default gesetzt. Also alle am CUL vorgenommenen Einstellungen notieren, um sie wieder einstellen zu können.

In Version 0.37 ist der Readout des Tranceiver RX Fifos insbesondere für ASKSIN verändert. Beim Reboot nach dem Flashen werden alle EEPROM Einstellungen auf Default gesetzt. Also alle am CUL vorgenommenen Einstellungen notieren, um sie wieder einstellen zu können.
RF_Router und fast_rf sind verändert und nicht kompatibel zu vorherigen Versionen.

Version 0.36 behebt ein Überlaufproblem des RX-FIFOs des Transceivers, der zum Empfangsausfall führen konnte (fiel nur beim reinen Empfangsbetrieb ohne regelmäßiges Senden auf). Danke Stefan für den Hinweis.

Auszug aus der Changed:
- little correction in rf_native, if slowrf monitoring is active
- lacrosse emu reworked
- SlowRf reception adapted for better ESA reception with still well E and HMS reception
- generic Manchester raw send added with Gm command
- ESA send added with 'S' command
- HMS send added with 'Q' command
- IT reception corrected
- RfRouter with repeat in FastRF packet, better send timing and reduced receive timeout
- for pure USB CULs blinking while waiting on watchdog reboot and during boot/bootloader reboot with different frequencies
- message finalization with \n on PIM receive buffer full
- ASKSIN, fastRF, RF-Router, moritz, rwe, RX-FIFO Overflow detection improved

Noch als Hinweis, für HMS und ESA scheint sens 12 eine ungünstige Einstellung für den Empfang  dieser Protokolle zu sein.

Diese Version bietet wakup support und keep awake Support. Für CULs mit wenig Speicher kann dies mit dem Attribut "hmForceLzyCfg" aktiviert werden, siehe auch der Hinweis zum EEPROM Verschleiß weiter unten.

Das RF-Router Ping Timing ist geändert, damit also auch nicht kompatibel mit Standard culffw oder a-culfw und auch nicht zur Version 0.32.
Ergänzt ist SlowRf Empfang von Pearl NC7427 Temperatur/Luftfeuchte Sensoren. Entsprechend Kanalwahlschalter können 3 Stück empfangen werden. Zum Anlernen mittels autocreate muss der TEST Taster am Sensor gedrückt werden.

Das EEPROM Layout ist geändert und daher werden nach dem Flashen alle Einstellungen auf default zurück gestellt. Also vor dem Flashen individuelle Einstellungen, z.B. Frequenzoffsets, notieren und nacher neu einstellen.

Auszug aus der Changed:
- FULL_PA_RAMPING bugs corrected
- CCA CS thresholds setable for ASKSIN, MORITZ, HAS_RWE, RFNATIVE and MBUS with XTxy, x=CARRIER_SENSE_REL_THR, y=CARRIER_SENSE_ABS_THR as in AGCCTRL1
- SlowRf receive timing limits corrected
- SlowRf lower filter switched off by define in rf_receive_timing.h
- RFR timing/timeout shortened, FastRF CCA disabled
- auto Ci interrupt counter messages
- XP command extended to switch on auto Ci messages, AP removed as all PLL messages switchable by XP
- improvement and corrections for CUNX RS485 PIG support
- CUNX: PIG RTS controllable by USB Host for serial foward and RS485 serial forward
- CUNX: DMX interupts changed to HI priority and CC1101 interrupts to MED priority
- CUNX: USB interrupts to LO priority
- GPIOR1 used for USB USB_DeviceState
- GPIOR1 used for SERIAL STACKING stacking_ST_state


Ein Peakfilter für SlowRF Empfang ist ergänzt und mit "peakfilter" einstellbar.
In dem Zusammenhang ist auch das RF-Router Ping Timing geändert, damit also auch nicht kompatibel mit Standard culffw oder a-culfw.
Außerdem kann das Senden von RF-Router Daten nach deren Empfang einstellbar verzögert werden (RfRdelay).

CCAMode wirkt nun auch auf IT-Senden und SOMY-Senden, sowie auf das Senden des RF-Router Pings. Mit fRfCCAMode kann auch das CCA Verhalten für RF-Router Senden und FastRF geändert werden.

Auszug aus der Changed:
- IT and SOMYFY use SlowRF EEPROM CCA setting now for sending
- changes in SlowRF reception for reset and sync start. IT V1 reception tested succsessfully.
- SlowRF filter and match adaption
- SlowRF spike filter improved, max. peak lenght settable with Xpxx, xx hex time in 8us units
- IR receive/transmit pause during send of SlowRF changed to not globally switching off all interrupts
- periodic RF-Router ping RSSI display as "Cuxx\r\n" with xx = RSSI Hex
- RF-Router ping timing changed for better distinguish from other protocols
- RF-Router pre silence before send settable with uRxx, xx hex time in 4ms units
- Xrrt commands bits:
  rr:
  report known protocol data                                                      Bit 0
  report repeated data                                                            Bit 1
  report received bits                                                            Bit 2
  report 'r' (rising) or 'f' (falling) edge, '.' (collect) or '?' (sync) timeout  Bit 3
  report edges, bit times and timeouts                                            Bit 4
  report S300 data with valid checksum only                                      Bit 5
  report FHT                                                                      Bit 6
  report 'l' RSSI decimal data continuosly                                        Bit 7
  t:
  report recorded SlowRF timing                                                  Bit 0
- corrections in interrupt flag clearing
- correction in delay function
- fastRF bug corrected, untested
- EEPROM layout changed for the new parameters


TSCUNX kann mit entsprechendem RS485 Modul nun auch DMX.
Auch HM485 ist für TXCUNX angepasst.
In dem Zuge ist auch die DMX Funktionalität bei CUNO2 etwas erweitert.
IR läuft nun auch richtig mit TSCONO2.
Außerdem läuft RF-Router auf der tsculfw, allerdings mit einer Änderung. Das 'U' ist durch '~' ersetzt. 'U' kollidierte mit dem Uniroll Senden.

Kurzer Auszug aus der CHANGED:
- IO optimizations CUNX, especially to/from PIM and Ethernet
- CUNX DHCP non blocking operation
- IO optimizations
- HM485 support for CUNX (like CUNO2) with RS485 PIM.
  HM485 switch off with Hx for CUNX. With CUNX after Hx RS485 PIM again accessible via PIM USB or Ethernet Interface
- CUNX support for DMX and HM485 with RS485 PIM (to be tested), a Dwxxxxyy switches to DMX via CUNX Interface, a Hsxxxxxxxxxxxxxxxxxx switches to HM485 via CUNX Interface
- DMX switch off with Dx. With CUNX after Dx RS485 PIM is again accessible via PIM USB- or Ethernet Interface
  DMX flexible channel usage. Channels are sent out upto the highest channel set (0 sent as default for unset channels). With switching off with Dx the highest channel is reset.
  DMX changed in timing and resting behaviour. Rests on IDLE if less then 24 device, only, to keep 1204µs min. BREAK to BREAK (to be tested)
  DMX Dt command to set/view timing of MarkAfterBreak and BREAK
  DMX less disturbed while sending SlowRF
- W function gives feedback after writing EEPROM
- clock timer unburdened, may impact onewire and fht (to be tested)
- corrections for IRTX
- IR base timings changed to 12500Hz or 20000Hz
- RF-Router working, but 'U' changed to '~' (definable in board.h, but 'U' disables HAS_UNIROLL)

Es ist eine Prüfung auf Stacküberlauf eingebaut. Am Anfang des heap werden zwei Byte mit einem Bitmuster beschrieben. Wird das verändert, dann ist der Speicher wahrscheinlich korrumpiert, was durch einen Stacküberlauf ausgelöst sein sollte. Sofern der CUL dann noch kann sendet er ein "C_M" an TSCUL, was zu einem entsprechenden Log Eintrag führt.
Damit kann man vorsichtig die Speichergrenzen ausloten. Ein langer Testzeitraum ist aber erforderlich, um einigermaßen sicher zu sein, dass der worst case auch mal durchlaufen worden ist.
Außerdem ist ein Kommando mU (je nach Firmware) eingebaut, mit dem man den vom Stack ungenutzen heap in etwa auslesen kann (auch als get unusedstack in TSCUL verfügbar). Auch hier gilt, nur nach langer Laufzeit einigermaßen sinnvoll. Es macht sicher keinen Sinn auf Grund des Wertes den Speicher bis auf das letzte Byte auszuquetschen, denn weiterhin hängt die Stacknutzung vom gewählten Protokoll und Einstellungen ab.

In TSCULflash ist Flashen auch von NanoCULs und MiniCULs ergänzt. Vor dem Flashen wird ein "B00" also Reset für die TSCUL Firmware an den nano/Mini geschickt, 1 Sekunde gewartet und dann versucht mit avrdude zu flashen.
Also erst die Firmware in den FHEM/Firmware Ordner kopieren und dann in FHEM mit
TSCULflash <nanodevicename> TSnanoCULbzw.
TSCULflash <minidevicename> TSminiCULversuchen zu Flashen. Im Log sollte danach (dauert etwas) die avrdude Ausgabe zu finden sein.

Ebenfalls (nur über USB Anschluss) möglich ist das Flashen eines PIGATOR Moduls an einem CUNX
TSCULflash <pigatordevicename>|<cunxdevicename> TSPIGATOR
AESCommReq wird unterstützt. Die Nutzung ist unverändert zu Standard CUL, sprich, beim gewünschten Gerät/Kanal aesCommReq auf 1 setzen und ggf. noch aesKey passend zum verteilten Key setzen.
Es werden von tsculfw nur die Keys 0 (Default Key) bis 3 unterstützt.

Diese Erweiterung erfordert jedoch auch zusätzliche Empfangspuffer im knappen Speicher des CULs. Ein CUL V3 nutzt bis zu 6 Empfangspuffer. Auch der FlashSpeicherbdarf ist angestiegen, so dass einige Protokolle nicht mehr gleichzeitig in ein Kompilat passen. Das sollte aber weniger tragisch sein, da im ASKSIN Modus ohnehin nur HM empfangen werden kann.

Bei CUL V2 reicht der verfügbare Speicher leider hinten und vorne nicht aus, um diese Version nutzen zu können.

Im Anhang ist in TSCUL_fwcode_00_xx.zip und FHEM_Modules_00_xxx.zip wieder die Timestamp Firmware zu finden. Getestet habe ich TSCUNX, TSPIGATOR , TSCUL_V3 , TSCUL_V3_RFR, TSCUNO2, TSCOC und TSSCC. (TSCUL_V3_RFR ist ohne HM Unterstützung, also nur SlowRF)

Die tsculfw Firmware kann für TSCUL_V3, TSCUL_V3_RFR (via USB), TSCUNO2, TSCOC, TSSCC, TSCUNX und TSPIGATOR (an CUNX) mit FHEM mit dem TSCULflash geflashed werden. Die anderen müssen mit dem jeweiligen Flash Programmer geflashed werden. Bei CUNO2 und SCC muss die Bootloadertaste gedrückt werden, bis der Flashvorgang anläuft.
So z.B. https://forum.fhem.de/index.php/topic,24436.msg631743.html#msg631743 kann es mit einem USB CUL Stick gehen, wenn man nicht TSCULflash verwendet.
TSCULflash ist erweitert auf COC, SCC, CCD, rpiaddon, CUNO2 und CUNO. Jedoch ist es nicht ganz so einfach zu handhaben, da zum einen teilweise die Taste zu drücken ist und bei Raspberry PI Modulen die Rechteproblematik für den Zugriff auf die IO-Pins überwunden werden muss. Tips dazu in der Command-Ref auch bei RPI_GPIO.
Bei einem Stapel aus SCC mit aufgesetztem COC, CCD oder (rpiaddon?) ist unbedingt beim SCC Flash darauf zu achten, die Taste am gewünschten Modul zu drücken. Sonst wird das oberste Nicht-SCC Modul mit der SCC Firmware geflashed.
Mit CUNO2 ist das flashen getestet (generell nur über USB!). Wichtig, aber auch hier, die Taste zu drücken.

Es gibt nicht den Luxus des Downloads beim TSCULflash, sondern die Firmware muss händisch in den FHEM/firmware Ordner kopiert werden. Der Typ ist dann z.B. TSCUL_V3.
Beispiel:
TSCULflash MeinCulV3Device TSCUL_V3
Wichtig für SCC Nutzer. TSSTACKED ist entfallen und wird nicht mehr unterstützt.
Statt dessen gibt es das neue Modul STACKABLETS (als Abwandlung von Rudolfs STACKABLE).
Dieses wird sozusagen zwischen die Stackteilnehmer eingebaut.

Beispiel für fhem.cfg:
#erstes SCC Modul als Basis
define SCC_WS868 TSCUL /dev/ttyAMA0@38400 0000
attr SCC_WS868 event-on-change-reading Ints_per_sec,IntCalcStat,MatchStat
attr SCC_WS868 rfmode SlowRF
attr SCC_WS868 room Receiver
attr SCC_WS868 sendpool CUL_HM868,SCC_WS868
attr SCC_WS868 verbose 1

#neues STACKABLETS virtuelles IO device
define STACK_1 STACKABLETS SCC_WS868
attr STACK_1 verbose 1

#zweites SCC Modul
define SCC_HM868 TSCUL FHEM:DEVIO:STACK_1:38400 1034
attr SCC_HM868 event-on-change-reading cond
attr SCC_HM868 hmId F11034

Ergänzender Hinweis zu USB CULs: 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_08\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 in der board.h festgelegt werden, so dass damit dann auch /dev/CUL868_1 etc. für mehrere gleiche CULs möglich sind.

Oder für CUNX
define CUNX_868 TSCUL /dev/CUNX868_0@12000000 0000oder für PIGATOR an CUNX
define PIGATOR_433 TSCUL /dev/CUNXPIM_0@38400 0000die Seriennummer wird aus der Seriennummer des XMEGA Chips des CUNX gebildet. Unter Linux lsusb nutzen!

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.

Bei nicht nativen USB CULs wie z.B. nanoCUL, miniCUL oder CUNO2, beträgt die Baudrate 38400, dementsprechend muss die Definition beispielsweise so aussehen:
define CUL_868 TSCUL /dev/CUL868@38400 1234bzw.
define CUL_433 TSCUL /dev/CUL433@38400 0000
Und noch ein Beispiel für eine Definition eines Netzwerk CUNX:
define CUL_868 TSCUL 192.168.178.111:2323 0000oder für PIGATOR an CUNX
define PIGATOR_433 TSCUL 192.168.178.111:2324 0000beim PIGATOR sollten zuvor mit Anschluss an USB und öffnen der Schnittstelle mit gewünschten Kommunikationsparametern mit ps oder unter TSCUL mit set PIMstoreBaud die seriellen Kommunikationsparameter zum PIGATOR Modul gespeichert werden, falls sie vom default abweichen.

Oder Netzwerk CUNO2:
define CUNO2_868 TSCUL 192.168.178.110:2323 0000
Die aktuell eingestellte oder per DHCP erhaltene Netzwerkadresse kann mit Lc repektive in TSCUL mit get NetAdresses abgefragt werden. Mit Lp respektive in TSCUL mit get NetPHYlink kann der Linkzustand des Netzwerkanschlusses angezeigt werden.


In der Zip Datei sind ebenfalls die ergänzten Module zu finden, die zur Nutzung der Firmware erforderlich sind.

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
16_TSCUL_RFR.pm -> der 16_CUL_RFR.pm, aus CUL_RFR devices werden damit TSCUL_RFR devices in der fhem.cfg (händisch anzupassen)
16_STACKABLETS.pm -> statt der 16_STACKABLE.pm, aus STACKABLE werden damit STACKABLETS devices in der fhem.cfg (händisch anzupassen)
97_timerTS.pm          -> Austausch-Timerroutinen und fhemFork()

10_UNIRoll_TS.pm  -> statt der 10_UNIRoll.pm, mit TSCUL 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 IO-devices zu verwenden, aus TSKS300 wird dann TSKS300  in der fhem.cfg (händisch anzupassen). Obsolet, da 14_TSCUL_WS.pm nun KS300 unterstützt.
14_TSCUL_TX.pm    -> statt der 14_CUL_TX.pm, mit TSCUL 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 IO-devices zu verwenden, aus CUL_WS wird dann TSCUL_WS  in der fhem.cfg (händisch anzupassen)
14_TSCUL_NC7427.pm  -> NC7427 Unterstützung
15_TSCUL_EM.pm  -> statt der 15_CUL_EM.pm, mit TSCUL IO-devices zu verwenden, aus CUL_EM wird dann TSCUL_EM  in der fhem.cfg (händisch anzupassen)
12_TSHMS.pm        -> statt der 12_HMS.pm zu verwenden
CalcUtil.pm              -> Hilfsrechenroutinen für Taupunkt und Windstärkeindex
ReadingUtil.pm          -> Hilfsroutinen für Readings

Da diese Module ergänzt werden (müssen!), überleben sie auch ein Update von FHEM.

98_fhemdebug.pm    -> fhemdebug zur zwingenden Nutzung mit 97_timerTS.pm.
98_apptime.pm          -> apptime zur zwingenden Nutzung mit 97_timerTS.pm.
98_apptm.pm            -> apptime zur zwingenden Nutzung mit 97_timerTS.pm, mit geringerem Speicherverbrauch bei weniger Details
10_IT.pm                  -> vermeidet unnötiges busy waiting beim Senden. Wird ohne Schutz von FHEM update überschrieben

Außerdem:

98_TSCULflash.pm    -> Zum Flash von TSCUL_V3, TSPIGATOR (an CUNX) mit Datei in FHEM/firmware

10_CUL_HM.pm        -> angepasste Version zur Nutzung mit TSCUL/tsculfw. Die Nutzung dieses Moduls ist optional. Für CUL_V3, nanoCUL, miniCUL im Multio-HM-IO Betrieb jedoch empfohlen, da sie den EEPROM Verschleiss über das Attribut "rssiSwitchHyst" verringert. Nur diese Version bietet derzeit vollständige TSCUL/tsculfw Unterstützung. Zur Einsparung redundanter Events werden teilweise Readings (actuator, desired-temp, measured-temp) nicht mehr zusätzlich im HM-device, sondern nur noch in den jeweiligen Channels aktualisiert.
HMConfig.pm            -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden. Einstelllimits für HM-CC-RT-DN Regler P und I Anteil erweitert. Damit kann man mit R-regAdaptive offDeter deutlich mehr an den Regelparametern spielen.
98_HMinfo.pm          -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden. Spaltenbreiten in Tabelle von protoEvents variabel zu verbesserten Übersicht in der Darstellung.
98_HMtemplate.pm  -> mit der enthaltenen 10_CUL_HM.pm zwingend zu verwenden.
Die 4 Dateien entsprechen einem Stand von Anfang 09/2020. Derzeit sollten diese verwendet werden.

10_CULG.pm              -> optional, enthalten, da die Firmware es unterstützt

98_autocreate.pm      -> autocreate mit TSCUL Unterstützung

98_Cumulate              -> Kumulieren von Zählwerten, wie Strom, Regenmenge etc.
98_SAverage.pm        -> Mittelwertbildung von z.B. Temperaturen. Stunde, Tag, Monat und Jahr, sowie ein gleitender Mittelwert der letzten Stunde sind damit möglich.
98_IntervalTimer.pm  -> optional, Intervalltimer um FEHM-Timerbasiert Kommandos in möglichst konstanten Intervallen absetzen zu können.

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_STACKABLETS.pm DevIoTS.pm 10_UNIRoll_TS.pm 13_TSKS300.pm 14_TSCUL_TX.pm 14_TSCUL_WS.pm 15_TSCUL_EM.pm CalcUtil.pm 14_TSCUL_NC7427.pm ReadingUtil.pm 97_timerTS.pm 98_TSCULflash.pm 98_apptime.pm 98_apptm.pm 10_IT.pm 10_CULG.pm 10_CUL_HM.pm HMConfig.pm 98_HMinfo.pm 98_HMtemplate.pm ReadingUtil.pm 98_autocreate.pm 98_Cumulate.pm 98_SAverage.pm 98_fhemdebug.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 zwingend auszuführender 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` }
Noch ein Hinweis: TSCUL fragt auch die Firmwareversion der tsculfw auf 0.40 ab. Eine ältere Version wird also nicht unterstützt!

Frequenzoffset: Für HM ist ein Frequenzoffset von -20.6kHz im EEPROM als default in der tsculfw hinterlegt (das ist ein individuelles Optimum für meinen COC). Dieser Frequenzoffset kann mit set hmFreqOffs umgestellt werden. 0 ist default in der Standard-culfw.
Wenn also keine Antwort von angesprochenen HM devices kommt, dann hmFreqOffs von 0 ausgehend verstellen. CUNX z.B. geht eher in Richtung + mit dem Offset.
Wer das Frequenzspektrum sichtbar machen kann, kann sich die optimale Mitte aller devices ermitteln und mit dem Offset sein CUL dazu passend einstellen.

Noch ein Tip zur Haltbarkeit der CULs mit wenig SRAM (CUL V3, nanoCUL, miniCUL ...). Jedesmal, wenn einem HM-Device das IODev durch Roaming neu zugeordnet wird, führt das zu EEPROM Schreibvorgängen in den beteiligten CULs. Die Lebensdauer des EEPROMs ist begrenzt (100000 Schreibzyklen laut Datenblatt). Daher rate ich zur Nutzung des VorzugsIOs beim Device Attribut IOgrp. Also nicht einfach stumpf
attr HMdeviceName IOgrp VCCUsetzen, sondern
attr HMdeviceName IOgrp VCCU:CUL_mit_gutem_Empfang_fuer_Devicesofern die Roaming Funktionalität entsprechend RSSI für das jeweilige device nicht zwingend benötigt wird. Ein Fallback auf einen anderen CUL bleibt dennoch möglich.
Mit dem Attribut "rssiSwitchHyst", das in der beigefügten 10_CUL_HM.pm verfügbar ist, kann bei den HM-devices die Umschalthysterese für das Roaming von 10 bis auf 2 bei Bedarf für mobile devices verringert werden.
Mit dem Attribut "hmForceLzyCfg" kann wakeup und keep awake support bei solchen CULs aktiviert werden. Das erhöht den EEPROM Verschleiß beim Lesen oder Verändern von Registerwerten bei wakup und lazy config devices.

Ergänzt ist auch noch ein set TX3Send.
Damit lassen sich TX3 Sensordatentelegramme auf 433er CULs versenden.
Beispiel:
define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 TX3Send T:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." SID:23 U")}

define NF_HumOut notify Sen_Aussen:humidity.* {fhem("set TSCUL_WS433 TX3Send H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." SID:23 U")}

Ergänzt ist auch noch ein set KSSend.
Damit lassen sich WS Sensordatentelegramme versenden.
Beispiel:
define NF_TempOut notify Sen_Aussen:temperature.*  {fhem("set TSCUL_WS433 KSSend T:".(ReadingsVal("Sen_Aussen","temperature","n.a."))." H:".(ReadingsVal("Sen_Aussen","humidity","n.a."))." Code:2")}

Zum regelmäßigen Senden von Sensordaten kann der IntervalTimer genutzt werden.
Beispiel:
define AussenSend_WS11 IntervalTimer CUNO2_WS868 176.5
attr AussenSend_WS11 offCmd {fhem("set @ KSSend T: ".ReadingsVal("C_Aussen","temperature",0.0)." H: ".ReadingsVal("C_Aussen","humidity",0.0)." Code:21")}
attr AussenSend_WS11 onCmd {fhem("set @ KSSend T: ".ReadingsVal("C_Aussen","temperature",0.0)." H: ".ReadingsVal("C_Aussen","humidity",0.0)." Code:21")}

Hier geht es zur vorherigen Version https://forum.fhem.de/index.php?msg=1167796 (https://forum.fhem.de/index.php?msg=1167796).

Gruß, Ansgar.