Slot_Info / Slot ID Type-Slot Category/ID implementation issue

[Thierry Dupont]

Thank you Peter to spend some time looking at our issue.

It is becoming clearer but still I would like if I may getting some precision just to make sure.

Personality for a 16 bit Dimmer:

Slot Offset [0x0000, (0)]
Slot Type [0x00, (0)] Primary Slot
Slot Label ID [0x0001, (1)], Intensity
-------------
Slot Offset [0x0001, (1)]
Slot Type [0x01, (1)] Secondary Fine
Slot Label ID [0x0000, (0)]

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)]

Quote:
We wanted to use more secondary for Strobe but the controller does not like it and we decided to use only primary.

Strobe is a primary, or do you mean say two secondary values such as timing and speed for frequency and duty cycle?

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.

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.

[peternewman]

Originally Posted by Thierry Dupont

Thank you Peter to spend some time looking at our issue.

No problem

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:

ola_rdm_get -u <UNIVERSE> --uid <UID> slot_info

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?

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!