Set Val Execution Scales Values - DO NOT MERGE. READ DESCRIPTION

[dfashbaugh]

Do not merge, these changes will make any devices you create incompatible with Front ends until the Front end catches up. We need to schedule that work, and should probably submit that front end PR to this branch

This handles control interoperability between range and on/off values, as well as any range values.

All range values are rescaled to match the range at their destination. Also constrains ranges to the values they should have. So no more Range values will be higher than their max value.

[KacobJeith]

What part of this PR breaks the front end? Did you make HAPI changes? Could you outline those changes?

[dfashbaugh]

Yep, HAPI handling of set val for range and on/off commands has changed to support the control interoperability.

Now the command is structured like this:
[SetVal OpCode] [NumBytes] [Destination Control ID] [Source Control Type]

if Control Type is Range or On/Off next bytes are
[Source Control High Val] [Source Control Low Val] [New Value]

If control type is buffer, nothing else is changed.

This does bring up the question.. Do we have enough devices out, that we should just make a new opcode and let the Original Setval die a slow death? Basically our strategy for not needing firmware updates. Then the version of this OS will just include the new setval type

[dfashbaugh]

In that case, the front end would need to determine which setval to send to which device.

[dfashbaugh]

The more I think about it, the more I'm leaning toward adding a new opcode for this to test our theory for how versioning and updating works in our world. Let me know what you think. Its easy on my end.

[KacobJeith]

I think we could manage with a controlled quick death still, but not for much longer. I almost see control interoperability as an inherent blocker to our theory of a no-update-needed future... I might be in favor of a hard replacement in this case, while we still can

[dfashbaugh]

Lets do a hard update on this front. While I'm certain that this is no blocker to the no-update future (because we would just make a new COP and then have to implement logic we will eventually have to implement), we might as well change it while we can so it universally functions how we want it to.

[dfashbaugh]

Spoke with @KacobJeith, And this PR will require changes as the COP will now become something that requires a non-free Heep license. Not closing this, but noting that it will be updated and not to merge