DrozmotiX / ioBroker.tado

Tado cloud connector to control Tado devices
MIT License
23 stars 13 forks source link

Datenpunkt History mit Tado-DayReports befüllen #376

Open seb2010 opened 3 years ago

seb2010 commented 3 years ago

Über den API-Call https://my.tado.com/api/v2/homes/?????/zones/5/dayReport?date=2021-10-20 kann man Daten wie:

für historische Zeitpunkte auslesen. Da man den History-Adapter ja leider gefühlt immer zu spät für Datenpunkte aktiviert, wäre es sehr spannend, wenn der Tado-Adapter die historischen Werte per API auslesen und in die History der zugehörigen Adapter-Datenpunkte mit den richtigen Zeitstempeln einfügt. Konkret geht es mir um die drei Datensätze oben. Heizlevel ist dabei dann der activityDataPoint.heatingPower.percentage.

Das parsen der Werte sollte nicht das Problem sein, das schreiben der Werte in die History im richtigen Intervall dann aber ggf. schon. Bin hier gerne für Testing und Input bereit. Beim Heizlevel "callforheat" müsste man dann noch die Werte high,medium,low,none in Prozente wie 100%,50%,30%,0% übersetzen (das sind nach vergleich mit den echten History-Werten in etwa die Schwellwerte).

Meint ihr das lässt sich machen? Wie man in die History-schreibt weiß ich leider noch nicht. Ggf. könnte ich sonst auch ein Script-Beispiel ohne Adapter beisteuern.

HGlab01 commented 3 years ago

Mittels einem Script ist es wirklich einfach. Da es eher eine Art von "Migration" ist, bin ich mir sehr unsicher, ob das in den Adapter gehört.

So bekommst du einen Wert (value) zu einem Datenpunkt (stateID) für einen gewissen Zeitpunkt (pointInTime)

function Monitoring(stateID, value, pointInTime) {
    sendTo('history.0', 'storeState', {
        id: stateID, state: {
            'val': value,
            'ack': true,
            'ts': pointInTime,
            'q': 0
        }
    });
};
DutchmanNL commented 3 years ago

Mittels einem Script ist es wirklich einfach. Da es eher eine Art von "Migration" ist, bin ich mir sehr unsicher, ob das in den Adapter gehört.

ich wuerde sagen es ist kein "Core-Feature" obwohl die Funktionalität praktisch sein kann. Da ich selber nicht in der Gelegenheit sein werde dies zu implementieren überlasse ich die funktionelle Entscheidung dazu @HGlab01.

Eventuell könnten man auch ein script template dafuer bereit stellen und nicht fest im adapter verankern. Das concept vom adapter ist im gründe "Jetzige werte darstellen" und damit laufen die backend Prozesse wie scripts und daten logging. Historische daten passen nicht ganz in das core concept