I get the difference between the read and write. You define which attribute ID (at) from which cluster ID (cl) to read the state from. But where does the “parse” come into play? It’s also got an cid/aid address, so it seems it is called seperately from the read or write?
The first implementation in fact had read/parse kind of combined but that reduced flexibility, as for some weird devices these two can be different and there are many devices which don’t support reading at all and the only thing we can do is parsing.
Another thing that it allows us is to have one item using read (and optional parse) but having the same incoming message processed by other items parse handlers. This works since all parse handlers are feedet with the message and this intentionally isn’t stopped after the first one processed a message. Here again this is done do gain a bit of flexibility.
Endpoint - Guess this is referred to as “ep” in the file? I see some DDF files using endpoint 1 and some using endpoint 2. Also 0 is seen - is this the value for “auto”
That’s right, 0 means the endpoint of the surrounding sub device will be used as convenience.
For example if a sub device has the following uuid set "uuid": [ "$address.ext", "0x02", "0xfc00"] the endpoint 0x02 will be used.
Currently I tend to use the exact endpoint as given by the device to speed things up a bit (albeit once extracted the auto endpoint is cached).
For “parse” there is also special endpoint 255, which means don’t care from which src endpoint an incoming message is received.
Does the endpoint reffer to different endpoint on the physical device or different logical endpoints as seen by clients on top of deConz?
It’s the endpoint of the physical device to which the related clusters belong. Note we also have a few devices which are representing one sub-device which grabs data from multiple endpoints, due the above mechanism this can be done on a per item base.
The bindings are to me the biggest mystery. I believe I read somewhere that bindings are required for the device to work. Not in my experience - I only have a very simple read operation from 1 attribute though.
Yes they can be tricky, there are many devices out there which don’t need any extra bindings in order to work, but also as much which won’t do anything without bindings 
For lights for example often polling via read/parse works but is slower as the combination of read/parse + a binding with reporting configuration. But for this reporting needs to be supported by the light, Philips Hue lights for example don’t support reporting and can only be polled.
Bindings seems to be reporting values to and from endpoints. Either to one or multiple endpoint. Should all values that are going to be exposed from a logical device on deconz, be in a binding to actually be seen by clients?
Similar to previous answer this depends a bit on the specific device. For sensors we often use unicast bindings to the gateway, for example to show battery or temperature values. For switches, if supported, we create group bindings if the switch doesn’t send commands out of the box.
For many devices is difficult to figure this out without a sniffer or studying the logs, there will be more GUI support for this in future to show more user friendly details about sending/receiving commands.
Hope this helps a bit
