Adapter terminating with uncaught exception

[ExecuteGK]

Adapter terminates with the following log entry:

RangeError [ERR_OUT_OF_RANGE]: The value of "value" is out of range. It must be >= 0 and <= 4294967295. Received -4034 at checkInt (internal/buffer.js:63:11) at writeU_Int32LE (internal/buffer.js:683:3) at Buffer.writeUInt32LE (internal/buffer.js:696:10) at E3dcRscp.addTagtoFrame (/opt/iobroker/node_modules/iobroker.e3dc-rscp/main.js:585:11) at E3dcRscp.queueSetValue (/opt/iobroker/node_modules/iobroker.e3dc-rscp/main.js:917:9) at E3dcRscp.onStateChange (/opt/iobroker/node_modules/iobroker.e3dc-rscp/main.js:1749:11) at E3dcRscp.emit (events.js:310:20) at Immediate._onImmediate (/opt/iobroker/node_modules/@iobroker/js-controller-adapter/build/lib/adapter/adapter.js:5379:53) at processImmediate (internal/timers.js:456:21)

Proper error handling should be introduced in order to ignore illegal values and keep the adapter running.

Regards,

Sebastian

[git-kick]

@ExecuteGK thank you for the bug report.
Please provide the adapter version, so I can match the source code line numbers.
(Best practice is to use the Bug Report template for reporting problems.)

[ExecuteGK]

Hi,

the version is 1.0.1.
Issue was caused by writing a wrong value into one of the objects. Although the javascript doing that has been fixed, the adapter should perform input validation at least for any external provided data. Best practice is to verify the input and return a save default value in case the input is out of bounds.

[git-kick]

Okay @ExecuteGK ,
I understand you can reproduce the issue.
Would you please provide the steps, i.e. the object, the value entered.

[ExecuteGK]

On my instance, it was: e3dc-rscp.0.EMS.MAX_DISCHARGE_POWER

It should be an easy fix. Default value could be 0 in case a negative value is dropped in here.

Regards,

Sebastian

[git-kick]

Will be fixed in v1.0.3
You can preview it now in the master branch

Like suggested above, out-of-range values are silently replaced by 0 (or "" in case of strings).
This "correction" is not visible in the object tree unless the response from E3/DC was processed, but I consider this acceptable in case of invalid input.
(For a "clean" solution we would need a state-specific handling, which I think is not worth of.)