How to query the current light level and use in a program

[Sixburg]

All:

 

I have a situation in my kitchen wherein I have an MS and a 2477D dimmer switch. The MS sets light level to 60% upon motion sense. However, I'd like to use a program to handle the situation when someone either raises or lowers the light level manually on the switch paddle. Right now, the light level snaps back to 60% upon motion.

 

To avoid this I'm thinking that if I can query the "new" light level set my the use of the switch, I can then set the MS to the new light level to avoid the MS either raising or lowering the level back to 60%. In effect, I want to write a program that says (pseudo):

 

If status Kitchen Light is not 60%

Then find out what the new light level is now

In scene Kitchen MS set Kitchen light to new level

Run the MS body program that has the wait x minutes

Fade down

Fade stop

 

I understand that the writes to the MS will take 1-2 secs (WISH THERE WAS A FIX TO THAT DELAY), but I've no idea how to accomplish the above. Thanks!

 

-Lloyd

[oberkc]

I am not sure that I fully understand what you are trying to accomplish. It looks as if you want to evaluate the kitchen light level and, if other than 60%, find out what it is and set it to that value (that it already is?) I am having trouble making sense of this. Regardless, I offer a few observations...

 

I understand that the writes to the MS

 

I am not sure that you can always "write" to the motion sensor. I believe the motion sensor is only receptive to updates if you manually put it into link mode, or within some short period after sensing of motion.

 

If status Kitchen Light is not 60%

I believe there is an ISY command like this.

 

Then find out what the new light level is now

New light level of what device? Kitchen light? ISY already knows this status in order to evaluate first line.

 

\Run the MS body program that has the wait x minutes

There is an ISY command that can do this.

[LeeG]

oberkc

 

The OP is not looking to change the Motion Sensor, he is looking to change the Responder On Level of the SwitchLinc Dimmer (when MS is Controller) to match the device current level.

 

Sixburg

 

It is a very messy implementation. The current On Level value cannot be stored anywhere the actual value can be used in the Adjust Scene statement. If you need the absolute On Level then approx 99 Programs are needed. Each Program tests for a specific On Level value

 

Program 1

 

If Status xxxx is 100%

 

Adjust Scene Responder On Level to 100%

 

 

Program 2

 

If Status xxxx is 99%

 

Adjust Scene Responder On Level to 99%

 

and so on.

 

The number of Programs can be reduced if a range of On Levels can resolve to a single Responder On Level

 

Program 3

 

If

Status 'SwitchLinc Dimmer' <= On

And Status 'SwitchLinc Dimmer' >= 90%

 

Then

 

Adjust Scene Responder On Level to 90%

 

Using 10% increments takes it to 10 Programs

 

Using 5% increments takes it to 20 Programs

 

 

Some day when device Status can be assigned to a Variable and that Variable used in other Program Action statements it will be easy. Until then it is messy.

[oberkc]

The OP is not looking to change the Motion Sensor

 

I was simply responding to a statement he made in the original post. I remain confused as to the intent of the OP.

[LeeG]

Requirement

 

Motion Sensor Motion On message sets a SwitchLinc Dimmer to 60%.

 

An individual manually changes the 60% On Level to 80% On Level by pressing and holding the On paddle.

 

The next Motion On should leave the SwitchLinc at 80% On Level rather than lowering the On Level to 60%.

 

Implementation

 

Concept is simple, use an Adjust Scene to change the Motion On message Responder On Level in the SwitchLinc to 80%.

 

Changing the Responder On Level with an Adjust Scene Action Statement is commonly done. It is often done at specific times of day so that Motion On turns the Responder On to different On Levels based on time of day for example. Brighter during the day, dimmer when it is dark. Less shock to the eyes. I do that with mine and others have as well.

 

Implementation is difficult in this case because the ISY currently has no means of dynamically changing the Adjust Scene Responder On Level value.

[oberkc]

Motion Sensor Motion On message sets a SwitchLinc Dimmer to 60%.

 

An individual manually changes the 60% On Level to 80% On Level by pressing and holding the On paddle.

 

The next Motion On should leave the SwitchLinc at 80% On Level rather than lowering the On Level to 60%.

 

