Sensor data collisions, for multi-sensor base stations

[ryan-lang]

This is a sticking point for me that I was hoping could be discussed for future versions of this integration. I have a base station that receives secondary sensor information from a remote sensor, which results in sensor data collisions. As discussed in the readme, this is currently a limitation of this integration. The current solution is to "flatten" any conflicting sensor data, which can lead to omitted sensor data.

In theory, you could make any conflicting sensor data unique by keying the data by the LSID (Logical Sensor ID) reported in the payload. However, Davis has given us a few challenges:

1. the base station will inherit some sensor values from remote sensors and report them under its own LSID, as if those values belong to the base station. And then the same values will be reported a second time under the actual originating LSID.

2. some fields use null values to indicate that the sensors are not reporting, but in the case of totals, such as rain, values will be zero, even if the sensor is not configured. For example, a remote sensor with no rain gauge will report 0 and not null for its rain totals. So you can use nulls to help omit some fields, but it won't catch everything.

This seems to lead to no great solution. If the sensor data is flattened, you may be omitting important sensor data. If all sensor data is reported (even excluding nulls) you're going to end up with some duplicate or "dead" entities.

My preference would still be the latter option. @siku2, if you take a look at my config flow, you'll see that I'm detecting any sensor data collision on initial data fetch, and then asking the user to provide labels for each LSID. If an LSID label is present, the entity name will be prefixed with that label. Then, when the user inevitably gets some entities that aren't reporting, or are duplicates, they always have the option to manually hide those entities though the Home Assistant entity config interface.

This seems like the most flexible solution that handles my use case, even if it does potentially add some extra steps for the user.

[siku2]

Related Issue: #10

This is one of the major pain points I want to address in the upcoming overhaul.
I fully agree with your approach of providing potentially redundant entities rather than keeping the "flattening" strategy (which was really just a band-aid fix).

I would like to hear your thoughts on taking this one step further and creating separate devices for the individual LSIDs as well.
That way the weatherlink config entry is essentially a hub, creating multiple devices that can potentially be assigned to different areas by the user as well as allowing the user to disable a device entirely.

[ryan-lang]

I like that idea. Conceptually, I think it's a better Davis-to-Homeasisstant mapping than what I was suggesting.

In fact, I'd just forget my suggestion about including any of this in the config flow, and just default to spinning off the LSIDs as devices, letting the user rename them later if they wish. That way it fits nicely with your no-config auto-discovery feature, which I've become a big fan of in my testing.