Same device serial number on two stations

[GaryFunk]

SK-00011522 is device 17894 on station 1689 AND device 18594 on station 664.

AR-00001383 is device 18133 on station 5844 AND device 10599 on station 4111.

SK-00012108 is device 18135 on station 5844 AND device 10723 on station 4111.

SK-00008087 is device 10195 on station 3818 AND device 10184 on station 4020.

SK-00005553 is device 18610 on station 4144 AND device 17728 on station 5683.

AR-00012504 is device 12580 on station 4590 AND device 18090 on station 5835.

And I have found 20 more devices that are duplicated.

@dsj @anon84912554 @WFmarketing

[dan.gealt]

I didn’t look at all of the stations in the list, but station 5844 looks like it is currently reporting data while station 4111 looks like it has been offline for several months. Maybe 4111 was shut down and then recreated as 5844???

[GaryFunk]

That could very well be. It’s wrecking havoc with my Map as the WeatherFlow API still shows the devices attached to 4111 and that 4111 is a valid station.

[dan.gealt]

Station 4111 shows data from mid-June through mid-September. I was thinking about how a station might be “tombstoned” but it seems that just deleting the station and its data might not be such a good idea. Maybe a new procedure needs to be developed on the WF server end to support reassignment of devices from one station to another while retaining historical data.

[GaryFunk]

This verges on being a security issue. What happens if a station is stolen and someone tries to set it up. Granted, it is not WeatherFlow’s duty, but…

Serial numbers are unique and duplicates should not be allowed in the database.

[vinceskahan]

@GaryFunk

This verges on being a security issue. What happens if a station is stolen and someone tries to set it up. Granted, it is not WeatherFlow’s duty, but…

Security issue ???
I think not…

Who could possibly ‘care’ if a sensor has been on multiple stations in its lifetime ?

re: auto-pruning the WF historical data, I’d suggest caution there…I see lots of people on the weewx google group who put stations in very remote and inaccessible places that they can’t get to in the winter that might not report for many months. A blanket ‘prune stations that have not reported in NNN weeks’ would be quite excessive.

Regardless, assuming sensor-NNN is always on one and only one station throughout its lifetime, or any arbitrary data pruning timeframe, is just not reasonable. It’s simply going to happen.

Just looking at the REST API, there are a couple interesting caveats in there…

• “Smart Weather Devices all belong to a Station. This response contains Station metadata and metadata for the Devices in it. Each user can create multiple Stations. A Device can only be in one Station at a time. Only devices with a serial_number value can send new observations. A Device without a serial_number indicates that Device is no longer active.”

Just looking at your example:

• AR-00001383 is device 18133 on station 5844 AND device 10599 on station 4111.
• SK-00012108 is device 18135 on station 5844 AND device 10723 on station 4111.

If I’m reading their API docs correctly, one station should show two ‘active’ devices with a SN, and one station should two inactive devices (no SN).

What’s interesting in this case is that if you query the two station IDs, the lat/lon are the same, but the hub s/n and station description strings are different, but both stations seem to show the devices as active.

Seems like a bug on the WF side to me. They should be marking devices as inactive in the old station whenever a device is associated with a new/different station. Now how they might do that is an exercise for WF to make happen. I can think of all kinds of reasons why messing with previously-recorded station mappings would cause more pain than it prevents.

Re: how it happened, I can guess that perhaps the owner had multiple stations in one site and they moved sensors around re: which hub they were attached to…or alternately their hub was replaced and the air/sky were reassociated with a new hub and they went through the new-station process.

Re: the ‘havoc in your app’ thing - I can only guess that perhaps you have a db table trying to return a mapping of ‘which station is device-NNN on’ and it can’t deal with multiple stations having ever been associated with a particular device. Bad assumption if that’s the case.

[GaryFunk]

@vinceskahan

Seems like a bug on the WF side to me.

I’m pleased you agree.

[dsj]

Sorry for the slow response here but there are a few things going on.

There are actually multiple reasons that the same serial number might be associated with more than one device. While it should be unique to a physical piece of hardware, the serial number is really just a piece of device meta data (like “name” or “height above ground”) as far as the object model is concerned. As developers, you should not assume a serial number is globally unique, nor should you use the serial number a primary key. That is, you should expect to see duplicate serial numbers.

@GaryFunk

It’s wrecking havoc with my Map

Sorry about that Gary. I’m actually surprised you haven’t bumped into this earlier since the above has always been true: the serial number was never meant to be unique. That said, we did make a change recently that amplified the number of cases where you’d see duplicates a good bit. It used to be that the serial number would be marked NULL in the old device record if that number were added to a new device record. But for several reasons, including the fact that we recently discovered a handful of physical units in the field with duplicate serial numbers, we changed that behavior so that the serial number is no longer removed. That’s why you’re seeing so many now.

@dan.gealt

it seems that just deleting the station and its data might not be such a good idea. Maybe a new procedure needs to be developed on the WF server end to support reassignment of devices from one station to another while retaining historical data.

We do plan to add functions to the app that will make it easier to add/move/change a physical device, but we do not have any plans to auto-prune data. We agree that would be a bad idea.

@vinceskahan

Seems like a bug on the WF side to me. They should be marking devices as inactive in the old station whenever a device is associated with a new/different station.

It’s not a bug, but it is a little confusing. Actively reporting devices are marked “online” in the system, and devices that haven’t reported for a while get marked “offline.” But that has nothing to do with the serial number. We don’t have an explicit label for “active” or “inactive” as far as I know. The implicit “inactive” mentioned in the docs is still true - if a particular device DOES NOT have a serial number, then it physically can’t be reporting fresh data. However, the converse is not true: a device that DOES have a serial number may not be reporting for a multitude of reasons.