This is more clear to me. It seems to me, however, that the way to approach that set of requirements would be for the motion sensor to trigger the light with a program, rather than a scene. This would allow one to put a condition in the program that if the light was already on (or "not off"), then don't do anything. Or keep light levels the same and run only a timer program.

[LeeG]

That approach eliminates the programming challenges. It also introduces a delay in the lights turning On.

[johnnyt]

Doesn't the adjust scene have the issue of wearing out the nvram, especially if one does an adjustment twice a day or every time motion is sensed?

 

 

 

Sent from my iPod touch using Tapatalk

[LeeG]

Twice a day for 10 years would be 7300 updates against a projected 1,000,000 update service life.

[Sixburg]

Thanks to everyone. LeeG nailed what I'm trying to do exactly. My apologies if my original intent was not clear to everyone. As LeeG stated the implementation for what I want is messy IF I control everything via program thereby resulting in unwanted delays. I'll either live with the delay, which allows me to more precisely control the light levels, or set specific levels regardless of what a user does with the paddle (i.e., "standard" = 60% and brighter = 100%...only allow 2 levels which works in my case).

 

Re "writes to the MS", what I should have said is changes to what the MS does via "adjust scene".

 

Thanks, again.

[apostolakisl]

Twice a day for 10 years would be 7300 updates against a projected 1,000,000 update service life.

 

That's interesting to hear. I had wondered about that and even asked it before but it never was responded to.

 

Is that number published by SH?

[LeeG]

SmartLabs/Smarthome did not publish that information. I researched the chip characteristics.

[oberkc]

I want is messy IF I control everything via program thereby resulting in unwanted delays.

 

I disagree. I believe using a program is the clean way of doing things here. And, while there is a delay, I am not sure one would notice it, since it is a delay only between the motion sensor and response (will anyone even notice when the motion sensor triggers?), and only around a second-or-so.

 

What you are trying to accomplish is pretty standard stuff, discussed often. I would be willing to bet that most have settled on a programmatic approach.

[johnnyt]

I have a bathroom light that is activated by a program triggered by a motion sensor and my wife always uses the switch because she can't (well, won't) wait. I confess the wait between my entering a room and the light going on was an early disappointment for me with this HA stuff in general but I'm used to it now. And my kids grew up with it. At least I didn't have to go turn the bathroom (and other) lights on for them every time before they could reach the switch. Now if I could just get my impatient wife to stop double clicking switches that cause other things to happen she didn't intend.

 

 

Sent from my iPod touch using Tapatalk

[oberkc]

I confess the wait between my entering a room and the light going on was an early disappointment for me with this HA stuff in general but I'm used to it now.

 

Do you have a sense of the source of the wait? Is it the result of a delay between the initial motion sensing and resultant action, or due to the performance of the motion sensor, itself?

 

My perception is that a good portion of the wait is simply due to the performance of the motion sensor. And this will remain regardless of whether one takes a scene-based approach or programmatic one.

[johnnyt]

I confess the wait between my entering a room and the light going on was an early disappointment for me with this HA stuff in general but I'm used to it now.

Do you have a sense of the source of the wait? Is it the result of a delay between the initial motion sensing and resultant action, or due to the performance of the motion sensor, itself?

My perception is that a good portion of the wait is simply due to the performance of the motion sensor. And this will remain regardless of whether one takes a scene-based approach or programmatic one.

I think it's a combination of the motion sensor delay and the delay in getting the message (by the program) to the light switch. It was worse with X10 (and HomeSeer) then with Insteon and ISY. It's less (as I recall it) if I link the motion sensor to the switch directly in a scene (through ISY, of course) rather than by triggering it after I received the on conditioned ("control is switched on") but I prefer the program route because it gives me more flexibility. For example I don't set the wait time for OFF in the sensor, I set it in ISY. Also I can disable auto on and auto off by having another program that when I double click the affected switch on/off it disables the on/off program. I want the flexibility to be able to leave the light on/off, regardless of motion. Now in fairness the delay is worse where, in the case of the bathroom, motion is actually sensed by a detector attached to my DSC Alarm Panel (on a partition that doesn't trip the alarm). In that case there's the added delay of getting the DSC panel to tell DSCLink (which has to run on my 24/7 file server) to tell ISY that motion is sensed... I think my basement sensor (an Insteon motion sensor, not a DSC connected sensor) is quicker.