Some documentation updates

docs/DESIGN.md

@@ -7,8 +7,7 @@ This file contains some design decisions. Mainly intended for future me.
 The library was initially intended for automation applications, so focused on control, not configuration.
 The scope changed to providing an interface that allows to set/get data using familiar YNCA vocabulary.
 
-However, since the amount of supported functions impacts the `initialize`time functions will only be added when
-someone has a usecase for it and not just all off them.
+Since the amount of supported functions impacts the `initialize`time functions will only be added when someone has a usecase for it and not just all off them.
 
 
 ## API guidelines
@@ -30,6 +29,8 @@ Some guidelines I try to follow when adding functions to the API.
         * All enums will have an "UNKNOWN" field for the case where a receiver responds with an unknown value. In these cases a warning will be logged. This UNKNOWN mapping is to avoid exceptions when mapping to an Enum which would break the code. Unknown values occur because there is no official documentation available and new receivers might support more/different values.
  * These are guidelines, exceptions can be made.
 
+Note:
+While using attributes to read/write values is pretty neat (and was a nice learning on how to use descriptors) it is a bit weird as you can write a value and it might not have been updated yet when you read it fast enough (sending the command and receiving response takes time). I am not planning to change it any time soon as I do like to just write attributes and not have functions for everything which makes the usage look more messy (IMHO).
 
 ## Input detection
 

docs/PRACTICALITIES.md

@@ -75,7 +75,6 @@ AURO-3D does not seem to be available on RX-1060 and it is unknown how to detect
 
 It is unfortunately unknown if it is possible to derive the 2CHDECODER options from other settings.
 
-
 ## SONG vs TRACK for songtitles
 
 It seems that most sources that support METAINFO for songs use SONG for songtitle.
@@ -93,7 +92,7 @@ There seem to be 2 methods of controlling HDMIOUT status
 
 ### MAIN:HDMIOUT 
 
-This seems to be how older receivers work.
+This seems to be how older receivers work like RX-A810.
 
 MAIN:HDMIOUT is an enum which can have values Off, OUT1, OUT2 and OUT1 + 2. I have only seen it for the MAIN zone, but in theory it could also apply to others
 
@@ -105,16 +104,16 @@ SYS:HDMIOUT# is a boolean that can have values On and Off. This command toggles
 
 This command has been seen for HDMIOUT 1, 2 and 3.
 
