CUL / Intertek frustration [solved]

Begonnen von Doddster, 19 März 2017, 10:20:09

Vorheriges Thema - Nächstes Thema

Doddster

Hi Guys,

I've been trying for a week now to get my CC1101-USB-Lite to talk to my Intertek radio sockets( Funksteckdosen) with no success.

I've flashed the stick and can read the config from the stick so I'm guessing it's ok (the green light is flashing),  but none of the devices react to the commands. I have SlowRF set and am addressing the devices using the hex codes as defined in the fhem wiki (Intertechno Code Berechnung), but nothing happens. If I use the remote that came with the set all devices work.

Is there a ways to switch the stick into receive mode so I can tell if it's seeing the remote commands, this might help me.

Any other ideas greatly appreciated.

Thanks,

Graham

KölnSolar

Hi Graham,

which version did you flash to the USB-stick ? Is FHEM up to date ? Did you find and able to understand the german Threads about Intertek ?

Best regards Markus
Edit: Do you have other devices working with the stick ?
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Wichtel

Do you get the right frequency setting when doing "get CUL ccconf" ?
For my setup of original Intertechno with rotating switches and cheap sockets from "Pollin" with DIP-Switches its "freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB".

You have autocreate enabled?

When opening event monitor and pressing the remote, nothing happens?
It should...

Doddster

#3
Zitat von: KölnSolar am 19 März 2017, 11:00:23
Hi Graham,

which version did you flash to the USB-stick ? Is FHEM up to date ? Did you find and able to understand the german Threads about Intertek ?

Best regards Markus
Edit: Do you have other devices working with the stick ?

Hi Marcus,

I used 1.66 _V3 which I believe is the correct one and yes FHEM is up to date.

I have read the german threads and understand how to setup the dip switches and which HEX codes to use. I also used the remote to verify the devices are working. I have no other devices working with the stick, I got the stick because it supports the Funksteckdosen

I am new to FHEM so I think it is more a configuration problem.

Thank you,

Graham

Doddster

Zitat von: Wichtel am 19 März 2017, 11:18:34
Do you get the right frequency setting when doing "get CUL ccconf" ?
For my setup of original Intertechno with rotating switches and cheap sockets from "Pollin" with DIP-Switches its "freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB".

You have autocreate enabled?

When opening event monitor and pressing the remote, nothing happens?
It should...

Hi,

yes when I do a get CUL cconf I get exactly the same as you and autocreate is enabled.

But I get nothing in the event monitor when I use the remote. Do I need to configure CUL to read the remote, or should it pick up the remote signal automatically?

Thank you,

Graham

KölnSolar

flash the newest version of aculfw. this should help  ;D
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Doddster

Hi Marcus,

flashed with the latest a-culfw and it works ;D

thanks for the help.

Graham

KölnSolar

great.
please add a [solved] to the topic.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

wk

Hi Graham,

can you be more specific, what works for you and how.

I have the same stuff as you and the same readings for ccconf. I tried all versions of a-culfw since 1.23.02 up to 1.24.01 with no luck getting it connected or usefull reading in the event manger.
With attr verbose 5 Iget a lot of chunk in the log, telling something of Manchester Code and Oregon and Hideki.

I would appriciate some explinations.

cu
Walter

KölnSolar

ZitatWith attr verbose 5 Iget a lot of chunk in the log, telling something of Manchester Code and Oregon and Hideki.
received code can't be interpreted  :(
you might add an extract of Log and list of CUL and dp sitch settings to get more help.
Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

wk

#10
Thank you Markus,

I'll try to get as precise as possible.

This is my CUL definition:

defmod CUL_3 CUL /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A1062BZJ-if00-port0@38400 0000
attr CUL_3 verbose 5

setstate CUL_3 2017-04-23 18:51:37 ccconf freq:433.920MHz bWidth:325KHz rAmpl:42dB sens:4dB
setstate CUL_3 2017-04-23 18:52:39 cmds  A B C e F f G i K L l M N R T t U V W X x
setstate CUL_3 2017-04-23 18:52:35 raw No answer
setstate CUL_3 2017-04-23 18:52:39 state Initialized
setstate CUL_3 2017-04-23 18:52:03 version V 1.24.01 a-culfw Build: 204 (2017-03-06_18-50-06) nanoCUL433 (F-Band: 433MHz)


