--- old
+++ new
@@ -1,10 +1,9 @@
-PublishInterval / PublishRate is default set to 5000ms.
+PublishInterval / PublishRate is default set to 5000 ms.
 This means we cannot publish "updates" any faster then each 5000 ms.

 How should we implement this?

-1) some form of delay which acts as a NDATA/DDATA buffer?
-For this to work we have to prevent NDATA/DDATA data to get sent immediately on-change and "buffer" theses changes into the encoding list until the PublishInterval expires. If the interval expired we can encode/send the blob which contains all changes from/during the last interval period.
+1) For this to work we have to prevent NDATA or DDATA data to get sent immediately on-change and "buffer" all incoming changes into the encoding list until the PublishInterval expires. If the interval expires we can encode the list into a blob which contains all changes from/during the last interval period and send it.

 2) Some readily available mechanism via the MQTT Publisher? (haven't looked for it, but cannot remember its there either)

--- old
+++ new
@@ -1,13 +1,7 @@
 PublishInterval / PublishRate is default set to 5000 ms.
 This means we cannot publish "updates" any faster then each 5000 ms.

-How should we implement this?
+After some debate we decided on the following mechanism:

-1) For this to work we have to prevent NDATA or DDATA data to get sent immediately on-change and "buffer" all incoming changes into the encoding list until the PublishInterval expires. If the interval expires we can encode the list into a blob which contains all changes from/during the last interval period and send it.
-
-2) Some readily available mechanism via the MQTT Publisher? (haven't looked for it, but cannot remember its there either)
-
-3) Some other mechanism?
-
-I think 1 is the most likely candidate unless someone has a better/other idea offcourse!
-
+We have a timer, it sets itself as soon as we have sent data and after T#PublishInterval it resets itself. If new data is detected during timer countdown, we "buffer" it. 
+If the timer has expired we can send data immediately and the timer sets itself again after this action. So, the timer "blocks" sending of data during countdown.

--- old
+++ new
@@ -1,7 +1,10 @@
 PublishInterval / PublishRate is default set to 5000 ms.
-This means we cannot publish "updates" any faster then each 5000 ms.
+So we cannot publish "updates" any faster then each 5s.

-After some debate we decided on the following mechanism:
+This means the publish rate is a kind of sample rate per signal change so 5000 means 1 change per interval of 5 seconds.

-We have a timer, it sets itself as soon as we have sent data and after T#PublishInterval it resets itself. If new data is detected during timer countdown, we "buffer" it. 
-If the timer has expired we can send data immediately and the timer sets itself again after this action. So, the timer "blocks" sending of data during countdown.
+100 means a signal change per 100mec.
+10000 means a signal change per 10 seconds.
+
+Solution
+We have a pulse timer (or some other means to detect a time interval), it sets itself as soon as we have sent data and after T#PublishInterval it resets itself. If new data is detected during timer countdown we ignore it. If the timer has expired we can send data immediately and the timer sets itself again after this action. So, the timer "blocks" sending of data during countdown.

--- old
+++ new
@@ -1,10 +1,11 @@
+# Publish interval Definition
 PublishInterval / PublishRate is default set to 5000 ms.
 So we cannot publish "updates" any faster then each 5s.

-This means the publish rate is a kind of sample rate per signal change so 5000 means 1 change per interval of 5 seconds.
+This means the publish rate is a kind of "sample-rate" per signal change:
+* 5000 means 1 signal change per interval of 5 seconds is sent,
+* 100 means 1 signal change per interval of 100mec is sent,
+* 10000 means 1 signal change per interval of 10 seconds is sent.

-100 means a signal change per 100mec.
-10000 means a signal change per 10 seconds.
-
-Solution
+# Solution
 We have a pulse timer (or some other means to detect a time interval), it sets itself as soon as we have sent data and after T#PublishInterval it resets itself. If new data is detected during timer countdown we ignore it. If the timer has expired we can send data immediately and the timer sets itself again after this action. So, the timer "blocks" sending of data during countdown.

--- old
+++ new
@@ -3,6 +3,7 @@
 So we cannot publish "updates" any faster then each 5s.

 This means the publish rate is a kind of "sample-rate" per signal change:
+
 * 5000 means 1 signal change per interval of 5 seconds is sent,
 * 100 means 1 signal change per interval of 100mec is sent,
 * 10000 means 1 signal change per interval of 10 seconds is sent.