Can the WeMo physical button push commands to Openhab?

Setup, Configuration and Use Runtime
, ,
1

The WeMo outlet Switch and Insight both have on/off switches on them. Is there a way to know when they’ve been pressed? So if I manually turn off a switch, can that trigger a rule in Openhab?

2

If you manually turn off the switch the status is updated in openHAB… Could you not trigger something based off that? Although I suppose you will have an issue if you also turn the switch on and off from within openHAB…

What are you trying to achieve?

3

I’ve had an issue with the manual switch not notifying OH ever since I migrated to version 2. The 1.8 binding received updates triggered from my Insight switch, but the 2.0 binding does not. The switch does respond to commands sent from OH. Latest firmware on the switch. I need to run a debug log later to see if there is any indication of what’s going on.

4

Can you give me an example of how you were triggering it 1.8 (that isn’t working in 2.0)? I want to know that I’m doing that right to begin with. I feel like maybe my understanding of how devices push notifications to OpenHab is lacking.

5

This is a working 1.8 config:

Switch    SW_HW_Kitchen_Coffee    { wemo="Insight-1_0-XXXXXXXXXXXXXX" }

rule "Coffee Maker"
when
    Item SW_HW_Kitchen_Coffee changed
then
    if (SW_HW_Kitchen_Coffee.state == ON) {
        // ON logic
    } else {
        // OFF logic
    }
end
6

Yup, was just using the “changed” status as well. Wasn’t working in 2.0. Very odd. The bummer is that I couldn’t get the WeMo devices to work in 1.8, which is why I switched.

7

Wemo is also what caused me to switch. I believe that the 1.x binding uses its own upnp discovery implementation, which started conflicting with another service on my system.

You might see if you have anything else latching on to port 1900. In my case, the 1.8 binding didn’t play nice with Emby server, which seems to wrongly bind to 1900 even if dlna/upnp is disabled in its settings.

The upnp in the 2.0 binding at least discovers devices now, but I’m not sure why the manual updates aren’t making it to OH.

8

Hi,
could you please post some debug logs.
I just checked manual updates with my IDE and this is running fine here.

Best
Hans-Jörg

9

Debug log below with the latest binding snapshot. I looked over the code in WemoHandler, and I never see the log entry for GENA in onSubscription(). I guess it’s not making it past “service.isRegistered(this)”. That explains why the polling fallback isn’t working either, since it uses the same test.

