I’m curious if anyone is having issues with WeMo devices, and the reliability of controlling those devices. I’m having very frequent issues, and it’s getting annoying.
I get a constant onslaugt of these, sometimes it’s for one or two devices, other times it’s for all of them (15 devices):
2017-12-12 18:33:52.603 [ERROR] [ome.binding.wemo.handler.WemoHandler] - Failed to get actual state for device 'wemo:lightswitch:GreatRoomFanMotor': Could not call WeMo
Those are innocuous in terms of my openHAB control features, but these are problematic:
2017-12-12 16:45:00.110 [ERROR] [ome.binding.wemo.handler.WemoHandler] - Failed to send command 'ON' for device 'wemo:socket:FrontWindowLedgeOutlet': Could not call WeMo
My WiFi access points are logging no errors and are stable. I also have had no errors controlling things with the WeMo app from my phone. If I reboot openHAB (running openHABian 2), it seems to be OK for a day or two, then goes downhill.
Has anyone else seen similar behaviors? Even if I’m hitting a wall with the Raspberry Pi 3, that’s fine…I’ll go build an Intel NUC, but I’d like to know it will solve the problem.
Hi Brian,
you are not alone seeing this stragen behaviour with WeMo devices, and unfortunately, there is nothing we can do about it.
Even if you face no errors with the WeMo app on your phone, you are on the lucky side, as I also see unresponsive devices there.
To explain the two errors you reported :
Due to the bad UPnP implementation in WeMo firmware, my binding sends SOAP messages to the devices, either to retreive their current state or to send controll information (ON/OFF).
WeMo devices should respond to theses messages, but sometimes they don’t, that’s when you see those errors logged.
Moving openHAB to a Intel NUC will definitely not solve your issues, my installation is running on a NUC.
I’m just starting to dig into WeMo programming, so this may be a stupid question, but can you avoid uPnP and target an individual switch by IP?
I’ve got a sizeable investment in WeMo, and the problem appears to get worse the more I get. I’d hate to have to sell them all off and switch to something else like ZWave due to time and cost.
Interesting discovery. After my last reboot, I changed my rules to have a thread sleep of 1 second between WeMo commanda. It’s been two days, and no issues of not being able to control a device. Usually I’d have several fails by now.
Hi,
same problem here. I don’t use original Wemo devices, but Tasmota-flashed switches with Wemo compatibility. After some days, they don’t react to openHAB (UI and rules) anymore. Alexa is still able to switch them (directly, not via openHAB). Any suggestions?
I see. Your issue is that the devices don’t register completely at UPnP, that’s why the GENA events are not registered. This seems to be a general UPnP issue within your network.
I just readded another WeMo Insight Switch, using openHAB 2.4M6 and ist is working flawless.
My new Mini Socket Switch (first one i have, my other wemo devices are all the older kind).
During bundle restart I see this:
11:47:54.768 [DEBUG] [org.eclipse.smarthome.binding.wemo ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.discovery.upnp.UpnpDiscoveryParticipant}={service.id=365
, service.bundleid=196, service.scope=bundle, component.name=org.eclipse.smarthome.binding.wemo.internal.discovery.WemoDiscoveryParticipant, component.id=241} - org.eclipse.sm
arthome.binding.wemo
11:47:54.780 [DEBUG] [org.eclipse.smarthome.binding.wemo ] - BundleEvent STARTED - org.eclipse.smarthome.binding.wemo
11:47:54.788 [DEBUG] [ding.wemo.internal.WemoHandlerFactory] - Trying to create a handler for ThingType 'wemo:socket
11:47:54.797 [DEBUG] [ding.wemo.internal.WemoHandlerFactory] - Creating a WemoHandler for thing 'wemo:socket:Socket-1_0-221834K010A8D9' with UDN 'Socket-1_0-221834K010A8D9'
11:47:54.805 [DEBUG] [home.binding.wemo.handler.WemoHandler] - Creating a WemoHandler for thing 'wemo:socket:Socket-1_0-221834K010A8D9'
11:47:54.833 [DEBUG] [home.binding.wemo.handler.WemoHandler] - Initializing WemoHandler for UDN 'Socket-1_0-221834K010A8D9'
11:47:54.841 [DEBUG] [home.binding.wemo.handler.WemoHandler] - Setting up WeMo GENA subscription for 'org.eclipse.smarthome.binding.wemo.handler.WemoHandler@c14ece' FAILED - s
ervice.isRegistered(this) is FALSE
11:47:54.849 [DEBUG] [home.binding.wemo.handler.WemoHandler] - WeMo UPnP device Socket-1_0-221834K010A8D9 not yet registered
11:47:54.855 [DEBUG] [home.binding.wemo.handler.WemoHandler] - Setting up WeMo GENA subscription for 'org.eclipse.smarthome.binding.wemo.handler.WemoHandler@c14ece' FAILED - s
ervice.isRegistered(this) is FALSE
11:47:54.853 [DEBUG] [ding.wemo.internal.WemoHandlerFactory] - Trying to create a handler for ThingType 'wemo:socket
11:47:54.867 [TRACE] [home.binding.wemo.handler.WemoHandler] - Command 'REFRESH' received for channel 'wemo:socket:Socket-1_0-221834K010A8D9:state'
I also have older LightSwitches and they tend to go offline regularly with this error:
11:59:08.537 [TRACE] [home.binding.wemo.handler.WemoHandler] - Command 'ON' received for channel 'wemo:lightswitch:Lightswitch-1_0-221333K130014B:state'
11:59:08.557 [DEBUG] [nding.wemo.internal.http.WemoHttpCall] - Could not make HTTP call to WeMo
11:59:11.607 [TRACE] [home.binding.wemo.handler.WemoHandler] - Command 'OFF' received for channel 'wemo:lightswitch:Lightswitch-1_0-221333K130014B:state'
11:59:11.634 [DEBUG] [nding.wemo.internal.http.WemoHttpCall] - Could not make HTTP call to WeMo
I have uPNP disabled on my router, since I do not want anyone automatically opening ports to the outside world. Is this needed to be enabled to get this reliable?
Do we need to have static IPs to help with reliability?
There are no big changes in the WeMo Binding, so you could stay with openHAB 2.3.
And Yes, you need UPnP to be enabled, as the Binding uses the GENA event system. No static IPs needed.
The issue you reported with devices can not be called might be related to an ugly behaviour they show. From time to time the WeMos seem to change their responding port without sending a notify. I try to find a solution by triggering a new discocery when this occurs. Just need to find time to implement it.
Could you explain why I need to enable uPnP on my router? This is used for applications/devices to request port forwarding automatically, and I fail to see why this is needed for my raspberry pi and my wemo devices which are all on my same internal network.
Perhaps there is something else that my router will do when uPNP is enabled? Like re-broadcast?
of my 9 lights, currently 7 are working, without uPNP working. I will “reboot” my one light switch and that should fix it again for a while. My new mini-plug is the one with the odd FAILED messages above. Not sure what is going on with that one.
I don‘t know your router, so I cannot really comment on this.
Some routers block UPnP specific packets if you sisable it, even it is just meant to control your router.
What firmware versions are your WeMo devices running?
Hmm, I can see that the Miniplug uses a different firmware version than the other devices. So it might be that those act different than the other WeMo devices. Unfortunately, Miniplugs are not available in Germany, so I cannot test and debug.
