Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Geesthachter]

@black-thunder
Ich bekomme es nicht hin. Aber egal so wichtig ist es mir momentan nicht.

Als Anregung für andere Nutzer, ich habe bei mir noch über ein Blockly einen Timer integriert.
Darüber kann ich einstellen wie lange die Klimaanlage laufen soll.

So sieht es dann in meiner Iqontrol Visualisierung aus.

Hier das Blockly als Bild

und hier das Blockly zum kopieren
Blockly Timer Klimaanlage.txt

dafür habe ich diesen Datenpunkt erstellt
0_userdata.0.Datenpunkt.Klimaanlage.Timer_Zeitbegrenzung

Björn

[derrapf]

@black-thunder
Ja genau. In der Mel-Cloud sehe ich auch nichts. Wo könnte man denn da fragen? Weil schön wäre es ja schon wenn ich da was hätte...

Gruss Ralf

[derrapf]

@darkblu sagte in Test Adapter melcloud v1.1.x Latest:

@derrapf
klickst du denn auch auf „getPowerConsumptionReport“ ?

Bei mir funktioniert das manchmal, aber auch nicht immer.

...
Eins noch in eigener Sache, wie kann ich den Button bei „getPower…“ eigentlich per VIS betätigen ?

Ich hab da keinen Button den ich drücken könnte:

Aber ich kann den Datenpunkt ja auf true setzen (ist er ja schon). Deswegen sind wahrscheinlich auch ein paar Werte da.

Zu Deinem Problem: In Vis kannst Du ja ein Feld das einen Boolean setzt verwenden und den Datenpunkt auf true setzen.

Gruss Ralf

[oxident]

Ich verzweifel auch an dem Abruf des Verbrauchs. Bei mir sind die Daten in der App zwar vorhanden, meine Auswertelogik will aber nicht.

Gerne würde ich per Skript jeden Tag (z. B. um kurz nach Mitternacht) den kompletten Gesamtverbrauch abrufen. Den kann ich ja dann entsprechend verarbeiten und Tagesverbräuche ausrechnen.

Hierzu wollte ich eigentlich den getPowerConsumptionReport-DP per setState auf true setzen. Das scheint aber nur beim ersten Mal geklappt zu haben.

Daher folgende Frage: Könnte es sein, dass man den Wert per Skript erst auf false und dann wieder auf true setzen muss?

[Black Thunder]

@oxident Du hast Recht. Bisher wurde nur auf eine Änderung des Werts von true auf false bzw. andersum reagiert. Habe gerade auf GitHub eine Anpassung hochgeladen, mit der jetzt immer auf den State "getPowerConsumptionReport" unabhängig vom Wert getriggert werden sollte. Bitte einmal die aktuelle Version von dort installieren und Bescheid geben, ob es jetzt klappt.

Unabhängig davon habe ich allerdings gerade bemerkt, dass es mit dem Abruf der Reports noch andere Probleme gibt und das im Moment nur für monatsübergreifende Reports richtig verarbeitet wird. Da muss ich mir noch Gedanken machen, wie ich das am besten noch für tagesgenaue und jahresübergreifende Berichte einbaue.

Aktuell ist es ja so, dass für jeden Monat und jeden Betriebsmodus ein separater State angelegt und mit dem entsprechenden Verbrauchswert befüllt wird. Ist das überhaupt nötig oder würde da statt aufgedröselten Einzelwerten ein kumulierter Wert auch reichen? Oder das Ganze nur in einem State als JSON aufbereitet?
Dann würde sich das Problem mit den verschiedenen möglichen Berichtszeiträumen etwas vereinfachen. ;)

[darkblu]

Also, mir würde Monat reichen, aufgedröselt nach Betriebsmodus bräuchte ich nicht

[oxident]

@black-thunder Jepp, sehe ich auch so. Die beiden Issues sind übrigens von mir ;-)

Die Warnungen beim täglichen Abruf sehe ich auch. Klappt aber dennoch.

[oxident]

@black-thunder said in Test Adapter melcloud v1.1.x Latest:

