[mikelangmayr]

• The keygrabber reads keywords that have no value, because keys.read only filters write-only ones when selecting by pattern and the keygrabber passes explicit names resolved from keys.list, which carried no access information.
• Two symptoms, one cause. A trigger answers a show with {"ok": true, "value": false}, so shutdown is archived as a datapoint that is false forever on every peer at every interval. A setter-only keyword answers with an error, so the inficon's units_code has been failing every read and inflating the keygrabber's readerrors counter with a fault that is not one.
• keys.list now reports writeonly alongside matches, and Collection.resolve subtracts it. matches stays complete, so libby list still shows a trigger.
• No extra requests: the keygrabber already calls keys.list on every resolve. Putting access there fixes it for every client rather than only this one; one keys.describe per keyword would be nineteen extra round trips per refresh on atccryo alone.
• Backward compatible. A peer on an older libby omits the field, nothing is filtered, and behaviour is exactly what it is today until that daemon's libby is reinstalled.
• Tested on both transports, plus the collection filtering and the older-peer case.

[scizen9]

Looks OK, but does it also handle "action" keywords?