[SOLVED] Wemo Not Found on Network

hmerk · March 3, 2016, 5:10pm

Hi,

I just checked the openHAB 1.8.1 release with included WeMo Binding and did not find any issues, so I will not need to provide a fix:

2016-03-03 18:05:56.985 [INFO ] [.o.core.internal.CoreActivator] - openHAB runtime has been started (v1.8.1).
2016-03-03 18:05:58.135 [INFO ] [o.o.i.s.i.DiscoveryServiceImpl] - mDNS service has been started
2016-03-03 18:05:58.268 [INFO ] [o.o.i.s.i.DiscoveryServiceImpl] - Service Discovery initialization completed.
2016-03-03 18:05:59.585 [INFO ] [penhab.io.rest.RESTApplication] - Started REST API at /rest
2016-03-03 18:06:07.712 [INFO ] [c.internal.ModelRepositoryImpl] - Loading model 'dashboard.sitemap’
2016-03-03 18:06:07.843 [INFO ] [c.internal.ModelRepositoryImpl] - Loading model 'energenie.sitemap’
2016-03-03 18:06:07.849 [INFO ] [c.internal.ModelRepositoryImpl] - Loading model 'home.sitemap’
2016-03-03 18:06:07.880 [INFO ] [c.internal.ModelRepositoryImpl] - Loading model 'smartwatch.sitemap’
2016-03-03 18:06:07.896 [INFO ] [c.internal.ModelRepositoryImpl] - Loading model 'cometVISU.items’
2016-03-03 18:06:07.909 [INFO ] [c.internal.ModelRepositoryImpl] - Loading model 'home.items’
2016-03-03 18:06:07.977 [INFO ] [c.internal.ModelRepositoryImpl] - Loading model 'system.items’
2016-03-03 18:06:09.001 [INFO ] [.o.u.w.i.servlet.WebAppServlet] - Started Classic UI at /classicui/openhab.app
2016-03-03 18:06:11.770 [INFO ] [.o.b.wemo.internal.WemoBinding] - Wemo Device with UDN ‘Socket-1_0-221438K0100073’ discovered
2016-03-03 18:06:11.775 [INFO ] [.o.b.wemo.internal.WemoBinding] - Wemo Device with UDN ‘Maker-1_0-221529S00001C9:sensor:switch’ discovered
2016-03-03 18:06:11.777 [INFO ] [.o.b.wemo.internal.WemoBinding] - Wemo Device with UDN ‘Bridge-1_0-231441B0100DE8’ discovered
2016-03-03 18:06:11.876 [INFO ] [.o.b.wemo.internal.WemoBinding] - Wemo Device with UDN ‘Insight-1_0-221443K1200202’ discovered

Discovery is working as expected, so there must be another issue if your WeMo’s are not shown.
What firmware versions are you using ???

Best
Hans-Jörg

russell · March 5, 2016, 6:35am

Current firmware is:

Should be the most recent.

The system fires up and I get as far as seeing the wemo addon initializing. But it never lists the devices.

hmerk · March 5, 2016, 9:38am

@russell
What OS and Java version are you runing?
I tried the latest Version under Windows and have it running 24/7 on Cubian with Oracle Java 1.8.x without any problem.

Best
Hans-Jörg

russell · March 5, 2016, 10:21pm

I’m running:
Mac OS version 10.9.5.
Java Version 8 Update 73 (build 1.8.0_73-b02)
javac version 1.8.0_73

And here’s a screenshot of the openhab runtime:

hmerk · March 5, 2016, 11:08pm

Could you please set loglevel for WeMo Binding to trace by appending
logger name=“org.openhab.binding.wemo” level="trace"
to logback_debug.xml and start openhab in debug mode.
You then should find the discovery request messages in the log and the received answers.
If there is no answer received (even from non WeMo devices) there could be an issue with some other programm/task blocking Port 1900, which causes the WeMo Binding to not work at all.

This issue is fixed with the latest Version of the openHAB2/ESH WeMo Binding.

russell · March 6, 2016, 3:32am

Here’s what’s going up:

