lutron programming conectp

adys

Hi all


I wanted to ask whats your concept of Lutron programming.

I created virtual keypads to add some presets, thats ok.

But the listening to the keypads on the walls are heavy duty, I am only in the first room and now I have to listen to 5 keypads that control this room... there is one keypad that I must listen to only for off button.

It will be very helpful for me to hear what approach you use when programming your house...


Thanks

Ady.

HARMAN_icraigie

Try setting up 1 virtual keypad for each room - expanded out you get access to 32 buttons, have yet to see the need for more than that many buttons to cover a single room.

DHawthorne

For control, I generally have a couple of virtual keypads, and reproduce them on my panel; if I need to control something else, I just send the button press directly. Sometimes, the customer wants to control every keypad in the house, so I allow the ability to call up one at a time. The key is, I'm only actively tracking keypads currently in-use keypads.

It's not that bad tracking just LED states that way, as long as you don't also track dimming levels. I have a job with 5 processors and nearly 200 keypads; the home owner can call up each and every one of them from any of 20 touch panels via a floor plan screen. It works perfectly, and with very little display lag.

ericmedley

I have the Lutron programmer put all loads on vitruals. I only speak to the virtuals. It seems to work out best for things when they need to change keypad addresses and whatnot.

I also wrote my own tweak for the comm between Lutorn and AMX. With it I'm able to run at 115Kbaud.

I agree with Dave on the LED tracking, dimmer level statement. LEDs are easy enough. Dimmer levels get a bit fuzzy at times if you have quite a few keypads/dimmers in the house.

adys

Thanks

I am listening only to the virtual keypads, and to some light levels (one for every preset)


Also I am listening only to the on event of the leds so I can sync it with the presets of the house

John Gonzales

5 processors

nearly 200 keypads

20 touch panels

home owner

Now that's a big house!


--John

adys

OK I finished the first room

Now I want to make a module base on what I done and learend and to have one instance of the module for each room.

I wonder if listening to the lutron messages in all my master controllers is a good idea (easy to implement but I am not sure the best thing to do)

The second way is to listen in one master, and send the message to the ui module (instance for each room)


The third option is to write a smart module that handles all ui for all TP and send only the apporpriate messages to the right TP. this is the most complex solution...


What do you think?

DHawthorne

As a general rule, I have the master that connects to a device control that device entirely, and let other masters get their data from it. In most cases, you can simply define your remote panels in the main master and use them as if they were local; if other parts of the remote programs need anything, I use a virtual device to communicate between them.

adys

Usualy I do that too.

But with all the notifications from the lutron, I will have lots of messages..

I thouhgt maybe to make a UI module that sends messages to the vLight virtual device of the driver module only, and listen to the events and filter them according to what room the module handle.


the second option is to make a very smart and complex module that handle all UI of all TPs.
This can save lots of messages, only the TP messages will be sent on the network....

DHawthorne

adys wrote: »

Usualy I do that too.

But with all the notifications from the lutron, I will have lots of messages..

I thouhgt maybe to make a UI module that sends messages to the vLight virtual device of the driver module only, and listen to the events and filter them according to what room the module handle.


the second option is to make a very smart and complex module that handle all UI of all TPs.
This can save lots of messages, only the TP messages will be sent on the network....

Like I said, I have a project with 20 panels and 5 Lutron processors, and it's all being handled perfectly fine by the same master that also controls 3 very chatty serial tuners, a couple iPod docks, a MAX server, 18 Viewstats, an Ademco alarm (also very chatty), and quite a few other devices. The raw processing power is not a real bottleneck for the NetLinx; the message queue that displays stuff on the touch panels, however, is. As long as you aren't updating feedback for all of it at once, you shouldn't have a problem.

adys

As John said beofe me, that is a huge house


First, thanks a lot for your help



one of the problems that I do have to update feedbacks to 14 TP...

And not only one button, its full of animations for every light on the sealing, for the heat, for the aircondition. I have to do it for the room map, house map, on 3 different sets of ui buttons.

and I must update all the 14 tps...

I have many problems of TP going very slow, even on local behaviour, animations gets very very slow on some screen, on the others they go fast... and thats before lutron.
Its a problem I talked with the support about, moving back to old firmware solved some of the problems??? but I still have a screen that when I get into it its animation looks very very very slow, and without any reason... local animation of 45 seconds (every 45 seconds I send ^ani commnad for button with 64 states)

So what you are saying is the solution that the master holds and controls all the lutron of the house, and updates the TPs?

That will be very complex to write...

What do you think about a module for every room that run 20 instances (for each room) but on the same master of the lutron?

DHawthorne

That's the way I do it: one master controlls the Lutron, all the TP's exist on that master even if connected to a remote master, and the main master updates them. However, I have extensive page tracking going on, so they only get updates if a lighting screen is showing, and even then, only the lighting that s shown at them moment. The master may be receiving, parsing, and controlling the Lutron at all times, but stuff only goes out to the panels when actually needed.

Of course, that's how I do it; you may have a better way for your application.

But, I don't think multiple instance running the same Lutron processor is a good idea. You are duplicating a lot of processing that way; I'm not sure, in any case, that the Lutron will accept multiple connections. However, doing it AMX style and having a comm module for the Lutron, and multiple UI modules for each room - that would probably work fine.