lf_wifi_msgs.py: Add standalone wifi messages script

[abhisheksharma-candela]

Add standalone wifi messages script

Pull LANforge Wi-Fi messages from the GUI REST API (/wifi-msgs).

CLI query modes:
--last N most recent N messages
--first N oldest N messages still buffered
--since TS everything since a LANforge epoch-ms stamp
--duration 30s|5m everything from the last
--between A B everything between two epoch-ms stamps
--poll [--interval] keep printing new messages as they arrive

[greearb]

This can break if two events have same ms timestamp? Maybe instead do not increment the timestamp by one and filter out any previously read events?

[abhisheksharma-candela]

Right , Fixed it!
Storing previous events based on resource and time-stamp, assuming WiFi messages polling are small and won't bloat memory
Thanks

[abhisheksharma-candela]

Done! Made it cursor based.

It advances since_ts to the newest time-stamp in the batch on each pass and seen holds one entry, or a few if several messages share the timestamp. It will make sure the seen do not grow along with the life of generator

[haricharan-candela]

1. --poll crashes if the newest message has a non-numeric time-stamp

since_ts = self.timestamp_ms(latest[-1]) if latest else 0
since_ts = int(since_ts)

timestamp_ms() is documented to return None on a missing or non-numeric stamp. The guard only covers latest being empty — not timestamp_ms returning None. Reproduced:

TypeError: int() argument must be a string, a bytes-like object or a real number, not 'NoneType'

duration() handles exactly this case with an explicit if base_ms is None: fallback. poll() should do the same.

Fix: since_ts = self.timestamp_ms(latest[-1]) if latest else None then if since_ts is None: since_ts = 0.

2. --poll silently drops messages that share a millisecond

The dedupe key is (resource, time-stamp), and seen is a set. Two different messages from the same resource in the same millisecond collapse to one key, so once the first is delivered the second is discarded forever. Reproduced with a stub — FIRST delivered, SECOND at the same ms never appears, LATER arrives fine:

yielded: ['LATER']
SECOND delivered? False

Silent loss, not a hang — which makes it worse in a log-tailing tool where nobody notices. Wi-Fi messages from a busy resource routinely land in the same millisecond.

Fix: key on message content too, e.g. (resource, time-stamp, text_as_str), or count occurrences per (resource, ts) and skip only as many as were already yielded.

3. --poll --output json emits a stream that isn't valid JSON

render() always writes a complete JSON array, and the poll loop calls it once per entry. The result is concatenated arrays:

[
  {...}
]
[
  {...}
]

json.loads() -> JSONDecodeError: Extra data: line 10 column 1

Anything consuming --outfile msgs.json from a poll run will fail to parse it.

Fix: in poll mode emit JSON Lines (one compact object per line) — that's the normal shape for a tail — or document that --output json is batch-only and reject the combination.

@abhisheksharma-candela Please check these above

[abhisheksharma-candela]

1. --poll crashes if the newest message has a non-numeric time-stamp

since_ts = self.timestamp_ms(latest[-1]) if latest else 0
since_ts = int(since_ts)

timestamp_ms() is documented to return None on a missing or non-numeric stamp. The guard only covers latest being empty — not timestamp_ms returning None. Reproduced:

TypeError: int() argument must be a string, a bytes-like object or a real number, not 'NoneType'

duration() handles exactly this case with an explicit if base_ms is None: fallback. poll() should do the same.

Fix: since_ts = self.timestamp_ms(latest[-1]) if latest else None then if since_ts is None: since_ts = 0.

2. --poll silently drops messages that share a millisecond

The dedupe key is (resource, time-stamp), and seen is a set. Two different messages from the same resource in the same millisecond collapse to one key, so once the first is delivered the second is discarded forever. Reproduced with a stub — FIRST delivered, SECOND at the same ms never appears, LATER arrives fine:

yielded: ['LATER'] SECOND delivered? False

Silent loss, not a hang — which makes it worse in a log-tailing tool where nobody notices. Wi-Fi messages from a busy resource routinely land in the same millisecond.

Fix: key on message content too, e.g. (resource, time-stamp, text_as_str), or count occurrences per (resource, ts) and skip only as many as were already yielded.

3. --poll --output json emits a stream that isn't valid JSON

render() always writes a complete JSON array, and the poll loop calls it once per entry. The result is concatenated arrays:

[
  {...}
]
[
  {...}
]

json.loads() -> JSONDecodeError: Extra data: line 10 column 1

Anything consuming --outfile msgs.json from a poll run will fail to parse it.

Fix: in poll mode emit JSON Lines (one compact object per line) — that's the normal shape for a tail — or document that --output json is batch-only and reject the combination.

@abhisheksharma-candela Please check these above

@haricharan-candela Addressed these suggestions