[heroprotagonist]

It doesn't even need that, really. Zigbee and similar long range wireless mesh networks are very realistic (and probably cheaper) for basic usage data.

Bandwidth is much more limited so it probably won't send screenshots of what you're watching like has been reported with some TVs. Screenshots aren't really needed, though, when there's a host of other metadata and on-device processing available.

[ashtonkem]

As someone who runs a Zigbee network at home, this won’t work. The signal strength across my small apartment was marginal at best, there’s no way you could plop down zigbee devices at random and hope that they could find each other, especially between detached houses.

[heroprotagonist]

Sorry, I was confusing LoRa and Zigbee.

LoRa claims 2-5 km range in urban areas or 15 km suburban, with even larger variability in rural areas depending on line of sight and landscape features.

Zigbee claims I found vary from 10 to 100 meters.

LoRa is pretty cheap, and there are a lot of gateways around to piggy back off if you don't want to set up your own.

You can see a map of one network of gateways here:

https://www.thethingsnetwork.org/

It also uses less power than Zigbee. The big downside, though, is that you get a lot less bandwidth with LoRa.

[guillem_lefait]

Vith Vizio data you get a log whenever user use its remote to (un)pause, go forward, or change channel. I'm not sure LoRa has enough bandwidth to send the usual data. However, it is still possible to send a lightly simpler data (not doing ACR on everything, but identify channels only) But would it worth it right now ? Until a large portion of buyers disable (now or in the next few years) the full data collection, it seems unlikely to me.

[heroprotagonist]

That's a lot of data, but I imagine if they operated with bandwidth restrictions, companies might limit themselves more in what they collect.

Though I do think that's within range of even the lowest possible LoRa bandwidth estimates since there's no realtime requirement.

A single remote click is a very small piece of data, even less than the 8-10 bytes that a datetime uses. Contextual data will likely be the larger portion, such as a unique system identifier, currently active application, and any metadata that provides. There are ways to limit that, like sending a context object once and giving it an id, then referencing the id instead of re-sending the same data repeatedly.

But even if that doesn't happen, the lack of realtime requirement means the data can simply be queued up to send over time. If a user generates a few kilobytes of data a second for hours by sitting on their remote control's channel switch button, they won't be that active forever. The device can eventually send out all of the data during the inactive periods.

Or it can prioritize which data to send first, or which to discard, when the queue reaches a certain threshold.