and now the log after pressing 5 times the same on-button:

2017.04.23 18:54:46 5: CUL/RAW: /om
2017.04.23 18:54:46 5: CUL/RAW: om/94848037

2017.04.23 18:54:46 4: CUL_Parse: CUL_3 om94848037
2017.04.23 18:54:46 5: CUL_3: dispatch om94848037
2017.04.23 18:54:46 5: CUL_REDIRECT (m94848037) length: 9 RSSI: -46.5
2017.04.23 18:54:46 5: CUL_REDIRECT (m94848037) match Manchester COODE length: 9
2017.04.23 18:54:46 5: CUL_REDIRECT decode Oregon 2 (94848037)
2017.04.23 18:54:46 5: bitdata: 10010100100001001000000000110111
2017.04.23 18:54:46 5: CUL_REDIRECT decode Oregon 3 (94848037)
2017.04.23 18:54:46 5: bitdata: 10010100100001001000000000110111
2017.04.23 18:54:46 5: CUL_REDIRECT decode Hideki (94848037)
2017.04.23 18:54:46 5: CUL_3: search in 10010100100001001000000000110111

2017.04.23 18:54:46 5: protocol does not match, ignore received package (94848037) Reason: Not a hideki protocol
2017.04.23 18:54:49 5: CUL/RAW: /om95
2017.04.23 18:54:49 5: CUL/RAW: om95/6B2437

2017.04.23 18:54:49 4: CUL_Parse: CUL_3 om956B2437
2017.04.23 18:54:49 5: CUL_3: dispatch om956B2437
2017.04.23 18:54:49 5: CUL_REDIRECT (m956B2437) length: 9 RSSI: -46.5
2017.04.23 18:54:49 5: CUL_REDIRECT (m956B2437) match Manchester COODE length: 9
2017.04.23 18:54:49 5: CUL_REDIRECT decode Oregon 2 (956B2437)
2017.04.23 18:54:49 5: bitdata: 10010101011010110010010000110111
2017.04.23 18:54:49 5: CUL_REDIRECT decode Oregon 3 (956B2437)
2017.04.23 18:54:49 5: bitdata: 10010101011010110010010000110111
2017.04.23 18:54:49 5: CUL_REDIRECT decode Hideki (956B2437)
2017.04.23 18:54:49 5: CUL_3: search in 10010101011010110010010000110111

2017.04.23 18:54:49 5: protocol does not match, ignore received package (956B2437) Reason: Not a hideki protocol
2017.04.23 18:54:51 5: CUL/RAW: /o
2017.04.23 18:54:51 5: CUL/RAW: o/m9A954836

2017.04.23 18:54:51 4: CUL_Parse: CUL_3 om9A954836
2017.04.23 18:54:51 5: CUL_3: dispatch om9A954836
2017.04.23 18:54:51 5: CUL_REDIRECT (m9A954836) length: 9 RSSI: -47
2017.04.23 18:54:51 5: CUL_REDIRECT (m9A954836) match Manchester COODE length: 9
2017.04.23 18:54:51 5: CUL_REDIRECT decode Oregon 2 (9A954836)
2017.04.23 18:54:51 5: bitdata: 10011010100101010100100000110110
2017.04.23 18:54:51 5: CUL_REDIRECT decode Oregon 3 (9A954836)
2017.04.23 18:54:51 5: bitdata: 10011010100101010100100000110110
2017.04.23 18:54:51 5: CUL_REDIRECT decode Hideki (9A954836)
2017.04.23 18:54:51 5: CUL_3: search in 10011010100101010100100000110110

2017.04.23 18:54:51 5: protocol does not match, ignore received package (9A954836) Reason: Not a hideki protocol
2017.04.23 18:54:54 5: CUL/RAW: /o
2017.04.23 18:54:54 5: CUL/RAW: o/mADAD8038