@oxident Du hast Recht. Bisher wurde nur auf eine Änderung des Werts von true auf false bzw. andersum reagiert. Habe gerade auf GitHub eine Anpassung hochgeladen, mit der jetzt immer auf den State "getPowerConsumptionReport" unabhängig vom Wert getriggert werden sollte. Bitte einmal die aktuelle Version von dort installieren und Bescheid geben, ob es jetzt klappt.

Yes, klappt. Danke!

[oxident]

@black-thunder said in Test Adapter melcloud v1.1.x Latest:

Aktuell ist es ja so, dass für jeden Monat und jeden Betriebsmodus ein separater State angelegt und mit dem entsprechenden Verbrauchswert befüllt wird. Ist das überhaupt nötig oder würde da statt aufgedröselten Einzelwerten ein kumulierter Wert auch reichen? Oder das Ganze nur in einem State als JSON aufbereitet?
Dann würde sich das Problem mit den verschiedenen möglichen Berichtszeiträumen etwas vereinfachen. ;)

Also ich denke, jeder wird hier vermutlich eigene Auswertungen fahren. Ich für meinen Teil bräuchte in der Tat nur einen "Gesamtverbrauch" für den definierten Zeitraum. Wegen meiner gerne nach Modus getrennt. Cool wäre halt, wenn's zusätzlich gleich für alle Klimageräte zusammen sein könnte.

Ich denke, die Aufteilung nach Monaten usw. kann man ja über Skripte selber lösen. Würde auch viel übersichtlicher im Objektbaum sein ;-)

[Black Thunder]

@oxident said in Test Adapter melcloud v1.1.x Latest:

@black-thunder said in Test Adapter melcloud v1.1.x Latest:

@oxident Du hast Recht. Bisher wurde nur auf eine Änderung des Werts von true auf false bzw. andersum reagiert. Habe gerade auf GitHub eine Anpassung hochgeladen, mit der jetzt immer auf den State "getPowerConsumptionReport" unabhängig vom Wert getriggert werden sollte. Bitte einmal die aktuelle Version von dort installieren und Bescheid geben, ob es jetzt klappt.

Yes, klappt. Danke!

Wunderbar, immerhin schon mal ein Problem vom Tisch. ;)

Zwecks der weiteren Anpassungen am Report mach ich mir noch ein paar Gedanken zur genauen Ausgestaltung und gebe hier wieder Bescheid, wenn's was zum Testen gibt. Danke auf jeden Fall schon mal fürs Feedback.

[Black Thunder]

So, folgende Anpassungen habe ich gerade auf GitHub hochgeladen:

• Der "reports"-Channel wurde umstrukturiert, daher am besten diesen Channel vor dem Update auf die neue Version löschen. Direkt darunter liegen als States jetzt nur noch "startDate", "endDate" und "getPowerConsumptionReport". Daneben gibt es jetzt zusätzlich als Subchannel "lastReportData", der nun alle abgerufenen Werte beinhaltet.
• Unter "lastReportData" liegen jetzt nur noch kumulierte Werte pro Betriebsmodus und ein komplett kumulierter Wert aller Betriebsmodi zusammen für den ausgewählten Berichtszeitraum. Damit entfallen alle anderen States, die bisher auf Monatsebene heruntergebrochen waren. Zusätzlich gibt es den neuen State "rawPowerConsumptionData", der die Berichtsdaten in kompletter Rohform als JSON enthält. Damit kann dann noch allerlei individueller Schindluder getrieben werden, wenn gewünscht. ;)
• "startDate" und "endDate" dürfen damit jetzt auch gleich sein

Sieht dann ungefähr so aus:

Bitte gerne mal von GitHub die aktuelle Version installieren und testen, ob alles wie gewünscht funktioniert oder noch Fragen offen sind. Wenn alles passt, werde ich noch die Doku entsprechend anpassen.

@oxident said in Test Adapter melcloud v1.1.x Latest:

Cool wäre halt, wenn's zusätzlich gleich für alle Klimageräte zusammen sein könnte.

Das schau ich mir dann im Anschluss noch an. Lässt sich bestimmt irgendwie realisieren. ;)

