I see that also sporadically happen with the Softing C++ Server:

Expected a dataChange for written a value of '44'. The item was previously modified with a DeadbandPercent of 0, so the
value should have been returned.

Okay I think I know the reason why this fails sproadically.

Read( NodesToRead #1; TimestampsToReturn: 2; MaxAge: 0 ).Response.ResponseHeader.ServiceResult: Good (0x00000000) as expected.
GetEURange determined:
Lo = 0
Hi = 100
Generating 4 values for deadband testing. Values to pass deadband filtering?true. Range is: 0 to 100, percentage being tested: 10
Values to Pass deadband filtering based on starting number '0' are:
11,22,33,44
Generating 3 values for deadband testing. Values to pass deadband filtering?false. Range is: 0 to 100, percentage being tested: 10
Min bound number = 34; Max bound number = 54
Values to Fail deadband filtering based on starting number '44' are:
44,50,51

First a few Items are written that guarantee to exceed the 10% deadband.
11,22,33,44, and then
3 random values are chosen, that do not exceed the deadband.
for instance 44,50,51
The test case always fails then the first random value is exactly 44.
When it is any other value it passes.

That happens, because
after the 51 is written, and the last keep alive received,
the deadband is changed to 0% and 44 is again written, but that
is the last published value.
Therefore the server does not publish 44 again.

Test can be fixed by the following patch:

--- library/NodeTypeBased/AnalogItemType/EURange.js 2018-11-06 18:09:42.000000000 +0100
+++ library/NodeTypeBased/AnalogItemType/EURange.js 2018-11-15 11:55:27.903400565 +0100
@@ -137,7 +137,7 @@
}
// add whatever has been generated to the array, providing it is not a duplicate
// of the last value written.

• if( currentValue != results[ results.length - 1] ) {
• if( currentValue != (results.length > 0 ? results[ results.length - 1] : startingNumber) ) {
  // is the number a decimal and if so restrict to 1 decimal place
  if( currentValue.toString().indexOf( "." ) > 0 ) {
  currentValue = Number( currentValue);

Interesting, why accessing results[-1] did cause a script error.

I mean, why accessing results[-1] did not cause a script error.

Thanks Bernd for the detailed investigation. I came to the same conclusion and therefore fixed the script accordingly.

reviewed in CMP call