|
Post by vmbray on Jan 1, 2021 16:21:20 GMT -5
I am using Roomie Remote and was working with them to try to enable feedback for two way communication for volume status, input status, mode, etc. They are saying that the need for a subscription to the updates is unusual in the device world and had a couple of suggestions, not sure how hard it would be to implement but it would be really nice to get the feedback working!
Their response to me:
The best path is for Emotiva to implement a TCP-based protocol.
The quick fix would be to send their reply packets to the source port of the control packets they receive. In other words, we send control packets to them at 7000. Our packets have a random source port, say 43617, which is part of the packet. They should observe that port number and reply on that port number. That's the port we're listening on for replies.
In theory I could add a lock to listen on 7001 like they seem to want. The problem with that on any consumer OS is that it becomes unreliable to use a fixed port number for listening. If more than one app uses that port number, it's all downhill from there.
I know in the Denon world for instance, you just send an http post with some command(s) and it acks back the new status, so if you set master volume +1 it responds with the new volume. Is that something you guys would consider adding?
|
|
|
Post by millst on Jan 2, 2021 13:20:44 GMT -5
I think your chances of getting Emotiva to create a whole new network API for all their processors is far less likely to happen than the Roomie devs just dealing with the existing interface. UDP 7000-7004 aren't used by any well-known apps so a conflict is fairly unlikely.
|
|
|
Post by vmbray on Jan 2, 2021 13:29:30 GMT -5
They did say it could probably be resolved by replying to the original port with the new status. That’s still udp just with a tweak.
|
|
|
Post by millst on Jan 3, 2021 12:54:39 GMT -5
I don't think that really solves the problem. The receipt of the ACK on the control port only indicates that the Emotiva device received your request and that it is valid. It does not indicate that anything was done. You still need to be subscribed and listening to the relevant notifications for that. Maybe if those messages followed the same pattern to get rid of the fixed ports.
|
|
|
Post by vmbray on Jan 4, 2021 18:43:00 GMT -5
Oh that makes sense I guess. I don't think Roomie is going to do all that since they say that the subscription model is unusual and requires a thread running to listen just for that. Sounds like I'm probably stuck, it's not a huge deal just something I thought Emotiva might want to spruce up to improve the integration with other systems, and maybe they will in the future.
|
|
|
Post by millst on Jan 5, 2021 11:18:00 GMT -5
Yeah, it is a bit unique. I remember complaints related to Crestron or similar a long while back, but nothing came of it. It's really not that difficult to support (there are XMC-1 control apps on multiple platforms), but you're probably out of luck if Roomie devs won't make the effort.
|
|
|
Post by vmbray on Jan 6, 2021 8:54:08 GMT -5
I think with any integration it’s in the vendors interest to make it as simple as possible to play with other systems, because that effort made one time is more efficient than having multiple control platforms do more work than really necessary.
In this case having to have a separate listener thread running when a reply could just be sent back to the original port isn’t as efficient as it could be, if I’m understanding it correctly.
|
|
|
Post by millst on Jan 6, 2021 14:55:19 GMT -5
Don't disagree, but what's done is done and many protocols use multiple ports.
Not strictly true. There needs to be multiple sockets active at once, but they could all be serviced through a single thread.
|
|
KeithL
Administrator
Posts: 9,902
|
Post by KeithL on Jan 6, 2021 15:15:28 GMT -5
I should also point out that there are already apps that use the current API.
Not only would the code in our processors have to be changed... But doing so would break the apps that currently work with it... Requiring that THEY be rewritten as well...
|
|
|
Post by AudioHTIT on Jan 8, 2021 17:46:55 GMT -5
I should also point out that there are already apps that use the current API. Not only would the code in our processors have to be changed... But doing so would break the apps that currently work with it... Requiring that THEY be rewritten as well... I just have to point out that the current Apps are already breaking with the latest versions of IPadOS, and probably just hanging on with iOS. While it doesn’t make sense to fix those, some work will need to be done in the near future, if it’s not already going on.
|
|
|
Post by millst on Jan 9, 2021 12:01:58 GMT -5
Doubtful those issues are related to Emotiva's API as other apps continue to work. Probably just changes in Apple's SDK or new privacy features that broke those. Wouldn't be a reason to touch Emotiva's API as that would break apps on Windows, Android, Linux, etc.
|
|
|
Post by AudioHTIT on Jan 11, 2021 10:52:35 GMT -5
Doubtful those issues are related to Emotiva's API as other apps continue to work. Probably just changes in Apple's SDK or new privacy features that broke those. Wouldn't be a reason to touch Emotiva's API as that would break apps on Windows, Android, Linux, etc. Yes, it seems very much related to the new Privacy policy on iOS / iPadOS 14, however (oddly) it only (currently) breaks iPadOS. I assume Android still works but haven’t heard it reported in some time. As far as I know, any Windows or Linux Apps are ‘unofficial’. The point of my post was that the ‘official’ Apps haven’t been touched in over 5 years, so compatibility with current hardware and OS’ is bound to be strained; if changes need to be made to make the Apps more compatible and more functionally useful, now would be a good time to bite the bullet.
|
|
|
Post by millst on Jan 11, 2021 12:24:21 GMT -5
Regardless of unofficial or official, I still think they should be wary of breaking changes to the API. Look at the blow-back Logitech got for messing with the XMPP interface on their hub.
Emotiva's support of their network remote capability has been weak, at best. Late to deliver apps and little to no maintenance after that (probably a contributing factor in the creation of the unofficial apps). Not really acceptable in my book since they advertised the capability.
|
|
|
Post by vmbray on Jan 16, 2021 12:50:09 GMT -5
Isn’t it possible to add a new tcp/http on a different port and leave the old protocol as-is? Then the various vendors have time to respond and later once everyone is on the new protocol, sunset the old one?
|
|
|
Post by megash0n on Jan 16, 2021 12:55:18 GMT -5
Isn’t it possible to add a new tcp/http on a different port and leave the old protocol as-is? Then the various vendors have time to respond and later once everyone is on the new protocol, sunset the old one? yep. I'm somewhat working on some code, and hardware, to talk wirelessly to the G3Ps, send commands and parse the XML responses for updating other software. Focusing on MQTT and likely Rest API. Not sure when I'll have the time to dig back in though as I'm working on AWS Cloud training ATM.
|
|
|
Post by megash0n on Jan 16, 2021 12:59:00 GMT -5
They did say it could probably be resolved by replying to the original port with the new status. That’s still udp just with a tweak. this is standard with normal UDP implementations. They've purposely locked it to a port. Also, the ack comes back on a different port than the subscription information I believe. I've beaten my head against the wall on this for a while before I figured it out. Unfortunately, without knowing how to properly parse the XML data, and what order to expect it in due to your subscriptions or specific request, it is a bit cumbersome.
|
|
|
Post by millst on Jan 17, 2021 1:51:18 GMT -5
Anything is possible. What is likely? Not Emotiva changing the API and breaking a bunch of dependent software. Even less likely? Emotiva creating a whole new API just for the Roomie dev(s)
|
|
|
Post by megash0n on Jan 17, 2021 10:21:22 GMT -5
Anything is possible. What is likely? Not Emotiva changing the API and breaking a bunch of dependent software. Even less likely? Emotiva creating a whole new API just for the Roomie dev(s) There's nothing horribly wrong with what they have now. It is just cumbersome. I would like to see, at a minimum, further development to incorporate ALL settings to be pulled or pushed via API. The API documentation needs an update to be more easily understood. It is not written well enough to be fully understood from a technical writing perspective. It is written from an "insider's" perspective. One who already has an underlying understanding of how it works logically. Real world examples of implementation using standard tools for example would be handy. Any multicast items should be eliminated due to many Wi-Fi solutions blocking that by default. If one has an application built that allows you to pull all available settings into an array, then you could select the items you would like to "subscribe to". This provides an order to a new array allowing one to configure 3rd party software to interact with said configurable items whether that be push or pull. I have in my head what I'd like to do with it, but I'm a hack when it comes to programming, so it takes me a long time just to figure out the basic, mechanical functionality. Adding a RestAPI to the G3P would probably be most ideal. This way one could simply pass a URL post or get to configure or retrieve a value. I highly doubt it would take a significant amount of effort on their part to do this, but I'm sure they have higher priorities.
|
|
|
Post by millst on Jan 17, 2021 12:25:49 GMT -5
What do you think is missing? There were definitely some gaps early on, but they corrected that. I'm pretty happy with the current set now.
Yeah, they could have used some flow diagrams or examples to help. There is no multicast in the API, so not sure what you mean there. There is a broadcast for the ping, but that is optional if you know the IP address and hard-code the ports.
I find it a bit contradictory that you struggle to manage a few sockets and parse XML, yet think it would be insignificant effort on their part to make changes. Software is not Emotiva's forte.
|
|
|
Post by vmbray on Jan 17, 2021 15:07:34 GMT -5
Anything is possible. What is likely? Not Emotiva changing the API and breaking a bunch of dependent software. Even less likely? Emotiva creating a whole new API just for the Roomie dev(s) That’s not what I was suggesting. I specifically asked would it be possible to modify what’s there or add a protocol in addition to what is there. That’s not a breaking change, so it would help the discussion not to keep saying it has to be. Not even asking for some new command set or anything. At the simplest it could possibly be the option to simply get a reply back to the port that sent the request. That could be added so that replies are sent to both the fixed port and to the sending port maybe? I don’t care that much but apparently the way it’s currently done is sub-optimal, and could possibly be improved without a major re-do. Roomie just asked if the response could come back to the originating port rather than having to run a listening daemon which again doesn’t have to be done for the majority of devices. When the design makes it harder for everyone down the line it’s just cumbersome and wastes time. Instead, make it as easy as it can be and that in turn improves integration to your product and in turn expands the market for the product. We can spend time arguing about how the request isn’t reasonable or on the other hand there might be a simple creative solution there.
|
|