Packets with empty payload not published to Webhook or MQTT

[jpmeijers]

Summary

If a device sends an uplink message (packet) with no payload data, the message is received by TTN and shown on the console

(Three messages shown here)

The same message is not being received on MQTT and also not on the Webhook integration. These packets have metadata that is valuable. Having to add a byte payload just to get a network "ping" to be forwarded to MQTT/Webhook is a wast of airtime.

Steps to Reproduce

1. Register and set up a device to send LoRaWAN packets with empty payloads.
2. Look at the console and see packets being received.
3. Subscribe to MQTT and see that nothing is received.

What do you see now?

Packets aren't being received via MQTT or Webhook.

What do you want to see instead?

Pacekts without payloads should be published on MQTT and Webhooks.

Environment

TTN v3.11.1

How do you propose to implement this?

Don't drop packets with an empty payload.

How do you propose to test this?

Same way we reproduce this issue.

Can you do this yourself and submit a Pull Request?

No

[cstratton]

Unless I'm mistaken, that traffic is on port 0 which is reserved for network-level housekeeping; if such housekeeping should be reported to an application feed is an interesting design question, but I suspect that's what is at issue.

Application traffic must use a port in the range of 1..223 so you might try sending your empty packet with a legal fPort

Additionally the 4/5 coding typically makes it such that with foptslen 0, adding a payload byte actually doesn't increase the airtime, since it doesn't yet require adding another coding group.

[jpmeijers]

Ahh ok, I see now that those packets are sent on port 0, incorrectly. It's a bug in the LoRaWAN library I use (https://github.com/GrumpyOldPizza/ArduinoCore-stm32l0/blob/master/libraries/LoRaWAN).

For interest sake on V2 MQTT I do receive these empty payload messages on port 0: jpm_crickets/devices/cricket_001/up {"app_id":"jpm_crickets","dev_id":"cricket_001","hardware_serial":"00E150E95369A0B0","port":0,"counter":34,"payload_raw":null,"metadata":{"time":"2021-03-03T06:48:22.480656651Z","frequency":868.3,"modulation":"LORA","data_rate":"SF7BW125","airtime":41216000,"coding_rate":"4/5","gateways":[{"gtw_id":"eui-60c5a8fffe71a964","timestamp":3339004220,"time":"","channel":6,"rssi":-79,"snr":9,"rf_chain":0,"latitude":34,"longitude":19,"altitude":1000},{"gtw_id":"eui-647fdafffe00b497","timestamp":515868203,"time":"","channel":1,"rssi":-30,"snr":9,"rf_chain":0},{"gtw_id":"eui-0080000000013e5b","timestamp":3552573203,"time":"2021-03-03T06:48:22.181691884Z","channel":0,"rssi":-19,"snr":9.25,"rf_chain":0},{"gtw_id":"eui-60c5a8fffe761551","timestamp":532555084,"time":"","channel":6,"rssi":-23,"snr":8.5,"rf_chain":0},{"gtw_id":"eui-647fdafffe007a1f","timestamp":2408843499,"time":"","channel":1,"rssi":-27,"snr":8.8,"rf_chain":0}]}}

I will try to either fix this bug, or find another device to test empty payloads with to be sure how V3 behaves. The important thing is there are beacons out in the field that follows best practices and keeps their payloads small/empty, and we can't break compatibility on V3.

[jpmeijers]

I've just tested on v3.11.3 (TTN).

The empty payload uplinks are now forwarded on MQTT, even though the port is 0.

This solves my original issue.