'Registration' messages have a strange or incorrect timetag (and contain old data)



  • Most of the time time the messages I receive are in the standard ‘reports’ format as described in the docs. Occasionally however I get messages in the more extended ‘registrations’ format. (I already mentioned that here: https://forum.iotcreators.com/topic/524/different-json-messages-from-the-t-mobile-server?_=1608714233162)
    These messages are supposed to be sent only for the first time a station sends data, or after it has been offline for a longer time. Even though all my stations send data every 15 minutes, I get these messages quite often. Now I noticed that the timetag in these messages is always off. I log all incoming messages, and all standard reports have a timetag that is right on , or very close to the time the message is received. The ‘registration’ messages however are always 30 to 40 minutes off.
    Also it seems that since a few weeks the data that is contained within these messages seems just old data (sometimes even 2 to 3 weeks old), something that I had not experience before. Anyone knows what is going on here ?


  • Deutsche Telekom IoT

    @Cees-Meijer

    could you please send me an example of such a message and the timestamp that you received this message?

    You can send it via PM of via email



  • @afzal_m Okay. I just sent you some sample records.


  • Deutsche Telekom IoT

    Thanks, just saw it!
    Just to be sure: so it’s not only about this gap of 30 or 40 minutes, right? Sometimes these payloads are from 2/3 weeks ago. Is my understanding correct?



  • @afzal_m Yes, it looks like it is old data in the packet.


  • Deutsche Telekom IoT

    This is due to agentlifecycle queue being processed too slow, so the lifecycle event (registration) is sent with a delay.

    We already prepared a fix for this. Next week we are going to test the fix on our staging environment! 🙂



  • @afzal_m I have just checked all my logs from January 1, and have not found a single ‘registration message’. Seems like the problem is solved. Thanks.