Add last_updated and last_changed fields for debugging purposes

[dbrgn]

last_updated wird bei jedem erfolgreichen POST vom sensor updated.

last_changed wird immer geändert wenn sich die anzahl personen ändert.

[rnestler]

last_updated könnte man direkt über die mtime des files herausfinden: datetime.datetime.fromtimestamp(os.path.getmtime('people.txt')) bzw. für UTC datetime.datetime.utcfromtimestamp(os.path.getmtime('people.txt'))

[rnestler]

So ala b27dd9b

[dbrgn]

Guter Punkt :) Werde ich gleich mergen.

Die Frage ist noch, wie die Daten in der JSON Response codiert werden.

[dbrgn]

Last change:

{
    "state": {
        "lastchange": 123123123
    }
}

Last update:

{
    "events": [
        {
            "name": "Presence Switches",
            "type": "updated_status",
            "timestamp": 123123123
        }
    ]
}

[rnestler]

Gemäss der Doku:

lastchange (number)
Description
The Unix timestamp when the space status changed most recently

Unser timestamp zeigt aber die Änderung der Anzahl Personen, nicht des Status.

[dbrgn]

Das ist doch auch eine Statusänderung :)

[rnestler]

Ja aber keine Änderung des ''state'' Objekts, aber ich bin wahrscheinlich ein wenig zu pedantisch 😉

[dbrgn]

In unserem Fall schon, da sich die message im "state" Objekt ändert. Hast du eine bessere Idee?

[rnestler]

Ich hätte es ebenfalls in "events" eingetragen, habe aber mittlerweile meine Meinung geändert 😄 Wir ändern ja tatsächlich unseren Status.

[rnestler]

Für last_changed müssen wir uns wohl den alten Wert merken. Gibt es dafür eleganteres als eine globale Variable?

[dbrgn]

Am besten diskutieren wir das morgen :) Entweder ein zweites File, oder gleich eine file based database. Oder eben globale variablen (yuck).

[rnestler]

Hier mal mit globals 237b5b9 als Diskussionsgrundlage für Morgen ;)

[rnestler]

This ticket did concern the python implementation, didn't it? So why the rust label?

[dbrgn]

Because we still want that feature :)