Monatsrückblick Januar/Februar 2026 ist online!

[Samson71]

@monster
Jaein. Ein Log bettet man als Text in Code-Tags </> (oben im Menü) im Text ein und hängt es nicht als Textdatei an.

[monster]

die box ist aus dem Jahr 2018. Keine 2.0

[monster]

@Samson71 danke für den Hinweis. Bin neu auf dem Gebiet.

[Black Thunder]

@monster Danke fürs Log, jetzt passt es.

Bist du dir sicher, dass die IP der Box korrekt ist (192.168.2.145)? Kannst du dich mit der offiziellen App verbinden oder scheitert das auch?

Ansonsten ist mir diese Meldung so auch noch nicht untergekommen. Es scheint so, als ob die Firmware auf deiner Box relativ alt ist und mit der "neuen" Version des Protokolls seitens des Adapters nicht harmoniert. Mir würden da spontan zwei Lösungsansätze einfallen:

1 . Versuch einfach mal in den Adaptereinstellungen unter Erweiterte Optionen die Versionsnummern für SHCVersion und SHAPIVersion runter zu setzen. Speziell für SHAPIVersion einfach kleinere Werte ausprobieren (z.B. 3.3 oder 2.13).

2. Wenn das nicht hilft, könnte ich dir eine Version des Adapters bereitstellen, die versucht diese Meldungen zu ignorieren. Eventuell geht es ja trotzdem, aber das halte ich eher für unwahrscheinlich.

[monster]

Mit der offiziellen App gibt es keine Probleme. Verbindet sich und Steuert auch. Die IP 192.168.2.145 ist vom Master. Die IP 192.168.2.179 ist vom Client. Wofür auch immer die gebraucht wird. Wenn ich in der App unter Informationen die SHCVersion nachschaue ist die 3.7.4 und die SHAPIVersion 3.4. Die Firmware ist V 1.4x

[Black Thunder]

@monster Ok, wenn die App funktioniert und dort auch dieselben Versionen angezeigt werden wie im Adapter, dann wundert es mich umso mehr, warum es nicht funktionieren sollte.

Aber was mir gerade beim nochmaligen Anschauen deines Logs auffällt, ist das hier:

2026-02-18 16:12:20.653 - debug: smartfriends.0 (3297) IP: 192.168.2.145 - Port: 4300 - CSymbol: D19033 - SHCVersion: 3.74 - SHAPIVersion: 3.4

Prüfe bitte mal in den Adaptereinstellungen, ob für SHCVersion "3.74" oder "3.7.4" eingetragen ist. Man beachte den fehlenden Punkt, es muss "3.7.4" sein. 😉

[monster]

ich habe den Fehler in der Versionsnummer korrigiert und auch mit anderen versionsnummen probiert. Leider kein erfolg. immer das selbe Problem. Trotzdem Danke fuer deine Unterstuetzung.
Vielleicht gibt es ja noch jemandem mit dem selben Problem und hat eine Loesung gefunden.

[Black Thunder]

@monster Das Einzige, was mir jetzt noch zusätzlich auffällt, ist dein konfiguriertes "CSymbol". Standardmäßig lautet das "D19033i", also mit angehängtem "i".
Hast du das schon einmal versucht bzw. warum hast du das abgeändert?

[Black Thunder]

@monster Ich konnte deine Fehlersituation wirklich nachstellen, indem ich bei mir auch das "i" am Ende des CSymbol entfernt habe. Es sollte also bei dir auch funktionieren, wenn du das "i" wieder anhängst und die SHCVersion und die SHAPIVersion ebenfalls auf den Standardwerten belässt.

In der kommenden Version des Adapters wird es zusätzlich eine Prüfung auf diese Konstellation samt einem entsprechenden Eintrag im Log geben.

EDIT: Jetzt als v1.3.5 im latest mit zusätzlichen Validierungen an der Oberfläche verfügbar.

[HeiLuRa]

