You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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/MySQLdatabase 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.
The text was updated successfully, but these errors were encountered:
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?
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.
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!
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.
The text was updated successfully, but these errors were encountered: