NEWS
Test Adapter Samsung Smartthings v.0.0.x
-
dieser adapter ist absolut unbrauchbar.
ein test eben mit 2 geräten in smartthings (2x klima) und ein i5 geht von 1.5% auf 5-30% CPU USAGE hoch (Debian12) und das dauerhaft! PI legt der adapter ganz lahm und die ioB FB Gruppe beschreibt auch das nicht nutzbar da er zuviel CPU frisst. teils 50%..
auch fügt er die 2 millionen datenpunkte gar nicht zusammen. alles zig fach in 50 ordnern. pro gerät! status-gerade, user, samsung, was man setzen könnte, sonst noch 28 versionen.. da ließt man ja hier das alleine die 5.000 neuen datenpunkte schon systeme lahmlegen.. wozu ist denn das gut? wer braucht diese infos?
ein blockly könnte diese DPs zusammenfügen und 1x was zum steuern und status in einem schaffen.. wie bei allen adaptern ja üblich. wieso ist das denn nicht im adapter intergriert???
ist der adapter TOD und wird nicht mehr weiterentwickelt?
so kann das ding doch niemand nutzen?! sinnfrei..ich gehe gerade dem umweg per szenen in smartthings->alexa->alexa2-Adapter wo man diese szenen/routinen antriggern kann... 0% cpu usage dafür und man hat zumindestens eine fernbediennung in eine richtung per ioB.. status abfragen geht so aber natürlich nicht.
andere mit ioB installieren sich nur dafür HA mit smartthings adapter und ioB gateway dazu... die lösung per homekit und dort plugin für samsung-klimas geht wohl seit 2023 gar nicht mehr..
schade das ganze denn der smartthing adapter läuft ja ansich. poolt alle 10s hier aber auch bei nur alle 60s verbraucht der so unnötig viel CPU.. und erstellt dann aber gar keine ordentlcihen datenpunkte und bis man da sin blockly/JS wiede rzusammengefrimmelt hat kann man ja fast gleich nem neuen adapter schreiben...
ps: 60min adapter test: cpu usage von 1,5 auf 7% hoch auf nem i5 der eigentlich pennt als server.. so soll es aber auch bleiben. kein adapter darf hier spürbar auch nur 1% cpu usage klauen sonst fliegt er! denn tut er das läuft da was schief und schlampig programmiert worden.. niemand braucht bei sowas updates 2817x die sekunde... poolen, alle 10s einloggen, daten saugen, aufbereiten, und ggf. sofort senden. fertig. das muss auch mit 0.1% cpu auf nem i5 laufen! wieso auch nicht?
würde bei samsung die web-api bei den klimageräten noch gehen wären das paar blocklys mit axios/http-requests und fertig. selbst diese "uralt weg" verbraucht weit weniger cpu als der smartthings-adapter jetzt gerade....... aber der ist ja anscheinend global für alles in smartthings. das ist schon nett für alle...
an alle die das hier (wie ich) finden da sie support für ihre klimaanlage suchen: vergesst leider diesen adapter.
notfalls broadlink nehmen und die IR fernbedienungen nachmachen. aber umweg per alexa2 solange man da nicht 80x die minute was steuern will, sollte für amazon aber inoffiziel auch ok sein.. aber darauf steht eigentlich rauswurf... auch per alexa2 textCommand datenpunkt geht: "schalte wohnzimmer klimaanlage ein/aus" etc denke ich.
@adamk Ich nutze den Adapter seit über einem Jahr für 2 WindFree Klimageräte (Mega Klimaanlage btw...). Das ganze auf einem Uralt ThinClient (Intel(R) Celeron(R) J4105 CPU @ 1.50GHz), auf dem auch noch die Homematic CCU parallel läuft. Ja, der Adapter frisst CPU - bei mir allerdings "nur" < 5% mit einem Abfrageintervall von 30s. Nicht schön, aber bei mir ohne nennenswerte Einschränkungen. Das 30s Intervall fällt in der Praxis auch nicht wirklich auf, man muss nur ggf. bei Scripten daran denken, dass es eben den Zeitversatz gibt. Beispielsweise frage ich die Fenstersensoren ab und wenn die Klima läuft bei geöffneten Fenstern gibt es eine Warnmeldung. Das funktioniert gut und da stört der Zeitversatz nicht wirklich. Was allerdings gar nicht funktioniert, ist mit den HMIP Raumthermostaten die Temperatur regeln zu wollen. 2 Systeme mit größeren Latenzzeiten, ich habs aufgegeben. Aber so ziemlich alles was die Fernbedienung hergibt mittels VIS zu steuern geht zuverlässig.
Ich habe mir das Ganze aber dennoch nach Deinem Post etwas genauer angesehen. Der Adapter bietet ja die Möglichkeit Datenpunkte und auch ganze Ordnerstrukturen aus der Abfrage auszunehmen. Um jetzt nicht jeden der Tausenden Datenpunkte zu analysieren, habe ich mal nur die größten rausgenommen: execute, ocf und samsungce. Wenn diese 3 Filter im Adapter gesetzt werden reduziert das die Last um ungefähr die Hälfte, ohne dass Steuerung und Statusabfrage eingeschränkt wäre. Alleine der execute Baum hat jeweils über 1.000 Datenpunkte. Damit reduziert sich die CPU Last auf +/- 3% bei einem 30s Intervall. -
dieser adapter ist absolut unbrauchbar.
ein test eben mit 2 geräten in smartthings (2x klima) und ein i5 geht von 1.5% auf 5-30% CPU USAGE hoch (Debian12) und das dauerhaft! PI legt der adapter ganz lahm und die ioB FB Gruppe beschreibt auch das nicht nutzbar da er zuviel CPU frisst. teils 50%..
auch fügt er die 2 millionen datenpunkte gar nicht zusammen. alles zig fach in 50 ordnern. pro gerät! status-gerade, user, samsung, was man setzen könnte, sonst noch 28 versionen.. da ließt man ja hier das alleine die 5.000 neuen datenpunkte schon systeme lahmlegen.. wozu ist denn das gut? wer braucht diese infos?
ein blockly könnte diese DPs zusammenfügen und 1x was zum steuern und status in einem schaffen.. wie bei allen adaptern ja üblich. wieso ist das denn nicht im adapter intergriert???
ist der adapter TOD und wird nicht mehr weiterentwickelt?
so kann das ding doch niemand nutzen?! sinnfrei..ich gehe gerade dem umweg per szenen in smartthings->alexa->alexa2-Adapter wo man diese szenen/routinen antriggern kann... 0% cpu usage dafür und man hat zumindestens eine fernbediennung in eine richtung per ioB.. status abfragen geht so aber natürlich nicht.
andere mit ioB installieren sich nur dafür HA mit smartthings adapter und ioB gateway dazu... die lösung per homekit und dort plugin für samsung-klimas geht wohl seit 2023 gar nicht mehr..
schade das ganze denn der smartthing adapter läuft ja ansich. poolt alle 10s hier aber auch bei nur alle 60s verbraucht der so unnötig viel CPU.. und erstellt dann aber gar keine ordentlcihen datenpunkte und bis man da sin blockly/JS wiede rzusammengefrimmelt hat kann man ja fast gleich nem neuen adapter schreiben...
ps: 60min adapter test: cpu usage von 1,5 auf 7% hoch auf nem i5 der eigentlich pennt als server.. so soll es aber auch bleiben. kein adapter darf hier spürbar auch nur 1% cpu usage klauen sonst fliegt er! denn tut er das läuft da was schief und schlampig programmiert worden.. niemand braucht bei sowas updates 2817x die sekunde... poolen, alle 10s einloggen, daten saugen, aufbereiten, und ggf. sofort senden. fertig. das muss auch mit 0.1% cpu auf nem i5 laufen! wieso auch nicht?
würde bei samsung die web-api bei den klimageräten noch gehen wären das paar blocklys mit axios/http-requests und fertig. selbst diese "uralt weg" verbraucht weit weniger cpu als der smartthings-adapter jetzt gerade....... aber der ist ja anscheinend global für alles in smartthings. das ist schon nett für alle...
an alle die das hier (wie ich) finden da sie support für ihre klimaanlage suchen: vergesst leider diesen adapter.
notfalls broadlink nehmen und die IR fernbedienungen nachmachen. aber umweg per alexa2 solange man da nicht 80x die minute was steuern will, sollte für amazon aber inoffiziel auch ok sein.. aber darauf steht eigentlich rauswurf... auch per alexa2 textCommand datenpunkt geht: "schalte wohnzimmer klimaanlage ein/aus" etc denke ich.
@adamk sagte in Test Adapter Samsung Smartthings v.0.0.x:
dieser adapter ist absolut unbrauchbar.
ich möchte dich bitten doch etwas an deine Formulierungen zu feilen.
Ein solcher Ton ist hier nicht üblich!Außerdem wäre es sinnvoll und üblich ein paar mehr Fakten zu liefern.
Der Adapter ist mehr als 2000 mal Installiert.
Das ist für eine Adapter im Betastadium schon ganz viel.Allerdings gibt es hier im Forum auch bezüglich der von dir genannten "massiven Probleme" bisher nicht auffällig viele Meldungen.
Möglicherweise befinden diese sich auch da wo sie von Betatestern hingehören, als Issue auf github.Dort aber bitte mit reproduzierbaren Informationen und Fakten.
-
@adamk sagte in Test Adapter Samsung Smartthings v.0.0.x:
dieser adapter ist absolut unbrauchbar.
ich möchte dich bitten doch etwas an deine Formulierungen zu feilen.
Ein solcher Ton ist hier nicht üblich!Außerdem wäre es sinnvoll und üblich ein paar mehr Fakten zu liefern.
Der Adapter ist mehr als 2000 mal Installiert.
Das ist für eine Adapter im Betastadium schon ganz viel.Allerdings gibt es hier im Forum auch bezüglich der von dir genannten "massiven Probleme" bisher nicht auffällig viele Meldungen.
Möglicherweise befinden diese sich auch da wo sie von Betatestern hingehören, als Issue auf github.Dort aber bitte mit reproduzierbaren Informationen und Fakten.
Ich denke, das Problem ist hier, dass es halt ein "generischer" Adapter ist. Bei dem riesigen Zoo an Geräten im Samsung-Universum wäre es auch unmöglich, hier seitens der Entwickler alle Sonderlocken abzubilden.
Schuld dürfte jedoch eher Samsung haben.
Daher auch mein Rat: Selektiv schauen, was überhaupt benötigt wird und den Rest dann ausfiltern. Ja, das ist komplex. Glaubt mir, mit einem Samsung Familyhub Kühlschrank weiß ich, wovon ich rede :-(
-
Ich denke, das Problem ist hier, dass es halt ein "generischer" Adapter ist. Bei dem riesigen Zoo an Geräten im Samsung-Universum wäre es auch unmöglich, hier seitens der Entwickler alle Sonderlocken abzubilden.
Schuld dürfte jedoch eher Samsung haben.
Daher auch mein Rat: Selektiv schauen, was überhaupt benötigt wird und den Rest dann ausfiltern. Ja, das ist komplex. Glaubt mir, mit einem Samsung Familyhub Kühlschrank weiß ich, wovon ich rede :-(
-
@adamk sagte in Test Adapter Samsung Smartthings v.0.0.x:
dieser adapter ist absolut unbrauchbar.
ich möchte dich bitten doch etwas an deine Formulierungen zu feilen.
Ein solcher Ton ist hier nicht üblich!Außerdem wäre es sinnvoll und üblich ein paar mehr Fakten zu liefern.
Der Adapter ist mehr als 2000 mal Installiert.
Das ist für eine Adapter im Betastadium schon ganz viel.Allerdings gibt es hier im Forum auch bezüglich der von dir genannten "massiven Probleme" bisher nicht auffällig viele Meldungen.
Möglicherweise befinden diese sich auch da wo sie von Betatestern hingehören, als Issue auf github.Dort aber bitte mit reproduzierbaren Informationen und Fakten.
@homoran ich kann den Frust schon ein bisschen nachvollziehen.
Nur weil er 2000 mal runtergeladen wurde, heißt das nicht, das ihn 2000 Leute benutzen.
Wenn man dann noch bedenkt, wie alt der Adapter ist und Probleme kaum gefixt werden, kann man seinen Unmut schonmal Luft machen. -
@homoran ich kann den Frust schon ein bisschen nachvollziehen.
Nur weil er 2000 mal runtergeladen wurde, heißt das nicht, das ihn 2000 Leute benutzen.
Wenn man dann noch bedenkt, wie alt der Adapter ist und Probleme kaum gefixt werden, kann man seinen Unmut schonmal Luft machen.@bakerman23 Nachdem der Adapter massive Probleme mit dem Einloggen hatte, habe ich den (wie auch den Roborock Adapter) auf eine separate HomeAssistant VM umgezogen. Seitdem funktioniert das Steuern meinen Samsung Geräten mittels HASS Adapter im iobroker wieder problemlos. Im HA Adapter gibt es auch diese Vielzahl an Datenpunkten nicht. Schade, dass dieser Schritt nötig ist, für mich wird der iobroker auch weiterhin das flexiblere und Dank VIS auch bessere System bleiben, aber nun eben halt mit ein paar Adaptern in HA ergänzt.
-
@bakerman23 Nachdem der Adapter massive Probleme mit dem Einloggen hatte, habe ich den (wie auch den Roborock Adapter) auf eine separate HomeAssistant VM umgezogen. Seitdem funktioniert das Steuern meinen Samsung Geräten mittels HASS Adapter im iobroker wieder problemlos. Im HA Adapter gibt es auch diese Vielzahl an Datenpunkten nicht. Schade, dass dieser Schritt nötig ist, für mich wird der iobroker auch weiterhin das flexiblere und Dank VIS auch bessere System bleiben, aber nun eben halt mit ein paar Adaptern in HA ergänzt.
-
@frederik-buss welche integration nutzt du bei HA?
@denjo Smartthings. Scheint gut zu funktionieren, ich habe allerdings nur die Klimaanlage ausprobiert. TV ist auch am Start, aber nicht getestet...
-
@denjo Smartthings. Scheint gut zu funktionieren, ich habe allerdings nur die Klimaanlage ausprobiert. TV ist auch am Start, aber nicht getestet...
-
@frederik-buss musst du nicht dafür fernzugriff haben oder so?
@denjo Das läuft alles über den Samsung/Smartthings Account, ja. Das ist aber bei Samsung meines Wissens grundsätzlich so und war auch beim iobroker Adapter so. Meines Wissens gibt es bei Samsung Geräten generell keine lokalen Zugriffe, alles läuft über die Cloud.
-
@denjo Das läuft alles über den Samsung/Smartthings Account, ja. Das ist aber bei Samsung meines Wissens grundsätzlich so und war auch beim iobroker Adapter so. Meines Wissens gibt es bei Samsung Geräten generell keine lokalen Zugriffe, alles läuft über die Cloud.
-
@frederik-buss ich meine damit du die integrationen installieren kannst brauch man doch irgendwie cloudflare oder sowas, hab das vor ca 2 Jahren mal probiert? Und da ich ha auch nur für sowas nutze investiere ich nicht in ha.
@denjo Nicht dass ich wüsste. Ich habe bei HA kein Abo o.ä. abgeschlossen und Cloudflare auch nicht bewusst installiert. Ich bin da bei Dir, HA derzeit nur für Smartthings und Roborock, ich würde da auch kein Geld zahlen wollen.
-
Habe es jetzt ebenfalls mit HA am Laufen. Scheint prinzipiell der bessere Weg zu sein da dort ja recht viele Eigenheiten der verschiedenen SmartThings-Geräte schon "kuratiert" sind.
Lässt sich dann über den HASS-Adapter auch gut im iobroker nutzen.
-
Habe es jetzt ebenfalls mit HA am Laufen. Scheint prinzipiell der bessere Weg zu sein da dort ja recht viele Eigenheiten der verschiedenen SmartThings-Geräte schon "kuratiert" sind.
Lässt sich dann über den HASS-Adapter auch gut im iobroker nutzen.
-
Schade. Der Adapter scheint mit Node 20 nicht mehr zu funktionieren.
Exception-Code: ERR_OSSL_WRONG_FINAL_BLOCK_LENGTH: error:1C80006B:Provider routines::wrong final block length
smartthings.0
2025-12-22 22:09:59.099 error Error: error:1C80006B:Provider routines::wrong final block length at Decipheriv.final (node:internal/crypto/cipher:193:29) at Smartthings.login (/opt/iobroker/node_modules/iobroker.smartthings/main.js:135:32) at Smartthings.onReady (/opt/iobroker/node_modules/iobroker.smartthings/main.js:58:18)
smartthings.0
2025-12-22 22:09:59.098 error unhandled promise rejection: error:1C80006B:Provider routines::wrong final block length
smartthings.0
2025-12-22 22:09:59.098 error Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch().Abwarten ob da noch was kommt....
-
Schade. Der Adapter scheint mit Node 20 nicht mehr zu funktionieren.
Exception-Code: ERR_OSSL_WRONG_FINAL_BLOCK_LENGTH: error:1C80006B:Provider routines::wrong final block length
smartthings.0
2025-12-22 22:09:59.099 error Error: error:1C80006B:Provider routines::wrong final block length at Decipheriv.final (node:internal/crypto/cipher:193:29) at Smartthings.login (/opt/iobroker/node_modules/iobroker.smartthings/main.js:135:32) at Smartthings.onReady (/opt/iobroker/node_modules/iobroker.smartthings/main.js:58:18)
smartthings.0
2025-12-22 22:09:59.098 error unhandled promise rejection: error:1C80006B:Provider routines::wrong final block length
smartthings.0
2025-12-22 22:09:59.098 error Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch().Abwarten ob da noch was kommt....
@smarteppi sagte in Test Adapter Samsung Smartthings v.0.0.x:
Der Adapter scheint mit Node 20 nicht mehr zu funktionieren.
Losgelöst vom Problem solltest du ohnehin auf nodejs 22 wechseln.
-
@smarteppi sagte in Test Adapter Samsung Smartthings v.0.0.x:
Der Adapter scheint mit Node 20 nicht mehr zu funktionieren.
Losgelöst vom Problem solltest du ohnehin auf nodejs 22 wechseln.
@Thomas-Braun sagte in Test Adapter Samsung Smartthings v.0.0.x:
@smarteppi sagte in Test Adapter Samsung Smartthings v.0.0.x:
Der Adapter scheint mit Node 20 nicht mehr zu funktionieren.
Losgelöst vom Problem solltest du ohnehin auf nodejs 22 wechseln.
Ja werde ich.
Ich denke aber es wird das Problem nicht lösen.
ChatGTP sagt hier:
** *Gespeicherte Login-Daten / Token zu entschlüsseln
*- Nutzt dafür crypto.createDecipheriv
- Node.js ≥ 20 (OpenSSL 3) ist strenger
- Alte Verschlüsselung → 💥**
-
@Thomas-Braun sagte in Test Adapter Samsung Smartthings v.0.0.x:
@smarteppi sagte in Test Adapter Samsung Smartthings v.0.0.x:
Der Adapter scheint mit Node 20 nicht mehr zu funktionieren.
Losgelöst vom Problem solltest du ohnehin auf nodejs 22 wechseln.
Ja werde ich.
Ich denke aber es wird das Problem nicht lösen.
ChatGTP sagt hier:
** *Gespeicherte Login-Daten / Token zu entschlüsseln
*- Nutzt dafür crypto.createDecipheriv
- Node.js ≥ 20 (OpenSSL 3) ist strenger
- Alte Verschlüsselung → 💥**
@smarteppi sagte in Test Adapter Samsung Smartthings v.0.0.x:
Ich denke aber es wird das Problem nicht lösen.
Das habe ich auch nicht behauptet. Allerdings befindet sich nodejs@20 kurz vor EoL und 22 ist schon länger die Empfehlung für den ioBroker.
-
Wie zu erwarten hat sich mit nodejs22 nichts verbessert.
Please enter a valid codeUrl or Samsung Smartthings Token
smartthings.0
2025-12-27 18:11:20.419 error Please enter a Samsung Smartthings Code Url in the instance settings
smartthings.0
2025-12-27 18:11:20.418 info Start login via code url
smartthings.0
2025-12-27 18:11:20.400 info starting. Version 0.2.2 (non-npm: TA2k/ioBroker.smartthings#b055221990231cf4c8xxxxxxxxe94ff59b0fd75) in /opt/iobroker/node_modules/iobroker.smartthings, node: v22.21.0, js-controller: 7.0.7
smartthings.0
2025-12-27 18:11:16.483 info terminating
smartthings.0
2025-12-27 18:11:16.035 warn Terminated (UNCAUGHT_EXCEPTION): Without reason
smartthings.0
2025-12-27 18:11:16.034 info terminating
smartthings.0
2025-12-27 18:11:16.033 info Got terminate signal TERMINATE_YOURSELF
smartthings.0
2025-12-27 18:11:15.980 error Exception-Code: ERR_OSSL_WRONG_FINAL_BLOCK_LENGTH: error:1C80006B:Provider routines::wrong final block length
smartthings.0
2025-12-27 18:11:15.980 error Error: error:1C80006B:Provider routines::wrong final block length at Decipheriv.final (node:internal/crypto/cipher:184:29) at Smartthings.login (/opt/iobroker/node_modules/iobroker.smartthings/main.js:135:32) at Smartthings.onReady (/opt/iobroker/node_modules/iobroker.smartthings/main.js:58:18)
smartthings.0
2025-12-27 18:11:15.980 error unhandled promise rejection: error:1C80006B:Provider routines::wrong final block length
smartthings.0
2025-12-27 18:11:15.979 error Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch().
smartthings.0
2025-12-27 18:11:15.977 info Start login via code url
smartthings.0
2025-12-27 18:11:15.956 info starting. Version 0.2.2 (non-npm: TA2k/ioBroker.smartthings#b05522199023xxxxxxxxxbee94ff59b0fd75) in /opt/iobroker/node_modules/iobroker.smartthings, node: v22.21.0, js-controller: 7.0.7 -
Das sagt KI:
Was genau schiefgeht (technisch korrekt)Node 20+ / 22 nutzt OpenSSL 3.x
Der SmartThings-Adapter:
verschlüsselt Tokens legacy-kompatibel
entschlüsselt sie mit createDecipheriv
OpenSSL 3 ist strenger bei:
Padding
Blocklängen
Ergebnis:
wrong final block length
KI schlägt downgrade nodejs auf 18 vor - mach ich natürlich nicht
Alternative:
Node 22 behalten (nicht empfohlen, aber möglich)Nur mit Legacy-Provider:
export NODE_OPTIONS=--openssl-legacy-provider
iobroker restartIst das zu empfehlen?
Support us
526
Online32.6k
Benutzer81.9k
Themen1.3m
Beiträge