[s]You’ve got a new UPnP device at 192.168.2.51 which is producing a nonstandard response to UPnP discovery. It’s crashing the WeMo plugin.
What is 192.168.2.51? If you remove it from your network and reload the Vera Luup engine does the problem go away?
Writing a robust UPnP controller is hard. There are so many nonconforming devices out there that hardening it against unexpected responses is difficult. You seem to have found another one.[/s]
Edit … waittasec, that’s Vera itself, isn’t it? No, there’s a different problem.
50 10/23/13 16:56:22.732 luup_log:29: Starting WeMo plugin (device 29) __LEAK__ this:290816 start:1576960 to 0xacc000 <0x2b605680>
50 10/23/13 16:56:22.732 luup_log:29: Creating up to 4 children <0x2b605680>
50 10/23/13 16:56:22.732 luup_log:29: Creating child 192.168.2.49 (Front Door) as urn:Belkin:device:lightswitch:1 <0x2b605680>
50 10/23/13 16:56:22.733 luup_log:29: Creating child 192.168.2.45 (Plug) as urn:Belkin:device:controllee:1 __LEAK__ this:4096 start:1581056 to 0xacd000 <0x2b605680>
50 10/23/13 16:56:22.734 luup_log:29: Creating child 192.168.2.2 (Motion) as urn:Belkin:device:sensor:1 <0x2b605680>
50 10/23/13 16:56:22.734 luup_log:29: Roll call of child devices <0x2b605680>
50 10/23/13 16:56:22.735 luup_log:29: MiOS child device 30 has unique id 192.168.2.49 <0x2b605680>
50 10/23/13 16:56:22.735 luup_log:29: MiOS child device 31 has unique id 192.168.2.45 <0x2b605680>
50 10/23/13 16:56:22.735 luup_log:29: MiOS child device 32 has unique id 192.168.2.2 <0x2b605680>
50 10/23/13 16:56:22.736 luup_log:29: Reconnecting to device at fixed address 192.168.2.2 <0x2b605680>
50 10/23/13 16:56:22.736 luup_log:29: M-SEARCH sent to 192.168.2.2:1900 <0x2b605680>
50 10/23/13 16:56:27.739 luup_log:29: No response from 192.168.2.2 __LEAK__ this:4096 start:1630208 to 0xad9000 <0x2b605680>
Your motion was registered at 192.168.2.2 but it’s not there any more.
Yesterday I picked up a WeMo appliance switch and installed this plug-in to integrate it into my Vera system. My goal was to use the WeMo as a trigger to set off a scene in Vera. Specifically I set up a IFTT recipe to turn on the WeMo switch when I took my Jawbone UP24 out of sleep mode. I then set up Vera so that when the WeMo turned on it triggered a scene to turn on my lights in the morning. The scene seemed to work last night when I tested it, but I tested it by turning on the WeMo switch from within the MiOS interface. This morning when the switch was turned on via IFTT it didn’t trigger the switch. I even waited about 10 minutes before giving up and turning the lights on myself. Anyone have any suggestions as to where to begin troubleshooting? the MiOS interface is still showing my WeMo switch and I can still turn it on and off from there so that doesn’t seem to be the issue. Other than that I’m not sure.
After doing some further testing it seems that while the plugin can control the switch it doesn’t actively monitor the status of the switch. What I mean is that I can turn the switch on and off from the MiOS interface but if I turn it on/off from the iPhone app MiOS doesn’t update the switch’s status. Am I right in this assumption? If so then trying to use the switch as a trigger wouldn’t work.
Hoping someone can help me… I am using a Vera lite running UI5
I get the following problems;
Belkin WeMo[13] : Startup Lua Failed
Also when I open the WEMO config page, I get an error that the UPNP Proxy is not running - in the attached screenshot, it shows the UPnP Event Proxy is running. ??? Confused?
I think because the WEMO plugin config states the UPNP proxy is not running, the Enable scan for WeMo devices on LAN doesn’t return any results…
If I do a UPnp scan via the UPnP module(not the WEMO plugin), It finds the WEMO - but doesn’t recognise it.
[quote=“thesleepydog, post:88, topic:175071”]I get the following problems;
Belkin WeMo[13] : Startup Lua Failed
Also when I open the WEMO config page, I get an error that the UPNP Proxy is not running - in the attached screenshot, it shows the UPnP Event Proxy is running. ??? Confused?[/quote]
Invariably this happens because there’s some other UPnP device on your LAN that is confusing the plugin during discovery. UPnP implementations are all nonconforming in their own special ways, so to figure this out I’ll need to get you to catch a Luup log while you press the RELOAD button on the web UI. Once I’ve got an idea of how that other device is producing unexpected output then I can work on hardening the WeMo plugin against it.
If the plugin hasn’t successfully finished loading then it won’t update the status of the UPnP proxy plugin on the Configure page, so that’s a red herring. It’s unlikely that the UPnP proxy is even being invoked yet, so just forget about that aspect for the moment.
Any solution for the Belkin WeMo[13] : Startup Lua Failed ?
I get that message randomly and have to reload a couple times before it works again or a reboot (which always works)
Wemo devices are set to static and scan for devices is uncheck.
Futzle, Have you found a workaround for the Wemo device not switching off after being triggered in a scene with delay ?
It doesn’t work for disarming the belkin motion sensor and wall plug. Also i tried with Sonos and its the same issue.
Fascinating. I admit I didn’t believe you when I read this, so I tried to reproduce it with a scene-with-delays: On at “immediate”, and Off at “10 seconds”. Yes, I can reproduce it.
The funny thing is that there is no indication in the Luup log that the 10-second command even tried to run; the plugn is never invoked a second time. It’s as if something about the Immediate command prevents Vera’s timer from acting again on the same device until it gets some form of secret clearance from the device. (Z-Wave devices just don’t behave the same as plugin devices when it comes to scenes, so the fact that you can get the expected behaviour with the Z-Wave switch doesn’t really help.)
This is going to be hard to debug, if indeed the bug is in the WeMo plugin at all. It may be that you’ve uncovered an undocumented feature of scenes-with-delays. If I were in your position, I’d start looking for workarounds, such as one of the many timer plugins. Finding the edges of the undesired behaviour may in itself identify what’s going on.
Edit: Huh. If I uninstall the UPnP Event proxy then all is good. I’ve got some ideas. But keep experimenting with workarounds.
[quote=“ronniech, post:90, topic:175071”]Any solution for the Belkin WeMo[13] : Startup Lua Failed ?
I get that message randomly and have to reload a couple times before it works again or a reboot (which always works)[/quote]
Without a Luup log, I can’t help you. “Startup failed” is the catchall for anything unexpected that happens during startup, so by definition, if you’re getting that error message, my code isn’t expecting it. I realize that you can only catch this after it’s happened, at which point the log may have already been overwritten. But I’ve got to have that log.
Recall that I don’t actually use this plugin myself any more. My WeMo devices are all in storage. My invitation for someone to take over this plugin is still open.
Have you found a workaround for the Wemo device not switching off after being triggered in a scene with delay ?
No, the workaround is to not use delays. Use the Countdown Timer or use PLEG for your delays. (Delays in scenes are broken by design, in any case.)
Most probably, if you’re seeing it with the Sonos plugin too, it’s the UPnP event proxy at fault. But I haven’t looked into it and I’d be lying if I said I plan to soon.
futzle any chance you could walk me through creating a log for the WeMo plugin? I’m suffering the same startup failure error and would love to get some help. Thanks!
You’re going to have to drive this; I don’t use this plugin and I don’t maintain it except for critical bugfixes. You’ll have to capture a Luup log. You can do that a number of ways. The old school way is to get SSH access to your Vera and tail the /var/log/cmh/LuaUPnP.log file. Kids these days are raving about the Info Viewer plugin which has a snazzy log viewer built into it.
Alrighty. Thanks for the reply. Unfortunately, I think it may have been a firmware update to the WeMo that broke this for me… really unsure of how to tell, though. Here’s to hoping someone picks this project up from you.