-What makes this command a bit weird is while it is part of the SYS subunit it can _only_ be controlled when the related zone is On. So for example you can only control HDMIOUT1 when the MAIN zone is On. See logging in https://github.com/mvdwetering/yamaha_ynca/discussions/119#discussioncomment-6103924
+What makes this command a bit weird is while it is part of the SYS subunit it can _only_ be controlled when the related zone is On. So for example you can only control HDMIOUT1 when the MAIN zone is On. See logging in [this discussion comment ](https://github.com/mvdwetering/yamaha_ynca/discussions/119#discussioncomment-6103924)
 
 That seems workable for HDMIOUT 1 and 2 since those always seem to be related to the MAIN zone, but HDMIOUT3 is special and can be linked with ZONE2 and ZONE4 on an RX-A4A or RX-A6A according to the manual. It is unknown if/how it is possible to figure out to which zone it is configured. Would need logging when changing that setting.
 
 In RX-A6A logging (see logs directory) it seems like both zones (2 and 4) report HDMIOUT3 as a result of requesting BASIC.
 
 ## AUDIO input
 
-Some receivers have 1 audio input and that input is called AUDIO. Receivers with multiple audio inputs have them called AUDIO1, AUDIO2 etc...
+Some receivers have a single audio input and that input is called AUDIO. Receivers with multiple audio inputs have them called AUDIO1, AUDIO2 etc...
 
-Seen on RX-V475 receiver in #230, but probably also applies to RX-V575/HTR-4066/HTR-5066 as they share the same firmware.
+Seen on RX-V475 receiver in [issue #230](https://github.com/mvdwetering/yamaha_ynca/issues/230), but probably also applies to RX-V575/HTR-4066/HTR-5066 as they share the same firmware.
 
 For some reason this input is _not_ reported when requesting the input names with `@SYS:INPNAME=?` (unlike AUDIO1, AUDIO2 inputs). This makes it impossible to automatically detect if the input is supported by the receiver. The receiver does respond with `@RESTRICTED` when requesting `@SYS:INPNAMEAUDIO1=?` or `@SYS:TRIG1INPAUDIO1=?` instead of `@UNDEFINED`. However these responses are currently not really handled by the library and building support for that will be hard as there is not a guarenteed request/response mechanism due to the asynchronous nature of the protocol.

docs/PROTOCOL.md

@@ -1,32 +1,33 @@
 # YNCA Protocol recap
 
-This is a short collection of the basics for the YNCA protocol.
+This is a short intro to the basics for the YNCA protocol.
 The final source of thruth is how the devices actually respond!
 
 Known receivers that support YNCA (there may be more):
-RX-V671, RX-A710, RX-V871, RX-A810, RX-A1010, RX-A2010 and RX-A3010
-
+> HTR-4065, HTR-4071, HTR-6064, RX-A660, RX-A700, RX-A710, RX-A720, RX-A740, RX-A750, RX-A800, RX-A810, RX-A820, RX-A830, RX-A840, RX-A850, RX-A1000, RX-A1010, RX-A1020, RX-A1030, RX-A1040, RX-A2000, RX-A2010, RX-A2020, RX-A2070, RX-A3000, RX-A3010, RX-A3020, RX-A3030, RX-A3070, RX-S600D, RX-V473, RX-V475, RX-V477, RX-V481D, RX-V483, RX-V575, RX-V671, RX-V673, RX-V675, RX-V677, RX-V679, RX-V771, RX-V773, RX-V775, RX-V777, RX-V867, RX-V871, RX-V1067, RX-V1071, RX-V1085, RX-V2067, RX-V2071, RX-V3067, RX-V3071, TSR-700, TSR-7850
 
 ## Description
 
-YNCA is a protocol to control certain Yamaha receivers.
+YNCA is a protocol to control Yamaha receivers.
 The protocol can be transmitted over serial or a TCP/IP socket.
 
 Serial connection parameters: 9600,8,N,1
 TCP port: 50000 (standard, can be customized by user)
 
-There are other protocols for Yamaha receviers like YNC and Musiccast.
-YNCA is simpler, but more limited.
+There are other protocols for Yamaha receivers like YNC and Musiccast.
+YNCA is the simpler one it seems, but more limited.
 
 In YNCA setting a value is referred to as a `PUT` and reading a value as `GET`.
-Both commands have the same format `@SUBUNIT:FUNCTION=VALUE`
+Both have the same format `@SUBUNIT:FUNCTION=VALUE`
 For a `GET` the `VALUE` will always be '?'
 
-The receiver will generate messages when a value changes, when a `GET` command is received or other releted events (e.g. turning on a zone will send multiple messages).
-Note there is no way to tell if a message is because of a `GET` request or the value got changed in another way (e.g. using the remote control or buttons on the device)
-This also means that sending a `PUT` will not always results in a message as messages are usually (not always) only sent when the value changes.
+The receiver will generate messages when a value changes, when a `GET` command is received or other related events (e.g. turning on a zone will send multiple messages).
+There is no way to tell if a message is because of a `GET` request or the value got changed in another way (e.g. using the remote control or buttons on the device)
+This also means that sending a `PUT` will not always result in a message as messages are usually (not always) only sent when the value changes.
+
+The receiver is split up in SUBUNITs, examples are zones (e.g. MAIN, ZONE2), inputs (e.g. TUN for the Tuner) and the system SYS
 
-The receiver is split up in SUBUNITs, examples are zones (e.g. MAIN, ZONE2), inputs (e.g. TUN for the Tuner) and the system 'SYS'
+An easy way to learn about the commands is to connect to the receiver, change some values and observe the value updates coming out.
 
 ## Examples
 
@@ -38,12 +39,12 @@ To get the current volume for subunit `ZONE2` use command `@ZONE2:VOL=?` and the
 
 There are 2 error types.
 
-Note that there seems to be no error response when writing to a GET only function (e.g. setting MODELNAME). In that case there is no response at all.
+Note that there seems to be no error response when writing to a readonly function (e.g. setting MODELNAME). In that case there is no response at all.
 
 ### @RESTRICTED
 
-This response occurs when a valid YNCA command was sent, but the command is (temporarily) not applicable to the unit
-(e.g. setting `VOL` when the unit is in standby or accessing a function not available on the unit like a Zone that does not exist)
+This response occurs when a valid YNCA command was sent, but the command is (temporarily) not applicable to the unit.
+For example setting `VOL` when the unit is in standby or accessing a function not available on the unit like a Zone that does not exist.
 
 ### @UNDEFINED