fix: clarify PUT use

[sbender9]

No description provided.

[tkurki]

Definitely good changes, let's get this merged.

What do you think of merging the PUT and Request response segments? There's quite a bit of overlap there, no need to keep them separate.

[joelkoz]

I have a question about this as I am working on an automated interior light switch (for my engine room to be exact). Has there been a determination of what device(s) owns the state? For my light switch example, my intuition would tell me that the light switch devices knows if it is on or off. It can report its state obviously. However, when an external PUT request comes in to the server, what happens? Does the sk server simply update its internal model then send out an update to all subscribers? Does the request get forwarded to the device who owns the state, and it is up to the device to acknowledge the PUT, change its state, then report an update via a delta push? In the first example, the sk server owns the state. In the second, the switch does

The easy implementation is for the sk server to update its internal state, and push out that update. If the device that owns it can not accommodate, it could always send a delta to change it back. While that is the easy implementation, in practice it does involve some quick "on/off again" chatter that might affect other automations in the system.

I am actively searching for this answer, which brought me to the specs, and then to this PR. This is a detail that would at least be worth mentioning in this section, even if the answer is "its currently undefined" or "its up to the implementation to define this exact behavior."

[sbender9]

When a PUT requests comes in, it is forwarded to the device/plugin/etc .that publishes the path. It responds per the Request/Reponse specification. The server does not update its internal state at all. The device needs to send out an update delta when the state actually changes.