Hi,
I’ve been struggling with ideas for using the Vera to communicate with the great home automation application “Girder” over the network. The best solution I could come up with is to use a plug-in for Girder that someone was kind enough (and brilliant enough, I may add) to build. Using the UPnP plug-in, it is possible to use Girder as a control point for UPnP devices.
Unfortunately, Vera is broken and does not play well with UPnP. Searching for the devices which are supposed to be created by the Vera for each of its devices and scenes yields no results.
SOOOOOooo… I am wondering if anyone knows how we might use LUUP to send payloads directly to Girder over the network and vice-versa.
What I would like to have is the ability to query device states and receive notifications of changes over the network using LUUP code, until MCV finally fixes the UPnP bug sometime in the year 2019.
EDIT:
This looks incredibly complicated. I have too much of a life to dedicate as much time as would be needed for me to learn and implement the required code, etc. (assuming I would even have the brainpower to do so)
I guess as long as MCV keeps their head in the sand and ignores UPnP as strictly for AV and not important enough to fix since “no one cares about it”, we’re screwed.
I am working on an xbmc plugin. Can you explain the advantages of using upnp? If I got that right from googling, xbmc only supports few upnp functions like play/pause/stop/mute. It looks like there would be way more options when using something like http calls (http://wiki.xbmc.org/index.php?title=JSON-RPC_API/v4). I want to be able to send these commands via upnp, but even though I looked at your solutions, I did not manage to get that running up to now…
I also do think this is quiet complicated (I am not a professional programmer).
The advantage of UPnP would be simplicity (once the plug-in is developed) as well as the automatic compatibility with a large range of devices and applications.
For example, a plug-in is under development for Girder that would allow you to fire events using UPnP with virtually any other trigger, including using an Android device with a third-party application installed that has an interface that you design yourself –
Imagine the power of a custom-built interface on your tablet that you create that allows you to control any UPnP device in your home in whatever way you choose to without having to write lines of code for each and every command.
If the Vera’s UPnP capabilities were fixed, we would also be able to control our lights in the same manner.
Another example would be automatically turning on your TV and switching to your front-door camera when the doorbell rings if you are home, otherwise taking a picture and emailing it to you at work.
Yes, I agree, but that is the general advantage of upnp. But I am talking about the connection in between vera and xbmc. XBMC itself advertises itself as an upnp device, and if I get that right, the vera (if it would work) would provide options to control devices by upnp even if the actual functions in the implementation files do something else than sending upnp commands.
So why not use the protocol which provides the greatest functionality and most features? I googled quiet a while, and I am not sure, but it seems like I can send way more commands and get way more information by using json-rpc compared to upnp (at least for xbmc)…
While I agree that Micasaverde should fix the UPnP bug (especially since it looks like the fix is easily attainable, Vera just needs to automate the steps outlined by @Ap15e) in this case I think the answer for both @Quixote (for girder) and @chixxi (for XBMC) is a custom plugin.
I use XBMC regularly, so I wouldn’t mind helping out a bit. I actually have been thinking about looking at that, but I have a half dozen things I need to finish up in other plugins so I haven’t gotten around to it yet. The biggest issue I have with developing code on Vera is just the testing / debugging phase. As I’ve figured out more Lua and started to run some of the code on my personal computer first where I can easily catch and fix bugs it has gotten a lot better. This is just a long way of saying I recommend getting the Lua code controlling the XBMC from my computer before moving it to Vera.
@Quixote, I would think you would want to start on the Girder side. Vera is pretty easy to control over http. For instance:
Will set a dimmable lite with device number to level , so simple control (the type you would achieve with UPnP) is not that much harder to do right now. It is all explained right here: UI Simple. Basically you would want to take the part entitled lu_sdata: The polling loop in implement the pseudo-code in lua and have it run on girder, and then do the proper girder thing when something changes on Vera (I don’t know enough about girder to know what that is).
It does involve writing some code, but it isn’t too awful, and it only needs to be done once in a nice plugin and then it is usable by many people. I like the promise of UPnP too! But fundementally I care more about getting done the things I want to get done. If that involves writing a little bit of glue code then that is what I do! If the code is a little intimidating there are plenty of us here on the forums that are willing to help if you get stuck.
If I get that right, if you add a upnp device on the vera (and you worked arround the bug), you “only” get some commands that you can send with scenes. I want to have more, I want to read out states and create events for them, I want to have a control panel where I can also manually send commands, and so on. Something like the plugin I released for the PocornHour Mediaboxes. That is the reason why I want to create a xbmc specific plugin and not just use the vera upnp feature.
There are some phyton scripts for xbmc arround, I use something like these to set variables on the vera, this way vera really knows what xbmc is doing and you can then run scene by events.
But again, is there any advantage if the plugin uses upnp to control xbmc compared to json-rpc (http://wiki.xbmc.org/index.php?title=JSON-RPC_API/v4)? The only one I can see is that it will only work with the newest version of xbmc (eden), but compared to upnp I could control way more things…
My gripe is not about controlling UPnP devices from the Vera, it’s about controlling the devices registered on the Vera through UPnP. I want to be able to control my lights, etc. using another UPnP control point, as I thought was possible when I purchased the thing.
The method that radarengineer helpfully pointed out is a nice bandaid, but not all UPnP control points have the added functionality required for that (ie.- using code to work over http).
It would be nice if we could just have all of our devices automatically added to our UPnP network, but I guess I can try to work with http for now. Thanks for the links.
Quixote:
Not sure if that’s what you are referring too, but yesterday I was making some tests with Vera and the software Device Spy (uPnP control point). From Device Spy, I was able to succesfully invoke the services of my zwave devices registered on Vera, and also launch the scenes defined there via HTTP/XML (SOAP) messages from Device Spy to Vera. In particular I controlled a Zuewi Dimmer directly and also invoked a couple of scenes that involved that dimmer.
I’ve read better and now I see you want to control uPnP devices registered to Vera, not Z-Wave ones ! Sorry.
So is it true Vera uPnP feature is broken? I need to create an interface with an external uPnP device. So this means that it’s not possible at the moment with Vera? This is really worrying me.
[quote=“floyderman3d, post:11, topic:171026”]Quixote:
Not sure if that’s what you are referring too, but yesterday I was making some tests with Vera and the software Device Spy (uPnP control point). From Device Spy, I was able to succesfully invoke the services of my zwave devices registered on Vera, and also launch the scenes defined there via HTTP/XML (SOAP) messages from Device Spy to Vera. In particular I controlled a Zuewi Dimmer directly and also invoked a couple of scenes that involved that dimmer.
BTW, I use Vera2, UI5.
Is that the function you need?[/quote]
Hi floyderman3d,
You had it right the first time; I want to be able to control my Vera scenes and devices using a UPnP control point. None of the UPnP software I use will detect it, including Device Spy. However I’m using UI4. I’ve been reluctant to migrate over to UI5 in light of all of the complaints I’ve read here, but I may give it a shot if it means having the functionality that I’ve been waiting for for so long.
Thanks!
No problem, Quixote! Glad I could help. That scenario you describe I can assure you it works for me with my VERA2 IU5 and DeviceSpy! So good luck
Now I’m concerned regarding Vera controlling external uPnP devices :-/ I have to integrate a service robot with Vera for a project, and if what you say its true, it seems its gonna be more difficult than I thought !
Wow… that’s really bad news, but thanks a lot for the info.
In this situation, is there any chance to perform the integration of a upnp service robot with Vera, so that I can control some robot services (movement and other services) through uPnP commands, integrating it in scenes and so on with the rest of zwave devices of my network? Any idea or recommendation?
Since I’ve just been about a couple of weeks working with Vera, I still don’t have a full vision of what it can be done and how complex implementation could be, so any help is really appreciated.
The only workaround for [tt]luup.call_action[/tt] known so far is to use Luup [tt]http[/tt] calls to get the SOAP parameters across in the right order …
I actually don’t understand why MCV is not supporting such a great feature they promised to provide. IMHO it’s one of the core ideas that makes this product so powerful, if it came to work.
As for me, I’m starting my study of Lua / Luup, and Vera plugins.
This is really worrying me.