<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://devzone.nordicsemi.com/cfs-file/__key/system/syndication/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Client stops after 6:25 hours...</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/71001/client-stops-after-6-25-hours</link><description>Hi there! 
 I&amp;#39;m currently facing an issue where the client will stop transmitting messages after six hours and twenty-five minutes. This is the case after 255 messages have been sent. These messages are part of a custom model that&amp;#39;s based on the Simple</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Thu, 11 Feb 2021 10:22:13 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/71001/client-stops-after-6-25-hours" /><item><title>RE: Client stops after 6:25 hours...</title><link>https://devzone.nordicsemi.com/thread/293928?ContentTypeID=1</link><pubDate>Thu, 11 Feb 2021 10:22:13 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:7ddb1d44-c255-4487-a914-11bafecf5307</guid><dc:creator>tesc</dc:creator><description>&lt;p&gt;Hi,&lt;/p&gt;
&lt;p&gt;Thank you for the update. You can of course use the time that you need. Feel free to continue the discussion if you find anything in your debugging, or have new related questions.&lt;/p&gt;
&lt;p&gt;Regards,&lt;br /&gt;Terje&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Client stops after 6:25 hours...</title><link>https://devzone.nordicsemi.com/thread/293803?ContentTypeID=1</link><pubDate>Wed, 10 Feb 2021 14:32:42 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:56a7e804-f68b-4e27-afaf-e446f27430da</guid><dc:creator>JVKran</dc:creator><description>&lt;p&gt;Hi Tesc,&amp;nbsp;&lt;/p&gt;
&lt;p&gt;Sorry for the delay. Thanks for letting this know. I made a reasoning mistake regarding the tid&amp;#39;s. The application doesn&amp;#39;t do anything with the tid&amp;#39;s. I assumed they were neccesary for the model to operate.&lt;/p&gt;
&lt;p&gt;Okay, so, I&amp;#39;ve got some debugging to do ;). Thanks anyway!&lt;/p&gt;
&lt;p&gt;Kind regards,&lt;/p&gt;
&lt;p&gt;Jochem&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Client stops after 6:25 hours...</title><link>https://devzone.nordicsemi.com/thread/291842?ContentTypeID=1</link><pubDate>Thu, 28 Jan 2021 15:17:42 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:1a3e8131-9c16-4682-8b28-ed51d3823651</guid><dc:creator>tesc</dc:creator><description>&lt;p&gt;Hi,&lt;/p&gt;
&lt;p&gt;Setting the field manually to 0 when it is about to overflow should have the same effect of letting it overflow, so both working the same is as expected.&lt;/p&gt;
&lt;p&gt;I have not found anything in the simple on/off model that indicates that an overflowing tid field there should cause any issues. I did not find any check of that field on the server side, similar to the model_tid_validate() function used by the generic on/off model and others. The field is on the application level, and so the implementation for checking it is up to the application. I would start by checking how the application handles the field, in both ends.&lt;/p&gt;
&lt;p&gt;Regards,&lt;br /&gt;Terje&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>