|
Post by millst on Jan 17, 2021 15:58:49 GMT -5
You kind of are suggesting that. At one point you asked for a TCP/HTTP implementation. That is all new.
Even if you just want replies sent back to originating port instead of control port, that breaks existing software. I'll admit I am intermixing the networking in with API, but in the end a change to either can break stuff. The safest change would be a field in the control request indicating the desired response port (default being control port).
Personally, I disagree that their API is "sub-optimal" and think people should just deal with it. I already have and it wasn't that complicated. Threads are cheap and not everything has to be a REST API.
|
|
|
Post by megash0n on Jan 17, 2021 19:43:12 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. I understand it isn't their jam... That's why they outsource it. You are correct in regards to the broadcast. I misspoke. I'm not a programmer either. I struggle with things when there are little to no examples, or half the information. At any rate, I'm sure the document was never intended for someone to develop their own application with. I'm simply saying it would be nice to have examples, a bit more verbiage about "how it works", and to be organized a bit more clearly. Not saying it sucks.. Just that it could be improved upon. When you don't " Know" exactly what you are expecting to see on the wire, you spend a significant amount of time second guessing where the issues are. Is it the code? Is it the documentation, etc..
|
|
|
Post by megash0n on Jan 17, 2021 19:58:24 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. I'm following you now. When I said "it is typical in UDP responses by default", I was referring to the sender's IP address. You are suggesting that, if one makes a request from and app on port XYZ, that it returns to the sender on port XYZ instead of a different port they have determined. I couldn't begin to tell you why they have separated those things, but my guess is they are different pieces of code, and those pieces of code are tied to different UDP ports. Because, who wants an ACK and a different response back for all the items you probe or have subscribed to? Someone probably complained about " too much data" in the response, so they broke up different functionality to different ports. That way you aren't bombarded with a bunch of useless XML data. I can certainly understand your vendor's gripe because they would actually have to write a listener as you mentioned. But, assuming they are relying upon the built-in UDP "sender IP" that returns the response back to the original sender, they are going to get a lot more data than they want to full with. This whole situation is why I'm somewhat working on a small, wireless ESP32 device to interface with the data and provide a better interface to typical home automation solutions. This is also why I want EVERY configurable item available in the current API. It would allow you to configure from a web interface, back up your settings another way, provide it's own web gui for use if desired, and a few different options for connecting to home automation.
|
|
|
Post by vmbray on Jan 17, 2021 21:57:18 GMT -5
I'm following you now. When I said "it is typical in UDP responses by default", I was referring to the sender's IP address. You are suggesting that, if one makes a request from and app on port XYZ, that it returns to the sender on port XYZ instead of a different port they have determined. I can certainly understand your vendor's gripe because they would actually have to write a listener This whole situation is why I'm somewhat working on a small, wireless ESP32 device to interface with the data and provide a better interface to typical home automation solutions. Exactly, Roomie is asking that the response comes back to the original port. The other poster suggested adding a field to the request to enable that, that’s actually probably a great idea to avoid breaking things. For context and to be fair, for example the denon is terrible and good, good that it is simple to talk to, terrible that it will only talk to one device at a time, requiring a dedicated hub for multiple remotes. I salute your effort but also a third software middleware shouldn’t be needed and is more stuff to go wrong. To the positive, Roomie is pretty light and individual remotes will talk to devices directly whenever possible. The hub is a necessary evil and does cause occasional issues, so ideally devices would talk efficiently with remotes and not need middleware. But I can tap volume up/down and be happy too
|
|
|
Post by megash0n on Jan 17, 2021 23:02:21 GMT -5
I'm following you now. When I said "it is typical in UDP responses by default", I was referring to the sender's IP address. You are suggesting that, if one makes a request from and app on port XYZ, that it returns to the sender on port XYZ instead of a different port they have determined. I can certainly understand your vendor's gripe because they would actually have to write a listener This whole situation is why I'm somewhat working on a small, wireless ESP32 device to interface with the data and provide a better interface to typical home automation solutions. Exactly, Roomie is asking that the response comes back to the original port. The other poster suggested adding a field to the request to enable that, that’s actually probably a great idea to avoid breaking things. For context and to be fair, for example the denon is terrible and good, good that it is simple to talk to, terrible that it will only talk to one device at a time, requiring a dedicated hub for multiple remotes. I salute your effort but also a third software middleware shouldn’t be needed and is more stuff to go wrong. To the positive, Roomie is pretty light and individual remotes will talk to devices directly whenever possible. The hub is a necessary evil and does cause occasional issues, so ideally devices would talk efficiently with remotes and not need middleware. But I can tap volume up/down and be happy too I agree with you on the middle-ware topic. For me, I already have many of these devices throughout the house. If you have any Wi-Fi enabled relays or light switches, you do too. I'm basically taking the software side of one of these devices to add in different functionality for various things. I may never finish the project, but it sounded fun. I had considered adding IR capability along with multiple manufacture capabilities. Technically, it could all be done with Dirac Pi as well, but that's outside the scope of what I want to do. Back to the point... I could be wrong, but I'm afraid the way Emotiva does their API is going to be more than your vendor is going to want to mess with. The push side is easy. It's the retrieval of information that is cumbersome. You can only get what you ask for, and in the order in which you ask for it. Certainly not impossible, it just needs some critical thinking to implement something that will function properly.
|
|
|
Post by vmbray on Jan 18, 2021 0:16:11 GMT -5
Yes and they integrate to hundreds (or thousands) of devices, the nail that sticks up takes more hammering. Probably not a good analogy but it’s the one that popped up.
|
|
|
Post by wizardofoz on Jan 19, 2021 5:44:51 GMT -5
Emotiva App on iPad has been broken since forever I do wish that would be fixed... thankfully still works till now on my iPh X
I dont see why it can be redone for use on iPads too and fixed up for the XMC-2/RMC units or at least a different one to replace the old iOS app which is barely good.
|
|