Neues Modul: vitoconnect

87insane · 04 Dezember 2024, 22:22:18

Hey und hallo,

danke für deine schnelle Nacharbeit.

Zuerst das Gute:
Ich kann mit der neuen Version auch schalten. Das klappt also super. Getestet habe ich die Temp Werte und auch mal an und aus. Also das was ich brauche geht nun alles.

ABER und nun das wirklich Schlechte:
Sobald ich deine Modul Version nutze und meinen Server neu starte, kommt mein FHEM nicht mehr hoch. Ich habe nun wieder ewig gesucht und nicht gefunden, warum dem so ist. Wenn ich das Modul wieder rauß nehme, neu starte, ist mein FHEM in 10 Sekunden wieder da.
Zuerst dachte ich das es meine beiden Zigbee Instanzen sein könnten. Die waren es aber nicht. Danach hatte ich Grafana im Verdacht. Das war es auch nicht. Und zu guter Letzt, woran ich nicht geglaubt habe, das Modul entfernt.

Im FHEM Log gibt es leider keinerlei Hinweise, warum das so sein könnte. Bei einem Systemdienst Neustart von FHEM dauert das beenden sehr lange. Innerhalb von top sehe ich auch das sich Perl im Kreis drehen muss. Denn die CPU steht bei 100%. Irgendwas ist beim init des Modul nicht grade.

Infos die ggf. helfen könnten:
- Wenn man das Modul herunter lädt (egal über welchen Weg) geht erstmal alles.
- Wenn man danach neu startet, ist der System Dienst ok, Perl dreht aber am Rad.
- Das einzige was ich im LOG finde ist:

Code Auswählen

Can't use an undefined value as an ARRAY reference at ./FHEM/98_vitoconnect.pm line 3907.
Das wiederum ist in meinen Augen die Gateway Funktion. Bisher hatte ich noch Kein Modul bei dem ich derartige Verhalten gesehen habe. Dieses Verhalten gab es auch in der Version, in der ich nicht schalten konnte.

Off Tpic:
Aktuell bin ich beruflich unterwegs und konnte leider nicht schneller reagieren.
Ich finde es mega, dass du dieses Modul nochmal in die Hand nimmst. Ich wünschte für Unifi und Unifi Protect würde das mal einer machen. Ggf. hast du ja auch Unifi Hardware ^^

Spaß bei Seite. Es auch Sinn, dass du einen Link in diesen Thread steckst, der auf einen neuen verweist. So kannst du die ganzen Änderungen usw. immer schön im ersten Post anhängen. Bei 75 Seiten sucht man sich schonmal verrückt. Das ist bei FHEM mittlerweile öfter so. Mein Perl reicht nicht aus um das alles zu überarbeiten. Daher kann ich hier nur Hilfe bei Fehlersuche anbieten oder irgendwas übersetzten. Für die ganzen Readings (oben im Post) würde ich das nachholen, wenn ich das Modul sorgenfrei nutzen kann.

Gruß,
87Insane

stefanru · 04 Dezember 2024, 22:32:48

So,

das war ein ganz schöner Mist.
Mit den mehreren Gateways habe ich mir beim neuen einplanen der Timer einen Bock geschossen.
Verzeiht mir ich habe noch nie so einen massiven Umbau an einem Modul vorgenommen.

Wenigstens denke ich genau verstanden zu haben was passiert ist.
Ich hoffe den Fehler auch in allen Rand Fällen gelöst zu haben.

Der Fehler war nicht neu, ich konnte ihn nicht sehen da ich eine Serial vorgebe, da ich ja 2 Gateways habe.

Ein Bug im Coding hat beim Update dazu geführt, dass er keine Gateway Serial fand und somit wieder eine Initialisierung startete.
Diese geht dann durch braucht aber 3 API Calls.

Auch hat er sich bei 2 Gateway Calls 2 Timer gegönnt, in denen er jeweils beide Gateways abgefragt hat.

Ich habe auch ein Logging mit Verbose 4 an dieser Stelle eingebaut.
Jeder Call wird mit " - enter getResource gw: " aufgeführt.

Version ist wie immer auf dem Git, aber ich hänge sie auch hier an, da sie einen schweren Fehler behebt.

P.S.: @87insane
Kannst du das durchstarten nochmal testen? Es hat sich jetzt so viel verschoben dass ich nicht mehr wirklich nachschauen kann.
Aber das ganze kann sich durchaus auch auf das durchstarten ausgewirkt haben.
Das mit dem neuen Thread habe ich mir auch überlegt. Aber habe am WE auch erstmal Urlaub. Danach gehe ich das an.
Auch wäre es super wenn du oder auch andere die das alte Mapping nutzen Verbesserungen melden. Ich pflege sie gerne ein.

Danke und Gruß,
Stefan

87insane · 04 Dezember 2024, 22:49:14

Hey stefanru,

alles kein Thema nur nervige Such-Arbeit....

