FHEM to OpenHab - 433CUL & 868MHz & Tradfri Issues

I decided to reboot the openhabianpi.

I noticed these entries in the log:

16:28:28.420 [DEBUG] [penhab.io.transport.cul.CULActivator] - CUL transport has been started.
...
16:28:28.495 [DEBUG] [io.transport.cul.internal.CULManager] - Registering class org.openhab.io.transport.cul.internal.serial.CULSerialHandlerImpl for device type serial
...
16:28:28.515 [DEBUG] [io.transport.cul.internal.CULManager] - Registering class org.openhab.io.transport.cul.internal.network.CULNetworkHandlerImpl for device type network
16:28:28.525 [DEBUG] [org.openhab.io.transport.cul        ] - BundleEvent STARTED - org.openhab.io.transport.cul
...
16:28:28.593 [WARN ] [io.transport.cul.CULLifecycleManager] - CUL config is NULL, doing nothing
16:28:28.606 [INFO ] [ternal.serial.CULSerialConfigFactory] - Update config, baudrate = 38400
16:28:28.623 [INFO ] [ternal.serial.CULSerialConfigFactory] - Update config, parity = NONE (0)
...
16:28:28.629 [DEBUG] [io.transport.cul.internal.CULManager] - Trying to open device serial:/dev/ttyUSB0 in mode MAX
16:28:28.633 [DEBUG] [io.transport.cul.internal.CULManager] - Searching class for device type serial
16:28:28.679 [DEBUG] [internal.serial.CULSerialHandlerImpl] - Opening serial CUL connection for /dev/ttyUSB0
16:28:28.755 [DEBUG] [org.openhab.binding.intertechno     ] - BundleEvent STARTING - org.openhab.binding.intertechno
16:28:28.764 [DEBUG] [hno.internal.CULIntertechnoActivator] - CULIntertechno binding has been started.
16:28:28.807 [DEBUG] [org.openhab.binding.intertechno     ] - ServiceEvent REGISTERED - {org.openhab.model.item.binding.BindingConfigReader, org.openhab.binding.intertechno.CULIntertechnoBindingProvider}={component.name=org.openhab.binding.intertechno.genericbindingprovider, component.id=190, service.id=309, service.bundleid=190, service.scope=bundle} - org.openhab.binding.intertechno
...
16:28:28.886 [DEBUG] [org.openhab.binding.intertechno     ] - ServiceEvent REGISTERED - {org.osgi.service.event.EventHandler, org.osgi.service.cm.ManagedService}={event.topics=openhab/command/*, service.pid=org.openhab.culintertechno, component.name=org.openhab.binding.intertechno.binding, component.id=189, service.id=311, service.bundleid=190, service.scope=bundle} - org.openhab.binding.intertechno
...
16:28:28.944 [DEBUG] [org.openhab.binding.intertechno     ] - BundleEvent STARTED - org.openhab.binding.intertechno
16:28:28.990 [DEBUG] [internal.serial.CULSerialHandlerImpl] - Adding serial port event listener
16:28:29.038 [DEBUG] [port.cul.internal.AbstractCULHandler] - Requesting credit report
16:28:29.053 [DEBUG] [port.cul.internal.AbstractCULHandler] - Requesting credit report
...
16:28:29.158 [DEBUG] [io.transport.cul.internal.CULManager] - Trying to open device serial:/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 in mode SLOW_RF
16:28:29.164 [DEBUG] [io.transport.cul.internal.CULManager] - Searching class for device type serial
16:28:29.168 [DEBUG] [internal.serial.CULSerialHandlerImpl] - Opening serial CUL connection for /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0
16:28:29.227 [WARN ] [io.transport.cul.CULLifecycleManager] - Can't open CUL

I will check the settings again.

/dev/ttyUSB0 or ttyUSB1 is dangerous reference since that is just up to boot luck.
I guess I configured Max!CUL binding to use the USB0 - I will thus use the by-id name instead.

By the way - are you using an 868 Stick for controlling Intertechno?
(I think that drastically shortens the life of the stick due to a temporary re-write).

I removed the Max related issue

16:40:17.077 [INFO ] [ternal.serial.CULSerialConfigFactory] - Update config, baudrate = 38400
16:40:17.084 [INFO ] [ternal.serial.CULSerialConfigFactory] - Update config, parity = NONE (0)
16:40:17.086 [DEBUG] [io.transport.cul.internal.CULManager] - Trying to open device serial:/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 in mode SLOW_RF
16:40:17.088 [DEBUG] [io.transport.cul.internal.CULManager] - Searching class for device type serial
16:40:17.091 [DEBUG] [internal.serial.CULSerialHandlerImpl] - Opening serial CUL connection for /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0
16:40:17.120 [WARN ] [io.transport.cul.CULLifecycleManager] - Can't open CUL
org.openhab.io.transport.cul.CULDeviceException: gnu.io.NoSuchPortException
	at org.openhab.io.transport.cul.internal.serial.CULSerialHandlerImpl.openHardware(CULSerialHandlerImpl.java:110)[186:org.openhab.io.transport.cul:1.10.0]
	at org.openhab.io.transport.cul.internal.AbstractCULHandler.open(AbstractCULHandler.java:133)[186:org.openhab.io.transport.cul:1.10.0]
	at org.openhab.io.transport.cul.internal.CULManager.createNewHandler(CULManager.java:149)[186:org.openhab.io.transport.cul:1.10.0]
	at org.openhab.io.transport.cul.internal.CULManager.getOpenCULHandler(CULManager.java:84)[186:org.openhab.io.transport.cul:1.10.0]
	at org.openhab.io.transport.cul.CULLifecycleManager.open(CULLifecycleManager.java:86)[186:org.openhab.io.transport.cul:1.10.0]
	at org.openhab.io.transport.cul.CULLifecycleManager.config(CULLifecycleManager.java:74)[186:org.openhab.io.transport.cul:1.10.0]
	at org.openhab.binding.intertechno.internal.CULIntertechnoBinding.updated(CULIntertechnoBinding.java:147)[190:org.openhab.binding.intertechno:1.10.0]

I think the remaining issue could be that openhab cannot access /dev/serial

How can I add the /dev/serial to the same group that loads openhab?

Thanks.

The log you posted looks good at the start, however the old ā€œcanā€™t open CULā€ is back. That went away by a change introduced to OpenHABian. When I had that I needed to start OH as root in order to use the CUL.
Are you using openHABian?
Or are you using already the second CUL on your system?

ā€¦and yes,I 'm using my 866 stick for intertechno .

Yes, I am using openHABian as provided in the ready made image.

So I am not sure what user is loading openHABian, but it loads as a service.

I also noticed, that both CULsticks have the same error, so it might be a root thing.
I cannot open screen without root.

Why not trying to connect one at a time?
On my installation Iā€™m using the stick defined at serial:/dev/ttyUSB0 .

Did you have to give it any special root or group management?

That is the point: No , nothing besides the .cfg and the items definition had to be done.!

I think I got it!

crw------- 1 root root 5, 3 Dec 20 16:37 ttyprintk
crw-rw---- 1 root dialout 188, 0 Dec 20 16:37 ttyUSB0
crw-rw---- 1 root dialout 188, 1 Dec 20 16:37 ttyUSB1

and
drwxr-xr-x 4 root root 80 Dec 20 16:37 serial

so the serial folders are not part of dialout or tty groupā€¦

now I will try to add /dev/serial to dialout, and if that fails, do as you said using USB0 or USB1.

1 Like

on my system

drwxr-xr-x 4 root root 80 Dez 19 10:35 serial
crw-rw---- 1 root dialout 166, 0 Dez 20 16:00 ttyACM0

however, the first is a directory, isnā€™t it?
And Iā€™m sorry, but my system is using the stick at ttyACM0, my memory plays tricks on me.

Will clean this up later but noticed that:

[17:07:51] openhabian@openHABianPi:/dev/serial/by-id$ ls -l
total 0
lrwxrwxrwx 1 root dialout 13 Dec 20 17:06 usb-FTDI_FT232R_USB_UART_001OKFXN-if00-port0 -> ā€¦/ā€¦/ttyUSB0
lrwxrwxrwx 1 root dialout 13 Dec 20 17:06 usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0 -> ā€¦/ā€¦/ttyUSB1

They were linked but NOT given to dialout group - I had to add it.

.and on my system in the same directory:
lrwxrwxrwx 1 root root 13 Dez 19 10:35 usb-busware.de_CUL868-if00 -> ā€¦/ā€¦/ttyACM0

So, the group of the linked ttyACM0 is used on my system.

No luck, that did not work.
I tried a reboot, and the access changed back to group ā€œrootā€.
So I changed the settings to /dev/ttyUSB1
no luckā€¦

try a reboot as a last resort.

oops realised i wrote ttyusb1 (lower case)

So time to try againā€¦ andā€¦ it might have worked
Weird! I am sure it is folder access issue related.

17:23:22.053 [INFO ] [ternal.serial.CULSerialConfigFactory] - Update config, baudrate = 38400
17:23:22.077 [INFO ] [ternal.serial.CULSerialConfigFactory] - Update config, parity = NONE (0)
17:23:22.079 [DEBUG] [io.transport.cul.internal.CULManager] - Trying to open device serial:/dev/ttyUSB1 in mode SLOW_RF
17:23:22.081 [DEBUG] [io.transport.cul.internal.CULManager] - Searching class for device type serial
17:23:22.083 [DEBUG] [internal.serial.CULSerialHandlerImpl] - Opening serial CUL connection for /dev/ttyUSB1
17:23:22.190 [DEBUG] [internal.serial.CULSerialHandlerImpl] - Adding serial port event listener
17:23:22.237 [INFO ] [smarthome.event.ThingUpdatedEvent   ] - Thing 'max:bridge:KEQ0817097' has been updated.
17:23:22.245 [DEBUG] [port.cul.internal.AbstractCULHandler] - Requesting credit report
17:23:22.275 [DEBUG] [port.cul.internal.AbstractCULHandler] - Requesting credit report
17:23:22.325 [DEBUG] [port.cul.internal.AbstractCULHandler] - Requesting credit report

definitely getting somewhere:

17:24:47.825 [DEBUG] [port.cul.internal.AbstractCULHandler] - Requesting credit report
17:24:47.867 [DEBUG] [port.cul.internal.AbstractCULHandler] - Received raw message from CUL: ? (`is01011011001000001011100010 0 0000010010 is unknown) Use one of A B C e F f G i K L l M N R T t U V W X x
17:24:47.874 [DEBUG] [port.cul.internal.AbstractCULHandler] - Requesting credit report
17:24:47.904 [DEBUG] [port.cul.internal.AbstractCULHandler] - Received raw message from CUL: 00 534
17:24:47.911 [DEBUG] [port.cul.internal.AbstractCULHandler] - credit10ms = 534
17:24:47.936 [DEBUG] [port.cul.internal.AbstractCULHandler] - Received raw message from CUL: 00 534
17:24:47.939 [DEBUG] [port.cul.internal.AbstractCULHandler] - credit10ms = 534
17:24:51.673 [INFO ] [smarthome.event.ItemCommandEvent ] - Item ā€˜Funkstecker1ā€™ received command OFF
17:24:51.686 [INFO ] [marthome.event.ItemStateChangedEvent] - Funkstecker1 changed from ON to OFF
17:24:51.695 [DEBUG] [port.cul.internal.AbstractCULHandler] - Requesting credit report
17:24:52.571 [DEBUG] [port.cul.internal.AbstractCULHandler] - Received raw message from CUL: is01011011001000001011100010F0F0000000010
17:24:52.576 [DEBUG] [port.cul.internal.AbstractCULHandler] - Requesting credit report
17:24:52.600 [DEBUG] [port.cul.internal.AbstractCULHandler] - Received raw message from CUL: 00 538
17:24:52.602 [DEBUG] [port.cul.internal.AbstractCULHandler] - credit10ms = 538
17:24:52.625 [DEBUG] [port.cul.internal.AbstractCULHandler] - Received raw message from CUL: 00 539
17:24:52.627 [DEBUG] [port.cul.internal.AbstractCULHandler] - credit10ms = 539

Great news!

I have old steckdose (not real intertechno). I could switch one of those on and off!

Now to making my real intertechno to work.

Thanks a lot, I feel we made major progress!

Do you know hot to declare a real intertechno (not raw mode)?

I guessed it would work with your older pluggs (mine is >25 years old!).

Looking at the log you see what the binding sends to the stick:

is01011011001000001011100010F0F0000000010

The is for interechno-mode send
up to the first F it is your address, however each blank is replaced by an F, and at the end the OFF command is added.
If you would know the exact command needed to be sent directly (for example by screen) we could make that up for the binding.

So, my new intertechno (the one with the 26bit address and self-learning) worked on FHEM and it could switch on and off.

but my older wall-sockets, didnā€™t work well with fhem. It seems that the on and off command is at the first bit rather than the final.

No, but thee is an updated binding which is made for V3 of the messages (the new intertechno ones). Look in here

Could you help me install it?
Thanks.