Vitoconnect - Verbesserte Version

[neworder]

Noch eine Frage die hier ggf. falsch aufgehoben ist: Wie lösche ich nach erfolgreicher Umstellung auf RAW-readings alle nicht mehr aktuellen Readings aus dem Device (HK1*, WW*, Stromverbrauch* etc.)? Jedes einzeln mit { delete $defs{<NAME>}{READINGS}{T_avg_day} } wär jetzt nicht so meins . So ganz ist FHEM immer noch nicht mein Freund.

[Beta-User]

Noch eine Frage die hier ggf. falsch aufgehoben ist: Wie lösche ich nach erfolgreicher Umstellung auf RAW-readings alle nicht mehr aktuellen Readings aus dem Device (HK1*, WW*, Stromverbrauch* etc.)? Jedes einzeln mit { delete $defs{<NAME>}{READINGS}{T_avg_day} } wär jetzt nicht so meins . So ganz ist FHEM immer noch nicht mein Freund.

Gibt einen set-Befehl dafür. Damit ist zwar erst mal alles weg, aber das kommt dann auch wieder.
Oder ist statistics oder so dann beleidigt?

[neworder]

damn, "clearReadings" gerade selber gefunden .

[Beta-User]

damn, "clearReadings" gerade selber gefunden .

Na ja, auf mich wirkt dieser setter auch etwas nach einer eher überraschenden Übergangslösung...

Eigentlich ist "deletereading" mit passender regex die Lösung, die man mittelfristig kennen sollte - ich würde nämlich dafür votieren, "Standardfunktionalität" (die man eigentlich in so einem Device - anders als in einem BT-GW - nicht braucht) nicht extra als setter bereitszustellen.

Btw.: Es gibt auch Devices, bei denen man via "get" ReadingsVal()-Abfragen machen kann - historsch gewachsen, aber irgendwann halt überholt.

Mit der Weiterentwicklung von stefanru und Dir sind meine Anforderungen gut abgedeckt.

Dieses Lob gilt ausdrücklich nur stefanru! Bis dato sind - abgesehen von dem dankenswerterweise aufgegriffenen Hinweis auf das "decode_json()"-codepage-Problem - keinerlei Vorschläge von mir im svn-Code enthalten

(Und anscheinend hat auch außer mir keiner Bedarf an weekprofile - jedenfalls hat auch keiner bisher die überarbeitete Fassung (die effektiv nicht mehr kann wie die svn-Fassung) am Start).

[Schlimbo]

Hi Stefan,

Im Log meiner Heizung ist mir aufgefallen, dass manche Fehlermeldungen HTML-formatierten Text zurückgeben (z. B. <ul><li>...</li></ul>). Wäre es möglich, diese im Modul zu parsen, sodass die Ausgabe als Klartext oder als formatierte Liste erscheint?

Code Auswählen Erweitern

