Hauptmenü

CUL: No answer

Begonnen von kennybl, 18 April 2021, 10:03:49

Vorheriges Thema - Nächstes Thema

kennybl

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!

KölnSolar

Zitatis 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

kennybl

#2
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

KölnSolar

Zitati should comment this part?
yes.
ZitatIt 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

kennybl

$ 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

KölnSolar

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

Beta-User

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-elitedesk@Debian 12, 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: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

kennybl

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

Beta-User

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-elitedesk@Debian 12, 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: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

kennybl

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

KölnSolar

ZitatI gave the relayboard a specific name (USB_RELAY, instead of USB0, USB1 etc) so i thought this would work
ZitatHow 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:
Zitatif it's done in all ends
That's the question.  ;)
Edit2:
ZitatI 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

kennybl

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

Beta-User

Should be OK. The Hub: is it USB3 compatilbe? If: try one not supporting USB3.
Server: HP-elitedesk@Debian 12, 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: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files


KölnSolar

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