Monatsrückblick Januar/Februar 2026 ist online!

[marian.t]

Hallo,
das Thema beschäftigt mich schon länger und habe auch andere Foren studiert. Aber der Reihe nach:

• Pairing ist durch das TV-Modell bestimmt (lt. Samsung-Foren), die API's müssen dem folgen. Dazu muss man die Funktion des npm Moduls 'encoding' nicht auswendig kennen; auffällig ist auch das die Scripts im Ordner /Encryption nur bei H-and-J-Series-lib vorkommen (siehe Github)
• die Initialisierung startet bei PIN 0 - aber nur manchmal. Ich kenne keine Möglichkeit es zu erzwingen. Mir reicht die Bestätigung im Debugger-Log dass die PIN bestätigt wurde. Der TV kann die Adapter 0.5.0 und 0.6.0 nicht unterscheiden, beide laufen mit gleichem PIN. Die TV-IP ist fix.

Ich habe die letzte Stunden die Abläufe der beiden Versionen per node inspect debuggt (bei der iOb Inst. mit js-contr. 5.0.19 weil dort beide Adapt. lauffähig sind) und festgestellt, dass die obige Exception und Meldung mit "encoding" (sowie weitere) bei beiden Versionen des Adapters vorkommen und es scheint nicht zu stören.
Weiterhin ist der Ablauf bis zur ''Connection established' weitgehend identisch (gem. Log in RPi, ist ausführlicher als iOb/Debugger log):

Confirming pin nnn
Step 1: Saying hello to the server
Generated serverHello 
...
hello verified
Step 2: Acknowledging
generatedServerAcknowledge: 
...
client ack true
identity { sessionId: '1', aesKey: 'nnnn' }
PIN confirmation succeeded. Identity:  { s.o. }
Handshake: nnnnnnnnnnnn
Opening new websocket
Connection established

Dann endet das neue Adapter 0.6.0 mit folgenden zwei Meldungen

unknown message received: 1::
unknown message received: 2::

Es wird an dieser Stelle kein Exception ausgelöst (die fängt der Debugger ab), der Ablauf endet hier (es gibt dann keine "Play" Taste in Deb.)

In der v.0.5.0 läuft es ab dem Punkt 'Connection established' anders:

SOCKET MESSAGE:  1::/com.samsung.companion
buildEmitMessage: registerPush, payload: {"body":"[173,190,181,208,161,57,189,141,18,69,51,178,238,118,210,234,32,153,15,16,163,99,213,252,192,168,105,194,208,91,149,255,152,129,46,34,51,83,16,30,208,138,114,242,167,7,18,105]","Session_Id":5}
buildEmitMessage: registerPush, payload: {"body":"[173,190,181,208,161,57,189,141,18,69,51,178,238,118,210,234,214,244,146,219,231,87,118,137,54,127,199,74,223,64,134,65,118,111,196,188,105,171,247,237,31,148,177,174,251,84,57,69]","Session_Id":5}
buildEmitMessage: callCommon, payload: {"body":"[63,209,125,153,163,238,224,22,239,218,39,5,7,58,137,35,235,72,92,226,74,182,204,32,110,218,39,121,253,25,160,55,98,47,108,230,250,134,150,182,108,104,128,188,183,152,191,134,1,182,23,231,195,171,72,43,135,149,83,96,183,199,125,202,202,219,227,176,209,18,2,190,9,120,205,79,91,37,112,76]","Session_Id":5}
unknown message received: 1::/com.samsung.companion
(node:20986) [INSPECTOR_ASYNC_STACK_TRACES_NOT_AVAILABLE] Warning: Warning: Async stack traces in debugger are not available on 32bit platforms. The feature is disabled.
keep-alive: 2::
SOCKET MESSAGE:  5::/com.samsung.companion:
Handle Event: receiveCommon
receiveCommon: [58,12,177,192,188,146,212,231,215,3,151,133,140,111,56,92,222,141,134,241,89,164,2,176,109,157,137,107,221,223,161,123,63,62,65,70,40,30,254,163,90,132,199,48,158,184,248,62,144,47,130,123,111,165,122,160,51,30,246,85,212,85,25,46]
decrypted:  { plugin: 'NNavi', api: 'GetDUID', result: 'H3CJ6OTEDSPFQ' }
GetDUID: H3CJ6OTEDSPFQ: GetDUID
2024-08-21 14:14:08.330  - info: samsung-community.0 (20986) Successfully connected to your Samsung HJ TV
keep-alive: 2::
keep-alive: 2::

Wieso die Meldung

unknown message received: 1::/com.samsung.companion

bei dem alten (0.5.0) Adapter nicht stört, kann ich nicht beurteilen - ist es das Teil ab /com.??
Irgendwas fehlt in der neuen Version was in der Alten zu - intern - 'buildEmitMessage' und 'receive common' und - extern - (Erfolgs-)Meldung 'Successfully connected' führt.

Fazit: ich denke wir brauchen uns nicht mit Initialisierung/PIN/API-Version zu beschäftigen, beide Adapter bestätigen die PIN und laufen ja bis 'Connection established'.

Ich bräuchte aber weiterhin eine Unterstützung wie ich den Fehler einzugrenzen könnte (z.B. wie ich die Module erfolgreich debuggen kann) und dann dabei wie es zu korrigieren ist.

[mcm1957]

@apollon77
FYI falls du den Adapter Samsung im Mode HJ kennst ev ne Idee hast.

Ich steig da mal aus. Mangels Gerät kann ich da nichts mehr effizient beitragen

@marian-t
Düa du je eh mittels node Aufruf Dinge ermittelt schau dir halt den Source an u schau was such zwischen der alten Version aus 2021 u jetzt geändert hat. In GitHub sind alle Änderungen bachvollziehbar.

[marian.t]

@mcm1957
Auf jeden Fall danke.
Coding habe ich schon versucht zu vergleichen. Gerade die v5.0.10 brachte bez. Messagehändling einige Änderungen in lib/H-and-J-Series-lib/Connection/SamsungTvConnection.js.

Da ich dauernd erfahre dass kein HJ Gerät zur Verfügung steht, kann es sein dass es ungetestet ausgeliefert wurde?

Ich habe ein passendes Gerät und über 30 Jahre Erfahrung in der IT - leider weder mit node.js noch mit Javascript. Deswegen stelle es mir vor, dass es nur in einer Zusammenarbeit mit jemandem der entsprechende Kenntnisse mitbringt, funktionieren kann.

[Feuersturm]

@marian-t sagte in Samsung Adapter veraltet:

Da ich dauernd erfahre dass kein HJ Gerät zur Verfügung steht, kann es sein dass es ungetestet ausgeliefert wurde?

Bei einem Release von einem Adapter werden nicht sämtliche Kombinatoriken durchgetestet. Der Adapter ist eine zeitlang im Beta Repository verfügbar und wenn nach einiger Zeit + Installationen keine Auffälligkeiten vorhanden sind, geht die Version ins stable Repository.

[marian.t]

Falls es noch jemand interessiert - @apollon77 ? - habe ich weitere Erkenntnisse in issue #202 verfasst.

[mcm1957]

Es gibt nun eine neue Testversion des Adapters ioBroker.samsung - v0.6.1

DANKE an @marian.t für die Fehlersuche und den PR mit fix.

Zum Tester Topic gehts hier:

https://forum.iobroker.net/topic/77147/test-adapter-samsung-0-6-x

@Homoran
Bite hier schließen um parallele Threads zu vermeiden.