OK. Wow. The product looks good on the user side, but their API is clearly geared toward building clients, and the remote control API documentation is so full or errors that it’s less than useless. Fortunately, they’ve got a swagger-based API test tool that works OK, so that fills in holes where the docs fail, and you can play with it to feel out what ends up working.
Here’s the download link to the first plugin release: https://www.toggledbits.com/assets/emby/Vera-Emby-0.1-181221.zip
What it currently does:
[ul][li]Finds your Emby server(s) using network discovery;[/li]
[li]Allows you to log in to each server, which generates an auth token that is stored in the Vera device (EmbyServer);[/li]
[li]Inventories the known, remote-controllable sessions (clients) on each server, and creates EmbySession devices;[/li]
[li]For each session, you can pause, unpause, skip forward/back, change volume, mute/unmute;[/li]
[li]Each session displays current playing media, position, and runtime, if any.[/li][/ul]
What it currently doesn’t do: A lot, but what you might be expecting that is currently absent includes:
[ul][li]Start playback of media on a client/session. Unlike Sonos, for example, a stopped Emby client doesn’t preserve its queue, so you can’t have the API “play” and have the last queue start/resume. “Play” in the Emby API requires the specification of one or more “items” (a generic term for some kind of media, or a playable media-related object like an album, playlist, etc.). That means that “Play” in this world is going to require a UI that allows you to select what media to play (or for a Vera action, tell it what to play). Creating a GUI that can browse the media library and let you choose what to play is, basically, creating an other Emby client, and it’s a big job, and it’s going to be a while before you see that in this plugin. I do plan on implementing play by (user-provided) title, with optional media type, but that will be optimized for starting playback via action (e.g. from Lua, Reactor, etc.); that’s where I’m headed next.[/li]
[li]To-the-moment updates on what is playing, client/session state, media position, etc., are not feasible in the Vera UI; there will be a lag. Aside from the two-second update interval of the UI itself, the only way to know what’s going on is to poll, which increases Vera’s load (and your Emby server’s). Polling frequency also affects timeliness of the displayed data, so it’s a balancing act. When a session is playing, the plugin polls more frequently (5 seconds default, configurable); but to avoid needlessly knocking the Vera, it polls at longer intervals when it last sees no active clients (nobody playing anything). That means when the client starts playing from a dead stop, it can take time before Vera displays that fact. An additional complication is that the Emby API does not have a way (at least, not that I’ve yet found) to query a single session, you have a single query that dumps the information for ALL of them, so there’s no way just to query the ones that are active/playing something, and that unfortunately makes frequent polling even more costly;[/li]
[li]The plugin does not provide a UI for, or implement in actions, the key-interface/navigation part of the remote control API, and I’m not planning on doing it. It doesn’t make sense to me, given the brutal sluggishness of the current Vera UI, that you would want to use the Vera UI to navigate menus on the client player, etc… “Down”. Wait three seconds. “Down”. Wait three seconds. “Left”. Wait three seconds. “Enter”. Wait three seconds… The thought of doing it that way makes a vein in my temple throb. It doesn’t seem like a use case this plugin should address.[/li][/ul]
Other matters:
Clients are going to be a bit of wildcard. Since each one is its own project, likely implemented by different product teams/developers who have their own approaches and inconsistencies, each client is going to function a little differently, but there’s no way for the server or the plugin to know that. For example, there are three commands to pause/unpause: Pause, Unpause, and Play/Pause (which toggles). A client is not required to implement all of them. The API will tell you the client can pause, but not tell you which to use. The docs recommend, but do not require, that clients implement PlayPause, so that is what the plugin uses, but I’m sure we’ll soon discover which clients ignore this guidance.
Another example: up/down volume control basically doesn’t work (at all) on the current Android client, but are functional on the Chrome desktop client but perhaps inconvenient/useless, because they use tiny (maybe 1%?) increments. I haven’t tried my Roku or others yet to see how they fare, but to make it better make sense for the Vera UI and actions, I’ve implemented a workaround: set the “SmartVolume” state variable in the session/client device to a value (0-100) that you want to use as a volume increment. When it’s non-zero, the up/down actions will not use the API up/down commands, but rather an absolute SetVolume command, incrementing or decrementing from the current level as needed.
Skip forward and backward are also hobbled for clients. The skip commands in the remote control API will skip to the next or previous song for audio, but do nothing when video is playing (and there is no separate “chapter skip” API command). So, like the volume issue above, I’ve implemented a workaround that, for video playback, ignores the API skip commands and instead does a seek using the chapter list and current position information.
Another thing I’m very interested in figuring out, if I can, is how this might be used for text-to-speech. Given that every TV, phone, tablet and desktop can be a controllable client, it seems like a great opportunity for TTS notifications. But for the moment, I’m off to figure out how to get playback of a known title started for version 0.2.
Oh… how to install it… it’s the usual for ZIP packages: once you’ve downloaded the ZIP file, unZIP it. The upload the files using the uploader at Apps > Develop apps > Luup files (remember to turn off the “Reload Luup when done” checkbox until the last file). Make sure you reload after the last file. If this is the first install of the plugin, you need to create the first device manually: go to Apps > Develop apps > Create Device and enter the following fields (leave the rest blank): set Description to [tt]Emby Interface[/tt], set Device Filename to [tt]D_Emby1.xml[/tt], and set Implementation Filename to [tt]I_Emby1.xml[/tt], and create the device (submit button). The reload Luup again (I just enter and run [tt]luup.reload()[/tt] in the Lua code test tool). After the reload, you can go in to the Emby Interface device and hit the “Run Discovery” button. It should find your local Emby server(s), and will create EmbyServer devices for them. On each server device, go in and log in with username and password. Once logged in, it will inventory the server or sessions/clients and be off and running. The discovery and inventory processes will cause Luup reloads themselves, and that’s expected–when you create child devices on Vera, it reloads. Fact of life. So take your time with the process and don’t be surprised if there are pauses in UI responsiveness while that’s going on.
Bugs and suggestions here in the thread, or PM or email me (email on my profile here).