Vera and Emby

Watching this thread definitely interested in the progress of an Emby plugin for Vera.

I’ve used Emby media server for a while now, mainly for remote access clients and library metadata management.

But sounds like we might be able to do some interesting things with Vera and Emby in the future.

To save the Vera on polling emby server when it is not being used and in a low power sleep state would it be possible to add in a ping check every polling period and if no response then don?t run any further code until next polling period? Or perhaps you already have some code efficiency built it if there is no response from the emby server?

Running around in holiday mode, so forgive the (relative) brevity here…

Already working on this. One of the shortcomings of their API is that you can’t query individual sessions (client states), the API returns ALL of them for a server, so if ANY client on a server is playing, I have to set a high update rate and it ends up updating all of them. Fortunately, the data isn’t too large, but it still kinda socks. Anyway, next version will fall way back when the server is unreachable.

Client issues, as I said earlier, are many; I’ve notice lots of inconsistencies between Android, Chrome, others. Not all clients support all functions, or consistently or in useful ways. I guess that’s our welcome to the Emby ecosystem (not unlike Plex and Kodi). I’m not going to be researching and coding exceptions for each client, as anyone can write a client, they’re often written by third parties, they rev without notice, and I can’t have every device to test with. I’ll will work around general issues (like whether they support ToggleMute or Mute/Unmute). Discovery on your network was hobbled by a hard-coded broadcast address for testing, fixed in coming version. Stop function is hidden intentionally (see my earlier explanation about queue and difference with other media players like Sonos). Your HTPC, if it’s an Emby server, won’t be “picked up” automatically, you need to discover it. If it’s a client, the plugin doesn’t support DLNA clients or clients that the Emby server reports as not remote controllable, so it’s likely one of these two conditions.

Version 0.2 (upcoming) will require server be 3.4 or higher, just to prepare you…

I just installed the plugin on my test / spare Vera Edge box.

The auto discovery worked for me, it detected my Emby server and created a new device for it, which now says Please login.

After logging in with my Emby username and password, its now added three Emby client devices.

  1. My Android phone
  2. My Windows 10 laptop Chrome
  3. FireTV Stick (This is a remote client not on my own LAN)

Screen shot attached.

I have more clients connected to Emby perhaps not currently active, but none of these other Emby clients were added to Vera.

If I play a movie in Emby on my laptop in the Chrome web browser.

That device in Vera is correctly showing the movie title I am playing.

All the transport control buttons appear to work OK, pause, stop, vol up / down, mute, skip back / forward etc.

So far so good !

I’ve got another remote access FireTV Stick connected and playing a movie right now, this Emby client hasn’t been discovered / added to Vera by the plugin.

I just reloaded the LUUP Engine in Vera and now that missing Emby client has just appeared as a device in Vera.

I know you have mentioned TTS to the Emby clients how about the messaging service ?

In the Emby server you can manually send a pop up notification on screen to the Emby client.

If we could use that for Vera scenes or PLEG logic, maybe when your doorbell is pressed for example, send a notification message to any active or pre selected Emby clients. Obviously I wouldn’t want any such messages to go to any remote access Emby clients off my LAN.

I think the popup is implemented as an action. Look at S_EmbyServer1.xml

When I was poking about in the API before I did manage to send a popup notification to an Emby client.

http://forum.micasaverde.com/index.php/topic,103145.msg414230.html#msg414230

When I was poking about in the API before I did manage to send a popup notification to an Emby client.

http://forum.micasaverde.com/index.php/topic,103145.msg414230.html#msg414230[/quote]

Not sure what you mean, but to be clear on what I’m saying, it’s already implemented:

[tt]luup.call_action( “urn:toggledbits-com:serviceId:EmbySession1”, “Message”, { Text=“Hello World!”, Title=“Greeting” }, client_device_num )[/tt]

[quote=“rigpapa”]

To save the Vera on polling emby server when it is not being used and in a low power sleep state would it be possible to add in a ping check every polling period and if no response then don?t run any further code until next polling period? Or perhaps you already have some code efficiency built it if there is no response from the emby server?

