GlobalCache iTach Flex

I have installed the Globalcache - 2.2.0 binding and I can’t get my device to go online. I have confirmed the IP address of the dcevice and tried setting up both a manual thing and doing it though PaperUI. Both results show the device is “initializing” and it never goes online.

It will not auto discoverthe device either. The firmware on the iTach Flex is Firmware version: 710-2000-19. I received that by going to it’s web browser so I know it’s online and the correct IP address.

Am I missing something?
Thanks

The only thing I can think of is to check that the “Active Cable” configuration in the binding matches how you have the device configured.

Thanks for responding Mark, I confirmed I am doing that. I have changed both the binding and the Web Brower setting. I have tried it in both Serial and IR mode with no luck.

You could try putting the binding in debug mode. That might provide a clue.

I checked my flex. It’s running 710-3000-19. So, that’s one thing that’d different.

Mark, Do you have a flex wifi. I ran the update with the iHelp program and I still get 710-2000-19. I can’t find any documentation on this online either.

Here is what I am getting from the debug. I know the IP address is correct because I can access with web browser with it. Also this is a Wifi unit not a IP unit.

10:58:54.279 [DEBUG] [.GlobalCacheHandler$ConnectionManager] - Connecting to command port for thing itachFlex:000C8A76E888 at IP 10.10.10.184
10:58:55.782 [DEBUG] [.GlobalCacheHandler$ConnectionManager] - Failed to get socket on command port for thing itachFlex:000C8A76E888 at 10.10.10.184
10:58:55.784 [DEBUG] [.GlobalCacheHandler$ConnectionManager] - Connection check failed for thing itachFlex:000C8A76E888 at IP 10.10.10.184

Ah, no, I have a wired one.

So this is a pretty basic communication failure. The binding is saying it can’t open a socket to the device at 10.10.10.184.

There’s a 1.5 second timeout when trying to open the socket. Can you think of any reason why it might take longer than 1.5 seconds to make the connection?

Is it possible that there would be something (e.g. firewall) blocking a connection on port 4998? That might explain why you can connect with a browser on port 80, but the binding can’t connect to the device.

I can connect from my PC using port 4998 to 10.10.10.184 with the iTest program from GlobalCache just fine. Very strange, I’m ordering another Wifi unit, an IR blaster and another serial cable. I will see if I can get any of those working and let you know.

Yeah, this is really strange. Where is openHAB running? Is it on the same PC where you’re running iTest, or is it on another box?

Can you telnet to the flex from your openHAB box?

telnet 10.10.10.184 4998

I tested telnet and it worked fine. I used Putty to access my QNAP NAS and then used telnet. It all worked correctly, I can see the serial string and send commands with no problems.

You reference port 4998 in your messages, I have to use 4999 for this device.

4998 is the port used for sending commands. 4999 is the port used for sending/receiving serial messages.

When both the flex and the binding are configured for serial (i.e. Active Cable = Serial), both ports are opened by the binding.

I have my Active Cable set to Serial and my binding set to Serial. When I telnet in to port 4998 and I send a command PF to turn my receiver OFF I get an “ERR 001” When I telnet into 4999, I send the same command and it turns off with no problems.

That’s expected. ERR 001 is for an invalid command. Port 4998 accepts the commands defined in section 5 of the API spec here.

Correct. That’s because 4999 is for serial commands.

The real question here is why the binding can’t open a connection to port 4998 on the flex. If the binding can’t get a connection on port 4998, it won’t even try opening the connection to port 4999.

One additional thought… How many network interfaces are on the QNAP NAS? It’s possible that the binding is selecting a network interface from which the flex is not reachable.

Can you put the binding in debug mode, then stop/start the binding? At startup, the binding will log the network interface it’s going to use to communicate with the devices.

Here is what I am getting when I restart the binding. I did also test using the TCP binding and I can see some communication happening, again on port 4999 only.

2018-02-20 11:46:33.875 [DEBUG] [iscovery.GlobalCacheDiscoveryService] - Globalcache discovery service activated
2018-02-20 11:46:33.876 [DEBUG] [iscovery.GlobalCacheDiscoveryService] - Starting background discovery job in 10 seconds
2018-02-20 11:46:33.877 [DEBUG] [org.openhab.binding.globalcache     ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.discovery.ExtendedDiscoveryService}={component.name=org.openhab.binding.globalcache.internal.discovery.GlobalCacheDiscoveryService, component.id=242, service.id=392, service.bundleid=228, service.scope=bundle} - org.openhab.binding.globalcache
2018-02-20 11:46:33.881 [INFO ] [e.internal.GlobalCacheHandlerFactory] - GlobalCache binding v2.2.0
2018-02-20 11:46:33.883 [DEBUG] [org.openhab.binding.globalcache     ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.core.thing.binding.ThingHandlerFactory}={component.name=org.openhab.binding.globalcache.internal.GlobalCacheHandlerFactory, component.id=243, service.id=393, service.bundleid=228, service.scope=bundle} - org.openhab.binding.globalcache
2018-02-20 11:46:33.889 [DEBUG] [org.openhab.binding.globalcache     ] - BundleEvent STARTED - org.openhab.binding.globalcache
2018-02-20 11:46:33.912 [DEBUG] [.GlobalCacheHandler$CommandProcessor] - Processor for thing itachFlex:b979b5cc created request queue, depth=10
2018-02-20 11:46:33.917 [DEBUG] [obalcache.handler.GlobalCacheHandler] - Initializing thing itachFlex:b979b5cc
2018-02-20 11:46:33.917 [DEBUG] [obalcache.handler.GlobalCacheHandler] - Handler using address 10.0.3.1 on network interface lxcbr0
2018-02-20 11:46:35.919 [DEBUG] [.GlobalCacheHandler$CommandProcessor] - Command processor STARTING for thing itachFlex:b979b5cc at IP 10.10.10.184
2018-02-20 11:46:35.919 [DEBUG] [GlobalCacheHandler$ConnectionManager] - Connecting to command port for thing itachFlex:b979b5cc at IP 10.10.10.184
2018-02-20 11:46:37.420 [DEBUG] [GlobalCacheHandler$ConnectionManager] - Failed to get socket on command port for thing itachFlex:b979b5cc at 10.10.10.184
2018-02-20 11:46:37.420 [DEBUG] [GlobalCacheHandler$ConnectionManager] - Starting connection monitor job for thing itachFlex:b979b5cc at IP 10.10.10.184
2018-02-20 11:46:43.877 [DEBUG] [iscovery.GlobalCacheDiscoveryService] - Discovery job is running
2018-02-20 11:46:43.877 [DEBUG] [internal.discovery.MulticastListener] - Discovery job using address 10.0.3.1 on network interface lxcbr0
2018-02-20 11:46:43.878 [DEBUG] [internal.discovery.MulticastListener] - Multicast listener joined multicast group 239.255.250.250:9131

I am only running one network interface on my QNAP.

Thanks for all your help with this. I am sure learning a lot while we trouble shoot this problem, lol

It looks like it is trying to use a virtual switch for the DHCP server on the NAS that I can not disable.