Events & Actions interface - is it required to advertise org.allseen.Introspectable?

asked 2014-10-21 07:57:44 -0700

anszom gravatar image

I'm trying to implement an application using the Events & Actions interface. I have some "virtual" appliances running, based on software which supports the Events & Actions interface:

  • ACServerSample
  • lighting_controller_service
  • my own test application

Currently I'm also using the android example Event_Action_Browser, but I intend to reimplement its functionality in my own application. I am looking for a way to quickly discover all objects which support Events & Actions. The sample app simply discovers all devices on the network, and then recursively introspects all available objects. Clearly this is not an optimal solution.

I've thought about discovering only objects which are advertised as supporting org.allseen.Introspectable, but I've noticed that ACServerSample advertises this interface, while lighting_controller_service does not. Is this advertisement is redundant in ACServerSample, or missing in lighting_controller_service?

The Events & Actions Guide mentions this issue and comments about calling GetDescriptionLanguages to check for this feature. Unfortunately this is of little use, since I still need to query every object on every device.

edit retag flag offensive close merge delete

1 answer

Sort by ยป oldest newest most voted

answered 2014-11-03 16:50:17 -0700

bspencer gravatar image

All applications that are written with the 14.06 or newer software support and contain the org.allseen.Introspectable interface. The current Event_Action_Browser android sample will introspect all devices it finds, if it has a description it will show it. If the application is older than 14.06 it will error and pass on the device. Yes this is some extra work, but at this time there is not a large amount of devices that support this. An improvement was suggested, and someone could bring this up at an AllSeen Alliance meeting, to update the About feature to include a flag/indicator that a object path contains descriptions. This would help to optimize the discovery of devices that contain Events/Actions, but it leaves the developer with the requirement to correctly set this flag.

The Event Action Browser is a sample, it is not intended to be the most optimal solution to collect Events and Actions. it is provided so that one can see how to perform the request, how one could possibly show them in a UI, and how to link an Event to an Action. The sample should be modified for your needs. One could cache the introspection XML so that you don't have to make the request when you find the device again. One could build the app to ignore the Control Panel Service as this does not have Actions or Events in it, etc.

edit flag offensive delete publish link more


The sample indeed is not optimal, but don't see any way to make it more optimal with the current design (apart from caching - which brings in other problems). The current way of allowing any (unadvertised) object to have events and actions actually forces any E&A application to use deprecated About APIs - as the comment for RegisterAnnounceHandler says: "This function has been deprecated. Please change your code to use RegisterAnnounceHandler where you specify the interface(s) that you are interested finding. Using this member function could have significant impact on network" Yes, I *can* work around all of this, but E&A design effectively nulls all the efficiency of the About service.

anszom ( 2014-11-04 02:50:17 -0700 )edit

I would like to separate out this discussion. E&A as a core feature is strictly adding in the ability to add a <description> tag into a new Introspection xml. The nature of what you are getting to is that the Sample application is not optimized, hence it is a sample, and not a final application.

bspencer ( 2014-11-07 11:46:04 -0700 )edit

Ok, I think that I understand it now, tell me if I got it right: 1. The E&A feature is meant to allow the developer to add human-readable descriptions for signals and events. What to do with those descriptions is left to the user. 2. The name "Events and Actions" is something of a suggestion that a full-fledged Events-and-Actions service *could* be build on top of this feature. This higher-level service could then define additional requirements allowing for better discovery (for example: supporting apps need to advertise some well-known interface).

anszom ( 2014-11-07 12:42:26 -0700 )edit

Yes. So, E&A as a feature of Core is exactly allowing the ability to put a human readable description. The sample is *one* way at which to present this to a user. An even higher level library could be created to help find the description tags(E&A tags) in an optimized way or support arguments etc.

bspencer ( 2014-11-10 14:08:58 -0700 )edit

ok, thank you for the explanation

anszom ( 2014-11-12 01:33:12 -0700 )edit
Login/Signup to Answer

Question Tools

1 follower


Asked: 2014-10-21 07:57:44 -0700

Seen: 296 times

Last updated: Nov 03 '14