Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

forward "dateutc" station timestamp #1079

Closed
wolfgangr opened this issue Aug 24, 2024 · 3 comments
Closed

forward "dateutc" station timestamp #1079

wolfgangr opened this issue Aug 24, 2024 · 3 comments
Labels
stale There has not been activity on this issue or PR for some time

Comments

@wolfgangr
Copy link

Problem:
in "raw" messages, I find
"runtime": "30397", "heap": "24360", "dateutc": "2024-08-22 00:06:13",
in processed messages, I find no human/SQL readable readable timestamp any more:
"runtime": 89577.0, "heap": 24152.0,
When we have latency e.g. due to network issues, timestamp is not reliable.

Proposed solution:
1st prio: simply forward "dateutc" field from raw to processed message format
2nd prio: may be, from "runtime" and "heap", we can form a true timestamp?
3rd prio: generate a timestamp by ecowitt2mqtt

Context:
I'm writing (among others) values to a MariaDB/MySQL database for historic log and special evaluations.
Time and station number comprise the raw data table's primary index.
Currently I use "current" system timestamp in the DB-update script.
This works ok in a local network without much latency.

At least a second remote station shall be connected via a third mosquitto in the internet via mqtt-bridging.
So, we may expect larger latency, outages, messages resent and stuff like that.
If genuine timestamp were kept in the data sets, data would be inserted at correct time even at delayed replay of larger amout of data.

Is the dateutc generated by all stations at all?
My current test station is a HP2551.
A WS2910 and a Gateway 1100 are in the shipment pipeline.

@wolfgangr
Copy link
Author

searching the source on github, I find

data.py#L190C1-L196C2:

DEFAULT_KEYS_TO_IGNORE = [
    "PASSKEY",
    "dateutc",

I might understand that if it is "default" to ignore datautc, we can change this by some configuration directive.
However, at least in the central README.md, I can't find any hint how to do so.

I there any undocumented way override this default?
Or do I have to go the crude hack way and simply remove this line from the source?

@wolfgangr
Copy link
Author

I can confirm that just commenting out dateutc from the list of DEFAULT_KEYS_TO_IGNORE does the job.
It's the format understood by SQL, so I can use it right in my database query.

My personal state is "works for me".

I'll leave the issue open for some day and leave it to the maintainer either to close it or follow up on the idea.

Copy link

There hasn't been any activity on this issue recently, so it has been marked as stale.
Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by leaving a comment.
This issue will be closed if no further activity occurs. Thanks!

@github-actions github-actions bot added the stale There has not been activity on this issue or PR for some time label Sep 24, 2024
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Oct 1, 2024
@github-actions github-actions bot locked and limited conversation to collaborators Oct 31, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
stale There has not been activity on this issue or PR for some time
Projects
None yet
Development

No branches or pull requests

1 participant