More information for manufacturers

[FloEdelmann]

• Store a fullname that should be the same as the one for which its RDM ID is registered for at ESTA.

• Think of a way to store child brands for a manufacturer, possibly:

  {
    // …
    "music-and-lights-srl": {
      "name": "Music & Lights",
      "fullName": "Music & Lights S.r.l.",
      "rdmId": 5584
    },
    // …
    "prolights": {
      "name": "Prolights",
      "childBrandOf": "music-and-lights-srl"
      // no rdmId set here, but could overwrite it
    },
    "prolights-tribe": {
      "name": "Prolights Tribe",
      "childBrandOf": "music-and-lights-srl"
    },
    // …
  }

  Then, the fixtures-valid test only has to make sure that childBrandOf refers to a valid manufacturer.

see also #288 (comment) and #298 (review)

cc @peternewman

[peternewman]

As I mentioned in #288 (comment) I wouldn't use the full name as a key as they do change (e.g. the latest PR here has an addition and a change https://github.com/OpenLightingProject/rdm-app/pull/129/files#diff-e485852a32255a37cbb9adbdb38af8d9L242 ). By all means store them as their official names (as it's the manufacturers that set them), e.g. Martin Professional A/S ( http://rdm.openlighting.org/manufacturer/display?manufacturer=19792 ) compared to Martin, but don't try and use it as a key to match on (the RDM ID is the solution there, for those with RDM at least).

Personally I'd store them as a literal array/hash of alternative names within the master brand. From the RDM perspective at least, it's just a display nicety.

I'd also question the comment "no rdmId set here, but could overwrite it", if they have different RDM IDs, they're different manufacturers from an RDM perspective, so the parent/child aspect is irrelevant, unless you're trying to map business info. E.g. Zero88/Cooper Controls as part of Eaton Lighting.

Actually if you're redesigning for this, have you also considered the real world badge engineering stuff, where one PCB with one set of code has two labels stuck on it. In non-RDM land, they may behave identically, so do you list both individually (so your fixture profile matches the sticker), or both names in the manufacturer bit, but then you have to guess which one it might be hidden under (e.g. knowing to look under "Bar, Foo" for Foo). From the RDM side, they may either have the same RDM ID, in which case no issue, or different RDM IDs, but the same underlying personalities, and it would be nice to avoid duplicating the profile, and trying to track both.

[FloEdelmann]

I quite like the idea of just storing a list of alternative names! Of course the manufacturer key would still be a static, all-lowercase-with-dashes string.

I'd also question the comment "no rdmId set here, but could overwrite it", if they have different RDM IDs, they're different manufacturers from an RDM perspective, so the parent/child aspect is irrelevant, unless you're trying to map business info. E.g. Zero88/Cooper Controls as part of Eaton Lighting.

It wouldn't hurt to allow it. If a child manufacturer overwrites the RDM ID, for /rdm mapping we just ignore the childBrandOf value. And we could display this business info on the manufacturer page.

Actually if you're redesigning for this, have you also considered the real world badge engineering stuff, where one PCB with one set of code has two labels stuck on it.

I haven't really considered this yet. I guess we would just have duplicated the fixture definition and added a comment (which would work equally well without RDM, with the same and with different RDM IDs). I can't immediately think of a good way to avoid this duplication though, since adding a "compound manufacturer" is not a solution.

[peternewman]

It wouldn't hurt to allow it. If a child manufacturer overwrites the RDM ID, for /rdm mapping we just ignore the childBrandOf value. And we could display this business info on the manufacturer page.

My point was more if the child brand has an RDM ID of it's own, it's no longer a child, at least in RDM terms. You may want to map child/parent from a company perspective, but I'd suggest that's a different thing and may want to be treated separately, so you can have some strong validation of the data (to protect against typos if nothing else).

I haven't really considered this yet. I guess we would just have duplicated the fixture definition and added a comment (which would work equally well without RDM, with the same and with different RDM IDs). I can't immediately think of a good way to avoid this duplication though, since adding a "compound manufacturer" is not a solution.

You could have some sort of symlink concept to avoid the duplication perhaps, it's up to you how complex you want to make it (and perhaps one for another issue anyway).