Retrieve state-, device- and zone status

[MadMonkey87]

Retrieve state-, device- and zone status

[i8beef]

https://github.com/i8beef/Denon/tree/5-HttpClientAbstraction

That branch is sort of what I mean. There was some cleanup that I was holding back for another release anyway. You should be able to use the underlying DenonHttpClient in that branch instead and bypass any of the eventing the library normally assumes. Ill look at getting a release together for this soon.

[i8beef]

It should publish updates for secondary zones as well, but only certain things like power, volume, mute, etc.

[MadMonkey87]

Is there anything that speaks against to make the following methods public and therefore accessible:

• I8Beef.Denon.HttpClient.GetDenonDeviceInfoAsync
• I8Beef.Denon.HttpClient.GetDenonStatusAsync
• I8Beef.Denon.HttpClient.GetDenonMainZoneStatusAsync
• I8Beef.Denon.HttpClient.GetAllDenonSecondaryZonesStatusAsync
• I8Beef.Denon.HttpClient.GetDenonSecondaryZonesStatusAsync

It would be really helpfull to be able to retrieve these details directly, or am I missing something?

[i8beef]

Yeah, that's not what this client is built for. It's built for real time eventing, not polling. The HttpClient is just exposed as an alternative to the TelnetClient as Denon receivers have a limitation on the number of telnet based clients that can be connected at once. Both are meant to expose the same functionality and interface. Using the HttpClient wouldn't even make sense for you as it stands if that's what you want here as the HttpClient inherently polls on an interval and emits events to be consumed.

I am NOT opposed to possibly splitting the current Client up to allow this though. Basically the existing Client would then USE a "stateless" http client in its implementation which you could use without the wrapper and such, which I COULD expose without changing the existing interfaces / expected usage of this library. The telnet client wouldn't have the same capability, and you could kind of "sneakily use" a type that SHOULD be "internal" if I exposed it as "public" instead... I can see how that could be useful to others that don't need the event based version.

[MadMonkey87]

You're right not to mixing up real time events polling and stateless requests. The proposed client abstraction is exactly what I was taking about, thx!

[i8beef]

3.0.0.10 should be out momentarily.