GlobalCache iTach Flex

Yeah, this is the key line. It’s trying to open the socket on 10.0.3.*

Your device is on 10.10.10.*

I need to think about this a bit.

@dsanow92 I thought we tried this, but I don’t see it in this thread. Maybe it was on something else.

In Paper UI, did you set the system’s Primary Address configuration parameter? It’s under Configuration->System->Network Settings. If not, could you try setting it? It should give you a drop down with 1 or more choices. If there are multiple choices, select the one that matches the 10.10.10.* network.

Sorry for putting you through all this trouble. :sweat:

BINGO!!! That did it. Thank you for your help and patience! Just so you know, other bindings with the auto discovery have not had the same problem. Doesn’t matter now though!
Thanks Again!

Glad we got it sorted out. I should’ve thought of this sooner. :man_facepalming:

Could you let me know the other bindings? I’m curious to know if there are any that don’t use uPnP as the discovery method.

Could you let me know the other bindings? I’m curious to know if there are any that don’t use uPnP as the discovery method.

Check into the Pioneer AVR, that’s the only other one I use that may not be using uPnP

That one uses uPnP, too.


Mark, I’m seeing the following error in my log (about every second). I’m on the latest snapshot #1332. Is this a newly induced globalcache issue?

2018-08-18 14:16:16.950 [ERROR] [nternal.DiscoveryServiceRegistryImpl] - Cannot notify the DiscoveryListener org.eclipse.smarthome.config.discovery.internal.PersistentInbox on Thing discovered event!

java.lang.ClassCastException: org.eclipse.smarthome.config.discovery.internal.DiscoveryResultImpl cannot be cast to org.eclipse.smarthome.config.discovery.DiscoveryResult

	at org.eclipse.smarthome.config.discovery.internal.PersistentInbox.get( ~[?:?]

	at org.eclipse.smarthome.config.discovery.internal.PersistentInbox.add( ~[?:?]

	at org.eclipse.smarthome.config.discovery.internal.PersistentInbox.thingDiscovered( ~[?:?]

	at org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl$ ~[?:?]

	at org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl$ ~[?:?]

	at Method) ~[?:?]

	at org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl.thingDiscovered( ~[?:?]

	at org.eclipse.smarthome.config.discovery.AbstractDiscoveryService.thingDiscovered( ~[?:?]

	at ~[?:?]

	at java.util.concurrent.Executors$ [?:?]

	at [?:?]

	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201( [?:?]

	at java.util.concurrent.ScheduledThreadPoolExecutor$ [?:?]

	at java.util.concurrent.ThreadPoolExecutor.runWorker( [?:?]

	at java.util.concurrent.ThreadPoolExecutor$ [?:?]

	at [?:?]

Nothing in the binding has changed in a very long time. I’m wondering if this is caused by a recent change to the framework.

You might be able to make it stop complaining by disabling discovery.

In conf/services/runtime.cfg, add these lines

# Enable/disable globalcache background discovery job

Let me know if that makes it stop.

Hmm. I just updated my test system to 1332 and I’m not seeing that error.

Interesting, turning off globalcache discovery fixed my logs. I’m not sure what else I might have done to induce the error. I honestly haven’t been watching my logs much, lately. I just noticed this error troubleshooting my weather underground data no longer populating.

That’s what I thought would happen. It didn’t fix the underlying issue. If you ever re-enable discovery (by setting the parameter value to true), it’ll start logging those errors again.

This looks similar…

Did you try restarting OH?

Or stopping OH, clearing tmp and cache, and restarting?

Yes, I had cleared the cache and tmp folder and a restart before posting the issue.

Hmm. I’m not sure what to suggest. The error you got is exactly the same as the one reported in the issue I referenced (except it’s a different binding). At least disabling discovery has silenced the errors to the log file.

Thanks Mark, I’m not too worried about it. I appreciate your support. This binding has been pivotal for my system since I have numerous iTach Flex’s controlling my media devices.