Consider using the rdm.openlighting.org website as a source of data

[peternewman]

Hi Flo,

I commented similarly on another related endeavour, incidentally you guys should talk, it may also be another output format for you/input format for afterglow ( Deep-Symmetry/afterglow#1 ).

Anyway, we already provide some basic personality info that we capture for fixtures, see for example:
http://rdm.openlighting.org/model/display?manufacturer=21075&model=84

But we actually capture a lot more in the background (although I'll admit I'm not certain if it's currently thrown away, or is actually stored in the back end and just not presented), e.g.:
https://github.com/OpenLightingProject/ola/files/1107996/robin_dl7s_profile.robe.txt

Essentially you could make use of this info (via some API), to pre-populate/produce initial templates for your fixture library. so users don't have to do some of the basic typing.

[FloEdelmann]

Great idea! I didn't know that the RDM database also contains "regular" DMX information.

We actually already have an open issue for Afterglow: #103

[FloEdelmann]

@peternewman how can we access that additional information for other fixtures, e.g. Robe Robin 600 LEDWash?

[peternewman]

Yep, the RDM protocol has:
http://rdm.openlighting.org/pid/display?manufacturer=0&pid=288
http://rdm.openlighting.org/pid/display?manufacturer=0&pid=289
http://rdm.openlighting.org/pid/display?manufacturer=0&pid=290

I still need to check if we've been storing what we've been gathering on the OLP RDM website or not. Then either just add an API, or store/display and add an API. Or alternatively you could parse the output from the model collector in the short term, to simplify the data entry bit, then transition to getting it from an API in future.

You should probably also extend your fixture profiles to store the RDM model ID and the RDM personality ID, then you've closed the loop and can map between your profile and the real world via RDM.

[FloEdelmann]

Seems to be a bit more work then if we also have to design the API on OLP's side... But it'd be definitely a good step to connect both projects!

I've opened another issue for RDM data in our fixture definitions (#288). Do you think that storing RDM manufacturer, model and personalities IDs are enough? Then we could link to the respective OLP RDM page.

Another idea that just comes to my mind: Once we store the RDM IDs, we could make a subpage (like open-fixture-library.herokuapp.com/rdm?manufacturer=21075&model=118) that redirects to the respective fixture page if it exists (like open-fixture-library.herokuapp.com/robe/robin-600-ledwash). Would it be possible to automatically link to this redirect page from the OLP RDM pages?

[peternewman]

Thinking about this more, parsing the output from the model collector is definitely the way to go for the short to medium term. We don't need to do anything on the server side to make it happen, and a user with a fixture in front of them can get the data instantly without needing to get the fixture approved when they submit it. Plus it will be easy to get enhancements and improvements into the data (just edit the model collector, not the model collector AND the RDM website).

As you've seen, I've replied to the questions in #288.

That sounds like a nice feature, I can't immediately see any reason why not. I've added a complementary issue on our end:
OpenLightingProject/rdm-app#127

[fxedel]

We can get machine-readable information about specific fixtures using the API:

http://rdm.openlighting.org/api/json/1/responder_personalities?manufacturer=21075&model=84

Or which the newest firmware of a fixture is:

http://rdm.openlighting.org/api/json/1/latest_responder_firmware?manufacturer=21075&model=84

[peternewman]

The newest firmware should also be the greatest version_id number listed.

So you can prefill a lot more data on the link to add a fixture here now :) :
https://open-fixture-library.org/rdm?manufacturerId=21075&source=olp&modelId=84

[peternewman]

For info, after a bit more digging, I've now found our UploadedResponderInfo table, which features previously dumped model collector data.

We'll need to work out the best way to make use of that data available data (either reprocessing storing it as part of our existing personality data), or returning the most recent, longest or all entries in a query for you to parse and process.