Hallo BlackThunder,
ich habe folgendes Problem. Dein Adapter funktioniert soweit ganz hervorragend, aber irgendwann kommt folgender Fehler:
"smartmeter.0 (815774) ERROR ON HTTP REQUEST: : Error: Parse Error: Invalid character in Content-Length" (s. auch Log-Datei)
Smartfriend-Box ist die alte, und ich habe die Version 1.3.4 installiert.

2026-02-23 smartfriend.txt

Nach einem Restart des Adapters läuft wieder alles, bis zur nächsten Fehlermeldung.

[HeiLuRa]

Hallo BlackThunder;
leider habe ich mich beim Kopieren versehen! Die Fehlermeldung lautet:
2026-02-23 10:15:01.907 - warn: smartfriends.0 (3103449) Socket ended
2026-02-23 10:15:01.914 - error: smartfriends.0 (3103449) Error in sendDeviceCommand: undefined
Sorry nochmal.

[Black Thunder]

@HeiLuRa Könntest du bitte den Adapter so lange auf Log-Level "Debug" laufen lassen, bis die Fehlerkonstellation auftritt, und dann nochmal das Log hier anhängen? Daran erkenne ich eventuell besser, warum das auftritt und wie sich damit umgehen lässt.

[Black Thunder]

@HeiLuRa Ich hätte noch eine andere Bitte: Auf npm habe ich gerade 1.3.6-alpha.0 hochgeladen, in der ich an der gesamten Verbindungslogik noch etwas geschraubt habe.
Probiere es bitte direkt mit dieser Version aus und gib mir wieder Bescheid, ob es damit besser funktioniert.

[HeiLuRa]

Danke erstmal, ich werde es erst mit 1.3.6 probieren, da die Verbindung irgendwann passiert, ich weiß dann nicht wie lang der Log-Level bei Debug wird.
Melde mich dann wieder.

[HeiLuRa]

@black-thunder Ich habe auf 1.3.6-alpha-0 umgestellt. Leider ist das Ergebnis das gleiche.
Obwohl sowohl die Rohrmotoren als auch die Steckdosenschalter (SilverCrest) einwandfrei funktionieren. Hier der Log-File mit Kommentaren.
2026-02-26 smartfriend-auszug.txt
Ich hoffe, dass ich richtig gekürzt habe. Sonst muss ich dir per PN senden.

[Black Thunder]

@HeiLuRa Du bekommst also weiterhin "Socket ended" im Log?
In deinem gekürzten Log sind nämlich keine Warnungen oder Fehler von meinem Adapter sichtbar. Schick mir bitte das gesamte Log.

[HeiLuRa]

@black-thunder Hier ein Auszug mit den jetzigen Fehlermeldungen:
Error in handleStateChange: undefined
Error in sendDeviceCommand: timeout

2026-03-01 smartfriend-1.txt

Wie kann ich dir den ganzen Log senden? (ca. 2-3MB)

[Black Thunder]

@HeiLuRa Du kannst mir das gesamte Log per E-Mail senden (Adresse siehe PN).
Nur für mich nochmal zum Verständnis: Trotz dieser Fehlermeldungen im Log funktioniert die Bedienung der Geräte weiterhin einwandfrei oder erst nach einem Neustart des Adapters wieder?

[HeiLuRa]

@black-thunder Die gesamten Logs kommen per Mail.
Hast Recht, wenn die Fehlermeldungen da sind, geht nichts mehr. (Mehr in der Mail.)

[Black Thunder]

@HeiLuRa Danke für die Logs. Ich habe gerade noch etwas an der Verbindungslogik geschraubt und 1.3.6-alpha.1 auf npm hochgeladen.

Wenn du es mit dieser Version testet, auch hier bitte wieder so lange auf Debug-Log laufen lassen, bis die Fehler auftreten. Idealerweise sollte die Fehlersituation aber jetzt besser gehandhabt werden und gar nicht mehr in diese blockierte Endlosschleife laufen.