Vitoconnect - Verbesserte Version

Beta-User · 18 Februar 2025, 07:19:40

json_decode() schafft uU. erst das Umlaut-Problem. JSON->new->decode() macht dieselben Datenstrukturen ohne zwangsläufige UTF8-Unterstellung....

(Unicode First aid-Thread für Details)

stefanru · 18 Februar 2025, 10:30:38

Danke Beta-User,

das werde ich ausprobieren.
Dann könnte ich die Fehlertexte in der FHEM Sprache auslesen.

Gruß,
Stefan

Beta-User · 18 Februar 2025, 11:12:58

Hoffe, du bist erfolgreich damit - wir bekommen die nächsten paar Tage auch eine Vitodens 200W...

Du darfst also damit rechnen, dass ich mir den Code auch nochmal näher reinziehe und dich ggf. nerve

.

Bis dahin auch von meiner Seite erst mal ein herzliches Danke für's Weiterentwickeln dieses Moduls!!!

(Ärgerlich, dass die bei Viessmann auch auf den Cloud-only-Zug gestiegen sind, den CAN-Teil werde ich mir dann auch bei Gelegenheit mal in Ruhe ansehen.)

stefanru · 18 Februar 2025, 12:26:00

@Beta-User
Ja openE3 (CAN Bus) sieht sehr interessant aus und scheint auch einfach per MQTT anzubinden zu sein.
Wegen fehlender Zeit und auch eventueller Garantie wollte ich aber erstmal bei der offiziellen Schnittstelle bleiben.
Weiß nicht was Viessmann sagt wenn man Parameter ändert an die man offiziell über die API gar nicht kommt.

Insgesamt muss ich sagen ist Viessmann mit ihrer Politik schräg drauf.
Alles zunageln, selbst für einfache Datenpunkte ein Abo Modell zu verlangen und vor allem kein direkten Kundenkontakt nur über Heizungsbauer, ist schon nervig.
Hatte jetzt ein paar Probleme mit meiner Anlage bei denen mein Heizungsbauer nicht weiter wusste.
Das lief dann immer über stille Post mit dem Heizungsbauer als Mittelsmann.
Sehr nervig und Zeitaufreibend.

Zum Modul:
Ich habe es ja übernommen und angepasst.
Es sind sicher noch einige Leichen im Keller und auch hat es einen dicken Overhead da ich die Kompatibilität der alten Mappings (SVN, Roger) mit rumschleppe.
Beim Raw Mapping bin ich auf einige Unzulänglichkeiten der Viessmann API gestoßen und musste hässliche Workarounds bauen die aber gut funktionieren.

Input und Verbesserungsvorschläge sind ausdrücklich erwünscht und es wäre toll wenn noch jemand sich den Code anschaut und Ideen und Verbesserungen einbringt.

Dann hoffe ich mit deiner Heizung geht alles glatt und freu mich auf Feedback.

Viele Grüße,
Stefan

stefanru · 18 Februar 2025, 20:30:27

Hi,

habe doch etwas Zeit gefunden.

Habe versucht alles umzusetzen.

Sprache: Wird aus dem Attribut language vom global device genommen.
Steht dort DE wird es deutsch.
@Beta-User: Danke dein Tipp hat geholfen und die Umlaute waren nun ok.

Markup: Es wird nun auch <q> </q> entfernt.

Severity: Da "note", "warning", "error" oder "criticalError" nicht in der Rückgabe kommt nehme ich es aus der Raw message und übersetze es selbst wenn DE gesetzt ist. Sie landet in device.messages.errors.mapped.0.severity

Log Meldungen: Die 2 Meldungen werden nur noch mit Verbose 5 ausgegeben.

Prototype mismatch: Ich habe JSON::XS wieder entfernt.
@Schlimbo, schaue bitte mal ob das hilft.

Löschen der Mapped Errors und File schreiben:
Ich habe mich erstmal gegen das automatische Löschen entschieden.
Immerhin sind Fehler eine Sondersituation und man muss sie für gewöhnlich sogar an der Heizung bestätigen.
Außerdem würde ich so einen Fehler der Nachts auftrat und sich selbst "geheilt" hat gern morgens im FHEM sehen.
Man kann die Fehler aber mit set <devicename> clearMappedReadings löschen.

Gegen das File schreiben habe ich mich auch erstmal entschieden. Ich müsste dann immer prüfen ob der Fehler schon drinsteht um nicht immer und immer wieder den selben Fehler ins Logfile zu schreiben.
Aber beim überdenken habe ich gemerkt, dass keiner der bisherigen File handles geschlossen wurde. Das habe ich gefixt.

Ich hoffe damit ist alles umgesetzt oder habe ich etwas vergessen?
Falls das mit löschen der mapped Errors und File schreiben doch gern anders gewünscht wird können wir natürlich darüber reden. Bitte mit Vorschlägen wie es am besten gehandhabt werden kann.

Neue Version ist im GIT.
Fix Text ist: enhanced error mapping now also language dependent, closing of file_handles, removed JSON::XS

