Quote:
Originally Posted by Thierry Dupont
Thank you Peter to spend some time looking at our issue.
|
No problem
Quote:
Originally Posted by Thierry Dupont
Personality for a 16 bit Dimmer:
In our example above (which is implemented as it is) regarding the Secondary should we have?
Slot Label ID [0x0001, (1)], Intensity
or Slot Label ID [0x0000, (0)]
Currently we have Slot Label ID [0x0000, (0)]
|
Yes that's correct. It's a secondary slot, so the Slot Label ID should be a reference to the offset of the slot that's it's primary.
I should probably have explained before, with OLA installed that pretty printed output, which I'd hope makes it pretty self-explanatory if it's correct or not, is as easy as:
Code:
ola_rdm_get -u <UNIVERSE> --uid <UID> slot_info
Quote:
Originally Posted by Thierry Dupont
We meant two secondary values as timing / one for duty cycle and one for frequency. The responder that we worked with cannot handle very well secondary.
|
Yeah, so the challenge seems to be that those channels have to be secondary so you can't say it's strobe. How do you actually turn the strobe on and off, a certain part of the intensity channel, or another one, or just have a frequency of 0 Hz and a duty cycle of 100%?
I'd probably have a primary of SD_STROBE and a secondary of ST_SEC_TIMING or ST_SEC_SPEED for the other channel.
I assume you meant the controller you worked with?
Quote:
Originally Posted by Thierry Dupont
We learnt the hard way recently that it is not because it is wrtitten that a responder support a specific PID that it is working as the standard says.
|
Yes, listing a PID in SUPPORTED_PARAMETERS is one thing, actually making it usable and useful is quite another!