Running around in holiday mode, so forgive the (relative) brevity here…

Already working on this. One of the shortcomings of their API is that you can’t query individual sessions (client states), the API returns ALL of them for a server, so if ANY client on a server is playing, I have to set a high update rate and it ends up updating all of them. Fortunately, the data isn’t too large, but it still kinda socks. Anyway, next version will fall way back when the server is unreachable.

Client issues, as I said earlier, are many; I’ve notice lots of inconsistencies between Android, Chrome, others. Not all clients support all functions, or consistently or in useful ways. I guess that’s our welcome to the Emby ecosystem (not unlike Plex and Kodi). I’m not going to be researching and coding exceptions for each client, as anyone can write a client, they’re often written by third parties, they rev without notice, and I can’t have every device to test with. I’ll will work around general issues (like whether they support ToggleMute or Mute/Unmute). Discovery on your network was hobbled by a hard-coded broadcast address for testing, fixed in coming version. Stop function is hidden intentionally (see my earlier explanation about queue and difference with other media players like Sonos). Your HTPC, if it’s an Emby server, won’t be “picked up” automatically, you need to discover it. If it’s a client, the plugin doesn’t support DLNA clients or clients that the Emby server reports as not remote controllable, so it’s likely one of these two conditions.

Version 0.2 (upcoming) will require server be 3.4 or higher, just to prepare you…[/quote]
I now have the htpc client/server device listed in Vera and showing correct media playing but no action currently work.

Update 0.2: https://www.toggledbits.com/assets/emby/Vera-Emby-0.2-181223.zip

*** Requires servers running 3.4 or higher!

  • Fixes a bunch of UI issues;
  • Behaves better when the server is unreachable;
  • Implements “PlayMedia” action (urn:toggledbits-com:serviceId:EmbySession1);
  • Removes action-less service declarations and use (if you’ve created any scenes that trigger from a change in session state, you’ll need to redo the trigger).

[quote=“rigpapa, post:50, topic:199693”]Update 0.2: https://www.toggledbits.com/assets/emby/Vera-Emby-0.2-181223.zip

*** Requires servers running 3.4 or higher!

  • Fixes a bunch of UI issues;
  • Behaves better when the server is unreachable;
  • Implements “PlayMedia” action (urn:toggledbits-com:serviceId:EmbySession1);
  • Removes action-less service declarations and use (if you’ve created any scenes that trigger from a change in session state, you’ll need to redo the trigger).[/quote]

If something doesn’t work as expected, please examine your log files and post any errors/warnings you find there. Also please be detailed in reporting issues; “doesn’t work” doesn’t cut it. Also, the output of the “Plugin Status” link on the master device may help (as long as I know the name of the client or server you’re reporting about as well).

[quote=“rigpapa”]Update 0.2: https://www.toggledbits.com/assets/emby/Vera-Emby-0.2-181223.zip

*** Requires servers running 3.4 or higher!

  • Fixes a bunch of UI issues;
  • Behaves better when the server is unreachable;
  • Implements “PlayMedia” action (urn:toggledbits-com:serviceId:EmbySession1);
  • Removes action-less service declarations and use (if you’ve created any scenes that trigger from a change in session state, you’ll need to redo the trigger).[/quote]how would I start a movie named Batman Returns on session 2 ? Probably a silly question but Where do we find the session number?

[quote=“PrincessCleavage, post:52, topic:199693”][quote=“rigpapa”]Update 0.2: https://www.toggledbits.com/assets/emby/Vera-Emby-0.2-181223.zip

*** Requires servers running 3.4 or higher!

  • Fixes a bunch of UI issues;
  • Behaves better when the server is unreachable;
  • Implements “PlayMedia” action (urn:toggledbits-com:serviceId:EmbySession1);
  • Removes action-less service declarations and use (if you’ve created any scenes that trigger from a change in session state, you’ll need to redo the trigger).[/quote]how would I start a movie named Batman Returns on session 2 ? Probably a silly question but Where do we find the session number?[/quote]