2025-02-25_14:32:26 vitoconnect device.messages.errors.raw.entries: expert, d4, note, 2025-02-25T14:28:49.000Z, debug, f0, note, 2025-02-25T14:28:49.000Z, maintainer, 07, note, 2025-02-25T14:28:48.000Z
2025-02-25_14:32:26 vitoconnect device.messages.errors.mapped.0.faultCode: D4
2025-02-25_14:32:26 vitoconnect device.messages.errors.mapped.0.faultCodes.0.cause: <ul><titel>Hochdruckstörung:</titel><li>Luft im Heizkreis</li><li>Sekundärpumpe oder Heizkreispumpe blockiert</li><li>Verflüssiger verschmutzt</li><li>Hochdrucksensor defekt</li></ul>
2025-02-25_14:32:26 vitoconnect device.messages.errors.mapped.0.faultCodes.0.measure: <ul><li>Heizkreis entlüften.</li><li>Anlagendruck prüfen.</li><li>Sekundärpumpe und Heizkreispumpen prüfen.</li><li>Heizkreise spülen.</li><li>Speichertemperatur-Sollwert (Warmwassertemperatur-Sollwert 6000, Warmwassertemperatur-Sollwert 2 600C) um 2 bis 3 K verringern.</li><li><ul><titel>Hochdrucksensor an folgenden Anschlüssen der Außeneinheit prüfen:</titel><li>Vitocal 100-S/111-S:Anschluss H_PRESS auf der Hauptleiterplatte: Siehe Hauptleiterplatte [7] / [7-1].</li><li>Vitocal 200-A/200-S/222-A/222-S:Anschluss J10 auf EEV-Leiterplatte: Siehe EEV-Leiterplatte [4-3] / [4-4].</li><li>Vitocal 200-A, Typ AWCI-AC 201.A:Anschluss J3 auf EEV-Leiterplatte: Siehe EEV-Leiterplatte [2].</li><li>Vitocal 222-G/333-G:Anschluss J10 auf EEV-Leiterplatte: Siehe EEV-Leiterplatte [4-6] / [4-7].</li><li>Vitocal 300-A, Typ AWO-AC 301.B:Anschluss J10 auf EEV-Leiterplatte: Siehe EEV-Leiterplatte [4].</li><li>Vitocal 300-A, Typ AWO 302.B:Anschluss J5 auf Reglerleiterplatte: Siehe Reglerleiterplatte [6].</li></ul></li></ul>
2025-02-25_14:32:26 vitoconnect device.messages.errors.mapped.1.faultCode: 07
2025-02-25_14:32:26 vitoconnect device.messages.errors.mapped.1.severity: Hinweis
2025-02-25_14:32:26 vitoconnect device.messages.errors.mapped.1.systemCharacteristics: Siehe Zusatzcode:Letzte Meldung aus Meldungshistorie Kältekreis
2025-02-25_14:32:26 vitoconnect device.messages.errors.mapped.1.faultCodes.1.cause: Meldung vom Kältekreisregler Wärmepumpe 1. Stufe
2025-02-25_14:32:26 vitoconnect device.messages.errors.mapped.1.faultCodes.1.measure: Diagnose, Kältekreis, Meldungshistorie beachten.
2025-02-25_14:34:26 vitoconnect device.messages.errors.raw.entries:

Viele Grüße
Schlimbo

[stefanru]

Hi Schlimbo, schaue ich mir an wenn ich wieder Zuhause bin.
Lässt sich besser darstellen.

Gruß,
Stefan

[Beta-User]

So, hatte mal wieder etwas Zeit, weitergeschraubt und mir dabei die API-Calls verbraucht...

