I am new to TTN and have this issue with a sensor I want to use with domoticz.
I have a Browan Sensor TBHH100 that sends every 24h an uplink message with a FPort = 103 and no data in the FRMPayload.
The Repository provided payload formatter generates a decoded payload nevertheless, which results in meaningless values:
"decoded_payload": {
"battery": 2.5,
"humidity": 0,
"status": 0,
"temperature": -32
},
This gives negative spikes in the values in Domoticz because it only considers the decoded_payload, which has valid values although meaningless.
Other uplink messages from this sensor are correct btw.
According to the documentation the FRMPayload is 0-N bytes and contains application data if the FPort is between 1 and 223.
After reading this I wonder if it is allowed to have no application data when using a FPort between 1 and 223.
Besides it is not clear why it would send it in the first place, but that is something I would have to sort out with the vendor I guess.
Is this something TTN intended to be handled by the application?
For now I changed the Repository provided payload formatter to return an errors object if the length of the application data is less than the required number of bytes it expects. (however this results in some warnings in the domoticz logs)
Another solution I tested is modifying the domoticz hardware module handling the TTN to ignore the uplinkMessage if the FRM_Payload does not exist in the MQTT message.
Since the latter is for my use case specifically, I do not know what the consequences are for other devices.
I want to know if we can safely ignore the uplinkMessage in Domoticz if the FRM_Payload does not exist, or that we should solve it using the payload formatter for the end device.
Thanks.