Problem Abruf der System Variables in Home Assitant

[DennisW]

Mein Home Assistant hat seit kurzem Probleme die System Variabels abzurufen und gibt mir folgenden Fehler

Code: Alles auswählen

Logger: hahomematic.json_rpc_client
Source: custom_components/homematicip_local/control_unit.py:839
Integration: Homematic(IP) Local (documentation, issues)
First occurred: 1:19:43 PM (1050 occurrences)
Last logged: 10:07:40 PM

GET_ALL_SYSTEM_VARIABLES failed: ClientException [('POST: error: {\'name\': \'JSONRPCError\', \'code\': 200, \'message\': \'internal error:\\nlist element in braces followed by "r," instead of space\\n while executing\\n"foreach sv $svList {\\n if { 1 != $first } then { append result "," } else { set first 0 }\\n array set _sv_ $sv\\n set type $_sv_(TYPE)\\n \\n append resu..."\\n (file "/www/api/methods/sysvar/getall.tcl" line 75)\\n invoked from within\\n"source [file join $env(DOCUMENT_ROOT) "api/methods/$method(SCRIPT_FILE)"]"\'}',)]
DO_POST failed: ClientConnectorError: Cannot connect to host 192.168.1.230:80 ssl:default [Connect call failed ('192.168.1.230', 80)]
GET_ALL_SYSTEM_VARIABLES failed: ClientException [("POST: error: Cannot connect to host 192.168.1.230:80 ssl:default [Connect call failed ('192.168.1.230', 80)]",)]

Ich habe den Fehler bereits im Repository der Home Assistant integration gepostet, wurde aber hierher verwiesen. Der Fehler ist wahrscheinlich im Zusammenhang mit dem Update auf 2023.7 und dem entsprechenden Update der Integration aufgetreten. Den gleichen Fehler hatte ich aber vor einigen Wochen schon einmal unter 2023.6 auf anderer Hardware. Nachdem ich aber Raspberrymatic und Home Assistant auf einen Proxmox Server umgezogen habe, hatte ich erstmal Ruhe. Ich habe extra kein CCU Backup eingespielt um Altlasten zu vermeiden. Raspberrymatic und Home Assistant habe ich über die Scripte installiert. Alle drei Komponenten laufen auf der aktuellen Version. Ansonsten funktioniert die Kommuikation zwischen CCU und HA problemlos.

Hat jemand eine Idee, woher der Fehler kommt? Ich bin für jede Hilfe dankbar!

[Xel66]

Ist jetzt nur ein Schuss ins Blaue. Wenn ich im Protokoll "...192.168.1.230:80 ssl:default [Connect call failed ('192.168.1.230', 80)..." lese, würde ich als erstes mal die Netzwerk (IP?) und insbesondere die Firewalleinstellungen überprüfen. Ansonsten ist die Faktenlage für eine Analyse recht dünn. Ich bin auch definitiv kein HA-Experte (setze ich nicht ein).

Gruß Xel66

[DennisW]

Mit der Firewall habe ich schon rumprobiert. Momentan sind Ports auf offen und 3x Vollzugriff ausgewählt um hier Probleme zu vermeiden. Ich betreibe ein Unifi Netzwerk aber auch dort kann ich nichts finden, was die Verbindung stören könnte. Die IP ansich ist die richtige und eine Verbidung zur CCU wird im Home Assistant auch aufgebaut. Es kommt nur zum Fehler bei den System Variablen.

Gerne stelle ich noch weitere Infos zur Verfügung - ich weiß nur nicht was. Im CCU Log konnte ich keine Ausschnitte aus der Fehlermeldung finden. Ich habe den Log angehängt.

[Baxxy]

Reduziere die Komplexität erstmal auf ein Minimum.

• Benutzer mit Admin-Rechten auf der Zentrale anlegen und ein ganze einfaches Passwort nehmen.
  (Bspw. Nutzer: Test / Passwort: Test)
• In der Systemsteuerung unter Sicherheit die Authentifizierung und die automatische HTTPS-Weiterleitung deaktivieren.
• Die Firewall der Zentrale komplett öffnen (Vollzugriff / Ports offen)
• Zentrale rebooten
• Dann den Config-Flow der Integration erneut durchlaufen:

Und dann mal gucken ob es läuft.

[DennisW]

Hallo Baxxy, danke für die Hilfe. Ich habe einen neuen Test User angelegt, die HA Integration entfernt und mit dem Test User eine neue Verbindung aufgebaut. Der Fehler ist der Gleiche. Alles geht bis auf die Systemvariablen.

