[quote=“chef, post:11, topic:200354”]Cool you did add message capabilities:
function actionSessionMessage( );
Fantastic! Will we be able to use it in vera scenes?
Perhaps if the Server was available as a device in scene creation, with the ability to use the message action, by selecting an emby device to message.[/quote]
Alas, if it is to be done in the scene editor, it has to be done using the limited UI capabilities of Vera’s “static JSON” page/action/control description. Anything dynamic, like presenting a list of Emby servers, won’t be happening, at least not in UI7. We can hope for better days ahead, perhaps. If I did it in JavaScript, you’d have it on the control panel, but it wouldn’t show up in the scene editor.
For now, the way to send a message in a scene is to use scene Lua (or you can use the action-running abilities of a Reactor activity, or Rules Engine, PLEG, etc.).
-- Send a message to an Emby session (devnum = its Vera device number)
luup.call_action( "urn:toggledbits-com:serviceId:EmbySession1", "Message", { Text="hello world!", Header="Greeting" }, devnum )
Sorry for so many posts, the lua is a great read sir.
The MVP is luke. Swagger didn't work for a long time when they added authentication. But, yeah...
Ah hahah! Indeed, those docs were killing me. The most trivial tasks turned into hours-long fussing about, until I found swagger. But I get it. The Remote Control API is probably not the most used, so between not getting a lot of in-team attention, and probably very few people looking at it outside, it’s bound to slip off. Swagger is the white knight.
Also, if you wanted specific endpoints in the emby server for something, I can whip them up for you.
That is, if there is something you’d want the emby server to handle and return to vera.
You’ve probably seen the discussion with Luke regarding a real “resume”–start replaying the whole queue from where it stopped. I faked it trivially, as you’ve now seen, by tracking the current media item playing, but since I also can’t access the session’s queue, I don’t know what comes after the current playing media item. The simplest thing for me would be a resume, that simply restarts the last queue on the session (which would imply that the session’s queue has to have some persistence, of course, which currently does not appear to be the case. Second best would be a way to fetch the session’s queue–a simple list of all the media items that are to be played (and perhaps even those played, and some kind of pointer to the current position on the list). That’s a user request, by the way. I’m not sure how useful it is, myself. I’m not sure I’d use it. If I want my queue to stop so I can pick it up later, I’d pause and unpause. If I want media queued up so I can start it playing, I’d create a playlist and use PlayMedia to launch it on demand. Relying on the client’s or server’s memory of what to play doesn’t seem like the right approach. But, it was requested, so I passed it along, and did what I could for now.
The other thing I’d like to get done that I think would really cool, expanding on the “Message” action, would be text-to-speech. I could pull that off if I could get a session to play media by URI (even if its just a file:///tmp/foo.mp3 to play a file that’s local to the server, but ideally, any common protocol/location). Basically, play media that isn’t in the library. I’ve mentioned that to Luke as well. Not a priority for anyone (self included), but could be useful.
Websocket… I have a whole implementation for that. I did it all, made it work. But the real benefit–update immediately when a message arrives–can’t be realized. If I block on the socket, Vera eventually deadlocks, trips the watchdog and reboots. They’re not hooked in deep enough to yield on I/O waits. They want the plugin routines to execute in five seconds or less, or they start logging warning messages. Even if I block for just five seconds, then, I have to give control back to them, I have to return; and then the only way to get control back is with a timer action (one second resolution)–basically polling again. Benefit gone. So I backed it out and shelved it. There is another method, an old, crusty method that’s actually modeled for collecting data from serial devices, that I can try, but I haven’t gone there yet; it would require restructuring all the I/O into that model. I look at this plugin more as a command and control thing, not as a replacement UI for the client UIs. Even if I overcame the socket blocking, Vera only updates its UI about once every two seconds at best, so it will still look jittery and, well, crappy. I can’t even do a free-running clock in JavaScript and try to sync it with the session play progress–UI7 isn’t that flexible on the dashboard cards. If Vera used ALTUI’s model, it would be easy. Hopefully they go that direction. But anyway, for now, it’s command and control, with just enough UI that you can generally see what’s going on.
