Timestamp in the VITALS vitals response

[JohnJ9ml]

I'm not sure this is the case, but it does look to me as though the VITALS property set at the bottom of the vitals() output is generated by the library and not the API. I ask because the timestamp property in here is just a raw Python ts. It's the only "timestamp" in the entirety of my data over the past several years that is anything other than a dateTime-style output.

Is there a reason this needed to be a raw ts number? It blows up the indexing in my database (which I've worked around for now), but I expect that over time I'm going to get annoyed by the diagnostics and potential false positives from query results. I can probably just rewrite the contents and fix this myself, but this is the only place I've run into this, and I want to be sure this is a library-produced value before deciding to take any action.

Or, could it possibly be changed at the library layer?..... ;)

[jasonacox]

Hi @JohnJ9ml - you are correct. It is a simple pythonic ts, but we can change it to whatever makes the most sense.

I believe this is the section of code we s hould change:

pypowerwall/pypowerwall/tedapi/__init__.py

Lines 1004 to 1009 in 2c93ce9

	header["VITALS"] = {
	"text": "Device vitals generated from Tesla Powerwall Gateway TEDAPI",
	"timestamp": time.time(),
	"gateway": self.gw_ip,
	"pyPowerwall": __version__,
	}

I have PR stage and could likely pull this into that. Let me know what you propose as to the replacement.

[JohnJ9ml]

I confess the only Python code I've written (basically stolen) is from this project, so I know I'm not a good one to have too much of a say.
Were it me, I'd naturally just be doing something in the ISO 8601 realm: 2013-02-14T13:15:03-08:00
However, I know I'm not the best person to state an opinion when I'm poaching an entirely different language.
I'd also want to be sure there wasn't a larger body of code counting on it to be as it currently is.

[jasonacox]

The old vitals payload doesn't have a VITALS section. In fact, the entire vitals payload has been deprecated by Tesla (API is gone). The pypowerwall library now simulates it by pulling in the data from other payloads including extended metrics from TEDAPI.

The old vitals payload, example https://github.com/jasonacox/pypowerwall/blob/main/docs/vitals-example-latest.json , seemed to use timestamps similar to pythoinc time() data (seconds since the Epoch) for lastCommunicationTime so that is why I followed that, but we could add another field if that helps you. Are there other timestamp data elements that are causing problems?

[JohnJ9ml]

What happened to me was more naive and unsuspecting: it's actually the name of the property more than the contents that "done me in".
I've got years of data from my house from every possible utility in a MarkLogic database. I have an index on "timestamp" from data that came from several devices that always was in ISO 8601 format date/time values. I'd never run into a problem, so the index was set to reject invalid values - but that makes the index blow up with this latest introduction.

If the property had been called anything else - even just ts - I'd have been in good shape.

I've been trucking along with the library output (and having a blast getting this all incorporated into the system - love the efforts and how easy this all has been!), and once I got hooked up directly to the gateway directly I decided today to enable the vitals processing. Boom!

Most everything else I've seen in the output looked like dateTime strings. I'd not noticed any other pythonic epochs in the data. All the data I'm seeing for last_communication_time or last_toggle_timestamp look stringy to me.