Mein nächster Schritt wäre eine frische CCU Instanz ohne jedes Gerät aufzusetzen und nochmal zu testen. Wenn das nicht hilft, würde ich es mit einem frischen Homeassistant probieren.

[SukramJ]

Die allgemeine Kommunikation wird, denke ich, nicht das Problem sein.
Wie ich ja schon im GitHub issue gesagt habe wirft die Abfrage der Systemvariablen einen 'internal error' in /www/api/methods/sysvar/getall.tcl. Das sieht man ja auch im initialen Post.

[Baxxy]

Hmm, bin gespannt was der Test mit einer "nackten" CCUx ergibt.

Wenn das dann läuft, dann würde ich spekulieren das in einer deiner (Text-)SysVars irgendwas drinsteht was das Script aus dem Tritt bringt.
Irgendwelche speziellen Zeichen vielleicht...

[DennisW]

So, ich habe das Problem endlich gefunden. Danke Baxxy für den Hinweis auf die Sonderzeichen. Keine Ahnung warum ich da nicht früher drauf gekommen bin.

Ich verwende ein eink display HmIP-WRCD. Dieses wird zur Zeit nicht vollständig in Home Assistant unterstützt. Um Texte auf das Display zu schreiben habe ich daher String-Systemvariablen angelegt mit denen ich Text vom HA an die CCU weiter geben kann. Außerdem habe ich eine boolean SV angelegt um ein Update des Displays zu triggern. Das Problem ist dass das Display nur einen eingeschränkten Zeichensatz hat. Für ein "ü" wie in Küche muss ich als String "K}che" senden. Genau diese Änderung habe ich in Home Assistant vorgenommen. Wenn aber in einer Systemvariable "}" als Zeichen vorkommt, dann kommt es zu dem Fehler und die gesamte SV Synchronisation bricht zusammen. Ich habe jetzt die Ersetzungen in das CCU Programm integriert und jetzt funktioniert alles problemlos. Ist das ein Bugbericht wert? Wenn ja wo?

Falls jemand über die Suche hier drauf stößt, mein Code zum beschreiben des Displays:

Code: Alles auswählen

string device ="HmIP-WRCD XXX:3";
string z1 = dom.GetObject("eink_z1").Value();
string z2 = dom.GetObject("eink_z2").Value();
string z3 = dom.GetObject("eink_z3").Value();
string z4 = dom.GetObject("eink_z4").Value();
string z5 = dom.GetObject("eink_z5").Value();

string newcontent="{DDBC=BLACK,DDTC=WHITE,DDI=0,DDA=CENTER,DDS="#z1#",DDID=1},{DDBC=WHITE,DDTC=BLACK,DDI=0,DDA=LEFT,DDS="#z2#",DDID=2},{DDBC=WHITE,DDTC=BLACK,DDI=0,DDA=LEFT,DDS="#z3#",DDID=3},{DDBC=WHITE,DDTC=BLACK,DDI=0,DDA=LEFT,DDS="#z4#",DDID=4},{DDBC=BLACK,DDTC=WHITE,DDI=1,DDA=CENTER,DDS="#z5#",DDID=5,DDC=true},{R=0,IN=1,ANS=-1}";
newcontent=newcontent.Replace("ä","{");
newcontent=newcontent.Replace("ö","|");
newcontent=newcontent.Replace("ü","}");
newcontent=newcontent.Replace("Ä","[");
newcontent=newcontent.Replace("Ö","#");
newcontent=newcontent.Replace("Ü","$");
newcontent=newcontent.Replace("ß","_");

channels.Get(device).DPByHssDP("COMBINED_PARAMETER").State(newcontent);

Das Script wird über eine boolean Systemvariable getriggert, sobald diese auf true wechselt. Im Anschluss setzt das Programm diese wieder auf false.

[Baxxy]

Schön daß es jetzt funktioniert.
(und ich den richtigen Riecher hatte )

Ist das ein Bugbericht wert? Wenn ja wo?

Ich denke eher nicht. Das ganze läuft ja über die JSON-Api der Zentrale. Und JSON nutzt nun mal selbst viele Klammern. Eine Klammer an der falschen Stelle und schon ist das JSON futsch.

Das Display könnte man auch mittels Service über den COMBINED_PARAMETER ansprechen, dort dürften (sollten) die Sonderzeichen kein Problem sein.
Aber wenn du jetzt ne funktionale Lösung hast dann lass es doch so.

[jmaus]

Was mich beim lesen dieses Beitrages jedoch wundert, ist das wirklich ein dokumentiertes vorgehen das man Klammern wie { als Ersatzzeichen für Umlauten verwenden muss/soll?!? Wo genau steht das?