*************************************************************************************************************
*************************************************************************************************************
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.
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
}
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.
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.
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
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
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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
- display_char wird ggf. in ISR(TIMER1_COMPA_vect) aufgerufen wenn REP_MONITOR aktiv ist oder wenn in einem Interrupt mal was ausgegeben werden soll
- CDC_Task wird auch von display_char aufgerufen, um bei vollem TTY Puffer Platz zu schaffen oder bei Zeilenende die Daten im TTY Puffer auch auf die Reise zu schicken
- input_handle_func sorgt wiederum ggf. für Output über display_char und verstellt dann bei einem möglichen Aufruf in einem Interrupt den Endpoint
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.
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.
Nicht wirklich
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.
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
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.
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.
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
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.
schade
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.
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.
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.
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.
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
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.
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
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
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
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
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
Hallo Ansgar,
super Arbeit! Bei mir ist es diese Woche etwas eng - sobald ich dazukomme, werde ich aber testen und Feedback geben.
Gruß
Tobias
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
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.
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
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.
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. :)
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
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.
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
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
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.
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
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
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
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
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
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
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
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.
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
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.
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
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.
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
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.
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.
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.
ohne jetzt alles gelesen zu haben, ist mit dieser Erweiterung jetzt auch HM auf einem CUNO sauber möglich?
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.
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 ?
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.
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
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.
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.
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 ?
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.
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.
@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.
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.
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.
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.
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.
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
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.
Wie geht es in dem Thema weiter? Ist es geplant, dass die Entwicklung in den Haupt-Zweig einfließen wird?
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.
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.
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.
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.
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.
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
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.
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.
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
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
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!
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.
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
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.
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
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.
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.
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!
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!
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
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.
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. ;-)
Hallo Mr. P,
danke für den Hinweis! Die Funktionsvielfalt von FHEM ist doch immer wieder überwältigend. :)
Gruß, Ansgar.
Hej Ansgar,
bin ebenfalls immer wieder überrascht. :-)
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!
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.
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 :-)
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.
Wäre es eigentlich möglich, diese Änderungen in die a-culfw einzubauen?
Grüße
Fabian
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.
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
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
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.
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
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.
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
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.
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...
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.
Hallo Ansgar,
vielen Dank für die Hinweise!!
Dann kann ich ja loslegen...
Gruß, Joachim
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
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?!
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
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.
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
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.
Hallo Ansgar,
vielen Dank schon mal!
Komme aber erst heute Abend (oder morgen) zum Testen...
Bin schon sehr gespannt!
Gruß, Joachim
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
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.
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!
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!).
Hallo Ansgar,
werd die Tage mal testen...
...und berichten.
Gruß, Joachim
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.
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
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
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
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... ;-)
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.
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
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
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 ;-)
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.
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
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
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.
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
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
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.
Hi Ansgar,
vielen Dank!
Leider komme ich frühestens am WE dazu...
...werde ich aber dann gleich mal testen...
Gruß, Joachim
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
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.
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
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.
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
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.
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...
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.
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.
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
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.
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.
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.
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
Hallo Ansgar, auch ich werde testen und mich melden!
Gruß Chris
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...
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
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.
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
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.
Hi Ansgar,
danke.
Komme aber leider erst morgen dazu...
Gruß, Joachim
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.
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
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.
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.
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
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
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
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
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
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.
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.
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.
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$
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.
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
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!
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.
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.
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!?
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.
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).
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.
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!
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.
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.
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
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.
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
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.
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.
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
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.
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
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
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.
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?
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
Danke dir, jetzt habe ich die Prozedur verstanden!
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
Hi,
soweit mir bekannt sind die für Original-CULs...
Ich hab meine FW selbst compiliert und geflasht...
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...
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!
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.
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.
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.
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
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.
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.
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` }
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
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.
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.
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
Hallo Christian,
beim NanoCUL musst Du das Attribut verbose auf 4 setzen.
Nur dann werden die Sende- und Empfangsdaten des NanoCUL geloggt.
Gruß, Ansgar.
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
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.
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
Habe jetzt gerade zur Sicherheit nochmal über das Eventlog geprüft: Der CUL taucht auch hier nicht auf, nur der Aktor.
Hallo Christian,
und wie ziehst Du das Log?
Gruß, Ansgar.
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.
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.
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
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.
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
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.
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
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.
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
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.
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.
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.
Hi Ansgar,
klar gerne, kann aber etwas dauern...
Gibt es was besonderes zu testen/beachten?
Gruß, Joachim
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.
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
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
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
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.
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)
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
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!!
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?
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.
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.
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
ja, bisher lief der CUL. Nur nach der Umstellung auf TSCUL nicht mehr ...
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.
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
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.
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
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
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.
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.
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
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
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.
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
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
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
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
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
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.
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
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?
@Ansgar: Darf ich fragen, was in der Version 0.03 neu ist? und welche Dateien sich geändert haben? Muss man die Firmware updaten?
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.
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
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
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
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.
Hallo Ansgar,
ich habe den CUL_V3.4. Könntest Du dafür die Firmware-Dateien bitte erstellen?
Frank
Hallo Frank,
hier eine Firmware Version für CUL V3.4 mit 9 HM Buffern.
Gruß, Ansgar.
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.
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
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.
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
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.
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)
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
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.
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
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
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.
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
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
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
Hallo Mario,
sieht erst mal gut aus.
Treten die Probleme wieder auf?
Gruß, Ansgar.
Hi,
bis jetzt funktioniert alles wunderbar.
Danke, gute Arbeit
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ß!
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.
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
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.
Danke! Ich beginne halt erst und außer dem Bewegungsmelder läuft noch nix weiter. Und gestern war halt ab nachmittags niemand zuhause :D
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?
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.
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
- 4E62E2 - Wohnzimmer WM55
- 4E5E9A - Küche WM55
- 2A4CC9 - Tür-/Fensterkontakt Optisch
- 4A6ED5 - Heizungsthermostat (funktioniert einwandfrei)
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
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.
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.
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
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.
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+&
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.
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.
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.
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
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.
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.
Hallo Kai,
wenn Du Deine Ergebnisse hier postest, dann kann ich sie in den Source einfließen lassen.
Danke!
Ansgar.
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?
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.
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
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.
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
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.
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?
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.
Hallo Ansgar,
nach dem Reset hatte ich deine erwähnten Werte, mal schaun wie sich nun alles verhält.
Danke
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
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.
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!
:) :) :) :) :)
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 ?
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...
;)
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
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)
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?
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?)
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 ?
RPi add-on ist nicht das gleiche wie SCC, du folgst der falschen Anleitung.
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
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.
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.
@Martin, Ansgar: Super!!
Hmm, dann muss ich wohl mal alles auf den neuesten Stand bringen... ;)
Danke, Joachim
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
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.
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.
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
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
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.
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.
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
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.
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
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.
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
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.
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.
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?
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.
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
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.
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
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.
Hallo Ansgar,
vielen Dank für deine Erläuterungen und deinen tollen Support :-).
Viele Grüße
Frank
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.
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
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.
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.
Und wie kommt jetzt Stefan ins Spiel? :)
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.
ZitatHabe ich da gerade eine neue Baustelle aufgemacht?
Ja :-\
Aber danke fuer den Hinweis.
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.
% 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.
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.
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 :)
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.
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
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.
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
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.
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
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.
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.
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.
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
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
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.
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.
Hallo Frank,
#define VERSION_1 01
#define VERSION_2 66
#define VERSION "1.66"
ergibt Version 1.66 .
Gruß, Ansgar.
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.
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?
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.
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 ;)
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
... hmm, komisch. In den Internals wird die Version mit 1.66 angegeben. Das OTA-Tool meldet aber, dass nur Version 0.66 vorliegt :-[
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.
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.
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
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?
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.
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.
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.
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.
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
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.
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
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.
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
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.
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
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.
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
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
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
.
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?
Hallo b4rRa,
wenn Du nicht von der Bauanleitung abgewichen bist, dann sollte es passen, da hier im Thread schon getestet.
Gruß, Ansgar.
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
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.
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.
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...
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
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?
Hallo Manul,
die Versionsinfo der TS Firmware fängt mit "VTS" statt "V" an.
Du warst offenbar nicht erfolgreich.
Gruß, Ansgar.
Danke. Ich bin wie folgt vorgegangen:
- Zip-Archiv aus diesem Post (https://forum.fhem.de/index.php/topic,24436.msg529649.html#msg529649) runtergeladen und entpackt
- alle Module aus FHEM nach /opt/fhem/FHEM kopiert, fhem neu gestartet
- Firmware/TSCUL_V3.hex nach /opt/fhem/FHEM/firmware/CUL_V3.hex kopiert
[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.
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.
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?
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.
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.
Noch eine Verständnisfrage zu AES: Wie interagieren die auf dem CUL gespeicherten Schlüssel mit denen in FHEM?
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.
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?
Hallo Manul,
Zitatden Rest erledigt FHEM?
Die fhem.cfg musst Du schon noch anpacken, damit die TS Module genutzt werden.
Gruß, Ansgar.
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.
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.
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
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.
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.
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.
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
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.
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
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.
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
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
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.
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!
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?
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.
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?
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.
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.
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.
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.
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.
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.
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.
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
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.
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"?
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.
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
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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
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.
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
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.
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.
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.
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 F00
1):
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 F10
3) 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.
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. :)
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
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.
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
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
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.
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
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.
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.
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
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.
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
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.
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
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.
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
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.
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
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, ...
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
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.
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.
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
Hallo Frank,
ZitatHast Du eine Idee woran es liegen könnte?
Ohne Log, Lists, etc. leider nicht.
Hast Du irgendwas geloggt?
Gruß, Ansgar.
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
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.
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
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.
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 ...
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.
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).
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.
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
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.
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.
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)
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.
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.
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.
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)
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
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.
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
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.
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
Hey Klausw,
man testet aber im Testsystem und nicht Produktiv ;-)
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
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
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
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
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.
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
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.
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
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.
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.
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?
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.
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
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.
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
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.
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...
Hallo Klaus,
ZitatAuf dem NanoCul ist noch die alte Firmware drauf.
welche Version denn?
Gruß, Ansgar.
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
Hallo Klaus,
ZitatVERSION VTS 0.02 nanoCUL868
Dann war die in der angehängten zip der Stand von damals.
Gruß, Ansgar.
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
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
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.
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 ;-)
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.
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.
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.
HAllo noansi,
vielen Dank. Aber ich sehe keine Anlage in Deinem Post.
Greets
Byte
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...
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.
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.
Hallo Byte,
hängt aber dran. Warst Du nicht eingeloggt?
Gruß, Ansgar.
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
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.
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)
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.
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
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.
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
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...
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.
Hab noch unusedstack vergessen: TSCUL unusedstack => 313
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.
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.
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!
Hallo Florian,
ZitatV0.20 läuft bei mir!
Schön. :) Ohne Modifikationen denke ich.
Wie ist der unusedstack Stand nach einiger Laufzeit?
Gruß, Ansgar.
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.
Hallo Zusammen,
mir sind noch 3 Fehler in der letzten Änderung von 00_TSCUL.pm aufgefallen. Bitte die aktuelle Version oben verwenden.
Gruß, Ansgar.
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
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.
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.
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?
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.
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.
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
AES nutze ich hier nicht.
Gesendet von iPhone mit Tapatalk
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.
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.
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.
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.
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
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.
Hallo Ansgar,
wieder mal ein fettes Danke von mir für deine unermüdliche und super Arbeit ;D
Viele Grüße
Frank
Version 0.21 funktioniert seit gestern Abend stabil bei mir.
Ebenso wie TSCULflash mit dem nanocul
Daumen hoch :D
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.
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
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.
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.
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.
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.
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.
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?
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.
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
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.
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
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.
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.
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?
Guten Morgen,
wurden die Änderungen zwischenzeitlich in die 10_CUL_HM.pm übernommen, oder muss ich sie weiterhin vom Update ausschließen?
Greets
Byte
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.
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.
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?
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.
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
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
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
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.
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.
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.
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
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
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.
Hallo Ansgar
Habe soeben die neuen Module reinkopiert und neu gestartet, es funktioniert mit meinem nanoCUL.
mfg waage
Hallo waage,
danke für das Feedback!
Gruß, Ansgar.
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.
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.
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
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.
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.
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
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.
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
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
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.
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.
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
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.
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
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.
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
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.
Hallo liebe Experten,
besteht die Möglichkeit auch den CUBE mit TSCUL zu flashen analog zu aCULFW?
Herzliche Grüße!
Heinz
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
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).
Hallo Heggeg,
vielleicht noch eine Idee, kannst Du in Deinem virtuellen Ubuntu USB2.0 Unterstützung abschalten?
Möglicherweise hilft das?
Gruß, Ansgar.
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.
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.
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!
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
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.
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
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
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
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
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.
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.
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.
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.
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.
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.
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!
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.
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.
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
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.
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
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.
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.
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!
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
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.
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!
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.
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!
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.
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!
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
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.
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)
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
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.
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
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.
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.
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
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.
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.
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.
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!
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?
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...
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
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
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.
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
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.
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...
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.
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
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.
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.
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.
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...
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.
Macht Sinn - und geht. Danke.
Sehr gesprächig das log jetzt - pairing mit einem Bewegungsmelder hat 1a funktioniert
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
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
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.
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.
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
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 ;)
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.
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
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
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
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
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.
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
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.
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.
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
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.
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
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.
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
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.
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
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
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.
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
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.
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
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.
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
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.
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.
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
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
Hallo Frank,
der Quellcode oben ist aktualisiert, weil mir noch was im Bezug auf OTA-Firmwareupdate mit Seriennummer aufgefallen ist.
Gruß, Ansgar.
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.
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.
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
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
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.
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.
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.
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.
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.
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.
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.
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).
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
Hallo noansi,
ich danke dir. Dann werde ich mal probieren.
Gruß jw1hal
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
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.
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
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.
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?
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.
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
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.
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.
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 ;)
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.
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!
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
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 ::)
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.
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
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.
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
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.
Danke für die Info.
Leider reichen da meine Kenntnisse in keinster Weise für aus. [emoji6]
Gesendet von meinem E6653 mit Tapatalk
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
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.
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
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.
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ß
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
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.
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ß
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
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.
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?
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.
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
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.
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.
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.
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
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.
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
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.
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.
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.
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.
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.
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. :)
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.
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.
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
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.
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.
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
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.
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
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.
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.
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, ...
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.
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
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
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.
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
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.
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.
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
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.
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
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.
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:
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.
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
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.
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
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.
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.
Irgendwie bin ich gerade blind - wo kann ich bitte die tsculfw herunterladen?
Hallo Markus,
im ersten Beitrag dieses Threads ist der link zum passenden Beitrag zu finden.
Gruß, Ansgar.
Vielen Dank. Hatte den Link zur Datei nicht gesehen
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)
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
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
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.
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.
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.
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
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
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.
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.
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
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.
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
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)
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)
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
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
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.
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.
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
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
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
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
Danke Joachim,
werde ich dann mal beobachten
vg Thomas
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.
Hallo Ansgar,
ja das Hauptsystem soll umgestellt werden.
Ok danke. werde das mal angehen. Danke
Thomas
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
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
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.
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
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.
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
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.
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
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.
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
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
definiere eine vccu.
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
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
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.
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.
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.
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
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.
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....
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.
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.
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
Hallo Peter,
ZitatDas erklärt es dann wohl nicht?!
Aber die automatische Zuordnung eines IODev, siehe oben sollte es erklären.
Gruß, Ansgar.
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
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.
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.
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.
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....
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.
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
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
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.
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
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.
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
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!
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, ...
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.
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
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
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.
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.
im device vom rt fehlt das attr IODev.
somit wird nichts gesendet.
mit vccu muss zusätzlich auch attr IOgrp existieren.
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
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!
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.
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:
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
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
@riker1
es funktioniert jetzt, weil nun das attr IODev existiert. ;)
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.
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
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
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.
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
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.
hallo ansgar,
attr iodev muss immer vorhanden sein, auch wenn attr iogrp genutzt wird, also bei verwendung einer vccu.
ansonnsten macht mindestens aes probleme.
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.
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.
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
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.
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
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. :)
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.
Hallo Ansgar,
lieferst Du die "fehlenden" HEX Files noch nach, wie z.B. rpiaddon, CUL_V4 etc?
Gruß
Peter
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.
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
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.
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.
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
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.
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
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
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, ...
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.
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.
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
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
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, ...
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.
Leider konnte ich die Info nicht finden.
Auf einem (Max) Cube ist die Firmware nicht einsetzbar. Ist das korrekt?
Vielen Dank!
Hallo Thargor,
ZitatAuf einem (Max) Cube ist die Firmware nicht einsetzbar. Ist das korrekt?
Das ist im derzeitigen Stand korrekt.
Gruß, Ansgar.
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.
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.
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.
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.
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
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.
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
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.
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
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.
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
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.
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
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.
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
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.
Diesmal wollte der Sensor einfach nicht senden..
Aber ein EB90 ist drin, auch "authentisch" ELV HMS100TF, siehe Anhang
Danke
Peter
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.
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
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.
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)
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.
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
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.
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)
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.
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.
23:59:44
00:02:18
00:05:06
habe ich was gesehen von beiden Sensoren
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.
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 ...
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
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 CULV3
RFR 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.
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
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.
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.
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
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.
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
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.
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.
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
Hallo Peter,
danke, mir scheint da noch eine Ziffer bei Lacrosse durch die Lappen gegangen zu sein.
Gruß, Ansgar.
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
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
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?
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.
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
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.
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
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.
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
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.
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
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
das ist sicher vom nachbarn.
definiere eine vccu.
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
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.
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
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.
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
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
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.
Hallo Ansgar,
Danke, hab gerade alles aktualisiert, bisher läuft alles. Ich beobachte es jedenfalls weiter.
Gruß,
Stefan
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
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
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.
Hallo Zusammen,
ich habe oben nochmal Module (nicht die Firmware) in der zip korrigiert., siehe Edit3.
Gruß, Ansgar
Hallo Ansgar,
alles klar, hab noch mal bei mir aktualisiert ;)
Gruß,
Stefan
Hallo Zusammen,
... Edit4.
Gruß, Ansgar.
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
Hallo Thomas,
kannst das mal mit screenshots erklären, was Du meinst?
Gruß, Ansgar.
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
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.
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
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.
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.
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
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
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.
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
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.
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
Hallo Thomas,
:o :o :o :o :o
Ich habe den Rudolfs Commandref Tip jetzt fett zwingend hervorgehoben.
Gruß, Ansgar.
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.
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
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.
Hallo Ansgar,
kurze Rückmeldung. Dateien ausgetauscht, Fhem neu gestartet und nu scheint es zu funktionieren. Danke schön.
Gruß Thomas
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
Hallo Chris,
hast Du auch ein list vom CUL (mit frischem ccconf) und ASH 2000 für die Glaskugel?
Gruß, Ansgar.
Hallo Ansgar,
die lists sind im Anhang
Grüße
Chris
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.
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
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.
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
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
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.
Danke Ansgar,
ich werde es in den nächsten Tagen ausprobieren.
Grüße
Chris
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
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.
Hallo Ansgar,
vielen Dank für die Info und nochmal für Deine schnelle Hilfe.
Grüße
Chris
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.
attr IODev=CUL_3 IODev CUL_Dach
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.
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.
Danke Ansgar.
Ich glaube, ich werde vorerst mal mit meinen begangenen Taten weiterleben. ;D
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.
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
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.
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_
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.
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
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.
in den hauptdevices der virt tc fehlt jeweils attr IOgrp.
hat hminfo configCheck keine probleme gemeldet?
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.
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
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.
Hallo Jörg,
noch eine Ergänzung im vorherigen Beitrag...
Gruß, Ansgar.
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
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.
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
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
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.
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...
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
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.
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
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
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.
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)
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.
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
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.
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
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.
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
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.
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
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
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.
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.
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
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.
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.
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.
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
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
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.
Hallo Ansgar,
keine Ahnung warum die 97_timerTS.pm nicht mitkopiert wurde. Aber das war der Fehler.
Danke dir fürs supporten.
LG Chris
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.
wow, hört sich super an.
funktioniert das auch mit anderen io oder nur mit cul?
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.
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
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.
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.
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.
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
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.
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.
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.
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.
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
Hallo Jörg,
dann bin ich auf das verbose 2 Log gespannt.
Gruß, Ansgar.
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
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.
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
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.
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
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.
hallo ansgar,
ZitatZitatps: 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
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.
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
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.
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.
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
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.
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
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
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.
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.
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
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.
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
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.
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
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.
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.
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
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.
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)
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.
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
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.
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.
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.
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
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.
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
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.
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.
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.
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
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.
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
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
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.
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
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.
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
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
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.
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
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.
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.
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.
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
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.
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
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.
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.
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
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.
Danke nochmal!
Da werde ich mir bei Gelegenheit mal die Antenne angucken.
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
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.
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
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
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.
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.
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
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
Hallo Jörg,
puhh, Glück gehabt, dass ich es spät genug gelesen habe. ;)
Gruß, Ansgar.
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.
Hi Ansgar,
gibt's eine kurze Zusammenfassung der Änderungen?
Danke,
Jörg
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.
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.
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
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.
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
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
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.
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
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.
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
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.
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. :)
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.
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.
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.
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. ;)
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.
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. :)
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.
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. :)
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.
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.
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!
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.
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.
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.
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.
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
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.
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
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.
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.
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.
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.
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
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.
Ok. Danke.
Dann mal noch schöne Ostern.
Gruß Peter
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
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.
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
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.
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
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)
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.
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.
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
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 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.
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
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.
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
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?
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
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?
Hallo Peter,
was sagt get PAtable1 bei(m) TSCUL?
Eventuell kommst Du mit set patable 9 weiter.
Gruß, Ansgar.
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
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?
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.
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.
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
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?
Hallo Thomas,
bitte nochmal ein frishes list vom Rauchmelder channel und device.
Gruß, Ansgar.
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
Hallo Thomas,
neuer Anlauf im Anhang.
Gruß, Ansgar.
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
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.
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.
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.
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
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.
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!!
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
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.
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
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.
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
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.
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> 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.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 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.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)
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?)
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
Hallo Jörg,
ZitatWo stelle ich das ein?
Attribut rfmode.
Gruß, Ansgar.
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.
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.
Hallo yersinia,
dank für das Feedback, ich habe oben den Modulstand entsprechend aktualisiert.
Gruß, Ansgar.
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
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.
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.
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
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.
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
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.
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
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
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
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.
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.
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
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.
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?
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.
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
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
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?
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.
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
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.
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.
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.
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. :)
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.
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.
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
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.
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
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.
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
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.
Es war mit vorzugsio definiert.
Hatte jetzt natürlich alles auf vorzugsio hmlanv gestellt, da der cul zickt...
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.
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.
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.
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
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.
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.
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
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,
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.
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.
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
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
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];
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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
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.
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,
:) Es funktioniert einwandfrei! Super!
Bin total Happy
Viele Grüße
Eckart
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.
Hallo Eckart,
im Anhang noch eine neue als V0.40 "getarnte" Version der Firmware, damit auch der IT Empfang wieder klappt.
Gruß, Ansgar.
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
Hallo Eckart,
kennst Du das IT Protokoll und clock des IT Handsenders?
Gruß, Ansgar.
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
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.
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...
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.
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
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.
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
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.
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
Hallo Eckart,
im Anhang nochmal eine Tarnversion zum testen.
Wenn Du mit
set CUL_0 raw X25
den 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.
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.
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.
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. :)
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
Hallo yersinia,
nein, Du hast nichts verpasst.
Meine Zählung unveröffentlicher Zwischenstände ist nur weiter fortgeschritten.
Gruß, Ansgar.
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.
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
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.
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");
}
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
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.
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
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.
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.
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
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.
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).
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
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.
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.
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
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
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.
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
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.
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
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.
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.
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.
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
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
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.
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
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.
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:
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:
- einen nanoCUL mit VTS 0.40 CSM433
- und einen CUL_V3 mit VTS 0.39 CUL868
Könntest Du mir bitte die gleiche oder größere TSCULFW für den CUL868 und die Scripte bereitstellen?
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.
::) Oh Mann. Gute Frage :))
Die FW ist nicht Frequenzabhängig, oder?
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.
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
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.
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
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.
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
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 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.
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.
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.
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
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.
tsculfw 0.39 Teil1
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)
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 :-)
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
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
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.
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
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äten, die die Ausstrahlung der Befehle für das
"logische" Gerät ausführen. Das erste aktive aus der Liste wird genutzt.
Ein Beispiel für ein physisches Gerät ist ein CUL.<br>
Anmerkung: Beim Start weist fhem einem InterTechno-Gerät kein IO-Gerä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.
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
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 kennen
wü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.
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"...
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 Sinn
Kommt 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.
Hallo Ralf,
ich habe nochmal einige Korrekturen und Verbesserungen eingepflegt, die mir noch aufgefallen sind.
Gruß, Ansgar.
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
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.
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
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.
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
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.
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?
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.
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
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.
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.
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.
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> 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.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 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.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 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?msg=1167796 (https://forum.fhem.de/index.php?msg=1167796).
Gruß, Ansgar.