[bug]: Changed message handling results in error iobroker-community-adapter/iobroker.samsung

[marian-t-web-de]

No existing issues.

• There is no existing issue for my problem.

Description

The analysis is already done in Issue #202
It seems that between js-controller 5.0.19 and 6.0.9 changed message handling results in error in above adapter.

Other changes in iobroker.samsung itself seems not to be a reason that this Adapter using API-Type SamsungHJ breaks the processing after succesfully hanshake, details see above Issue (and its predecessor #201)

There are no resources in iobroker-community-adapters team to analyse errors deep in system so maybe somebody here can help to fix the error.

So far I can I'll help testing it.

Reproduction instruction

Start the iobroker-community-adapter/iobroker.samsung v.0.6.0 using API-Type SamsungHJ and accordingly TV, see into ioB logs.
The processing ends by "Connection to TV initialised", the next message "Successfully connected to your Samsung HJ TV" is not listed any more.
This message and working API is given using iobroker.samsung adapter v.0.5.0 under js-controller 5.0.19.
Under js-controller 6.0.9 is this adapter not working at all and adapter v.0.6.0 not connecting.

JS-controller version

6.0.9

Node version

18.19.0

[mcm1957]

And which changes related to js-controller do you think break the adapter? And if any changes rellated to js-controller do you think are a BUG at hs-controlker?

Opening a issue at js-controller ONLY to note that some Adapter is not working does not make sense. So if no concrete BUG which shiould be fixed at js-controller is noted here this issue should be closed and existing problem with the adapter discussed and eventually fixed using the existing issue at adapter sansung. The hs-controller us NOT Insolvenz in communication between device an adapter.

[Apollon77]

There should be no changes in js-controller that are relevant here because all stuff I saw so far is Websocket or such? Or what exactly is the connection to the js-controller?

[marian-t-web-de]

I can only say that the above Adapter is after update of js-controller no more working. I don't have enough expierience to say if this update cause dependencies in other core modules as websocket as said above. As You can see in '#202' the bug seems to be somewhere in modules handling messages received via websocket and not in the adapter. So I think only one person which is familiar with js-controller, websocket and other 'core' modules is capable to solve this problem.

I hope'd to find him here, in js-controller vicinity.

If you know a better way to solve it, please tell me.

[mcm1957]

I still cannot see any problem with js-controller. Websocket data communication between Adapter an device is not handled by js-controller.

Js-controller 6requires an up to date adapter-core so your several years old samsung-community Adapter release is no longer compatible with js-controller 6. This is no Bug but a documented breaking change. This must be fixed (and is fixed) with samsung 0.6.0 and will not require any changes to js-controller.

Yes it seems that the Support of your devicetype is brocken between the old samsung-community code aka 0.5.0 an current code. But this is covered by issue at samsung Adapter and "only" needs to be investigated by some dev having time and interest to do so.

It"s no core problem as far as I can see.

[marian-t-web-de]

We can discuss only where the bug seems to be or try to solve the problem.
As one can see in '#202' the call after the handshake is the same in Adapter in both versions: 5.0.0 and 6.0.0, but the answer/message in the first will be accepted, in the second not. For the first only js-controller was changed. I don' t see what is in Adapter to do to get the answer via websocket accepted. Do You?

I'm back now. The point where the processing in Adapter 6.0.0 unter js-controller 6.0.9 breaks is by creating 'const handle =' in Module Messages.js

This is result of calling
await remoteHJ.connect()
in main.js module of this Adapter, via:
this.connection = new SamsungTvConnection(...)
in module SamsungTV.js, via
const openSocket = (...)
In module SamsungTvConnection.js. Following call within it:
.then (() => hanshake(config))
is processed correct and receives token (mask: "sAPeeUi-IPSVEU7tAvcd")

All above calls are in both Adapter versions identical (at least till 'return new Promise((resolve...', which is in 6.0.0 changed to 'return new Promise((resolve, reject) try => { ..'; however not relevant because called after the above described processing breaking return).
But the returned message data are different. The matcher() within handle is checking the format of data. '1::' is being accepted and exact this is returned using Adapter 5.0.0. Adapter 6.0.0 unter js-controller 6.0.9 returns data as object ( Buffer 0:49 1:58 2:58 ) therefore the handle is not instantiated and the processing is broken at
return new promise(...)
But to establish the connection the second new promise(resolve=>...) has to be called where also correct handle is needed. It is correct processed in Adapter 5.0.0 unter js-controller 5.0.19.

In my option above confirms that the bug is not in the Adapter itself.

But where the bug is placed stays open. Two important areas were changed:

• js-controller and all belonging dependencies
• iobroker 'utils' adapter

The second results from following change in above Adapter, main.js:

//const utils = require(`${__dirname}/lib/utils`);     // old 5.0.0
const utils = require('@iobroker/adapter-core');    // new 6.0.0

Are the 'utils' 1:1 moved to @ioBroker 'core' or was also necessary to changed them?

There aro no more important changes btw. above Adapter versions - using try/catch to avoid hard interrupts or changes in power-on/off recognition (in main.js) are in my opinion not critical at all ( and used in all working API's not only SamsungHJ)

[marian-t-web-de]

Hello, You can close this issue, see #202
Is were not the changes but one missing change needed, caused by different format of messages receiving from js-controller/webSocket.