OpenLightingProject
Web RDM controller fails for proxy devices
Web interface can only display UIDs of proxy devices because it needs to call get queued_message after each call. Instead it is just filling the queued message buffer of the devices.
Hi @JustLighting ,
I thought we already had an issue open for this, but I can't currently find one aside from references on our GSoC ideas page: https://wiki.openlighting.org/index.php/OLP_SOC_Ideas_Page#Open_Lighting_Architecture_Ideas
Any news about this, or plans? I use a Lumenradio TX2 connected via CRMX to my devices, but while the web interface shows the proxied devices, I can't read anything from them.
Manually, in the CLI, it's possible though via the queued messages:
$ ola_rdm_get -u 1 --uid 7ff0:00001234 DEVICE_INFO
$ ola_rdm_get -u 1 --uid 7ff0:00001234 QUEUED_MESSAGE 1
Protocol Major: 1
Protocol Minor: 0
Device Model: 0
Product Category: Dimmer DC level
Software Version: 9903302372
DMX Footprint: 2
Current Personality: 2
Personality Count: 2
DMX Start Address: 2
Sub Device Count: 0
Sensor Count: 0
Would be nice to be able to use the web interface in "proxy mode" as well.
I think it's still Pull Requests welcome @SimonKagstrom
However in the meantime, if you use the Python CLI tool, either standalone or in interactive mode, it should be more usable, it automagically fetches queued messages so ought to help here: https://github.com/OpenLightingProject/ola/blob/master/python/examples/ola_rdm_get.py
Absolutely and understood @peternewman !
Thanks for the hint, I'll explore that a bit more. At first I thought there was something wrong on our end, but found out it worked fine via the QUEUED_MESSAGE, so that led me into searching for old bug reports.
Similarly our sub device support via the Web UI is somewhat lacking/non-existent too.
I think part of the challenge, particularly with queued messages, is how well, or otherwise, some responders handle them, so the challenge would be stopping a wonky responder breaking the UI for everything else.