Several service files for the same service type ?

Plugins & Plugin Development General Plugin Discussion
#1

Is it a problem with Vera to load several different services files (S_xxx.xml) for the same service type ?

Normally, it should not as each device then implements a service described in a service file.

#2

As I have mentioned in a few other threads. Using different service files with the same service type will cause conflicts. Vera will only use one of the files for that service and will cause many head aches. It’s not like the implementation file where each device can use a different implementation file. Same goes for Device file. You can not have different device files with the same device type.

  • Garrett
#3

Thank you for your answer.

That would be a major problem for me. I need a set of services (AVTransport and RenderingControl) for Sonos and another set of for DLNA (generic).

The service type is not defined in the S_xxx.xml file defining the service, but only in the device file that implements this service. If MCV is storing data per device and not per service, it should work ?

Do you directly experiment the problem or is it just an assumption ?

#4

This is from experience. It seems that when Vera loads the devices and it will either use the first or last (not sure the order) service type and file it finds. I ran into this issue helping a developer convert his Russound plugin to use the standard device types. His service typs for AVTransport, MediaNavigation, etc were interfering with my Squeezebox service types of the same type. I would get errors saying implementation not found, etc. See this thread for details:

http://forum.micasaverde.com/index.php/topic,16200.msg124257.html#msg124257

  • Garrett
#5

[quote=“garrettwp, post:4, topic:177565”]This is from experience. It seems that when Vera loads the devices and it will either use the first or last (not sure the order) service type and file it finds. I ran into this issue helping a developer convert his Russound plugin to use the standard device types. His service typs for AVTransport, MediaNavigation, etc were interfering with my Squeezebox service types of the same type. I would get errors saying implementation not found, etc. See this thread for details:

http://forum.micasaverde.com/index.php/topic,16200.msg124257.html#msg124257

  • Garrett[/quote]

Unfortunately I did not follow this discussion.

Ok, in this case, I see only one solution: each plugin must define its set of services (this point is I think obvious as each vendor can extend, use or not optional stuff, …) in specific XML files. And to avoid mismatch due to service type, each plugin must rename the standard type by a specific type, for example …:SonosAVTransport:1 for Sonos and …:DLNAAVTransport:1 for my new plugin. The only point to take care in the plugin is to use the “real” service type …:AVtransport:1 when communicating with the UPnP device.

So, for the Sonos plugin, I will have file S_SonosAVTransport.xml defining the service, and the Sonos device will implement service urn:schemas-upnp-org:service:SonosAVTransport:1 using file S_SonosAVTransport.xml.
Another plugin, for example DLNA plugin will have file S_DLNAAVTransport.xml defining the the service, and the device will implement service urn:schemas-upnp-org:service:DLNAAVTransport:1 using file S_DLNAAVTransport.xml.

Do you know if we have to rename the service id too ?

#6

I do not think this will work. Because when you call an action using the AVTransport service, it will give you a implementation error! Have you tried it?

  • Garrett
#7

[quote=“garrettwp, post:6, topic:177565”]I do not think this will work. Because when you call an action using the AVTransport service, it will give you a implementation error! Have you tried it?

  • Garrett[/quote]

My idea is to use SonosAVTransport service at Vera level. AVTransport will not really exist, except at a low level when the plugin invokes a UPnP action through a SOAP message.

#8

This would require that all third party apps now support the new custom service types. This would be an issue and I would rather maintain the use of the same service type for the same functionality. The only option is to have a single service file with all of the data for that service to be used by all plugins.

  • Garrett
#9

This is an option but it has limits because each vendor can adjust the service. While it is additional actions, it is not a problem. But as an example, a vendor could define that the volume range is 0-100 while another could define a range 0-1000. If we have only one file for each vendor, we are able to manage conflicts between vendor specifics.

But we can try to continue like that. I will first check whether the Sonos services (AVTransport and RenderingControl) are compatible with the DLNA standard. I think it should.

If we go in this direction, we have to rename the files S_Sonos.xml in something more generic,like S_.xml.