[quote=“LH, post:41, topic:175071”]Loaded up the Log Viewer. I think this is the section that may interest you:
07/13 6:24:09.235 ctrl_chr[31;1mLuaInterface::CallFunction_Startup-1 device 24 function initialize failed [string “–…”]:132: attempt to concatenate field ‘uuid’ (a nil value)ctrl_chr[0m <0x2c0f3680>[/quote]
Yes indeed, that’s just what I needed.
I’m submitting version 6 of the plugin to apps.mios.com. This version has extra paranoia about the uuid string, so it should bypass the crash on line 132.
Thanks for the log.
There will probably be a few more cycles of this as every new UPnP device that a user has on their LAN subtly breaks the plugin. It’s not a poorly-written spec, so I don’t know why so many devices implement it so poorly.
Installation is a bit tricky with the two plugins and many restarts are needed to finally get the child device(s) showing. I was bit confused with the wording “Add Dynamic” / “Add Static”. It’s simple enough - I must be a bit slow, as I was wondering what was being “added” to. Maybe “Use Dynamic/Static IP” may be an option. While installing at one stage the status of the “UPnP Event Proxy” was showing as blank. Could it be defaulted to some message that means “not installed” as opposed to “running/not running”. It’s just a confidence thing during installation process.
For readers with an Android phone - there is now a WeMo Android app (App version Beta v0.2). Apparently it’s only been tested on a Samsung Galaxy SIII https://play.google.com/store/apps/details?id=com.belkin.controller&hl=en
I loaded it on to an older Samsung Galaxy S with Android Firmware 2.3.3. Using that I was able to set up my WeMo switch but that was all I wanted to do, so I haven’t tested the app any further than that.
One slight problem on the display of the switch device in UI5 - the light bulb icon is always showing the “On” icon. Which is weird as this is the icon being used by my browser: http://Vera_IP/cmh/skins/default/icons/Binary_Light_100.png but D_WeMo1_Controllee1.json uses “Binary_Light_0.png” and “Binary_Light.png”, which are both available on my Vera 3 but are both “Off” icons.
All the code was installed using the plugins from the 25th of April - should I update any files to cover any other bugs found since?
When I click on the on/off buttons in UI5, sometimes I get a “Device not ready” but I think that’s some start up thing after a Luup restart. I’ll keep an eye on it.
EDIT: well the lamp on/off icons have come good and now work. This may be due to some override by one of the other light switches? Which are now in use as as night has come. Icons in use are now “Binary_Light_0.png” and “Binary_Light_100.png”
Yeah, I’m sorry that it takes so many restarts. Here’s what they are all for, if you are curious:
[ol][li]First to initialize the WeMo plugin after you install it from apps.mios.com.[/li]
[li]Second to populate the discovery results.[/li]
[li]Third to commit the discovery to create child devices.[/li]
[li]Fourth to initialize the UPnP event proxy plugin, which installs the daemon.[/li]
[li]Fifth to ensure that the UPnP event proxy daemon is running when the WeMo plugin starts.[/li][/ol]
I was bit confused with the wording "Add Dynamic" / "Add Static". It's simple enough - I must be a bit slow, as I was wondering what was being "added" to. Maybe "Use Dynamic/Static IP" may be an option.
How about “Add (DHCP)” vs “Add (Static IP)”? Is that any more informative? I need a short name to prevent word wrap hassles.
While installing at one stage the status of the "UPnP Event Proxy" was showing as blank. Could it be defaulted to some message that means "not installed" as opposed to "running/not running". It's just a confidence thing during installation process.
Yes, I think I can do this (but it will still not show anything until the first Luup restart, that’s how all plugins work; this is related to the following point that you make).
One slight problem on the display of the switch device in UI5 - the light bulb icon is always showing the "On" icon. Which is weird as this is the icon being used by my browser: http://Vera_IP/cmh/skins/default/icons/Binary_Light_100.png but D_WeMo1_Controllee1.json uses "Binary_Light_0.png" and "Binary_Light.png", which are both available on my Vera 3 but are both "Off" icons.
EDIT: well the lamp on/off icons have come good and now work. This may be due to some override by one of the other light switches? Which are now in use as as night has come. Icons in use are now “Binary_Light_0.png” and “Binary_Light_100.png”
This happens to me, sometimes, on other plugins. It normally happens when the plugin is newly-installed, and it goes away if I clear the browser cache or reload Luup (or both). As you’ve noticed, it comes good and it shouldn’t reappear for you now. I wish I knew what causes it.
When I click on the on/off buttons in UI5, sometimes I get a "Device not ready" but I think that's some start up thing after a Luup restart. I'll keep an eye on it.
Do, please. That could happen in the ten or so seconds after a Luup restart. It shouldn’t happen during normal operation.
Thanks for the very valuable feedback. There should be no reason for you to update to the newly-released version 6 unless you have discovery problems like LH reported.
Have encountered a slight problem. I have a scene that turns a WeMo switch on when the scene is started and the scene then turns it off after a 15 minute timeout. That is the WeMo switch is just on for 15 minutes.
Problem is that the WeMo switch never goes off, when the timer times out. I modified the scene so it also turned a z-wave GPO on and off as well. The z-wave GPO works as expected. So the scene runs OK but the WeMo switch does not go off. I can however turn it off in UI5 via the device setup on/off buttons.
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.
Have had a few WiFi complications when using the LimitLess LED box and the WeMo switch (firmware version WEMO_WW_2.00.1689.PVT) together.
My router has these three choices:
WPA TKIP
WPA2 CCMP
WPA+WPA2
LimitLess LED box has these choices - (we all ignore WEP as it’s insecure):
WEP 64
WEP 128
WPA_PSK TKIP
WPA_PSK CCMP <— does WPA using CCMP (AES) exist???
WPA2_PSK TKIP <— does WPA2 using TKIP exist???
WPA2_PSK CCMP
The LimitLess LED documentation says: “Special Note: your WIFI router must be using 2.4Ghz: WPA2-Personal, not WPA2/WPA-mixed.” The Belkin WeMo site states that Mixed/Mode does not work - refer to first note:
OK - so I select WPA2_PSK CCMP (same as: AES) for the LimitLess LED box and WPA2 CCMP at the router. It doesn’t work, nor does the WeMo.
Next: I select WPA_PSK TKIP for the LimitLess LED box and WPA TKIP at the router. The LimitLess box and the WeMo both work.
I then select the “does not work” WPA2/WPA-mixed on the router and WPA2_PSK TKIP on the LimitLess LED box and it and the WeMo both work.
Note that in all the tests the router reckons that both the devices have connected using WPA, not WPA2. That makes some sort of sense as I’m pretty sure WPA2_PSK TKIP doesn’t exist (If I’m wrong please say so) and it’s perhaps negotiated WPA_PSK TKIP instead. (edit When I say worked - I mean connected)
I would really like my router to be using WPA2_PSK CCMP - but neither the LimitLess LED or WeMO will connect to it, even though the documentation for both devices, says they both support it.
a-lurker, I recently replaced all of my Wi-Fi access points with Apple AirPort devices, which apparently don’t do TKIP any more at all in WPA2 Personal mode ? it’s AES only. That’s what I’m using. (Airport Express on WPA/WPA2 setting but s… - Apple Community)
In my house both the WeMo and LimitlessLED devices happily can be seen from my VeraLite.
Yeah - that’s it. Closer coupling to the WeMo relay may be the answer - dump that Z-Wave stuff ;–)) . Meanwhile I’m still worried that my electric kettle is going to get owned. It’s stuxnet burning down my house.
Futzle, do you know if the wemo devices can be recognized as the zwave devices, im using a plugging for xmbc, but it only recognizes zwaves. Is there a way we can make the wemos appear like zwaves. The Ui5 handles as they were zwaves. But some 3rd party app, does not. Any ideas?
It is up to the developer of the third party apps to support third party plugins. As long as the developer of the plugin uses the standard / common service id’s where needed (which futzle does), the support falls on the other developer. In this case the xbmc plugin developer.
I’m curious if anyone has been using the WeMo Motion sensor with this plugin to trigger scenes, and if so, how reliable that has been and how quickly the scenes are triggered. I have two different Z-wave motion sensors in the house and both aren’t always reliable and they don’t always immediately trigger scenes when motion occurs.
In my opinion there is currently a gap in the Z-wave market for a reliable and rapid triggering motion sensor and I’m wondering if the WeMo motion sensor with this plugin would effectively fill that gap.
Hi futzle,
Great plugin - Wemos are about half the price of a zwave controller in Australia. I bought half a dozen after seeing this plugin!
It’s probably by design, but I’ve noticed that if any one of the wemos doesn’t have power (at startup?), then none of them can be controlled. I get a “device not ready” popup if I try.
Plugging in the missing wemo (or turning on the upstream switch) doesn’t recover the error- I need to do a UI5 reload to get back on track.
Probably not a biggie, but I originally intended to chain a couple (stuff on while watching TV being a subset of stuff on when we are at home)
During development I tested this and it is essentially instant, on a good day.
You are still at the mercy of your Wi-Fi network: if the WeMo device can’t inform Vera of the state change because of Wi-Fi interference then the WeMo device won’t retry.
Also, the UPnP implementation in this plugin still has some gaps. UPnP requires renewal every so often and the plugin only retries a few times if it can’t renew, the result being that the WeMo device thinks Vera is no longer interested in getting updates. I’ve asked users to report back on how often this happens in reality but haven’t had a great deal of any feedback.
Restart the Luup engine and the plugin resubscribes, and it’s all good again, but that isn’t practical.
Yeah, the plugin assumes that an unreachable WeMo is an error condition. That’s more than a design decision; during startup is when the plugin discovers the IP addresses of each WeMo device and sends its UPnP subscription request to each WeMo device. This doesn’t happen again until you restart the Luup engine.
When a WeMo device starts up it doesn’t do any kind of broadcast, so the only way that Vera could become aware of its existence is to poll every so often. Polling is a good idea, and it may find its way into the plugin one day, but you’ll never get instant notification when a WeMo device joins the wireless network.
I’d advise against daisy-chaining WeMos, much as I’d advise against daisy-chaining Z-Wave power modules.
I’ve set up the wemos as static, thinking that discovery only happened during config (& that the existence of the individual wemo devices in was based on the config results).
I had one of the wemos become unresponsive today (first time in the month that I’ve had them) & needed to recycle the power to get it to rejoin the wireless network. Hopefully not a regular occurrence!
Still a shame that the failure of one brings down all, but I’ll keep them all plugged in and happy!
Technical stuff ahead: even if you add your WeMos as static, the TCP port number for the UPnP listener on each WeMo can change. The plugin has to do another, targeted, round of UPnP discovery when it starts up in case these port numbers are different. I’ve seen this happen on my network.
That said, I accept that the current behaviour of failing for all WeMos when only one falls over is a bug in the plugin.
