I think we’re in agreement; Losant isn’t accepting the packets, it’s just indicating that it got a packet that was rejected in the Application Log window. The malformed packet data isn’t actually making its way into the device’s data history. It’s possible the connection is being closed by the Losant end when it sees malformed packets; I haven’t yet investigated the socket behavior we’re seeing when the corrupted packet is transmitted.
I would copy the exact error message into this thread, but it’s pretty device-specific and I didn’t want to reveal product information.
So, it’s not an issue of us seeing incorrect data being displayed as if it was correct data. The issue is providing an indication to our transmitting device that a particular MQTT packet was rejected.
I’m not familiar with how MQTT acknowledgement works (I’ve just jumped into this project), so I’ll probably start looking there in our device firmware. It sounds like detecting a missing ACK or a NACK from the server would be sufficient to treat a transmission as failed, and queue it for retry. At least this would catch issues like a corrupt device ID or topic, even if it may not catch a corrupted data-field value, right?
Edit: To address a couple more of your points,
- I agree with what you’re saying about TCP; it should handle any transmit errors between our modem and your server, so the issue is likely not at that point
- I suspect the error is between our MCU and modem, but I’d like to be able to catch this error at the server-response level if somehow the MCU->modem transmit fails. We’re currently working on debugging and validating the MCU->modem payload transmission to catch any transmit errors at that stage as well.