Denon binding for DRA-100 - amend exisitng or make a new binding?

I hope it’s OK to ask the question here. The existing binding for Denon/Marantz work with Denon DRA-100, but it’s only partially compatible. What’s a better direction to fix it: make a new dedicated binding or try to modify the existing one? My concern is that if I go with the modification I wont be able to check if my changes are not affecting the other Denon models.Creating a new one is easier, but there would be some code duplication, so it’s not optimal. What’s the preferred way?

DRA-100 API is very well documented, so that should not be a problem. Quality of that API is a different story :slight_smile:

You should extend the existing binding. Is it a new protocol or an extension of any of the existing protocols (telnet and http)? If entirely new, maybe it would make sense to create a new thing type.

1 Like

Thanks for the guidance! It’s telnet, so it’s just a matter of adjusting the commands.

The Denon docs are here: Documentation/DRA-100_PROTOCOL_Ver1.0.0.pdf · master · Przemo Firszt / dra100 · GitLab (my repo with DRA-100 python library)

I did “read the source, Luke” exercise and I don’t see any list of supported models - which is OK as it allows to support new models by detection of MAC address. My problem is that input source provided by the binding is 40 positions long and only 3 are relevant to Denon DRA-100 (IRADIO, SERVER, USB). I could define them with in the Selection widget (comma separated list instead of list provided by the server, but it means that every user would have to do it al well - I don’t like that, as it would require some knowledge that’s beyond a clicking user. Another option would be to extend the list and make it 46 positions long :nauseated_face: but that would make it less useful for all other models. Is there a way of restricting the list provided to the Selection widget by the binding depending on the model detected?
Please let me know if I’m completely wrong - maybe there is a better way to solve that problem?

I dare to call the authors @idserda and @jwveldhuis for advice :grinning: (thank you for all your work!!)

If you mean that the options listed here:

lacks BLUETOOTH, COAXIAL, DIGITALIN1, DIGITALIN2, ANALOGIN, ANALOGIN2 - then I think you should just add it to this list, which is already a list of all possible input sources across all models (and evens brands).

Filtering this list should be done outside the binding, at least with the current design. I have not read the source code, so there is a chance I’m missing something, for example if the binding would dynamically manipulate this list based on detected model from the MAC address, but I wouldn’t think so. :slight_smile:

1 Like

Yes, that’s the list - I added DRA-100 options to it. But it means I’ll have 46 options on the screen, with only 6 of them relevant to DRA-100. I think I’ll have to implement filtering based on detected model. That won’t change anything for the existing users.

I need to find out if other bindings do something like adjusting a selection list based on detected thing properties.

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.