Does the network server retransmit the confirmed downlink message in case the message was not received by the end device, or is the duty of MQTT application to do the retransmission of the confirmed downlink message?
When does …/down/nack get triggered or what is the difference between …/down/ack and …/down/nack?
I guess the topic …/down/failed is called when the downlink message fails? If so, what are possible failures that could lead the application server to publish on this topic?
v3 message key field jsonpaths: <ttn device id> = .end_device_ids.device_id <ttn app id> = .end_device_ids.application_ids.application_id (not including the <at symbol>ttn in the topic) <payload> = .uplink_message.frm_payload
Presumably these fundamental changes must be documented somewhere, and when I find that I’ll post it here (or anyone else?). Maybe I’ve misunderstood things and there’s no real ‘migration’ but it’s a “new network” so just read the docs and rebuild for it.
well… take something as fundamental as the name of the field containing the uplink data from your sensor. That changes from “payload_raw” in V2 to something else in V3.
A “migration document” (as opposed to “system documentation”) would mention that somewhere, so that’s the link I’m looking for.