kclenden Posted February 11, 2019 Posted February 11, 2019 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. 1
larryllix Posted February 11, 2019 Posted February 11, 2019 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 Posted February 11, 2019 Author Posted February 11, 2019 (edited) 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 Edited February 11, 2019 by ABLE1 Updated input 1
larryllix Posted February 11, 2019 Posted February 11, 2019 You're getting there!Nice going!Sent from my SM-G930W8 using Tapatalk
kclenden Posted February 12, 2019 Posted February 12, 2019 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 Posted February 12, 2019 Posted February 12, 2019 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 Posted February 12, 2019 Posted February 12, 2019 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 Posted February 13, 2019 Author Posted February 13, 2019 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 Posted February 13, 2019 Posted February 13, 2019 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 Posted February 25, 2019 Author Posted February 25, 2019 (edited) 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 Edited February 25, 2019 by ABLE1
kclenden Posted February 26, 2019 Posted February 26, 2019 (edited) 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. Edited February 26, 2019 by kclenden
ABLE1 Posted February 26, 2019 Author Posted February 26, 2019 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 Posted February 26, 2019 Posted February 26, 2019 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 Posted February 26, 2019 Author Posted February 26, 2019 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 Posted February 27, 2019 Posted February 27, 2019 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. 1
kclenden Posted February 27, 2019 Posted February 27, 2019 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. 1
ABLE1 Posted February 27, 2019 Author Posted February 27, 2019 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 Posted February 27, 2019 Posted February 27, 2019 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. 1
ABLE1 Posted February 28, 2019 Author Posted February 28, 2019 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 Posted February 28, 2019 Posted February 28, 2019 (edited) 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. Edited February 28, 2019 by oberkc
ABLE1 Posted February 28, 2019 Author Posted February 28, 2019 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 Posted March 1, 2019 Posted March 1, 2019 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 Posted March 1, 2019 Author Posted March 1, 2019 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 Posted March 1, 2019 Posted March 1, 2019 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.
Recommended Posts