Code folgt, wenn (morgen früh?) alles soweit wieder funktioniert, hier aber erst mal ein paar Gedanken und Anmerkungen:
- Für das define würde ich vorschlagen, dass man nur den user angeben muss, aber sowohl apiKey wie Passwort (nebst Intervall) optional direkt mit angeben kann; die beiden "secrets" würden dann direkt weggeschrieben und aus der DEF entfernt?
- Bisher gab es gar keine RenameFn(). Ich hätte jetzt eine im Angebot. Der Haken: das ganze funktioniert (bei allen RenameFn() lt. https://wiki.fhem.de/wiki/DevelopmentModuleIntro#X_Rename) allerdings nur dauerhaft, wenn man danach auch noch speichert. Da bei uns hier der user-Name Pflicht ist, könnte man auch einfach hergehen, und den (zusammen mit dem Modulnamen) als Kenner verwenden, dann könnte man sich das (weitgehend) sparen. "Lustig" wird das nur, wenn sich jemand beim user vertippt hat, das bekommt man dann nicht ohne weiteres aus der file wieder raus... Meinungen?
- Bei manchen Variablennamen habe ich Bauchweh: %translations, $client_secret, $callback_uri und ein paar andere sind imo eigentlich nicht verwechslungssicher, werden aber im main-namespace definiert. Das schafft definitiv spätestens dann Probleme, wenn jemand den Code als Blaupause für was eigenes verwenden will...
Also müssen wir entweder überall was unterscheidendes wie "vitoconnect_" davor schreiben, oder das Modul einpacken (ich würde letzteres vorschlagen).
- Was das "Verdoppeln" von Devices angeht, mals ins Unreine gesprochen:
Wir könnten Anfrageantworten doch schlicht so dispatchen, dass man andere Instanzen als Clients mit versorgt. Das ginge z.B., indem man im Define eines solchen Clients den Namen der Hauptinstanz als "IODev=xxx" mit angibt, zusammen mit einem weiteren Parameter für den Anlagenteil, den man in der Nebeninstanz haben will (z.B. "subset=0.heating"). Vorteil: Man könnte in den Nebendevices "schöne" Reading-Namen, set-Benennungen usw. haben, zu definieren über je eine eigene "Übersetzungsdatei", ohne dass der Anfrage-Aufwand steigt oder man irgendwelche Klimmzüge mit Ein- und Ausschalten machen muss.   

Meinungen?

[Beta-User]

Code folgt

Hmmm, das weekprofile wird zwar nicht versendet (vermutlich noch eine Frage der Payload, set_new scheint das anders zusammenzubasteln?), aber der Rest funktioniert anscheinend, ohne FHEM abzuschießen.

Daher hier meine aktuelle Fassung als Diskussionsgrundlage, ich komme vermutlich im Moment nicht wirklich dazu, das mit der Payload zu fixen.

[Beta-User]

OK, Fehler gefunden - das mit weekprofile funktioniert jetzt mit dem ersten Heizkreis .

Achtung: Da ist einiges geändert, wer testen will, muss zum einen FHEM neu starten und sollte zum anderen seine raw-Def irgendwohin wegsichern, weil die DEF selbst dann angefasst wird. So kann man gleich das echte Passwort und den apiKey übergeben, das wird dann intern weggesichert und nachträglich aus der DEF entfernt . Vorschlag für die neue commandref:

Code Auswählen Erweitern

define vitoconnect vitoconnect user@mail.xx password=somesecretthing apiKey=someothersecret 60

[stefanru]

Hi Beta-User,

bin zurück vom Urlaub.

Danke für deine Arbeit.
Zur Zeit habe ich noch einiges abzuarbeiten was liegen blieb während meines Urlaubs aber ich würde mir deine Änderungen danach anschauen.
Ist die Version die, die dann ins Repo sollte oder bist du noch weiter am Arbeiten daran?

Danke und Gruß,
Stefan

[Beta-User]

Erst mal: Willkommen zurück!

Lass dir Zeit beim Ankommen.

Meine Fassung ist - soweit erkennbar - funktional, aber
- das nur mit der passenden weekprofile-Version,
- nicht intensiver getestet
- in manchen zentralen Punkten, "anders", v.a., was die Einrichtung angeht.

Man könnte das jetzt in Abschnitten angehen, aber vermutlich wäre es besser, wenn
- zumindest du (und ggf. weitere User) die Änderungen mal eine gewisse Zeit am Laufen hast (und das gut findest), und
- Risiko das in weekprofile übernommen hat, was da an Änderungen vorzunehmen wäre. Ich pinge ihn dazu jetzt mal an (erledigt, siehe https://forum.fhem.de/index.php?topic=46117.msg1338915#msg1338915).

Dann würden wir in der Zwischenzeit ggf. weitere Schritte überlegen:
- die Topic-Änderung auch an was anderes durchreichen wie im Moment nur den 0-er Heizkreis. Ich hätte da zwar ein paar unreife Gedanken dazu im Kopf, aber auch eher wenig Zeit, das anzugehen...
- Sub-Devices (z.B. für das Brauchwasser) ermöglichen? Das ginge jetzt vermutlich mit der geänderten DEF-Logik relativ einfach (ich müßte mal in den Code von snapcast schauen), und angrenzend:
- wie ist das mit eventuellen "Übersetzungsfiles"?

[stefanru]

Hi @Schlimbo,
zu deiner Anfrage der HTML Fehler.
Ich versuche gerade herauszufinden wo das gelogged wird, bin aber etwas unschlüssig.
Da ich gerade keine Fehler bei meiner Anlage bekomme, ist es schwer für mich nachzuvollziehen.
Hast du vielleicht noch etwas davor und danach?
Außerdem fehlt mir irgendwie die Severity der Meldungen?

@ Uwe S.
Ich würde mir dein Problem mit dem Mapping auch gerne anschauen.
Könntest du mir zuerst mal das File resource_[seriennumemr].json aus dem FHEM Log Verzeichniss schicken?
Danach würde ich schauen dass wir debugging für dich einbauen und du das dann testest.


Gruß,
Stefan