ISY Programming 101?????

[kclenden]

1 hour ago, larryllix said:

 

 

You are going to hate this one.

 

When your Tony Rear Door program becomes true the status condition will become false after A5 turns on.

Now your If will get re-evaluated to false and Else will run.

But there's nothing in the ELSE so in this case it won't matter.  For future programming, ABLE1 will probably want to know about the pitfalls of changing the value of an IF conditional within the same program.

[larryllix]

But there's nothing in the ELSE so in this case it won't matter.  For future programming, ABLE1 will probably want to know about the pitfalls of changing the value of an IF conditional within the same program.

Yes exactly!

Any lines in the Then after a Wait or Repeat line will not get executed.

A very common gottcha'

 

I am working from a small screen and its getting difficult keeping things organized here.

Confession...I thought there was else lines in his program.

 

Sent from my SM-G930W8 using Tapatalk

 

 

 

[ABLE1]

Hello,

Still a bit mystified here.  I have  this small program entered and running.

• X10 Test - [ID 0003][Parent 0001]
• If
•         X10 'A5/On (3)' is Received
•  
• Then
•         Set '4D.76.AA.1  Rear Door' On 100%
•  
• Else
•    - No Actions - (To add one, press 'Action')

Seems rather straight forward in that If  a X10 A5 is received then set 4D.76.AA.1 to On at 100%

However the Log shows that it is turning on at 100% and then turns Off in the same second or 1 second later.  

This is the part I am missing or not understanding!!     What is turning it off??

-----------------------------------------------------------------------------------------------------------------------

X10	A5		Mon 2019/02/11 01:14:00 PM
X10	A5	On (3)	Mon 2019/02/11 01:14:00 PM
4D.76.AA.1 Tony Rear Door	Status	100%	Mon 2019/02/11 01:14:01 PM
4D.76.AA.1 Tony Rear Door	Status	Off	Mon 2019/02/11 01:14:01 PM
X10	A5		Mon 2019/02/11 01:14:03 PM
X10	A5	Off (11)	Mon 2019/02/11 01:14:03 PM
X10	A5		Mon 2019/02/11 01:15:50 PM
X10	A5	On (3)	Mon 2019/02/11 01:15:51 PM
4D.76.AA.1 Tony Rear Door	Status	100%	Mon 2019/02/11 01:15:51 PM
4D.76.AA.1 Tony Rear Door	Status	Off	Mon 2019/02/11 01:15:52 PM
X10	A5		Mon 2019/02/11 01:15:53 PM
X10	A5	Off (11)	Mon 2019/02/11 01:15:54 PM

Thanks,

Les

This is an edit.

I think that I found the problem.  It seems that I forgot to disable the other program

to have the light off during the day and as such they were being turned off just after 

being turned on.    Maybe i will know once the driveway sensor is tripped again

now that I have the  other programs disabled.   My bad...........

I decided not to delete the above since it may help others with the challenge someday.

Les

 

 

[larryllix]

You're getting there!

Nice going!

Sent from my SM-G930W8 using Tapatalk

[kclenden]

8 hours ago, ABLE1 said:

I decided not to delete the above since it may help others with the challenge someday.

Les

Practice makes perfect!  Good job.

[Hurting2Ride]

11 hours ago, ABLE1 said:

Hurting2Ride

Please look at the loaded image.  

In the Add To Program area it states Time is  After Sunset

However, it the Program Line it states  Time is Sunset.

It does look like a contradiction but it is the Admin Console that is making it look that way.

Besides I don't see a "between" selection or choice.  It is either Before or After.

That is UNLESS I am missing some other program pull down.

 

ABLE1

The code above the midline is what is currently loaded in the Admin Console.  The "Add to Program" is of no effect other than when inserted in to the code above.  (Remember that if you do modify the code you then need to save the program.)  

As for the dropdown, you were right there.  Click on "Time is" and change it to "From".  That will add a 2nd line where you can choose the end time.

Regards.

 

[Hurting2Ride]

11 hours ago, ABLE1 said:

Hurting2Ride

Please look at the loaded image.  

In the Add To Program area it states Time is  After Sunset

However, it the Program Line it states  Time is Sunset.

It does look like a contradiction but it is the Admin Console that is making it look that way.

Besides I don't see a "between" selection or choice.  It is either Before or After.

That is UNLESS I am missing some other program pull down.

 

ABLE1

The code above the midline is what is currently loaded in the Admin Console.  The "Add to Program" is of no effect other than when inserted in to the code above.  (Remember that if you do modify the code you then need to save the program.)  

As for the dropdown, you were right there.  Click on "Time is" and change it to "From".  That will add a 2nd line where you can choose the end time.

Regards.

 

[ABLE1]

Hello ALL,

Ok, so I now have my program working as desired.  At least it appears to be from looking at the Log File.

The program is attached for those that have a similar desire.  Now I am sure that there are a multitude of

other variations to do the same thing.  However, this seems to work for me, at this time.

