observation change semantics about aiocoap HOT 2 CLOSED

I'm not sure I get all you are asking (the "if the state changes [...] it will return the observe payload" is unclear to me), but let me try:

First, the state of the resource is not something that is directly accessible in CoAP, you can only query representations. It might help to think of a resource /temp that reflects a sensor's temperature. The temperature itself is practically continuous, and might be subtly different at any two instants you look at it.

A text/plain representation of it might just slowly jump between "cold", "medium" or "hot" (and emit an observation update whenever the respective thresholds are crossed), while a JSON representation might change on every 1/10th of a degree change.

Second, observation does not so much deal with change events, but with eventual consistency. This means that the individual notification does not matter (eg. it's common in CoAP to send notification events as a NON, and only occasionally send a CON to verify that the recipient is still alive), but only that "eventually", some time after the resource has reached a stable state, all observers see that state.

In practice, this means that network congestion can cause event to be dropped, as can proxies that decide you're sending too fast, or (although it's not done) even aiocoap might wait some time after you've declared the resource changed in some circumstances.

Finally, it's still the resource's call to decide when to offer updating a state at all -- for example, it'd be perfectly OK for a clock to always report time to the second, but still on observation only send an update once a minute. One possible way of indicating the client's preferences in that matter is described in draft-ietf-core-dynlink, but in the end, it's up to the resource when to send.

(@ChangSam – pinging you as i can't subscribe you to this question).

from aiocoap.

It appears the question is answered; feel free to reopen if anything was left unclear.

from aiocoap.