Autor Thema: CUL: No answer  (Gelesen 2277 mal)

Offline kennybl

  • Jr. Member
  • **
  • Beiträge: 52
CUL: No answer
« am: 18 April 2021, 10:03:49 »
Hello,

Last week i connected my CUL again to start using my new program. It works good except that the cul loses connection multiple times a day.

I get:
CUL: No answer


I see a strange thing after restarting fhem:

2021.04.02 07:58:31 1: usb create starting
2021.04.02 07:58:31 3: Probing ZWDongle device /dev/serial1
2021.04.02 07:58:31 3: Probing CUL device /dev/ttyAMA0
2021.04.02 07:58:32 3: Probing TCM_ESP3 device /dev/ttyAMA0
2021.04.02 07:58:32 3: Probing ZWDongle device /dev/ttyAMA0
2021.04.02 07:58:32 3: Probing SIGNALDuino device /dev/ttyAMA0
2021.04.02 07:58:32 3: Probing MYSENSORS device /dev/ttyAMA0
2021.04.02 07:58:32 3: Probing ArduCounter device /dev/ttyAMA0
2021.04.02 07:58:32 3: Probing ElsnerWS device /dev/ttyAMA0
2021.04.02 07:58:33 3: Probing FRM device /dev/ttyAMA0
2021.04.02 07:58:39 3: Probing TCM_ESP3 device /dev/ttyUSB0
2021.04.02 07:58:39 3: Probing TCM_ESP2 device /dev/ttyUSB0
2021.04.02 07:58:39 3: Probing FHZ device /dev/ttyUSB0
2021.04.02 07:58:39 3: Probing TRX device /dev/ttyUSB0
2021.04.02 07:58:40 3: Probing ZWDongle device /dev/ttyUSB0
2021.04.02 07:58:40 3: Probing SIGNALDuino device /dev/ttyUSB0
2021.04.02 07:58:40 3: Probing MYSENSORS device /dev/ttyUSB0
2021.04.02 07:58:40 3: Probing ArduCounter device /dev/ttyUSB0
2021.04.02 07:58:40 3: Probing ElsnerWS device /dev/ttyUSB0
2021.04.02 07:58:41 3: Probing FRM device /dev/ttyUSB0
2021.04.02 07:58:59 3: Probing TCM_ESP3 device /dev/ttyUSB_RELAY
2021.04.02 07:58:59 3: Probing TCM_ESP2 device /dev/ttyUSB_RELAY
2021.04.02 07:58:59 3: Probing FHZ device /dev/ttyUSB_RELAY
2021.04.02 07:58:59 3: Probing TRX device /dev/ttyUSB_RELAY
2021.04.02 07:59:00 3: Probing ZWDongle device /dev/ttyUSB_RELAY
2021.04.02 07:59:00 3: Probing SIGNALDuino device /dev/ttyUSB_RELAY
2021.04.02 07:59:00 3: Probing MYSENSORS device /dev/ttyUSB_RELAY
2021.04.02 07:59:00 3: Probing ArduCounter device /dev/ttyUSB_RELAY
2021.04.02 07:59:01 3: Probing ElsnerWS device /dev/ttyUSB_RELAY
2021.04.02 07:59:02 3: Probing FRM device /dev/ttyUSB_RELAY
2021.04.02 07:59:07 1: usb create end


I see ttyUSB0 and ttyUSB_RELAY (a name i gave to a relayboard connected via USB).
I am not sure if it always happens but after i turn on or off a relay, i think the cul "crashes".

The connection to the cul is this:
/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@38400 0000

Did i do something wrong, is above just normal or is my USB cable wrong for example?

Thanks a lot!

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5234
Antw:CUL: No answer
« Antwort #1 am: 18 April 2021, 10:11:54 »
Zitat
is above just norma
No. You should remove usb commands in Your FHEM-config.
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

Offline kennybl

  • Jr. Member
  • **
  • Beiträge: 52
Antw:CUL: No answer
« Antwort #2 am: 18 April 2021, 10:21:52 »
i should comment this part?

# Disable this to avoid looking for new USB devices on startup
define initialUsbCheck notify global:INITIALIZED usb create
setuuid initialUsbCheck 5f847b85-f33f-c04f-3b46-18d1c7338ccc398c


I commented both lines, but as soon as i set a relay, fhem reports this line in the log:

2021.04.18 10:36:57 1: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0 disconnected, waiting to reappear (CUL)