I also set the Ramp Rate for each switch to 8.5 seconds.  I assume that it will apply to both up and down

since I am not there to observe the effect.  Which brings up a few questions.  

I decided not to add the Ramp Rate in the program itself since it is available in the switch itself.  Is that correct??

I also noticed in the programming pull down that there are a number of ways to say the same thing. 

Such as Brighten and Fade Up or Fade Down and Dim.   Why so many choices to do the same thing??

Seems odd, but I assume there is a good reason.

The other odd thing that I noticed is that in the switch programming under Ramp Rate the values go from 0.1 seconds up to 8.5 seconds 

and then jump to 19.0 and 21.5 seconds and move up to 47 seconds. 

Is there some mathematical value of prime numbers going on there that creates those values??

And thanks to all for the input.  All very helpful.  

Have a good rest of your week.

Les

 

ISY Program 02_12_19.pdf

[larryllix]

The local switch control, ISY program lines and every scene link have their own levels and ramp speeds and do not interact.

 

Sent from my SM-G930W8 using Tapatalk

 

 

 

Fade up and down was an old system that would start the ramp and Stop would make it cease dynamically. IMHO those commands are a waste of time with ISY. Good between linked switches though.

[ABLE1]

UPDATE:

Over the past  two weeks all seems to be working quite well.  However,

I did notice something that needs a little enlightenment.  I noticed on the Log

the following in the attachment.

This is the first time I noticed that the Ramp Rate is Logged into the report.

It was not triggered by the driveway sensor X10 input but did start with a "Null" being logged.

First question, what is a Null and then what would cause it to happen??  It actually triggered all switches

to do the same thing.  Status OFF >> On 100% >> Ramp Rate 8.5 seconds

At some point the lights went Off since when I looked at the switch they were off.

May not be a big deal but I am curious as to what caused it to happen??

Again thanks for any input.

Les

[kclenden]

18 hours ago, ABLE1 said:

May not be a big deal but I am curious as to what caused it to happen??

The null is associated with the log type of Start.  It means that your ISY rebooted.  The only times my ISY has rebooted was either when I commanded it to reboot, or as the result of a power failure.  Since you weren't there, I'm going to guess your ISY rebooted because of a power failure.

The following six lines in the log show your ISY querying devices for their status.  It's not actually commanding them to do anything, but just finding out what state there currently in.  That's what the Status Off means.  The On Level 100% and Ramp Rate 8.5 seconds mean that the switch is configured to come on to 100% with a ramp rate of 8.5 seconds if you actually tap it.

Your ISY queries all of the devices for their status after a reboot because you have Query at Restart checked within the System box on the Configuration tab.  If you uncheck that box, then the ISY will not query devices for their status each time it reboots.

[ABLE1]

Hello kclenden,

Thank you for the detailed response to my question.  Very helpful!! So the info in the Log was a report of the

configuration status of the switch not an command to the switch.  Got it!!

In your response you triggered another question.  You said:

"the switch is configured to come on to 100% with a ramp rate of 8.5 seconds if you actually tap it."

If in programming I have a switch go from 30% to 100% will it ramp up at a rate of 8.5 seconds??

By your statement I am guessing that to be not true.  If that be true then the programming needs to be

modified to have the switch ramp up to 100%.  Is that correct??

Thanks again!!

Les

 

 

 

 

 

 

[Sub-Routine]

1 hour ago, ABLE1 said:

Hello kclenden,

Thank you for the detailed response to my question.  Very helpful!! So the info in the Log was a report of the

configuration status of the switch not an command to the switch.  Got it!!

In your response you triggered another question.  You said:

"the switch is configured to come on to 100% with a ramp rate of 8.5 seconds if you actually tap it."

If in programming I have a switch go from 30% to 100% will it ramp up at a rate of 8.5 seconds??

By your statement I am guessing that to be not true.  If that be true then the programming needs to be

modified to have the switch ramp up to 100%.  Is that correct??

Thanks again!!

Les

 

 

 

 

 

 

If the last time the level was changed it was by using the switch it will use the local ramp rate.
If the level was changed using a scene it will use the ramp rate the scene has.

If you want to specify the ramp rate when your program changes the level you will need to use a scene and specify the ramp rate and level in the scene.

[ABLE1]

5 hours ago, Sub-Routine said:

If the last time the level was changed it was by using the switch it will use the local ramp rate.
If the level was changed using a scene it will use the ramp rate the scene has.

If you want to specify the ramp rate when your program changes the level you will need to use a scene and specify the ramp rate and level in the scene.

Sooooooo what you are saying is that I need to do some different/more programming??  

Maybe, I will just leave well enough alone.....................  until I have nothing better to do.

Thanks,

Les

 

[Sub-Routine]

8 hours ago, ABLE1 said:

Sooooooo what you are saying is that I need to do some different/more programming??  

Maybe, I will just leave well enough alone.....................  until I have nothing better to do.

Thanks,

Les

 

The only changes you need to make are
1) create a scene for the lamp with the level and ramp rate you desire.
2) call the scene from your program instead of the device.

