Closed wolfgangr closed 4 weeks ago
searching the source on github, I find
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?
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.