[JSON] Additional Events to support Home Automation needs

TRAC Ticket #12830

opened ticket and made the use case more general after getting some good info in the thread.

I'm not sure I understand 100% which notifications you are looking for.

Events on GUI actions will be very unlikely to be implemented (soon) but there already are notifications for play, pause, stop etc and they are sent as Player.OnPlay, Player.OnPause, Player.OnStop etc and they contain the ID and type of the file that is currently played so you can use FooLibrary.GetFooDetails based on the received type and ID to retrieve additional information.

(2012-03-25 00:01)Montellese Wrote:  Events on GUI actions will be very unlikely to be implemented (soon) but there already are notifications for play, pause, stop etc and they are sent as Player.OnPlay, Player.OnPause, Player.OnStop etc and they contain the ID and type of the file that is currently played so you can use FooLibrary.GetFooDetails based on the received type and ID to retrieve additional information.

If type includes specific items: Movie, TV, Music, Photo, Video, etc... this would work as the Home Automation could use these to provide context of what the room environment should be set to (lighting, audio/video settings, etc).

Some background...
For any Home Automation (HA) integration some GUI actions would be preferred based on what section is being entered (Movies, Music, name of Favorite, etc) on the menu system. This would provide the HA system to "prepare" the environment for the upcoming "event" - example: Watching a Movie after 6pm might mean dim the lighting to 20%
Then Player notifications can be used afterwards, since 'context' can been set based on the section notification having been received into the HA system (Homeseer, EventGhost, MiCasaVerde Vera, and many more). Player notifications, without context, is not actionable for HA.

To respond to 'asking' for more info from XBMC...
Requiring an HA system to get a notification, then ask XBMC for more context on what the notification's specific are, then getting back an answer -- very inefficient and far more complex since it requires new coding on the HA side which will be new/different for every HA system in the world.
I'd prefer to see the more efficient way of XBMC providing the relevant information in the initial notification string. This would allow the HA system to parse the string, and ignore all/parts as it desires... which is a simple thing to do, programatically -even for crappy programers like myself

Adding this to notifications for important items it solves tons of usability problems for HA, and also adds functionality for other systems like dashboards/front-ends/guis/remotes that are being built to supplement XBMC... like Marachino, HTPC Manager, and others

(2012-03-25 01:04)Livin Wrote:  If type includes specific items: Movie, TV, Music, Photo, Video, etc... this would work as the Home Automation could use these to provide context of what the room environment should be set to (lighting, audio/video settings, etc).

Yup those notifications contain a "type" property (which can be "movie", "episode", "musicvideo", "song", "picture", ...) and an "id" attribute which specifies the ID of the item in the respective database.

(2012-03-25 01:04)Livin Wrote:  Some background...
For any Home Automation (HA) integration some GUI actions would be preferred based on what section is being entered (Movies, Music, name of Favorite, etc) on the menu system. This would provide the HA system to "prepare" the environment for the upcoming "event" - example: Watching a Movie after 6pm might mean dim the lighting to 20%
Then Player notifications can be used afterwards, since 'context' can been set based on the section notification having been received into the HA system (Homeseer, EventGhost, MiCasaVerde Vera, and many more). Player notifications, without context, is not actionable for HA.

With the "type" property you should have a context (a bit late but you still have it).

(2012-03-25 01:04)Livin Wrote:  To respond to 'asking' for more info from XBMC...
Requiring an HA system to get a notification, then ask XBMC for more context on what the notification's specific are, then getting back an answer -- very inefficient and far more complex since it requires new coding on the HA side which will be new/different for every HA system in the world.
I'd prefer to see the more efficient way of XBMC providing the relevant information in the initial notification string. This would allow the HA system to parse the string, and ignore all/parts as it desires... which is a simple thing to do, programatically -even for crappy programers like myself

Adding this to notifications for important items it solves tons of usability problems for HA, and also adds functionality for other systems like dashboards/front-ends/guis/remotes that are being built to supplement XBMC... like Marachino, HTPC Manager, and others

The reason why the notifications only contain the "type" and the "id" (except if the item is not in the database then you get additional information like title etc) is because the more data we put into the notification, the longer it takes to transmit it and to parse it. Furthermore we have to consider how many clients will probably need e.g. the plot of a movie in the Player.OnPlay notification. That's why we trimmed the information down to a minimum which still allows to retrieve additional information if necessary. Another reason is to keep memory usage on clients as low as possible. If I write a JSON-RPC client on a microcontroller which has very limited RAM then I'd be grateful if the notifications only contain as much information as necessary so I can keep memory usage as low as possible.

Thanks for discussing this with me. I'm going to look into using the 'type' attribute, I suspect that should work fine.

I completely understand your point about the memory and time with the communications. Just a thought... Would it be difficult to have options for the items send with the initial notifications... basically giving the user the ability to select (via advancedsettings.xml) the specific items the notifications sent on the initial communication? This would give fine-grain controls to "tune" the for the user's specific needs... again, just something that might be cool, and very useful - if you think it is reasonable to do?

It would be a possibility. Currently a client can only specify which types of notifications (Player, AudioLibrary, VideoLibrary, System, ...) he would like to receive and which ones not (by default every client receives all notifications). That logic could be extended to allow every client to specify which additional properties to receive with the notification. While this sounds easy it will probably be rather difficult to implement. But it won't hurt if you create a feature request ticket on trac describing this idea.

Thx for the help, ticket created... http://trac.xbmc.org/ticket/12830

Request content...

Currently a client can only specify which types of notifications (Player, AudioLibrary, VideoLibrary, System, ...) to receive and which ones not (by default every client receives all notifications).

Please extended the logic to allow every client to specify which additional properties to receive with the notification.

This would give fine-grain controls to "tune" the notifications for the 3rd party systems and increase efficiency of the communications.

Today's method would require a 3rd party system to get the initial notification, then ask XBMC for more specific information, then getting back an answer -- very inefficient and far more complex to handle on the 3rd party system since it requires new coding on the 3rd party side which will be new/different for every 3rd party system.

Thank you for considering.