2017.04.23 18:54:54 4: CUL_Parse: CUL_3 omADAD8038
2017.04.23 18:54:54 5: CUL_3: dispatch omADAD8038
2017.04.23 18:54:54 5: CUL_REDIRECT (mADAD8038) length: 9 RSSI: -46
2017.04.23 18:54:54 5: CUL_REDIRECT (mADAD8038) match Manchester COODE length: 9
2017.04.23 18:54:54 5: CUL_REDIRECT decode Oregon 2 (ADAD8038)
2017.04.23 18:54:54 5: bitdata: 10101101101011011000000000111000
2017.04.23 18:54:54 5: CUL_REDIRECT decode Oregon 3 (ADAD8038)
2017.04.23 18:54:54 5: bitdata: 10101101101011011000000000111000
2017.04.23 18:54:54 5: CUL_REDIRECT decode Hideki (ADAD8038)
2017.04.23 18:54:54 5: CUL_3: search in 10101101101011011000000000111000

2017.04.23 18:54:54 5: protocol does not match, ignore received package (ADAD8038) Reason: Not a hideki protocol
2017.04.23 18:55:00 5: CUL/RAW: /om9
2017.04.23 18:55:00 5: CUL/RAW: om9/56B2438

2017.04.23 18:55:00 4: CUL_Parse: CUL_3 om956B2438
2017.04.23 18:55:00 5: CUL_3: dispatch om956B2438
2017.04.23 18:55:00 5: CUL_REDIRECT (m956B2438) length: 9 RSSI: -46
2017.04.23 18:55:00 5: CUL_REDIRECT (m956B2438) match Manchester COODE length: 9
2017.04.23 18:55:00 5: CUL_REDIRECT decode Oregon 2 (956B2438)
2017.04.23 18:55:00 5: bitdata: 10010101011010110010010000111000
2017.04.23 18:55:00 5: CUL_REDIRECT decode Oregon 3 (956B2438)
2017.04.23 18:55:00 5: bitdata: 10010101011010110010010000111000
2017.04.23 18:55:00 5: CUL_REDIRECT decode Hideki (956B2438)
2017.04.23 18:55:00 5: CUL_3: search in 10010101011010110010010000111000

2017.04.23 18:55:00 5: protocol does not match, ignore received package (956B2438) Reason: Not a hideki protocol

             
I hope this helps a bit.

cu
Walter

KölnSolar

Hi Walter,
please put extracts of code or Logs into code tags(the # symbol above) to make it more readable. You may change your earlier post.

Zitat9A954836
1001 1010 1001 0101 0100 1000 0011 0110
looks not that bad. 32-bit received, means the switches are using IT V3 protocol. Normally the protocol looks like
id: 1001 1010 1001 0101 0100 1000 00 
all: 1
state(on/off):1
unit: 0110
But
Zitat
and now the log after pressing 5 times the same on-button:
I can't believe in this, since you received
Zitat94848037
956B2437
9A954836
ADAD8038
956B2438
You've received 5 different codes pressing the same button ? I don't have an idea whats happening  :-[
With other devices the CUL is working properly ?
Regards Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

wk

Hi Markus,

as you sugested I edited the post.

And I confirm, that it has been 5 times the same button. That's confusing me.
Other product working great. I have some original Intertechno Switches with rotating Codeselectors and a wireless thermometer. All no problem.

But I have some more of the Unitec self learning switches, that work perfect with wide range from their remote control. Until now they refrain from working with fhem.

cu
Walter

KölnSolar

Hi Walter,
I assume this intertek stuff is different to Doddster's.

Maybe its a kind of a rolling code or a sending/receiving problem.  :-[
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

wk

Hi Markus,

I thought, we are discussing about the widespread Unitec Switches (see Picture).

There are many threads about this switches with no real solution and I hoped to find a solution here.
You see them in every market and they are cheap. So it is hard to believe, that they use a code that is so different from the rest of the world.

cu
Walter