19:18:46.061 [DEBUG] [.s.internal.SchedulerActivator:36   ] - Scheduler has been started.
19:18:46.159 [INFO ] [uartz.impl.StdSchedulerFactory:1175 ] - Using default implementation for ThreadExecutor
19:18:46.197 [INFO ] [rtz.core.SchedulerSignalerImpl:61   ] - Initialized Scheduler Signaller of type: class org.quartz.core.SchedulerSignalerImpl
19:18:46.197 [INFO ] [rg.quartz.core.QuartzScheduler:243  ] - Quartz Scheduler v.2.1.7 created.
19:18:46.199 [INFO ] [org.quartz.simpl.RAMJobStore  :154  ] - RAMJobStore initialized.
19:18:46.200 [INFO ] [rg.quartz.core.QuartzScheduler:268  ] - Scheduler meta-data: Quartz Scheduler (v2.1.7) 'openHAB-job-scheduler' with instanceId 'NON_CLUSTERED'
  Scheduler class: 'org.quartz.core.QuartzScheduler' - running locally.
  NOT STARTED.
  Currently in standby mode.
  Number of jobs executed: 0
  Using thread pool 'org.quartz.simpl.SimpleThreadPool' - with 2 threads.
  Using job-store 'org.quartz.simpl.RAMJobStore' - which does not support persistence. and is not clustered.

