"uncaught exception: Cannot convert undefined or null to object" at fronius restart

[mcm1957]

Adapter crashes at restart of fronius system:

2023-06-06 08:55:12.079 - error: fronius.0 (26028) uncaught exception: Cannot convert undefined or null to object
2023-06-06 08:55:12.079 - error: fronius.0 (26028) TypeError: Cannot convert undefined or null to object
  | at hasOwnProperty ()
  | at createStates (/opt/iobroker/node_modules/iobroker.fronius/lib/devObjects.js:474:41)
  | at Timeout._onTimeout (/opt/iobroker/node_modules/iobroker.fronius/lib/devObjects.js:127:17)
  | at listOnTimeout (node:internal/timers:561:11)
  | at processTimers (node:internal/timers:502:7)

An exception stating problems would be OK, a crash must be avoided.

Detail log see comments at forum:

• https://forum.iobroker.net/topic/65948/test-adapter-fronius-2-0-x/12
• https://forum.iobroker.net/topic/65948/test-adapter-fronius-2-0-x/17

[nkleber78]

There i need to think how to handle cases where somewhere in the middle of the process the object is not delivering the expected values. @mcm1957 do you think we should issue an error log or just a warning log for such catched errors?

[mcm1957]

Depends on the situation:

If this is a situation which can occure in normal operation, neither warning nur error is needed. In most cases even no try/catch will be necessary then but a normal if (obj && obj.element ...) or even ... obj?.element... code sequence will do it and either some action will be skipped or processed with a default value.

If the situation is really unexpected (i.e. the fronius reports the voltage of 2 phases but the third phase is missing in response) logging a warning should be ok. This would allow the user to (tempory) change logging to error if the warnings are too often while the overall operation is still ok.

If the adapter need to terminate / restart / drop the connection and reinitialize itself or cannot do any useful operation an erro will be OK.

There i need to think how to handle cases where somewhere in the middle of the process the object is not delivering the expected values.

If you have the situation where the system sends an answerblock but some data is missing you could evaluate whether ist acceptable to simple set the states to null (and optionally set a siutable q flag) indicating "well - fronius did not send currentz power value ...")

[nkleber78]

Part of Release 2.0.2