It won't reappear until i restart fhem
« Letzte Änderung: 18 April 2021, 10:38:27 von kennybl »

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5234
Antw:CUL: No answer
« Antwort #3 am: 18 April 2021, 13:27:13 »
Zitat
i should comment this part?
yes.
Zitat
It won't reappear until i restart fhem
Seems to be a problem with your relay board. Is it defined in FHEM too ? Otherwise its an OS-issue. What shows ls -l /dev/serial/by-id ?
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

Offline kennybl

  • Jr. Member
  • **
  • Beiträge: 52
Antw:CUL: No answer
« Antwort #4 am: 18 April 2021, 13:30:24 »
$ ls -l /dev/serial/by-id
total 0
lrwxrwxrwx 1 root root 13 Apr 18 11:07 usb-1a86_USB2.0-Serial-if00-port0 -> ../../ttyUSB1
lrwxrwxrwx 1 root root 13 Apr 18 10:53 usb-Prolific_Technology_Inc._USB-Serial_Controller_D-if00-port0 -> ../../ttyUSB0

The relayboard is a 8-chanel Conrad relayboard (https://www.conrad.nl/p/conrad-components-197730-relaiskaart-module-12-vdc-197730), sometimes it works great but sometimes it crashes too after setting some relays.

This doesn't happen all the time but all the them FHEM loses connection to the usb CUL

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5234
Antw:CUL: No answer
« Antwort #5 am: 18 April 2021, 17:20:16 »
At least it is not a busware-CUL. A nanoCUL has an FTDI-Chip. What kind of CUL do you have and are you sure it is this one
Zitat
/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0

How and where ist the relayboard defined ? As ttyUSBx ?
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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15657
Antw:CUL: No answer
« Antwort #6 am: 18 April 2021, 17:53:19 »
That's a WCH CHG340 vor 341, often used for China Clones. As both converters habe unique and different id's here, I'd recommend addressing both "by-id". There's a wiki Entry (german) " mehrere USB-Geräte", should be self-expaining.(For next device at USB, look for different ones).
 
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline kennybl

  • Jr. Member
  • **
  • Beiträge: 52
Antw:CUL: No answer
« Antwort #7 am: 18 April 2021, 17:58:35 »
I forgot how to check the usb id, but the relayboard is not a CHG340 clone, it is the Conrad relayboard, the nanoCul is a china clone, but it is the only china clone connected to the Raspberry Pi.

I gave the relayboard a specific name (USB_RELAY, instead of USB0, USB1 etc) so i thought this would work

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15657
Antw:CUL: No answer
« Antwort #8 am: 18 April 2021, 18:06:25 »
Using udev rules should also work, that's true (if it's done in all ends).

Might be a powering issue. Is your Server base a Rasspberry Pi?
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline kennybl

  • Jr. Member
  • **
  • Beiträge: 52
Antw:CUL: No answer
« Antwort #9 am: 18 April 2021, 18:16:53 »
I only uded the rule for the relayboard, not for the nanocul.

I use a raspberry pi 4 for fhem and some other things. The relayboard and the nanocul are being powerd by a 8A usb hub, so i think the power should be okay

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5234
Antw:CUL: No answer
« Antwort #10 am: 18 April 2021, 18:19:11 »
Zitat
I gave the relayboard a specific name (USB_RELAY, instead of USB0, USB1 etc) so i thought this would work
Zitat
How and where ist the relayboard defined ?
The system defines it as ttyUSBx. The x might change with a reboot. There is no rule. Therefore the suggestion of Beta-User to define the CUL by-id(what you already did).
Edit:
Zitat
if it's done in all ends
That's the question.  ;)
Edit2:
Zitat
I only uded the rule for the relayboard, not for the nanocul.
Maybe the posting of the definition helps.
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

Offline kennybl

  • Jr. Member
  • **
  • Beiträge: 52
Antw:CUL: No answer
« Antwort #11 am: 18 April 2021, 18:30:05 »
But in Fhem, i did like this:

/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0@38400 0000
It connected by id right?
What rule can / do i need to make

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 15657
Antw:CUL: No answer
« Antwort #12 am: 18 April 2021, 18:38:52 »
Should be OK. The Hub: is it USB3 compatilbe? If: try one not supporting USB3.
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline kennybl

  • Jr. Member
  • **
  • Beiträge: 52
Antw:CUL: No answer
« Antwort #13 am: 18 April 2021, 19:20:38 »

Offline KölnSolar

  • Developer
  • Hero Member
  • ****
  • Beiträge: 5234
Antw:CUL: No answer
« Antwort #14 am: 18 April 2021, 20:42:25 »
I still believe your problem is the definition of the relay card. Stop the program which controls the relay card and the CUL will work.
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