ola
ola copied to clipboard
OpenLightingProject
Additional RDM Responder tests to add
- [ ] Check the device doesn't respond to non-1 sub-start-codes
- [ ] Supported params for sub devices must return all PIDs
- [ ] Check what happens if you send a DISC command with a non-0 sub device
- [ ] personality 0 / 0 should be an advisory , given eric's reading of the standard
- [x] check what happens if we find a 'hidden' sensor, prob. print an advisory.
- [ ] Set an invalid date (leap year, etc.)
- [ ] Mute all devices before performing the discovery tests- otherwise other devices may respond to the mutes.
- [ ] test factory defaults & mutation.
- [ ] Add a test if split_level_supported is false to deliberately set the minimum level - decreasing field and confirm it's ignored by the responder.
- [ ] check device does not respond to broadcast / vendorcast mute / unmute cmds
- [ ] check no DUB response while device is muted
- [ ] set supported params to non-root subdevice
- [ ] get / set support params to sub device 513
- [x] set supported params with data
- [ ] get / set device info for each sub device & for 513
- [ ] get / set device info to broadcast / vendorcast address
- [x] set device info with data
- [ ] check for request with a port id of 0 - what should this return?
- [ ] check no response to a req with a bad checksum
- [ ] get / set sw version label to subdevices, inc. 513
- [ ] get / set dmx start address to subdevices inc. 513
- [ ] get dmx start address for broadcast / vendorcast
- [ ] set start address with PDL 1
- [ ] get / set identify device to subdevices, inc 513
- [ ] get identify device for broadcast / vendorcast
- [ ] get / set proxied devices to subdevices, inc 513
- [ ] get / set comms status to subdevices, inc 513
- [ ] set queued message
- [ ] get / set queued message to subdevices, inc 513
- [x] set status messages
- [ ] get status messages
- [ ] get status messages to non-root sub-device - should nack
- [ ] get status id description (1)
- [x] set status id description
- [x] get / set status id description with format errors
- [ ] get status id with format errors
- [ ] get / set sub device report threshold , w format errors & sub devices.
- [x] set param description with data
- [ ] get / set param description to subdevices, inc 513
- [x] set product detail id with data
- [ ] set null terminated device label
- [ ] set {data, null, data} device label
- [x] set boot s/w version with data
- [ ] set lang cap. with and without data
- [ ] get / set slot description to subdevices, inc 513
- [ ] get / set default slot value to subdevices, inc 513
- [ ] set dmx block address to a sub device
- [ ] get / set {fail mode, startup mode} to subdevices, inc 513
- [ ] get / set sensor values for sub devices
- [ ] get / set record sensors to subdevices, inc 513
- [ ] get / set dimmer info to subdevices, inc 513
- [ ] get / set min / max level / output response times/ mod frequency/ curve desc. / curve to subdevices, inc 513
Regarding "check what happens if we find a 'hidden' sensor, prob. print an advisory. " We return "GetSensorDefinition: Found too many 2/1 sensors", so I think we can tick that off.
Although I think in this case the error was not returning enough sensors in DEVICE_INFO, rather than intentionally trying to hide it.
We should also test factory defaults, or see if they change when we've set other stuff.
Alright, the idea I'm exploring is:
i) separate the tests out into 'standards', i.e. the document the test relates to ii) parametrize the tests by sub device. We'll need a root & current device context iii) Allow the user to specify which sub devices to run the test on. Root only, Root & known sub devices, all subdevices.
Can we not do i based on adding the information to the PIDs as discussed previously?
ii and iii sound good. I was going to add some similar stuff for e.g. sensors to run the test against every sensor versus known ones, although that idea probably falls down for the 32 bit stuff like network interface IDs due to time constraints.
If we're reworking, is it also worth adding an option to just run non-intrusive tests, e.g. gets, so you can run it "safely" on something?
Fair point, I guess an out of range get could upset something for example.
More test work being done here https://github.com/OpenLightingProject/ola/pull/1067
If a test fails due to timeout, look at retrying after a short delay (flag as warning), try again, then if it still fails move on.
A few more jobs ticked off based on commits in #1067 and #1181 among others.
7.4.1 Clearing of Mute Flag on reset command message (RESET_DEVICE) sent to responder.
Check that the PID we sent is the same one the fixture responds with! Does this work for ACK_TIMER/QUEUED MESSAGE stuff?
Broad and vendorcast DISC_MUTE and DISC_UNMUTE from https://github.com/mathertel/DmxSerial2/issues/10
Verify responder ignores bad command class values. From Europe 2018 plugfest.
Make sure the responder only replies to E120_DISCOVERY_COMMAND, E120_GET_COMMAND and E120_SET_COMMAND all other command class ID's should be ignored / timeout.
We should also try setting an invalid date.
See https://github.com/OpenLightingProject/ola/issues/1510
Parameter description check should validate the range of the min/max/default based on the data type.
Check that devices which return queued messages actually support them (assuming this is in the standard), see here: https://groups.google.com/d/msg/open-lighting/Yt_UI57-pyw/U3SeOJ9oCQAJ
Add at least an advisory (check the standard) if multiple DMX personalities listed in device info, but the relevant PIDs aren't supported.
ii) parametrize the tests by sub device. We'll need a root & current device context iii) Allow the user to specify which sub devices to run the test on. Root only, Root & known sub devices, all subdevices.
Test set of unsupported subdevices too in this model.
Lamp hours/device hours advisories, I suspect lamp shouldn't be more than device, as it says neither should reset on boot.
Maybe try setting lamp hours/device hours/lamp strikes to a non-zero number (both bigger and smaller than the current value)