FHEM Forum

FHEM => English Corner => Thema gestartet von: kennybl am 18 April 2021, 10:03:49

Titel: CUL: No answer
Beitrag von: kennybl 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!
Titel: Antw:CUL: No answer
Beitrag von: KölnSolar am 18 April 2021, 10:11:54
Zitatis above just norma
No. You should remove usb commands in Your FHEM-config.
Titel: Antw:CUL: No answer
Beitrag von: kennybl 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
Titel: Antw:CUL: No answer
Beitrag von: KölnSolar am 18 April 2021, 13:27:13
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 ?
Titel: Antw:CUL: No answer
Beitrag von: kennybl 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
Titel: Antw:CUL: No answer
Beitrag von: KölnSolar 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 ?
Titel: Antw:CUL: No answer
Beitrag von: Beta-User 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).
Titel: Antw:CUL: No answer
Beitrag von: kennybl 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
Titel: Antw:CUL: No answer
Beitrag von: Beta-User 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?
Titel: Antw:CUL: No answer
Beitrag von: kennybl 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
Titel: Antw:CUL: No answer
Beitrag von: KölnSolar am 18 April 2021, 18:19:11
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.
Titel: Antw:CUL: No answer
Beitrag von: kennybl 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
Titel: Antw:CUL: No answer
Beitrag von: Beta-User am 18 April 2021, 18:38:52
Should be OK. The Hub: is it USB3 compatilbe? If: try one not supporting USB3.
Titel: Antw:CUL: No answer
Beitrag von: kennybl am 18 April 2021, 19:20:38
It is this USB 2.0 Hub: https://nl.aliexpress.com/item/4000291584825.html?spm=a2g0s.9042311.0.0.27424c4d7k1bHd
Titel: Antw:CUL: No answer
Beitrag von: KölnSolar 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.
Titel: Antw:CUL: No answer
Beitrag von: juergs am 29 April 2021, 11:52:35
May be also an interference by switching relais?
Certainly there is no or rather minimalistic surge supression on the relay-card?

https://www.omron-ap.co.in/service_support/FAQ/FAQ02804/index.asp (https://www.omron-ap.co.in/service_support/FAQ/FAQ02804/index.asp)

Adding some Capacitance (100nF, 1..10 µF)  in the 3V3 or 5V line will probably help a lot ;-)

Some ideas: https://www.infineon.com/dgdl/Infineon-AN372-AN-v01_01-EN.pdf?fileId=5546d461464245d3014695667b266a49 (https://www.infineon.com/dgdl/Infineon-AN372-AN-v01_01-EN.pdf?fileId=5546d461464245d3014695667b266a49)