Ich kann für heute leider nicht mehr testen. Hab meine API Calls überschritten. Denke mal durch das ganze Testen. Morgen Abend kann ich mich dazu nochmal melden.
Was ich aber jetzt schon sagen kann, ich habe die neue Version geladen, den Viessmann Server neu angelegt und Fhem kommt auch wieder hoch. Denke das sollte keinen Unterschied machen ob ich noch Calls überhabe oder nicht.

PS: Die Meldung im LOG ist auch weg. Bin ich mal auf morgen gespannt.

Danke!

stefanru · 04 Dezember 2024, 23:05:12

Super, das klingt schonmal gut.
Ja das die Calls aufgebraucht sind sollte am Startup eigentlich keinen Unterschied machen.

Gruß,
Stefan

buec65 · 05 Dezember 2024, 07:00:06

Hallo stefanru,

bei einen kurzen Test über 18 Minuten wurden auf beiden Installationen zusammen 12 Abfragen in der API registriert, sieht sehr gut aus.

Bei mir wird das nur zum Monitoring verwendet zum setzen von Werten kann ich leider keine Auskünfte geben.

Danke für die schnelle Anpassung

Gruß Stefan

stefanru · 05 Dezember 2024, 09:38:32

Perfekt, vielen Dank für die Rückmeldung.
Das passt genau bei dir, da bin ich froh das es klappt.

Hier für alle Wärempumpen Besitzer, getestet mit einer VitoCal250AH 2 User Readings die fehlende Datenpunkte von Viessmann selbst berechnen.

heat.pump.thermal.power { 1.162222 * ReadingsVal("$name","heating.sensors.volumetricFlow.allengra.value", undef) * ( ReadingsVal("$name","heating.boiler.sensors.temperature.commonSupply.value", undef) - ReadingsVal("$name","heating.sensors.temperature.return.value", undef) )},
heat.pump.deicing {ReadingsVal("$name","heat.pump.thermal.power", undef)<0?"on":"off"},

Thermal power, wird aus Volumenfluss * 1,162222 (spezifische Wärmekapazität von Wasser (4184 Joules/kg/K) geteilt durch 3600) * Temperaturunterschied Vorlauf und Rücklauf berechnet.
Enteist wird wenn dieser Wert negativ wird.

Viele Grüße,
Stefan

ph1959de · 05 Dezember 2024, 10:45:58

Hallo Stefan ... und alle anderen aktiven (Mit-)Nutzer des Moduls vitoconnect.

Ich bin gerade über die Versions-/Funktions-/Entwicklervielfalt dieses Moduls "gestolpert" ... und möchte dafür plädieren, da mal etwas aufzuräumen. Meine Vorschläge dazu:

Stefan (stefanru) - Deine Version des Moduls scheint die derzeit aktuelle und auch die einzige aktiv gepflegte zu sein. Würdest Du bitte ein neues Thema zu dem Modul hier im Forum aufmachen? Dann bist Du der "Herrscher" über den ersten Beitrag und kannst da den Status pflegen und die jeweils letzte Version des Moduls zum Download zur Verfügung stellen
Ich werde diese Info dann anschließend in die Wiki Seite zum Modul einfügen und auch die "Eigentumsverhältnisse" und den Status da reflektieren
Version "Roger" (z.B. hier) - wird die noch benutzt / gepflegt oder ist sie mittlerweile komplett durch Version "stefanru" ersetzt? Auch da empfiehlt sich, ein eigenes Forenthema aufzumachen.
Dieses Forenthema sollte anschließend mit Verweis auf die neuen Themen geschlossen werden
Wie weit ist die Version "stefanru" von der "offiziellen" (Marc/Andreas) entfernt? Könn(t)en Benutzer der "Originalversion" (relativ?) problemlos auf Version "stefanru" updaten?
Stefan - könntest Du Dir vorstellen, offizieller Maintainer von 98_vitoconnect.pm zu werden (oder - falls inkompatibel zur Originalversion von einer neuen, offiziellen Variante)?
Ich werde den daraus resultierenden Status auf jeden Fall im Wiki dokumentieren.

stefanru · 05 Dezember 2024, 10:53:00

Hi @ph1959de,

danke für deinen Input.
Ja genau neuer Thread will ich machen.
Ich könnte das Modul auch übernehmen wenn gewünscht.
Meine Version beinhaltet letzte SVN und Roger. SVN ist standard.
D.h. es ist kompatibel, wenn du das Modul normal verwendest und nicht anders parametrrisierst merkst du keinen Unterschied zu SVN.

Die ganzen Punkte muss ich aber noch etwas schieben. Mir geht die Zeit aus.
Aber ich melde mich wieder sobald ich Zeit finde einen eigenen Thread zu starten und es wäre natürlich super wenn du das Wiki übernehmen und updaten würdest.

Das hat eventuell auch den Vorteil das wir mit einer halbwegs getesteten neuen Version starten und der Thread nicht gleich voll mit Bugfixen ist.

Gruß,
Stefan

ph1959de · 05 Dezember 2024, 11:56:52