luup.call_action( "urn:toggledbits-com:serviceId:EmbySession1", "PlayMedia", { Title="Batman Returns", MediaType="Video" }, session_dev_num )

The session_dev_num is the device number of the client/session.

Version 0.3 now available here: Release v0.3 · toggledbits/Emby · GitHub

Version 0.3 (development release 2018-12-31)

  • Change list of media types to better match capabilities in PlayMedia action;
  • Add Inventory action on server to force re-inventory without Luup reload;
  • SmartMute’s default will now figure out how to accomplish mute based on what the reported device capabilities are, with first priority given to ToggleMute/Mute/Unmute commands, followed by SetVolume, and last Pause/Unpause.
  • Allow DLNA clients now that we can see them working (not all are responsive–many require a UPnP proxy to be functional);
  • Add a 60-second delay in transition from (server) active to idle, in case new media starts playing (so frequent polling continues for a short while after all clients go idle, in case a client starts playing again);
  • Tweak service files for better Reactor interaction;
  • Enforce limit on number of results returned by PlayMedia search (default 25).

Very cool, I have audio auto triggering. I have uploaded the latest file and rebooted and I can see my main home theatre server listed and also listed as a client but when play media it shows as off line and can be controlled. Is there any troubleshooting or logs I can provide that might help to identify why it?s offline?

No, there are many devices that show and can’t be controlled, for whatever reason. It’s just going to be one of the things we need to figure out and see how we can filter them. The initial query for sessions (clients) does an unrestricted request, so it may return devices that were used once and never again, etc… anything appearing in your Emby server’s list of devices when you look at that in their settings UI. Cleaning up that list will help in the short term; I’ll restrict the initial query a bit more on startup as well for the next version.

Oh, but one thing you might try… if the device is UPnP, it may do better if you have an operating UPnP proxy on your network (your router will sometimes fulfill this role, but be careful–security monsters lurk). My Sonos, for example, shows up, not off-line, and is controllable, but status never changes–it always looks idle, and the data from the Emby server shows no changes or activity. But if I enable the UPnP proxy at my router, the status starts to correctly follow the Sonos’ activity.

That said, I have a dozen devices that Emby reports as “controllable.” About half of them actually work at all, and just the Android and Chrome clients work consistently across the board (so these are my benchmark devices). DLNA-discovered devices are particularly troublesome, with no actual ability to control anything in most cases, even though Emby lists them as controllable. Some, like my Onkyo receiver, will respond to volume control commands (badly–the server appears to maintain volume level different from the receiver display/knob, and rather than use the receiver’s real mute function, it toggles volume between -infinity db and whatever), and nothing else I’ve found as yet works. It’s just a roll of the dice with each device.

[quote=“rigpapa”]Oh, but one thing you might try… if the device is UPnP, it may do better if you have an operating UPnP proxy on your network (your router will sometimes fulfill this role, but be careful–security monsters lurk). My Sonos, for example, shows up, not off-line, and is controllable, but status never changes–it always looks idle, and the data from the Emby server shows no changes or activity. But if I enable the UPnP proxy at my router, the status starts to correctly follow the Sonos’ activity.

That said, I have a dozen devices that Emby reports as “controllable.” About half of them actually work at all, and just the Android and Chrome clients work consistently across the board (so these are my benchmark devices). DLNA-discovered devices are particularly troublesome, with no actual ability to control anything in most cases, even though Emby lists them as controllable. Some, like my Onkyo receiver, will respond to volume control commands (badly–the server appears to maintain volume level different from the receiver display/knob, and rather than use the receiver’s real mute function, it toggles volume between -infinity db and whatever), and nothing else I’ve found as yet works. It’s just a roll of the dice with each device.[/quote]
My Home Theatre server/client was showing play style correctly with the first version you released but no longer seems to show current state

Run the Plugin Status link on the Emby Plugin control panel and PM me the response. I’ll take a look.

As you mentioned I have been calling media on device without specifying media type and seems to work ok:
luup.call_action( “urn:toggledbits-com:serviceId:EmbySession1”, “PlayMedia”, { Title=“Dts blu-Ray music demo disc 4”, }, 703 )