[kclenden]

17 hours ago, ABLE1 said:

If in programming I have a switch go from 30% to 100% will it ramp up at a rate of 8.5 seconds??

My understanding of Ramp Rate is that it represents the time to go from 0% to 100%.  So if the light is already at 30% and you then command it to go to 100%, I would expect it to take only about 6 seconds (70% of 8.5 seconds) to get to full brightness.

[ABLE1]

7 hours ago, Sub-Routine said:

The only changes you need to make are
1) create a scene for the lamp with the level and ramp rate you desire.
2) call the scene from your program instead of the device.

Maybe true.  However, I tried using a scene in the beginning and for some reason

had trouble with it not working as desired.  When I went to just controlling the

switches themselves then all was good.  As I said, I will give it a try when I have nothing else to do.

Thanks for the input!!

Les

 

[oberkc]

2 hours ago, ABLE1 said:

However, I tried using a scene in the beginning and for some reason

had trouble with it not working as desired.  When I went to just controlling the

switches themselves then all was good. 

I think you are making this too complicated and getting hung up on logs and event viewers and stuff.  I admire your interest in understanding these logs, but not at the expense of solving your problem.  You need to break this problem into smaller parts, and fix the parts that are broken.  

Controlling individual devices tends to be more robust than controlling scenes.  I understand that controlling individual devices includes responses and retries, whereas controlling scenes does not.  The fact that individual devices respond does not make it necessarily true that scenes will respond equally reliably.  This is indicative, in my mind, of a comms problem.  This needs to be solved.

[ABLE1]

10 hours ago, oberkc said:

I think you are making this too complicated and getting hung up on logs and event viewers and stuff.  I admire your interest in understanding these logs, but not at the expense of solving your problem.  You need to break this problem into smaller parts, and fix the parts that are broken.  

Controlling individual devices tends to be more robust than controlling scenes.  I understand that controlling individual devices includes responses and retries, whereas controlling scenes does not.  The fact that individual devices respond does not make it necessarily true that scenes will respond equally reliably.  This is indicative, in my mind, of a comms problem.  This needs to be solved.

 

Hi oberkc,

May be somewhat true.  However, my present programing is doing what I wanted it to do except for 

what I assume is the Ramping of the light levels.    The customer is happy with how it is working!!

Therefore for me to work on this by using scenes to get the ramping to actually work is not really

necessary.  I just would have liked the it to ramp.  At this point figuring it out has little value for me.   

If the customer expressed a desire for it and was willing to pay for the extra time spent

that might be a different story.  Economics 101  or Rewards for Time spent.

Thanks,

Les

 

 

 

[oberkc]

9 hours ago, ABLE1 said:

May be somewhat true.  However, my present programing is doing what I wanted it to do except for 

what I assume is the Ramping of the light levels. 

Possibly true.  I hope that it stays true.  Unfortunately, my fear would be that the reliability of the system will not be as consistent as the customer expects.  Communication problems rarely get better, often get worse, and manifest themselves in unexpected ways.  What will happen as the customer starts plugging new things in, like phone chargers, new lights, other electronic gadgets?  In an environment with marginal communications, things can stop working suddenly.

Hopefully, you won't get a call-back and hopefully the customer will be happy and a customer for a long time.

[ABLE1]

1 hour ago, oberkc said:

Possibly true.  I hope that it stays true.  Unfortunately, my fear would be that the reliability of the system will not be as consistent as the customer expects.  Communication problems rarely get better, often get worse, and manifest themselves in unexpected ways.  What will happen as the customer starts plugging new things in, like phone chargers, new lights, other electronic gadgets?  In an environment with marginal communications, things can stop working suddenly.

Hopefully, you won't get a call-back and hopefully the customer will be happy and a customer for a long time.

obeerkc,

Thanks for your reply.  However I am a bit mystified by your "reliability" comment.  What I was questioning

was the Ramp at 8.5% in the Log and it was explained by kclenden to be a result of a power start up status report.

Which makes sense and it could have easily been.  It hasn't happened since.  If there is something else that I

might be missing then please explain, since I am missing it somewhere in translation. 

As for the programming of scenes or not I am quite happen at this time with the not.

Thanks,

Les

[oberkc]

22 hours ago, ABLE1 said:

However I am a bit mystified by your "reliability" comment. 

I was responding to your post stating that you had trouble with scenes working, yet individual devices worked fine.  This, to me, is a potential indicator of marginal communications.  If true, then I get concerned that this could get worse as existing electronics age and as new electronics are added.  

[ABLE1]

oberkc,

Ok, that was more of a "ME"  programming thing than anything else.  

I just found it easier for "ME" to not use scenes to get the job done.

All is good.

Thanks,

Les

 

[oberkc]

On ‎2‎/‎28‎/‎2019 at 8:22 AM, ABLE1 said:

However I am a bit mystified by your "reliability" comment. 

Great.  So the problem was NOT with the reliability of scenes, but the possibility that they were not configured correctly.  I stand corrected.