Add projection to watch and map max once/sec, varsToWatch to model

[ewoudwijma]

SysModModel: move varsToWatch here (from E131)
AppModLeds:

• remove E131 dependency,
• add projection
• add doMap and lastMappingMillis
• call ledFixProjectAndMap in loop (max 1/sec)

[netmindz]

I don't agree with the move. The watch isn't really a watch, it's really about dmx patching. The channel we are listing here is a dmx channel number so does relate directly to e131

[netmindz]

If you are going to add a new "common" param then the effects will need to be updated to use new channel. Might be best that the per effect parameters start at 10

[ewoudwijma]

I don't agree with the move. The watch isn't really a watch, it's really about dmx patching. The channel we are listing here is a dmx channel number so does relate directly to e131

Channel part is indeed e131 related. That's the disadvantage of my proposal.
It was an attempt from me to decouple dependencies between both modules as ifdef e131 in modled is 'dirty' - this coming back to discussion with @softhack007 about inter module comms.

Could we look for an alternative? I was thinking that ModLed is just reporting the vars which can be updated and then e131 go through that list and allocates it to the channels, I don't know enough of dmx but is current solution not inflexible as well as it allocated fixed bri to 1 and fx to 2 while in case of multiple instances in the universe channel mapping should be configurable ?

So I think whatever solution we choose now it will be further developed in the future and it's more where do we compromise now: module independency or allocating channels where it should be .

Also fine for me we leave it now as is, but at least it should be on our radar to think about a module independent solution

[netmindz]

I still don't have a solution for removing the inter mod dependency.

This change moves the dep from App to User, this changes to System to User - even "deeper" into the system.

Given e131 is primarily a lighting system, that's why it's ok for optional reference to e131 in the LEDs mod (for now)

[ewowi]

Screen mockup:

@netmindz
Isn't this what you want, especially when you have multiple StarMod fixtures, each fixture specify it's channels theirselves (in this example, universe and channel values are writable... (at least that is what I see with dmx lights on stages).
This is all done in the E131 module, so no need to worry about adding E131 lines in Leds module

And StarMod per default allows things like this:

curl -X POST "http://4.3.2.1/json" -d '{"chChan#2":5}' -H "Content-Type: application/json"

(set the channel of the 3th row (Projection) of the channel column to 5)

So fixture setups can then be controlled remotely

[netmindz]

On a lighting desk you have a fixture definition that lists what attribute is what is associated to each channel, if you were to set that address to 1. It higher then that offset is applied.

E.g

First channel = brightness
Second channel = effect

On the lighting desk under dmx patching I could say I have one StarMod instance on 10 and another on 20

Sometimes you have different modes, e.g ”3 channel mode", ”9 channel mode" etc where you might have more detailed control of the fixture.

You would never allow the user to just randomly change specific channels, only the mode and start address

I'm not sure if QLC has accepted my submission of the updated WLED fixture definition to match the current QLC or if it's got stuck in the review process