2016-03-24 11:17:15.687 [INFO ] [smarthome.event.ThingAddedEvent     ] - Thing 'wemo:insight:Insight-1_0-221352K1200391' has been added.
2016-03-24 11:17:15.715 [INFO ] [rthome.event.ItemThingLinkAddedEvent] - Link 'wemo_insight_Insight_1_0_221352K1200391-wemo:insight:Insight-1_0-221352K1200391' has been added.
2016-03-24 11:17:17.407 [DEBUG] [org.eclipse.smarthome.binding.wemo  ] - BundleEvent STARTING - org.eclipse.smarthome.binding.wemo
2016-03-24 11:17:17.411 [DEBUG] [org.eclipse.smarthome.binding.wemo  ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.discovery.UpnpDiscoveryParticipant}={component.name=org.eclipse.smarthome.binding.wemo.discovery.WemoDiscoveryParticipant, component.id=190, service.id=316, service.bundleid=174, service.scope=bundle} - org.eclipse.smarthome.binding.wemo
2016-03-24 11:17:17.414 [DEBUG] [org.eclipse.smarthome.binding.wemo  ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.discovery.DiscoveryService}={component.name=org.eclipse.smarthome.binding.wemo.discovery.WemoDiscoveryService, component.id=191, service.id=317, service.bundleid=174, service.scope=bundle} - org.eclipse.smarthome.binding.wemo
2016-03-24 11:17:17.415 [DEBUG] [.wemo.discovery.WemoDiscoveryService] - Starting WeMo UPnP discovery...
2016-03-24 11:17:17.416 [DEBUG] [.wemo.discovery.WemoDiscoveryService] - Starting UPnP RootDevice search...
2016-03-24 11:17:17.417 [DEBUG] [org.eclipse.smarthome.binding.wemo  ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.core.thing.binding.ThingHandlerFactory}={component.name=org.eclipse.smarthome.binding.wemo.internal.WemoHandlerFactory, component.id=192, service.id=318, service.bundleid=174, service.scope=bundle} - org.eclipse.smarthome.binding.wemo
2016-03-24 11:17:17.420 [DEBUG] [ing.wemo.internal.WemoHandlerFactory] - Trying to create a handler for ThingType 'wemo:insight
2016-03-24 11:17:17.422 [DEBUG] [ing.wemo.internal.WemoHandlerFactory] - Creating a WemoHandler for thing 'wemo:insight:Insight-1_0-221352K1200391' with UDN 'Insight-1_0-221352K1200391'
2016-03-24 11:17:17.430 [DEBUG] [ome.binding.wemo.handler.WemoHandler] - Creating a WemoHandler for thing 'wemo:insight:Insight-1_0-221352K1200391'
2016-03-24 11:17:17.435 [DEBUG] [org.eclipse.smarthome.binding.wemo  ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.core.thing.binding.ThingHandler}={thing.type=wemo:insight, thing.id=wemo:insight:Insight-1_0-221352K1200391, service.id=319, service.bundleid=174, service.scope=singleton} - org.eclipse.smarthome.binding.wemo
2016-03-24 11:17:17.437 [DEBUG] [ome.binding.wemo.handler.WemoHandler] - Initializing WemoHandler for UDN 'Insight-1_0-221352K1200391'
2016-03-24 11:17:17.438 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'wemo:insight:Insight-1_0-221352K1200391' changed from UNINITIALIZED to INITIALIZING
2016-03-24 11:17:17.439 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'wemo:insight:Insight-1_0-221352K1200391' changed from INITIALIZING to ONLINE
2016-03-24 11:17:17.440 [DEBUG] [org.eclipse.smarthome.binding.wemo  ] - BundleEvent STARTED - org.eclipse.smarthome.binding.wemo
2016-03-24 11:17:17.697 [DEBUG] [o.discovery.WemoDiscoveryParticipant] - Discovered a WeMo Insight thing with UDN 'Insight-1_0-221352K1200391'
2016-03-24 11:17:17.698 [DEBUG] [o.discovery.WemoDiscoveryParticipant] - Created a DiscoveryResult for device 'Coffee' with UDN 'Insight-1_0-221352K1200391'
2016-03-24 11:17:18.403 [INFO ] [home.event.ItemChannelLinkAddedEvent] - Link 'SW_HW_Kitchen_Coffee-wemo:insight:Insight-1_0-221352K1200391:state' has been added.
10

That’s strange, cause in my IDE the GENA Subscription is set up straight after initializing the WemoHandler.

What JAVA version are you running ??

11

I’m currently running 1.8.0_74.

I just tried an experiment and built a jar of the binding to put in the addons folder instead of installing through paper ui. If I delete the binding from addons while OH is running and then add it back, I do see the GENA subscription in the log during initialization. It just doesn’t happen during regular OH startup. I tried many restarts, and the results are consistent.

Maybe it’s some kind of timing issue with the service registration and the binding initialization on some systems? This machine is an i5-4250 / 8GB on Win10.

12

Ok, so definitely some kind of timing thing. I added a 5 second sleep in initialize() before the call to onSubscription(). The GENA subscription works on startup every time with that in place. I can see the polling happening now as well. Obviously not an actual solution, but somewhere to start.

13

Thanks for looking into this.
As I am just fixing a bug in the WemoLightHandler, I will provide a fix for this as well.

14

Perfect, thanks for all of your work on the binding. I’m happy to help where I can.