19:18:46.201 [INFO ] [uartz.impl.StdSchedulerFactory:1324 ] - Quartz scheduler 'openHAB-job-scheduler' initialized from specified file: './etc/quartz.properties'
19:18:46.201 [INFO ] [uartz.impl.StdSchedulerFactory:1328 ] - Quartz scheduler version: 2.1.7
19:18:46.201 [INFO ] [rg.quartz.core.QuartzScheduler:534  ] - Scheduler openHAB-job-scheduler_$_NON_CLUSTERED started.
19:18:46.205 [DEBUG] [o.config.core.ConfigDispatcher:146  ] - Processing openHAB default configuration file '/Users/Plex/Desktop/openhab-runtime/configurations/openhab_default.cfg'.
19:18:46.401 [DEBUG] [o.config.core.ConfigDispatcher:168  ] - Processing openHAB main configuration file '/Users/Plex/Desktop/openhab-runtime/configurations/openhab.cfg'.
19:18:46.514 [DEBUG] [.o.core.internal.CoreActivator:93   ] - UUID file already exists at '/Users/Plex/Desktop/openhab-runtime/webapps/static/uuid' with content '**REMOVED THIS JUST IN CASE**'
19:18:46.543 [DEBUG] [.o.core.internal.CoreActivator:115  ] - Created file '/Users/Plex/Desktop/openhab-runtime/webapps/static/version' with content '1.8.1'
19:18:46.544 [INFO ] [.o.core.internal.CoreActivator:61   ] - openHAB runtime has been started (v1.8.1).
19:18:46.670 [DEBUG] [a.internal.AutoUpdateActivator:31   ] - AutoUpdate binding has been started.
19:18:49.336 [DEBUG] [.p.i.PersistenceModelActivator:23   ] - Registered 'persistence' configuration parser
19:18:49.376 [DEBUG] [.c.t.i.TransformationActivator:38   ] - Transformation Service has been started.
19:18:49.501 [DEBUG] [m.internal.MultimediaActivator:34   ] - Multimedia I/O bundle has been started.
19:18:49.566 [DEBUG] [.s.i.DiscoveryServiceActivator:27   ] - Discovery service has been started.
19:18:49.574 [INFO ] [o.o.i.s.i.DiscoveryServiceImpl:93   ] - mDNS service has been started
19:18:49.641 [DEBUG] [.io.transport.mqtt.MqttService:123  ] - Starting MQTT Service...
19:18:49.703 [INFO ] [o.o.i.s.i.DiscoveryServiceImpl:53   ] - Service Discovery initialization completed.
19:18:49.802 [DEBUG] [.i.internal.ItemModelActivator:24   ] - Registered 'item' configuration parser
19:18:49.892 [DEBUG] [o.o.c.i.items.ItemRegistryImpl:137  ] - Item provider 'GenericItemProvider' has been added.
19:18:51.411 [DEBUG] [.o.m.s.i.SitemapModelActivator:23   ] - Registered 'sitemap' configuration parser
19:18:51.638 [DEBUG] [io.rest.internal.RESTActivator:33   ] - REST API has been started.
19:18:51.876 [INFO ] [org.atmosphere.util.IOUtils   :370  ] - META-INF/services/org.atmosphere.cpr.AtmosphereFramework not found in class loader
19:18:51.958 [INFO ] [sphere.cpr.AtmosphereFramework:2601 ] - Atmosphere is using org.atmosphere.cpr.DefaultAnnotationProcessor for processing annotation
19:18:51.959 [INFO ] [cpr.DefaultAnnotationProcessor:138  ] - AnnotationProcessor class org.atmosphere.cpr.DefaultAnnotationProcessor$BytecodeBasedAnnotationProcessor being used
19:18:51.973 [WARN ] [cpr.DefaultAnnotationProcessor:178  ] - Unable to detect annotations. Application may fail to deploy.
19:18:52.007 [INFO ] [sphere.cpr.AtmosphereFramework:1891 ] - Auto detecting atmosphere handlers /WEB-INF/classes/
19:18:52.042 [INFO ] [sphere.cpr.AtmosphereFramework:639  ] - Installed AtmosphereHandler org.atmosphere.handler.ReflectorServletProcessor mapped to context-path /* and Broadcaster Class org.atmosphere.jersey.JerseyBroadcaster
19:18:52.043 [INFO ] [sphere.cpr.AtmosphereFramework:1945 ] - Auto detecting WebSocketHandler in /WEB-INF/classes/
19:18:52.044 [INFO ] [sphere.cpr.AtmosphereFramework:1602 ] - Installed WebSocketProtocol org.atmosphere.websocket.protocol.SimpleHttpProtocol 
19:18:52.181 [INFO ] [.a.h.ReflectorServletProcessor:103  ] - Installing Servlet com.sun.jersey.spi.container.servlet.ServletContainer
19:18:52.542 [INFO ] [c.s.j.s.i.a.WebApplicationImpl:815  ] - Initiating Jersey application, version 'Jersey: 1.18.1 02/19/2014 03:28 AM'
19:18:52.544 [INFO ] [c.s.j.s.i.a.WebApplicationImpl:826  ] - Adding the following classes declared in META-INF/services/jersey-server-components to the resource configuration:
  class org.atmosphere.jersey.AtmosphereResourceConfigurator
19:18:52.712 [INFO ] [j.s.i.a.DeferredResourceConfig:101  ] - Instantiated the Application class org.openhab.io.rest.RESTApplication
19:18:54.328 [INFO ] [sphere.cpr.AtmosphereFramework:2435 ] - AtmosphereInterceptor CORS Interceptor Support will always be executed first
19:18:54.329 [INFO ] [sphere.cpr.AtmosphereFramework:2404 ] - Installed AtmosphereInterceptor CORS Interceptor Support with priority FIRST_BEFORE_DEFAULT 
19:18:54.330 [INFO ] [sphere.cpr.AtmosphereFramework:2404 ] - Installed AtmosphereInterceptor Default Response's Headers Interceptor with priority AFTER_DEFAULT 
19:18:54.332 [INFO ] [sphere.cpr.AtmosphereFramework:2404 ] - Installed AtmosphereInterceptor Android Interceptor Support with priority AFTER_DEFAULT 
19:18:54.333 [INFO ] [sphere.cpr.AtmosphereFramework:2404 ] - Installed AtmosphereInterceptor SSE Interceptor Support with priority AFTER_DEFAULT 
19:18:54.334 [INFO ] [sphere.cpr.AtmosphereFramework:2404 ] - Installed AtmosphereInterceptor JSONP Interceptor Support with priority AFTER_DEFAULT 
19:18:54.336 [INFO ] [sphere.cpr.AtmosphereFramework:2404 ] - Installed AtmosphereInterceptor Atmosphere JavaScript Protocol with priority AFTER_DEFAULT 
19:18:54.337 [INFO ] [sphere.cpr.AtmosphereFramework:2404 ] - Installed AtmosphereInterceptor Browser disconnection detection with priority AFTER_DEFAULT 
19:18:54.343 [INFO ] [sphere.cpr.AtmosphereFramework:935  ] - Using EndpointMapper class org.atmosphere.util.DefaultEndpointMapper
19:18:54.345 [WARN ] [sphere.cpr.AtmosphereFramework:941  ] - No BroadcasterCache configured. Broadcasted message between client reconnection will be LOST. It is recommended to configure the org.atmosphere.cache.UUIDBroadcasterCache
19:18:54.346 [INFO ] [sphere.cpr.AtmosphereFramework:949  ] - Default Broadcaster Class: org.atmosphere.jersey.JerseyBroadcaster
19:18:54.347 [INFO ] [sphere.cpr.AtmosphereFramework:950  ] - Broadcaster Polling Wait Time 100
19:18:54.348 [INFO ] [sphere.cpr.AtmosphereFramework:951  ] - Shared ExecutorService supported: true
19:18:54.354 [INFO ] [sphere.cpr.AtmosphereFramework:958  ] - Messaging Thread Pool Size: 10
19:18:54.355 [INFO ] [sphere.cpr.AtmosphereFramework:968  ] - Async I/O Thread Pool Size: 10
19:18:54.356 [INFO ] [sphere.cpr.AtmosphereFramework:979  ] - Using BroadcasterFactory: org.atmosphere.cpr.DefaultBroadcasterFactory
19:18:54.362 [INFO ] [sphere.cpr.AtmosphereFramework:980  ] - Using WebSocketProcessor: org.atmosphere.websocket.DefaultWebSocketProcessor
19:18:54.362 [INFO ] [sphere.cpr.AtmosphereFramework:990  ] - Invoke AtmosphereInterceptor on WebSocket message true
19:18:54.363 [INFO ] [sphere.cpr.AtmosphereFramework:991  ] - HttpSession supported: false
19:18:54.363 [INFO ] [sphere.cpr.AtmosphereFramework:993  ] - Atmosphere is using DefaultAtmosphereObjectFactory for dependency injection and object creation
19:18:54.364 [INFO ] [sphere.cpr.AtmosphereFramework:994  ] - Atmosphere is using async support: org.atmosphere.container.JettyAsyncSupportWithWebSocket running under container: jetty/8.1.3.v20120522 with WebSocket enabled.
19:18:54.366 [INFO ] [sphere.cpr.AtmosphereFramework:996  ] - Atmosphere Framework 2.2.5 started.
19:18:54.367 [INFO ] [sphere.cpr.AtmosphereFramework:998  ] - 

	For Atmosphere Framework Commercial Support, visit 
	http://www.async-io.org/ or send an email to support@async-io.org

19:18:54.368 [INFO ] [penhab.io.rest.RESTApplication:144  ] - Started REST API at /rest
19:18:54.370 [DEBUG] [o.o.i.s.i.DiscoveryServiceImpl:66   ] - Registering new service _openhab-server._tcp.local. at port 8080
19:18:57.223 [DEBUG] [o.o.i.s.i.DiscoveryServiceImpl:66   ] - Registering new service _openhab-server-ssl._tcp.local. at port 8443
19:18:58.743 [INFO ] [c.internal.ModelRepositoryImpl:80   ] - Loading model 'wemo.sitemap'
19:18:59.030 [INFO ] [c.internal.ModelRepositoryImpl:80   ] - Loading model 'wemo.items'
19:18:59.060 [DEBUG] [i.internal.GenericItemProvider:154  ] - Processing binding configs for items from model 'wemo.items'
19:18:59.062 [DEBUG] [i.internal.GenericItemProvider:133  ] - Read items from model 'wemo.items'
19:19:00.275 [INFO ] [.o.u.w.i.servlet.WebAppServlet:80   ] - Started Classic UI at /classicui/openhab.app
19:19:00.538 [DEBUG] [.r.internal.RuleModelActivator:42   ] - Registered 'rules' configuration parser
19:19:00.550 [DEBUG] [m.r.internal.engine.RuleEngine:77   ] - Started rule engine
19:19:03.480 [DEBUG] [.b.wemo.internal.WemoActivator:34   ] - Wemo binding has been started.
19:19:03.492 [DEBUG] [i.internal.GenericItemProvider:341  ] - Start processing binding configuration of Item 'Insight1 (Type=SwitchItem, State=Uninitialized)' with 'WemoGenericBindingProvider' reader.
19:19:03.493 [DEBUG] [w.i.WemoGenericBindingProvider:75   ] - Configuration for WeMo item 'Insight1':
19:19:03.494 [DEBUG] [w.i.WemoGenericBindingProvider:76   ] -         UDN = 'Insight'
19:19:03.494 [DEBUG] [w.i.WemoGenericBindingProvider:77   ] - channelType = 'state'
19:19:03.503 [DEBUG] [.o.b.wemo.internal.WemoBinding:301  ] - wemoDiscovery() is called!
19:19:03.504 [TRACE] [.o.b.wemo.internal.WemoBinding:327  ] - Request: M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"
MX: 5
ST: urn:Belkin:service:basicevent:1

The bottom section was just the switch I attempted to make in my .items, which wasn’t working.

hmerk · March 6, 2016, 12:04pm

What is happening after the request message ?
No answers received, not even from non WeMo devices ???

russell · March 7, 2016, 1:49am

Yeah, nothing. I’ve tested it with my Philips Hue lights (which are currently disabled, this was a fresh setup of Openhab, so the only thing was the Wemo jar). Hue lights work fine.

I just installed openhab2 and everything worked perfectly. Only thing that confuses me in Openhab 2.0 is, when you add a new device (I add the new device from the inbox), it doesn’t show up in my .items. Do I still need to add it manually. Or, when I add an item, I need to link the device from the Paper UI menu?

hmerk · March 7, 2016, 8:19am

Yes, either one is needed and works.
I still don’t understand why the WeMo Binding does not show discovery in your 1.8.x installation.

juched · April 21, 2016, 12:17am

This isn’t working for me as well. Windows 10 with Java 8u77 latest, running OpenHAB 1.8.2.

My Wemo switches are all on firmware WeMo_WW_2.00.100062.PVT-OWRT-LS.

I enabled the trace logging, and this is what I see every minute:
20:09:12.156 [DEBUG] [.o.b.wemo.internal.WemoBinding:118 ] - execute() method is called!
20:09:12.160 [DEBUG] [.o.b.wemo.internal.WemoBinding:123 ] - Wemo item ‘Light_KitchenSink’ state will be updated
20:09:12.165 [TRACE] [.o.b.wemo.internal.WemoBinding:429 ] - Calling WeMo item ‘Light_KitchenSink’ with configuration :
20:09:12.169 [TRACE] [.o.b.wemo.internal.WemoBinding:430 ] - UDN = 'Kitchen Sink Light’
20:09:12.173 [TRACE] [.o.b.wemo.internal.WemoBinding:431 ] - ChannelType = 'state’
20:09:12.176 [DEBUG] [.o.b.wemo.internal.WemoBinding:450 ] - No Location found for item ‘Light_KitchenSink’, start new discovery
20:09:12.182 [DEBUG] [.o.b.wemo.internal.WemoBinding:301 ] - wemoDiscovery() is called!
20:09:12.187 [TRACE] [.o.b.wemo.internal.WemoBinding:327 ] - Request: M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"
MX: 5
ST: urn:Belkin:service:basicevent:1

20:09:12.195 [TRACE] [.o.b.wemo.internal.WemoBinding:337 ] - Source-Address = 'JucheDesk/192.168.2.100:1901’
20:09:12.200 [TRACE] [.o.b.wemo.internal.WemoBinding:339 ] - Send multicast request.
20:09:12.203 [TRACE] [.o.b.wemo.internal.WemoBinding:342 ] - Multicast ends. Close connection.
20:09:12.211 [DEBUG] [.o.b.wemo.internal.WemoBinding:354 ] - Send datagram packet.
20:09:12.214 [DEBUG] [.o.b.wemo.internal.WemoBinding:359 ] - Receive SSDP Message.
20:09:12.490 [DEBUG] [.o.b.d.i.DSCAlarmActiveBinding:121 ] - DSC Alarm Execute
20:09:13.218 [DEBUG] [.o.b.wemo.internal.WemoBinding:383 ] - Message receive timed out.
20:09:13.223 [DEBUG] [.o.b.wemo.internal.WemoBinding:472 ] - New binary state ‘null’ for item ‘Light_KitchenSink’ received

Note that KitchenSink light is one I added manually with the wrong friendly name since I can’t figure it out.

I tried turning off the windows firewall, the SSDP service in windows and still no luck.

Thanks.

juched · April 21, 2016, 2:08am

Seems this is caused by Plex Media Server running. It opens a multicast listener on port 1901, which causes this discovery to fail. Stop Plex and it works.

Now, if only I know how to stop Plex from opening that port in the first place.

juched · April 21, 2016, 1:33pm

So, heard back from the plex forum, and you can disable this. If you are running plex server and cannot get your Wemo devices to discover, then disable this option and restart your plex server.

Settings>Server>Network “Enable local network discovery (GDM)”

mjitkop · June 6, 2016, 4:26am

Dave, thanks a lot for the tip about Plex!

I’m a newbie with openHAB and somehow I managed to install it on an old laptop that is running Ubuntu Server, and Plex Media Server (PMS) runs 24/7.

I was having trouble getting openHAB to discover my Wemo Insight switch. I did as you suggested and turned off the GDM option in my PMS and now it works. Even if PMS is started before openHAB, the Wemo device is discovered now!

Cool stuff.

shanekuz · July 4, 2016, 6:46am

Hi, i have one switch that also has the error mentioned above the other 6 in my hose work fine. One device in the logs have these two errors.

18:42:55.480 [DEBUG] [.o.b.wemo.internal.WemoBinding:472 ] - New binary state ‘null’ for item ‘GarageLights’ received
18:43:55.495 [DEBUG] [.o.b.wemo.internal.WemoBinding:118 ] - execute() method is called!
18:43:55.495 [DEBUG] [.o.b.wemo.internal.WemoBinding:123 ] - Wemo item ‘GarageLights’ state will be updated
18:43:55.495 [DEBUG] [.o.b.wemo.internal.WemoBinding:450 ] - No Location found for item ‘GarageLights’, start new discovery
18:43:55.495 [DEBUG] [.o.b.wemo.internal.WemoBinding:301 ] - wemoDiscovery() is called!

Its the same firmware as the other devices which all work fine,

Any ideas?

Thanks

Shane

Pal · September 23, 2016, 1:52am

Just FYI:

OpenHAB did not discover my WeMo.
Turned off Plex.
OpenHAB discovered my WeMo, and operations worked fine.
Restarted things. I don’t know if I restarted OpenHAB, Plex, the whole server or a combination of two or three of those - but some things was restarted.
WeMo did no longer work.
Turned off Plex.
WeMo started to work again.
Turned on Plex.
WeMo still works.

So a useful tip if WeMo doesn’t work - and not only during discovery - would be to temporarily turn Plex off.

bradleyshaw · October 12, 2016, 12:08pm

Hi all,

I’m having the same issue detecting WeMo devices on the network running openhab 1.8.3 on RaspberryPi. Without any wemo devices configured in .items or .sitemap I’ve enabled trace in debug mode as suggested and receive the following output which doesn’t find anything:

21:41:07.561 [DEBUG] [.b.wemo.internal.WemoActivator:34   ] - Wemo binding has been started.
21:41:08.020 [DEBUG] [.o.b.wemo.internal.WemoBinding:301  ] - wemoDiscovery() is called!
21:41:08.025 [TRACE] [.o.b.wemo.internal.WemoBinding:327  ] - Request: M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"
MX: 5
ST: urn:Belkin:service:basicevent:1


21:41:08.031 [TRACE] [.o.b.wemo.internal.WemoBinding:337  ] - Source-Address = 'raspberrypi/127.0.1.1:1901'
21:41:08.035 [TRACE] [.o.b.wemo.internal.WemoBinding:339  ] - Send multicast request.
21:41:08.038 [TRACE] [.o.b.wemo.internal.WemoBinding:342  ] - Multicast ends. Close connection.
21:41:08.042 [DEBUG] [.o.b.wemo.internal.WemoBinding:354  ] - Send datagram packet.
21:41:08.046 [DEBUG] [.o.b.wemo.internal.WemoBinding:359  ] - Receive SSDP Message.
21:41:09.051 [DEBUG] [.o.b.wemo.internal.WemoBinding:383  ] - Message receive timed out.
21:41:09.056 [INFO ] [.service.AbstractActiveService:169  ] - Wemo Refresh Service has been started
21:41:09.060 [DEBUG] [.o.b.wemo.internal.WemoBinding:118  ] - execute() method is called!

And that’s it.
Does the configuration of the IP:port look weird to anyone: “127.0.1.1:1901”?

When I do add a configuration into .items (using the ‘old’ style of configuration using the friendly name, rather than the UDN since I don’t know it) it searches for the configured device name but gets no response similar to juched’s post above.
I haven’t got Plex installed (removed the plex .jar file from addons and there’s nothing in openhab.cfg) and the logfile also has no mention of Plex, so I don’t think that’s the issue (but I’d be happy if it was!).

Any ideas?
To date everything else is working fine, but this has me stuck - perhaps I should take a look at 2.0?

Thanks!

hmerk · October 12, 2016, 12:16pm

If there is any other software listening on the used ports, you would get different errors. So in your case, I would assume that something is blocking UPnP traffic completely. Please check your router settings.
Furthermore, please report your WeMo devices firmware versions here.

bradleyshaw · October 12, 2016, 1:19pm

I upgraded to the latest wemo firmware, which is now 2.00.10626 as per the attached. I’ll check my router settings and let you know, thanks.

bradleyshaw · October 15, 2016, 2:12pm

It was my router settings; now I’ve sorted that out (I had a number of different wireless routers setup with WAN connections to the modem rather than as Access Points) I’m up and running.
Cheers for the assistance!

hmerk · October 15, 2016, 2:46pm

Glad you got it running👍