Ich habe einen kurzen Update ins Wiki gestellt, um auf die derzeitige Versions-/Maintainersituation aufmerksam zu machen.

Ich fände es gut, es gäbe jetzt einen neuen Thread (damit Du die Kontrolle über die Versionsstände hast - im Augenblick gibt es Modulupdates in diversen Forenbeiträgen) - der kann dann ggf. auch die Zusammenführung ins SVN begleiten. Wenn Deine Version zur offiziellen Version wird (und Du im Idealfall der neue Maintainer), kann die Diskussion ja auch wieder hierher "umziehen".

stefanru · 05 Dezember 2024, 12:14:21

Hi @ph1959de,

danke für das update im Wiki.
Bitte gib mir Zeit bis nächste Woche.
Es passt gerade gar nicht bei mir.

Dann schaue ich dass ich einen neuen Thread erstelle und ein paar Infos zu den wichtigsten Änderungen reinschreibe, die du dann auch fürs Wiki übernehmen kannst.

Da ich solch eine Heizung jetzt besitze und das Modul auch verwenden will kann ich gerne erstmal das Modul übernehmen.
Weiß aber auch nicht was für die Übernahme eines Moduls zu tun ist.

Wie gesagt gib mir mal eine Woche Zeit dann stellen wir das auf ordentliche Füße.

Danke und Gruß,
Stefan

stefanru · 05 Dezember 2024, 19:45:10

Noch ein letzter Fix vorm Wochenende.
Das Flag von logRespnceOnce wurde nicht wieder entfernt.
D.h. das File resource_[gateway].json wurde wenn einmal logResponseOnce ausgeführt wurde immer und immer wieder geschrieben.

Der Bug war schon immer im Modul und ist mit der neusten Version aus dem GIT behoben.
https://github.com/StefanRu1/FHEM/raw/refs/heads/main/FHEM/98_vitoconnect.pm

Gruß,
Stefan

wieral · 06 Dezember 2024, 12:24:58

Hallo Community

In den letzten 10 Tagen habe ich wiederholt Probleme mit der Meldung "Anzahl API Calls überschritten".
Bei einer Überprüfung im Developer Portal ergaben sich mal 1,2 oder sogar 7 transactions bei einem Call.

Desweiteren ergaben sich Unstimmigkeiten im Timing. Im Intervall sind 360 Sek. definiert, aber der call findet nach ca. 174 - 186 Sek. statt.

Version: 98_vitoconnect.pm 2024-12-04
Definiert ist RAW mit userreadings für die Übersetzung.
Ein reboot hat keine Veränderung ergeben.

Irgend eine Idee?
Gruß Ralf

stefanru · 06 Dezember 2024, 12:54:18

Hi Ralf,

ja es gab einige Bugs mit den internal Timern.
Den letzten habe ich gerade behoben wenn man das Intervall ändert und so ein redefine des Devices auslöst, den Bug gab es aber schon immer.

Bitte versuche nochmal die letzte Version des Moduls aus meinem Git.
https://github.com/StefanRu1/FHEM/raw/refs/heads/main/FHEM/98_vitoconnect.pm

Danach unbedingt einen FHEM restart machen um alte Timer Leichen loszuwerden.
Ich hoffe damit ist alles behoben.

Sollte dies wider erwarten nicht der Fall sein gib mir gerne bescheid.
Bitte mit verbose 4 auch ein Logfile erzeugen und anhängen, falls der Fehler doch nochmal auftritt.

Es gibt auch eine Möglichkeit sich die internal Timer anzeigen zu lassen, siehe:
Siehe: https://forum.fhem.de/index.php?topic=85958.0

Viele Grüße,
Stefan

wieral · 07 Dezember 2024, 11:56:04

Hallo Stefan,

erst einmal Danke für deine Arbeit.
Deine Anweisungen haben prima funktioniert. Alles läuft wie gewünscht.

Nun habe ich eine weitere Frage. Meine WP arbeitet mit den Viessmann Smart Home Thermostaten ViCare ZK03840 zusammen.
Ich denke sie sind in dem Reading "device" ["type:E3","type:actuator","type:radiator","type:smartRoomDevice"] zu erkennen.
Gibt es dazu noch mehr Informationen wie Soll/Ist Name des Device?

Vielen Dank für deine Bemühungen.

Gruß Ralf

87insane · 07 Dezember 2024, 23:44:24

@Stefanru: Ich muss mich leider erst darum kümmern mein FHEM wieder sauber zum laufen zu bekommen. Zeitgleich mit dem Thema des Moduls habe ich wohl noch irgendwas anderes gefangen. (https://forum.fhem.de/index.php?topic=140014.msg1327186#msg1327186)

Wenn alles wieder geht, kann ich hierzu wieder was sagen. Leider habe ich noch keine Idee wie das alles im Zusammenhang steht. Habe das Modul in dem anderen Thread nicht benannt, da ich es testweise gelöscht habe. Daher kann es nicht das gleiche sein wie eine Version zuvor.