[oxident]

@black-thunder Perfekt. Läuft wie geschmiert.
Jetzt kann ich endlich den aktuellen Tagesverbrauch ohne umständliches Abziehen des Vortageswerts ermitteln.

Danke ;-)

[Black Thunder]

@oxident
Ich habe mal wieder was Neues gebastelt und die gewünschte Funktionalität eingebaut, geräteübergreifend Berichte abzurufen und zu kumulieren. Dazu gibt es jetzt auf "root"-Ebene einen neuen Channel "reports", der genau wie die gerätespezifischen Channels strukturiert ist. Wird nun dort der Abruf gestartet, werden im Hintergrund alle Geräte einzeln abgerufen und im Anschluss als kumulierte Datenpunkte im neuen Channel abgelegt. Sieht dann wieder so aus in etwa:

Auf GitHub wartet die entsprechende Version darauf, getestet zu werden. ;)

[oxident]

@black-thunder Mega danke. Das vereinfacht mein Blockly doch enorm...

Jetzt kann ich endlich schauen, ob sich das Heizen mit Klima (und PV) besser schlägt als die Gastherme.

[fdr]

@black-thunder
Mir ist aufgefallen, dass meine Verbrauchsdaten in der MECloud dem falschen Gerät zugewiesen werden. Das Innengerät im Schlafzimmer hat Verbrauchsdaten in der Größenordnung des Innengerätes im Wohnzimmer und umgekehrt.
In der MECloud habe ich alles noch einmal neu angelegt, auf Etagen und Bereiche verzichtet. Hat aber nichts geholfen.
Bei der Suche nach Tipps bin ich auf diesen Post gestoßen und antworte, weil auch diese Zahlen bei mir nicht stimmen.
Siehe Screenshot (alle Reports sind von oben nach unten frisch angefordert). Die Summen stimmen nicht.
Liegt es vllt daran, dass die MECloud die Geräte nicht richtig löscht?

[Black Thunder]

@fdr Um da mehr zu sagen zu können, bräuchte ich bitte ein genaueres Log des Adapters, wenn du die Berichte abrufst. Am besten die Logstufe auf "silly" stellen und dann die Berichte abrufen, da wird wirklich alles protokolliert. Bevor du das hier postest (oder gerne auch per PN), bitte deine persönlichen Daten (Zugangsdaten etc.) entfernen.

[oxident]

Habt ihr in den letzten Tagen eventuell auch Stress mit ständigen Verbindungsabbrüchen zur Melcloud? Ich versuche gerade, herauszufinden, ob es am meinem Netz, dem Adapter oder der Melcloud-API liegt.

Bei mir wechselt der deviceOnline-DP mehrmals pro Stunde von true auf false ohne erkennbaren Grund. Das Gerät selber ist permanent im Netz und die Melcloud-Webseite auch erreichbar.

[fdr]

@oxident geht mir auch so.

[darkblu]

Wie schonmal geschrieben, ist meine Verbindung zur Melcloud
praktisch nie vorhanden.
Bedienung der Klimaanlage per App oder ioBroker funktioniert aber immer.
Ich glaube nicht, dass es an Mitsubishi liegt.

[Black Thunder]

Ab und an kommt es bei mir auch vor, dass "deviceOnline" kurzzeitig auf "false" springt. Das renkt sich aber in der Regel nach kurzer Zeit von selbst wieder ein.

@darkblu
Was meinst du mit "Verbindung zur Melcloud"? Dass einzelne Geräte via "devices.XXX.info.deviceOnline" offline angezeigt werden oder die grundsätzliche Verbindung ("info.connection") nicht zustande kommt? Und die Steuerung über den Adapter funktioniert dann in dieser Zeit aber trotzdem?
Du kannst gerne mal einen Debug-/silly-Log (persönliche Daten unkenntlich machen) posten, wenn das Problem auftritt. Dann sehe ich zumindest, ob diese Werte schon so aus der Cloud gemeldet werden oder diese evtl. falsch im Adapter verarbeitet werden.