Morgen dann auch im SVN.

Gruß,
Stefan

Schlimbo · 19 Februar 2025, 22:06:05

Hi Stefan,

funktioniert alles, und "Prototype mismatch" ist mit der Version auch behoben.

zu "Löschen der Mapped Errors": kein Thema, passt für mich auch.

zu "Gegen das File schreiben habe ich mich auch erstmal entschieden.": Sorry, da habe ich mich vielleicht nicht klar ausgedrückt. Ich meinte nicht, dass hierzu etwas in das Modul aufgenommen werden sollte. Mein Ansatz war, dass man sich einfach selbst eine Log-Datei anlegt, wenn man die Meldungen speichern möchte:

Code Auswählen

define Viessmann_errorLog FileLog ./log/Viessmann_errorLog-%Y-%m.log vitoconnect:device.messages.*
Mir ist jetzt aber noch etwas anderes aufgefallen, das scheinbar schon länger vorhanden ist und nichts mit den letzten Änderungen im Modul zu tun hat:
Sobald ich die Detailansicht meines vitoconnect-Devices öffne, werden Mehrbyte-Zeichen (Umlaute & ß) in der FHEM-Weboberfläche nicht mehr korrekt angezeigt.
"Büro" wird in der Raumauswahl als "BÃ¼ro" dargestellt.
Klicke ich jedoch auf einen anderen Raum, werden die Umlaute wieder korrekt angezeigt.
Ich weiß nicht, ob das mit dem Modul zusammenhängt, aber es scheint, als würde vitoconnect die Codierung der gesamten Webansicht ändern.
Weißt du an was das liegen könnte?

Das habe ich dazu im Forum gefunden: https://forum.fhem.de/index.php?topic=55539.0
Der Beitrag ist aber schon sehr alt und das Problem wurde damals scheinbar gefixt.

stefanru · 19 Februar 2025, 23:10:30

Hi Schlimbo,

danke für die Rückmeldung und super dass alles auf Anhieb funktioniert.

Das Umlautproblem habe ich bei mir nicht, siehe Screenshot.
Hast du irgendeinen besonderen Skin?
Das konnte ich jetzt nicht testen.
Ich habe nichts wegen UTF8 ins Modul gebaut und finde auch erstmal nichts was es auslösen könnte.

Hast du gerade Fehlermeldungen mit Umlauten im Device?
Oder wird deine komische Seriennummer angezeigt?
Ich vermute dass eines der Zeichen ein Problem verursacht, wahrscheinlich die seltsamen Zeichen deiner Seriennummer.
Du könntest das Device mal disablen und die kritischen Readings eins nach dem anderen löschen.
Sollte es die Seriennummer sein könnte ich das rausfiltern im Modul.

Gruß,
Stefan

Schlimbo · 19 Februar 2025, 23:44:23

Tatsächlich,es liegt an der komischen Seriennummer.
Lösche ich das Reading "heating.controller.serial.value" werden die Umlaute korrekt angezeigt.

Danke für den Tipp

stefanru · 20 Februar 2025, 00:35:34

Hi Schlimbo,

ich habe mal etwas versucht um nicht druckbare Zeichen zu entfernen aus dem JSON.
Kannst du die angehängte Version mal bei dir testen?

Gruß,
Stefan

Schlimbo · 20 Februar 2025, 06:52:32

Guten Morgen Stefan,
hat nicht geklappt, die Zeichen sind weiterhin vorhanden.
LG Schlimbo

Beta-User · 20 Februar 2025, 08:08:45

Zitat von: stefanru am 20 Februar 2025, 00:35:34ich habe mal etwas versucht um nicht druckbare Zeichen zu entfernen aus dem JSON.

Nach meinen Erfahrungen mit RHASSPY bringt es "relativ wenig", mit den vielen (de-) Codier-Optionen groß rumzuexperimentieren - jedes System ist etwas anders, und sobald man es für den einen passend hat, bringt man woanders was durcheinander...

Vielleicht sollten wird das Codierungs-Thema gesondert behandeln, auch damit sich Rudi mal mit dem FHEMWEB-Darstellungsthema auseinandersetzen kann (ohne sich groß mit den Details zum Modul ansonsten rumplagen zu müssen)?

Eventuell zielführende Infos wären
- OS, auf dem FHEM läuft
- Perl-Version
- Einstellung für Codierung in FHEM (schon bytestream?) und natürlich die Version
- tritt das Problem mit verschiedenen Browsern und Zielsystemen auf?
- Was passiert, wenn man die ganze Seite neu läd? (Cache etc.).
- Möglichkeit, das mit aktivierter bytestream-Option man separat auf einem "frischen FHEM" zu testen?
- Gibt es Optionen auf der Gegenstelle (dem cloud-Dienst)?

Zur Gegenstelle allgemein: Die _sollte_ eigentlich "sauberes UTF8" liefern - soweit ich mich entsinne, ist das die Konvention für JSON. Vielleicht ist das auch einfach ein Bug auf dieser Seite, den man adressieren müßte?

