How to make lights flash?

[LeeG]

Running a 99i means the PLM is more than 1 year old. Is it a 2412 or 2413 PLM?

[espann]

Running a 99i means the PLM is more than 1 year old. Is it a 2412 or 2413 PLM?

It's a 2413S

[espann]

Thts possible. I'm still seeing no traffic from the sensor.

 

-Xathros

Just a note, I never downloaded the driver from http://www.ftdichip.com/Drivers/VCP.htm as instructed in the quick start guide for the PLM. Is that driver file necessary?

[Xathros]

There are no drivers needed fo ISY or the PLM. That link looks like its pointing to a USE to Serial adapter. That might be useful for connecting the serial PLM to your PC via a USB to serial adapter but the PLM would normally be connected to the ISY.

 

-Xathros

[larryllix]

Ok, I removed the lamp from ISY, rreset it to factory reset, and added it back to ISY. Now either lamp will flash if I run their THEN program. But when I move in front of the motion detector nothing happens for either lamp and the admin console does not change status. But this is different from before, because before I reset the bedroom module they both did respond to the motion sensor. Both the sensor and the lamp module are referenced rrespectively..

I am not seeing the MS have the same process done to it. (factory reset and relinked to the ISY)

Was it ever factory reset? Many have learned the hard way and so have I. I don't know what they do to these things at the factory but 90% of all my Insteon modules do really weird stuff until factory reset.

[espann]

Ok, I removed the lamp from ISY, rreset it to factory reset, and added it back to ISY. Now either lamp will flash if I run their THEN program. But when I move in front of the motion detector nothing happens for either lamp and the admin console does not change status. But this is different from before, because before I reset the bedroom module they both did respond to the motion sensor. Both the sensor and the lamp module are referenced rrespectively..

I am not seeing the MS have the same process done to it. (factory reset and relinked to the ISY)

Was it ever factory reset? Many have learned the hard way and so have I. I don't know what they do to these things at the factory but 90% of all my Insteon modules do really weird stuff until factory reset.

OK, what is the best way to unlink the motion sensor from ISY? Do I just click "start linking" and select 'Remove existing links'? I think I've done that but I'll try it again. Also, it is very difficult to factory reset the motion sensor; I'm told to remove the battery, then press the SET button while reconnecting the battery, but I may not have done that in the precise manner indicated.

[LeeG]

Assuming the 'erase existing links' (the default) was already done with the motion sensor there is still the Responder link record in the LampLinc(s). Since these links were created with the Set button do a Restore Device to the LampLinc(s) to eliminate the Responder link(s).

[espann]

Assuming the 'erase existing links' (the default) was already done with the motion sensor there is still the Responder link record in the LampLinc(s). Since these links were created with the Set button do a Restore Device to the LampLinc(s) to eliminate the Responder link(s).

