Implement DIMMER_INFO, DIMMER_MINIMUM, and DIMMER_MAXIMUM PIDs per E1.37-1

[kecramer]

Includes code from #1483

[peternewman]

Thanks.

The conflicts are sorted, but the comments haven't been addressed. Can you merge in the contents of this commit (and do the same fixes on the other functions).

[peternewman]

Some more issues, mostly just minor code styling

[peternewman]

I've fixed the Travis Codespell issue as it's just whitelisting, but can you fix the Travis lint issue please, two lines are > 80 characters.

[peternewman]

A few more comments

[peternewman]

Hopefully this is almost it now. Have you tested a round trip of get/set/get against our dummy responders for the new PIDs you can set?

[kecramer]

I have checked round trips and the behavior is the same as the command-line API. Maximum value setting has some odd behavior that is present in both - I haven't gotten to look into that yet, however.

[peternewman]

Okay thanks, if you can give some detail on the maximum value oddities, I can try and make sense of it from the RDM side, it could be a bug in our implementation (and hence also the RDM tests if they didn't catch it).

[kecramer]

So setting a maximum value should set that value, however the value that ends up getting set is not the value entered. For instance, setting the value to '60000' results in '65514' as the new value.

[peternewman]

One minor typo

[peternewman]

So setting a maximum value should set that value, however the value that ends up getting set is not the value entered. For instance, setting the value to '60000' results in '65514' as the new value.

I've just tried that against master, and it works fine for me. Was this the dummy advanced dimmer responder, UID 7a70:ffffff04, or a real device?

Can you paste the exact ola_rdm_get/set commands you used, and what version everything reports? Were you using your locally compiled ola_rdm_get/set, or other ones (which version, installed how)?

Does it happen every time or just intermittently?

[kecramer]

I've just tested it again on my branch and can't reproduce that either (from command line). Let me investigate what's going on, but definitely don't merge this yet. I wonder if the high order byte is always sending ff for some reason.

[peternewman]

I've just tested it again on my branch and can't reproduce that either (from command line). Let me investigate what's going on, but definitely don't merge this yet. I wonder if the high order byte is always sending ff for some reason.

Very strange. I think you're using our HostToNetwork functions already anyway, a byte getting stuck seems odd too, I could just about imagine it referencing the wrong one, but then it would always be wrong.

[peternewman]

Did you get a chance to look further at this @kecramer ?

Given neither of us could reproduce, and the code all looks fine, I'm tempted to carry on and see where we are code review wise.

[kecramer]

I tried to figure out what was going on and ended up spinning my wheels. Been occupied with another project, so haven't been able to dedicate much time to it past few weeks. I'm fine with that plan, and also plan to return to this bug when time allows.

[peternewman]

Okay great. Just to confirm though, you didn't manage to reproduce it, or understand why it might have happened during your investigations @kecramer ?

[peternewman]

Just one trivial change which I'll push in.