[GaryFunk]

@dsj

you should not assume a serial number is globally unique, nor should you use the serial number a primary key

The entire idea behind a serial number is that it should be unique and may be used as a primary key.

This is the last I will publicly comment on this issue.

[vinceskahan]

@dsj

It used to be that the serial number would be marked NULL in the old device record if that number were added to a new device record. But for several reasons, including the fact that we recently discovered a handful of physical units in the field with duplicate serial numbers, we changed that behavior so that the serial number is no longer removed.

Thanks for the update David…

So the underlying thing here is the online APIs are not accurate, or in this case not accurate any more. Makes sense.

The docs falling behind the code and implementation continues to cause confusion. I’d suggest time is proving repeatedly that it would be helpful if WF would set up some ‘public’ bug reporting system that we could search effectively before we all keep going running down these rabbit holes over and over…

There are software bugs. There are documentation bugs. Both cause confusion among the user community especially due to the private-only nature of how WF tracks stuff (geez, I ‘hope’ you are tracking stuff, it’s sure opaque to us).

Again, a public bug list is to me the best way to go, unless you want to wiki and let us help you with a community-created aggregate list along the same lines.

The forum software sure isn’t working for that kind of thing, nor should it be expected to. That’s what things like bugzilla and mediawiki are for.

[dan.gealt]

Hi @dsj

While I am not as familiar with the API as the third-party developers are . . . I am very familiar with confusion (and I frequently cause plenty of it, I am quite sure).

So, after re-reading your message I find that the two statements below are causing me even more confusion. Are we maybe talking about two different types of “serial numbers” here?

@dsj

I’m actually surprised you haven’t bumped into this earlier since the above has always been true: the serial number was never meant to be unique.

@dsj

we recently discovered a handful of physical units in the field with duplicate serial numbers

I don’t want to drag out this topic any more than necessary, but . . . is there any way to clarify this a bit more?

Dan.

[eric]

Got to agree with Dan here, not seeing the tree and the wood anymore in this history of serials.

Is there some definition of serial ? Because or I don’t understand it or maybe we don’t speak about the same …

Thanks David.

[vinceskahan]

@eric

Is there some definition of serial ? Because or I don’t understand it or maybe we don’t speak about the same

Serial number is the unique identifier for a piece of hardware:

• SK-000nnnnn for a sky
• AR-000nnnnn for an air
• HB-000nnnnn for a hub

Think of a serial number just like a serial number on any other computer gear, or even the vehicle registration number on your car. Same idea.

Where it gets a little confusing is the use of ‘device id’, which to me is a WF-server-side registration of a particular piece of hardware and also ‘station id’, which to me is a WF-server-side registration of what lots of folks might call a ‘site’ (ie, a set of devices acting as a weather station collectively).

There are a couple problems if I’m reading the thread correctly:

• it’s possible there are multiple physical devices with the same serial number (for example, more than one Air with the same AR-000nnnnn identifier. That would be bad if true. I got a little lost in the thread reading WF’s answer, so I might have read this one wrong.

• the mapping of serial number to device id on WF’s side does not prune old/superseded data. This means that if you search the db you can (and Gary did) find SK-000nnnnn in more than one WF ‘station’. The API reads like WF intended to clean out superseded registrations to prevent this, but David’s response basically said the API was now incorrect and they don’t do that any more.

So basically the published API isn’t what WF is actually doing, so assuming that a particular plysical device (identified by serial number) can be found in only one WF station (identified by station id) within the database is not a good assumption. WF is keeping the old history and not invalidating the old registrations in any way we can use the API to see.

[…fwiw - weewx has a station registry that re-registers each station weekly to try to keep up with this kind of thing, with devices basically falling off their map after some time period in which they haven’t done the weekly phone-home, so to speak…]

[vreihen]

Per Wikipedia: Serial Number - A serial number is a unique identifier assigned incrementally or sequentially to an item, to uniquely identify it..

Per Merriam-Webster:

Serial - of, relating to, consisting of, or arranged in a series, rank, or row; appearing in successive parts or numbers.

Series and unique being the key words.

My assumption was that they kept the sensor data (keyed on the device S/N) around even when it is attached to a new station/Hub, so that the support folks could re-attach a deleted sensor to a particular station/Hub without losing the historical data. Now, I’m wondering if I am mistaken?

[dsj]

Sorry for the confusion!

@dan.gealt

Are we maybe talking about two different types of “serial numbers” here?

We’re talking about the same serial number, but two different locations where it is stored. The serial number of a physical device, which is stored in the flash of an individual device’s circuit board, should* always be unique. However, it’s now common to find duplicate serials stored in our back-end (and accessed via the API). That’s because, as @vinceskahan notes, we are no longer trying to prune formerly connected devices. But these “duplicates” are only duplicate in the virtual device sense. Serial numbers can be duplicated across multiple stations, but there should* still be only one physical device with that serial number.

To complicate it a bit further, serial numbers in our data model must be unique within an individual station’s scope. That is, you can’t have two devices connected to one station with the same serial number. So, as developers, you do not need to handle the case of non-unique serial numbers on a single Station/Hub (because it’s not possible). That said, if you want to be super safe, you could use the hub serial and device serial together as a globally unique identifier, even at the local/udp level.

*I say “should” because we have seen a handful of true duplicate serial numbers (two physical devices with the same number) in the field. That’s thanks to a SNAFU at the factory and not by design. We are taking steps to ensure that doesn’t happen again, but there are a few out there.

@vinceskahan

a public bug list is to me the best way to go, unless you want to wiki

We agree - it’s a goal for 2019 to provide better public bug tracking and documentation!