OK, I removed the motion sensor as a controller (correctly this time, I think I didn't do it exactly right before) and I factory reset the motion sensor again, and did Restore Device to recognize the LampLinc, and it FINALLY is responding to the program!

Now the problem I have is that it responds slowly sometimes! And even tho I set the WAIT time to 1 sec, the ON and OFF periods are more than 1 sec. Also, the Administrative Console often says "System Busy", sometimes while executing the program and sometimes randomly. Could this be a phase bridging problem? I don't think it's a matter of proximity of the MS, since it happens even when I have it right next to the PLM and control panel.

But thanks for everyone's help with this issue so far! At least I think we've got it 75% solved! And thanks for your patience with this noob..

[larryllix]

OK, I removed the motion sensor as a controller (correctly this time, I think I didn't do it exactly right before) and I factory reset the motion sensor again, and did Restore Device to recognize the LampLinc, and it FINALLY is responding to the program!

Now the problem I have is that it responds slowly sometimes! And even tho I set the WAIT time to 1 sec, the ON and OFF periods are more than 1 sec. Also, the Administrative Console often says "System Busy", sometimes while executing the program and sometimes randomly. Could this be a phase bridging problem? I don't think it's a matter of proximity of the MS, since it happens even when I have it right next to the PLM and control panel.

But thanks for everyone's help with this issue so far! At least I think we've got it 75% solved! And thanks for your patience with this noob..

I don't know why the response would be slow but one gotcha' I have had is removing and reinstalling devices. Now your program was left with nothing defined and you reinstalled the same device. Go to your programs, make sure your correct device is being tested for conditions and correct device is being operated, reselect, update each one and then save program. Sometimes the links get confused in the programs when a device is removed and then replaced. I find the folder, the device resides in, is usually missing in the programs. Once reselected all info shows up again.

[espann]

OK, I removed the motion sensor as a controller (correctly this time, I think I didn't do it exactly right before) and I factory reset the motion sensor again, and did Restore Device to recognize the LampLinc, and it FINALLY is responding to the program!

Now the problem I have is that it responds slowly sometimes! And even tho I set the WAIT time to 1 sec, the ON and OFF periods are more than 1 sec. Also, the Administrative Console often says "System Busy", sometimes while executing the program and sometimes randomly. Could this be a phase bridging problem? I don't think it's a matter of proximity of the MS, since it happens even when I have it right next to the PLM and control panel.

But thanks for everyone's help with this issue so far! At least I think we've got it 75% solved! And thanks for your patience with this noob..

I don't know why the response would be slow but one gotcha' I have had is removing and reinstalling devices. Now your program was left with nothing defined and you reinstalled the same device. Go to your programs, make sure your correct device is being tested for conditions and correct device is being operated, reselect, update each one and then save program. Sometimes the links get confused in the programs when a device is removed and then replaced. I find the folder, the device resides in, is usually missing in the programs. Once reselected all info shows up again.

Thanks larryllix! I think that was a part of the problem; I actually had several of the same programs in the folder! I deleted the duplicates and the response time on the remaining program is back to about 1 sec.

I still am getting "System Busy" on the Administrative console, lasting for up to 1 or 2 minutes sometimes..

But thanks for reminding me to clean out the My Programs folder, and to reselect and update everything

[larryllix]

Thanks larryllix! I think that was a part of the problem; I actually had several of the same programs in the folder! I deleted the duplicates and the response time on the remaining program is back to about 1 sec.

I still am getting "System Busy" on the Administrative console, lasting for up to 1 or 2 minutes sometimes..

But thanks for reminding me to clean out the My Programs folder, and to reselect and update everything

The times I get the busy messages are when changing levels in a scene or when queries are happening.

 

Other CPU tie-ups can be due to logic flag (consisting of program states or variable states) condition based programs that modify the same logic flags negatively causing oscillations of programs.

 

if

variable = true

AND

variable is not false

 

then

variable == false

 

else

variable == true

 

Right click a suspected program and select stop. Then recheck your light flasher and busy messages.

[espann]

Thanks larryllix! I think that was a part of the problem; I actually had several of the same programs in the folder! I deleted the duplicates and the response time on the remaining program is back to about 1 sec.

I still am getting "System Busy" on the Administrative console, lasting for up to 1 or 2 minutes sometimes..

But thanks for reminding me to clean out the My Programs folder, and to reselect and update everything

The times I get the busy messages are when changing levels in a scene or when queries are happening.

 

Other CPU tie-ups can be due to logic flag (consisting of program states or variable states) condition based programs that modify the same logic flags negatively causing oscillations of programs.

 

if

variable = true

AND

variable is not false

 

then

variable == false

 

else

variable == true

 

Right click a suspected program and select stop. Then recheck your light flasher and busy messages.

Thanks larryllix, I'll check that.

[rlanza1054]

Hi,

 

I didn't want to create a new thread, so I figured it was OK to post to this older thread.

 

I just added a Open/Close Sensor.

 

I'm going to replace a manual Open/Close Sensor that came with a 'back door' wiresless doorbell.

 

I had been using it to let me know if anyone came in the front door (I don't really have a back door, as I live in an apartment building) and did not ring the doorbell.

 

I should not say this but I leave my door unlocked and if my friends come over they know just to come in, there is no need for them to ring the doorbell or for me to get off my butt to open it up to let them in. So having the OpenClose Sensor allowed me to know if someone came in when I was in the back rooms of my apartment. Of course, owning a dog, every time the bell rings the dog goes crazy. If it was a windy day out and I did not at least close the door until the latch clicked even when it is unlocked caused the door to open and close when a breeze went by. So I was getting the bell to go off more than it should have.

 

Of course, if I just made should the door was closed until you have the click, it would not do that stuff.

 

I remember one night at 2am when I was asleep hearing that bell go off, I thought a robber came in to mug me. heheheee.. I was still sleeping. That was the only night I really locked the door.

 

Ok, I digressed.

 

This thread was about making something flash repeatedly.

 

I know how to do that with the 'repeat' command'.

 

What I don't know how to do, is to have it repeat 'until' the door got closed?

 

I want it repeat until a condition is met?

 

Right now with this version of firmware there is no 'until' function. I don't know if UDI added it to the upcoming 5.0 version, if it has, I can upgrade now.

 

I haven't looked at the wiki pages yet, maybe something is in there.

 

Thanks

 

Rob

[larryllix]

...

 

This thread was about making something flash repeatedly.

 

I know how to do that with the 'repeat' command'.

 

What I don't know how to do, is to have it repeat 'until' the door got closed?

 

I want it repeat until a condition is met?

 

Right now with this version of firmware there is no 'until' function. I don't know if UDI added it to the upcoming 5.0 version, if it has, I can upgrade now.

 

I haven't looked at the wiki pages yet, maybe something is in there.

 

Thanks

 

Rob

V5 has a Repeat While construct and this sounds like it would work well for this situation. Right now, I don't recommend upgrading until the next v5 Beta is released since this should be any day now.

 

You could try this.

Create three programs.

1 - flash lights - make sure you insert some wait 1-2 seconds into the repeat 200 times so that other processing gets a chance.

2 - door open - calls flash lights

3 - door closed - stops flash lights.

 

On second thought These could be combined into possibly one program.

 

If

   control door.sensor is switched On

   control door.sensor is not switched Off

 

Then

   repeat 200 times

       set light On

       Wait 1 second

       set light Off

       Wait 1 second

    repeat 1 time

 

Else

    set light Off    <---when door closes the light may be on when Then cancelled.

[apostolakisl]

I would modify as follows

 

 

If

   control door.sensor is switched On

   control door.sensor is not switched Off   <-----------kills running then clause and runs else clause when door closes

 

Then

   repeat every 2 seconds   <----------------- keeps repeating until then clause is killed by door closing

       set light On

       Wait 1 second

       set light Off

    

Else

    set light Off    <---when door closes the light may be on when Then cancelled.

[rlanza1054]

I would modify as follows

 

 

If

   control door.sensor is switched On

   control door.sensor is not switched Off   <-----------kills running then clause and runs else clause when door closes

 

Then

   repeat every 2 seconds   <----------------- keeps repeating until then clause is killed by door closing

       set light On

       Wait 1 second

       set light Off

    

Else

    set light Off    <---when door closes the light may be on when Then cancelled.

Oh man, I feel stupid.

 

I only saw the FOR, not realizing that there was an EVERY option.

 

As far as turning off the light if the THEN is broken, somewhere I read using a second Repeat in the THEN area to break out of the first REPEAT.

 

I think the example went something like what I wrote for the Doorbell and I/O Linc:

 

Doorbell IO Linc Rung - [iD 0022][Parent 0001][Not Enabled]

 

If

        Control 'DoorBell IO Linc-Sensor' is switched On

 

Then

        Repeat 3 times

           Set 'DoorBell IO Linc-Relay' Fast On

           Set 'Foyer Dimmer' On

           Wait  0 seconds

           Set 'DoorBell IO Linc-Relay' Fast Off

           Set 'Foyer Dimmer' Off

        Repeat 1 times

           Set 'Foyer Dimmer' Off

           Set 'DoorBell IO Linc-Relay' Off

 

Else

        Set 'Foyer Dimmer' Off

 

 

BTW: I'm still playing around with the above program.

 

I'm trying to solve the loop I'm encountering because for some reason, triggering the Relay, triggers the Sensor, which the Sensor activates the Relay again, hence loop.

 

No need to reply to that because I asked that question in another thread.

 

But I was pointing out that I read to break out of the loop to try and put the second REPEAT in, so I could turn off the light and disable the program so the looping stops automatically.

 

So when you say the Light might be still on, when the door gets closed. Were you just saying that because that's the reason you added the line in the ELSE part.

 

I might have overthought this again, because I was planning on having two programs, one to turn on the light (and ultimately also ring the doorbell, but the back door bell hookup which rings differently) and the other program to turn off the light when the door is closed.

 

In your program, we never really separately test for the door closed.

 

We are only saying if the door is opened do something.

 

We never say what to do when the door is closed, if I am actually planning on not really doing anything.

 

So then one program should work, I didn't realize that within the same program you can ultimately test for the two conditions.

 

I just thought we are always testing to make sure the item went on and to make sure it wasn't off.

 

Oh, I  must be tired today.

 

It is really very simple then.

 

I actually thought there was a way of doing NESTED things in the THEN but it seems you can only do those NESTs in the IF part of the program.

 

I was going to write:

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

program 1

If sensor opened (ON=door opened)

 

REPEAT x times (maybe keep it low something like 3 or less)

do function 1

wait x seconds

do function 2

 

but this is where I can add a second repeat 1 time to help break out of a loop

 

REPEAT 1 time

 

RUN program 2 (Check in that program for door closed)

 

ELSE

 

turn off light and reset any other function  programmed for it to do

 

program ends

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

 

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

program 2

IF sensor is still OPENED (ON=door still opened)

 

THEN

run program 1 THEN FUNCTION no need to do the IF (this keep the repeating process to keep going as long as the door is opened)

ELSE

 

turn off light and reset any other function  programmed for it to do

 

program ends

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

 

 

But you feel its ok to just do it all in one program using REPEAT EVERY x seconds that it should break out of the THEN when the condition changes.

 

I didn't think it would go back and recheck the IF portion while its running the THEN portion.

 

Its seems I'm still thinking logically and not event based.

 

Rob

[stusviews]

Wait 0 seconds does nothing. It's the equivalent of Don't Wait. To end a Repeat, add Repeat 1 times.

[rlanza1054]

Wait 0 seconds does nothing. It's the equivalent of Don't Wait. To end a Repeat, add Repeat 1 times.

 

Sorry I should have put a comment in that part. I was testing out different wait times. I wanted to test it without the wait, so instead of deleting it I just updated it to 0 seconds.

 

Rob

[larryllix]

Sorry I should have put a comment in that part. I was testing out different wait times. I wanted to test it without the wait, so instead of deleting it I just updated it to 0 seconds.

 

Rob

Another thing to note is that Repeat every x seconds does not loop every X seconds.

 

The syntax should have been something like Repeat with X second delay.

 

Repeat Every 5 seconds

   do something

   Wait 2 seconds

   do something

   Wait 2 seconds

 

Does something twice every nine seconds.

[rlanza1054]

Another thing to note is that Repeat every x seconds does not loop every X seconds.

 

The syntax should have been something like Repeat with X second delay.

 

Repeat Every 5 seconds

   do something

   Wait 2 seconds

   do something

   Wait 2 seconds

 

Does something twice every nine seconds.

Again, I'm sorry, the reason for using the word loop is because of and issue that I am having.

 

It seems even though I have the I/O Linc Relay NOT to follow the Sensor part of I/O Linc, everytime I send an ON to the Relay the Sensor picks up that ON and sends it back to the Relay.

 

So a loop is introduced inside the I/O Linc. Because the Relay gets told to turn on, then it receives what its not supposed to receive (based on default settings, if I am reading the manual correctly) an ON command from the Sensor.

 

The Sensor is supposed to only react to the physical button attached to the Sensors input terminals of GND and Sensor.

 

The Relay is not supposed to be either listening to the Sensor to being instructed by the Sensor part of the I/O Linc.

 

I am trying to determine if the unintended loop (which is causing the doorbell to ring for infinity, until I disable the program) is an Option setting not getting applied correctly or maybe the ISY can only handle some of the features of the I/O Linc, which I verified today, its missing quite a few. 

 

I started this thread just to talk about the open/close sensor using the Relay part of the I/O Linc and having it repeat certain things.

 

But because I post my program for the doorbell which is something else I am working on, I was showing you something I read in the wiki on how to break out of a repeat by introducing a second repeat, which allows you do insert a method of getting out of a the first repeat because it allows you to sneak in a way to check on things, such as run a different program that either doesn't allow the first repeat to continue or allow it to continue.

 

Its all because the first REPEAT is executing all of the lines of code within the THEN area, and that includes that second REPEAT. I guess a way of getting something NESTED into the THEN area.

 

Am I explaining it in a way that you understand what

I was attempting to do based on the information that is in the wiki?

 

It might not be the best way, but it did help me until I solve it all.

 

And I do like that you provided another way to do REPEATS based on time (EVERY) not amount (FOR).

 

I thank you for that.

 

And what I just wrote in another thread, I discovered  "the hard way" that I misunderstood what the Momentary B setting on the I/O Linc does.

 

I now know, I no longer have to worry about sending any OFF commands to the RELAY when it is set in Momentary B, it will automatically Open the circuit (turn the device connected to it OFF) based on the duration time set to keep the circuit CLOSED (turn the device connected to it ON).

 

Just this very important way the RELAY is working, might solve my issues.

 

It could actually solve the loop problem.

 

Tomorrow I will re-write the programs with this new learned information of how the I/O Linc is working.

 

And I will call Insteon on Monday to find out why the default setting of "Sensor input’s control of output relay will be reset to disabled".

 

instead of creating yet another thread, let me pose this question which I know the answer is No, but maybe just maybe is it something other than NO.

 

I had things working with two extremely simple scenes.

 

One scene was to listen to the I/O Linc Sensor, in my case, to see if the physical doorbell switch was pushed ringing the doorbell the old fashion way, but because the Sensor is watching for this when it sees it rung, it will turn on a light for example.

 

The other scene was using the I/O Linc's Relay function, so having the doorbell wired to the I/O Linc to act as the switch for the doorbell, I have a motion sensor send the ON command and it rings the doorbell closing the Relay and the doorbell ding dongs according to the duration time set in options.

 

That is one ding dong.

 

But since I have been talking about getting the doorbell to ring REPEATLY, I was forced to use a program.

 

Is there a way to insert a program into a scene. So if the scene is triggered instead of just turn the RELAY on and off once as it does by default, is there a way to make the scene react differently than its normal linking allows (a scene links one item to another, so the controller turn on and off the responder), could a program be added to the scene and act as a controller?

 

Maybe the ISY assigns a program a virtual Insteon device address so that you can link it into the scene like a motion sensor acts like a controller to the light switch turning it on. But in this case since the program is a virtual device that is disguised to look like a controller to the switch (in this case the I/O Linc's relay is the responder, but the program can do more than a simple ON or OFF, it can send repeating ON's of Off's and also doing wait times in between those commands.

 

Like I said I am expecting a No, it can't be done.

 

But think about having that ability to encase a program give it an Insteon address which can then be linked to a Insteon device, the Insteon device doesn't know if its a regular Insteon device getting link to itself or this sudo program that looks like a Insteon device.

 

Then you would be able to add a program into a scene.

 

Interesting idea or have I gotten into the crazy territory?

 

Rob