stefanru · 20 Februar 2025, 09:25:58

Hi Beta-User,

meine bisherige Einschätzung ist dass hier ein Bug auf der Sender Seite vorliegt.
In dem Teil des JSON sollte eine Seriennummer bestehend aus Zahlen stehen.

Bei Schlimbo kommt aber "value": "ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½".
Sonst hat niemand den Fehler.

Sieht nach irgend einem Codierungsproblem des JSON nur für die Seriennummer und nur bei Schlimbos Setup aus.
Alles andere ist ok in Schlimbos JSON.

Ich werde nochmal auf der Viessmann Developerseite nachsehen ob irgendetwas zur Codierung des JSON steht.
Ansonsten versuche ich erstmal den einen Wert bei Schlimbo zu entfernen, bzw. das JSONB auf darstellbare Zeichen zu reduzieren.

Gruß,
Stefan

stefanru · 20 Februar 2025, 10:33:57

Ok, @Schlimbo, neue Version zum testen.
Unbekannt Zeichen sollten nun als [VUC] gefiltert werden.

Schlimbo · 20 Februar 2025, 21:04:56

Hi Stefan,

danke damit klappt es.
Im Reading "heating.controller.serial.value" steht jetzt "[VUC]" und die Umlaute sind wieder richtig.

Zitat von: Beta-User am 20 Februar 2025, 08:08:45Eventuell zielführende Infos wären
- OS, auf dem FHEM läuft
- Perl-Version
- Einstellung für Codierung in FHEM (schon bytestream?) und natürlich die Version
- tritt das Problem mit verschiedenen Browsern und Zielsystemen auf?
- Was passiert, wenn man die ganze Seite neu läd? (Cache etc.).
- Möglichkeit, das mit aktivierter bytestream-Option man separat auf einem "frischen FHEM" zu testen?
- Gibt es Optionen auf der Gegenstelle (dem cloud-Dienst)?

Zur Gegenstelle allgemein: Die _sollte_ eigentlich "sauberes UTF8" liefern - soweit ich mich entsinne, ist das die Konvention für JSON. Vielleicht ist das auch einfach ein Bug auf dieser Seite, den man adressieren müßte?

Hi Beta-User,

mein System ist ein Raspberry Pi 4 B mit Raspberry Pi OS Lite Debian Bookworm.
Fehm läuft im Docker image: ghcr.io/fhem/fhem-docker:4-bullseye
Perl v5.36.3
Fhem: FVERSION fhem.pl:v6.1-s29402/2024-12-05 (letztes SVN update am 19.02.2025).
attr global encoding ist nicht gesetzt, also sollte default bytestream verwendet werden.
Problem ist bei allen getestete Browsern vorhanden: Chrome (Windows 11); MS Edge (Windows 11); Chrome (Android 15).
Auch beim neu laden der Seite (mit gelöschten cache) tritt das problem auf.
Möglichkeit auf einem frischen FEHM System zu testen habe ich gerade nicht.
Auf der Viessmann API Seite kann man hierzu nichts einstellen. Ich werde bei Viessmann mal ein Ticket dazu erstellen...

Viele Grüße
Schlimbo

stefanru · 20 Februar 2025, 21:59:53

Hi Schlimbo,

da bin ich mal gespannt was Viessmann dazu sagt.

Es gibt eine neue Version im GIT und morgen im SVN.
"0.8.1"
replace U+FFFD (unknown character with [VUC] see https://forum.fhem.de/index.php?msg=1334504
fill reason in error case from extended payload

Das letzte ist wegen diesem Post:

Zitat von: jemu75 am 08 Februar 2025, 23:02:37Hallo Stefan,

ich wollte nochmal ein kurzes Feedback geben. Bei mir sind heute zeitweise nochmal Fehler im log aufgetaucht.

Code Auswählen Erweitern
2025.02.07 10:41:52 1: vitodens - unbekannter Fehler: Bitte den Entwickler informieren! 2025.02.07 10:41:52 1: vitodens - statusCode: 400 errorType: DEVICE_COMMUNICATION_ERROR message: error: 2025.02.07 10:43:53 1: PERL WARNING: Use of uninitialized value $a[1] in subtraction (-) at ./FHEM/99_Utils.pm line 21. 2025.02.07 10:43:53 1: PERL WARNING: Use of uninitialized value in subroutine entry at ./FHEM/99_Utils.pm line 21.
Hast du einen Tipp, wie ich dem Problem noch besser auf den Grund gehen kann?

Grüße
Jens

Ich hatte es heute auch. Der Grund war das heute Nacht meine FritzBox ein Update gemacht hat und die Viessmann Geräte nun an einem weiter entfernten Repeater hingen und ab und zu die Verbindung verloren haben.
Die extended Payload zeigt dann: 'reason' => 'GATEWAY_OFFLINE'
Dies wird nun auch im State oder Log je nach Art des Fehlers angezeigt.

Viele Grüße,
Stefan