UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[marian.t]

Ich habe nur den einen TV mit Iobroker Adapter verbunden und der hatte mit samsung-community Adapter v.0.5.0 und API SamsungHJ letzte Woche noch funktioniert.
Nichts Böses denkend habe ich auf js-controller upgedated und dann ging nichts mehr - daher die #201/#202 issues.
Pairing ist bei diesem TV verschlüsselt, dass würde sich mit dem Error aus inspect-debugging "Error: Cannot find module 'encoding' " decken.

Ansonsten habe ich gerade ale vier API's ausprobiert, nur die 'SamsungHJ' führt zur "Connection to TV initialised" Meldung.
Mache Schluss für heute.

[Thomas Braun]

@mcm1957

Meldung für die Galerie/Statistik:
Bei mir läuft sowhl der samsung wie der samsung-tizen Adapter. Eben noch nochmal getestet.
nodejs 22 und auch sonst 'bleeding edge' unterwegs.

[mcm1957]

@marian-t said in Samsung Adapter veraltet:

Ansonsten habe ich gerade ale vier API's ausprobiert, nur die 'SamsungHJ' führt zur "Connection to TV initialised" Meldung.

Das ist klar. Der Log ist nur in diesem Submodul enthalten. :-) und wird bei anderen Apis nicht ausgegeben.

[mcm1957]

@marian-t said in Samsung Adapter veraltet:

Ich habe nur den einen TV mit Iobroker Adapter verbunden und der hatte mit samsung-community Adapter v.0.5.0 und API SamsungHJ letzte Woche noch funktioniert.

Nur leider ist der samsung-community bzw. die version des amsung 0.5.0 seit Jahren veraltet gewesen. Krgendwann gehen Museumsversionen nicht mehr wie du eben festgestellt hast.

Pairing ist bei diesem TV verschlüsselt, dass würde sich mit dem Error aus inspect-debugging "Error: Cannot find module 'encoding' " decken.

Darf ich fragen was dich zu dieser Aussage veranlasst? Kennst du die Funktion des npm Moduls 'encoding'? :-)

Siehe https://www.npmjs.com/package/encoding
'encoding is a simple wrapper around iconv-lite to convert strings from one encoding to another.'

Der Modul dient dazu TEXT Codierungen zu konvertieren - hat also zu 100% nichts mit einer Verschlüsselung zu tun ...

Hast du schon mal die ganze initialisierung durchgespielt? Irgendwie wird ja bei diesem Api das Gerät gepaired. Und das muss natürlich nach der Neuinstallation komplett neu durchgeführt werden.

Siehe README:
Samsung HJ - 2014 and 2015 After first connect you need to enter the Pin shown on your TV.

Wenn ich das richtig im Code lese muss

• der Adapter OHNE pin gestartet werden
• dann wird am Fernseher ein PIN angezeigt
• dieser Pin muss in der Adapter Config eingetragen werden
• und der Adapter neu gestartet werden

Hast du diese Sequenz nach der letzten Installation gemacht?
Kann es sein dass dazu am TV irgendwas initialisiert / eingestellt werden muss?

Oder hast du den Pin eingegeben der bisher im Adapter eingetragen war? Je nachdem was bei der Erstellung des Pins vom TV beachtet wird, kann es sein dass der PIN auf eienr anderen IP ev nicht passt.

[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.