Crosslink devices

[yardman 49]

Hello all:

 

Sorry for such a basic question. But the User Guide is out of date, and the Wiki was not much help either.

 

I just want to know how to crosslink devices via ISY. So, for instance, if I want to link a Togglelinc to a KPL button as controller/responder, and then vice versa, do I need to create 2 scenes? Or can it all go in one scene?

 

Also, adding devices and creating scenes seems so slooowwwww.

 

Sorry

 

Nooblinc Frank

[sloop]

one scene - both devices added to the scene as controllers

 

that will sync the keypad button and the togglelinc - both will perform the same function AND - the keypad button will be in sync

 

i have lots of that kinda stuff - like a button linked to a lamplinc - i name those scenes with a unique special character in the first position so they will be grouped together

[yardman 49]

Slooplinc:

 

Mine doesn't seem to be responding properly. Let me tell you what's happening:

 

I added the KPL and 2 Togglelincs to the ISY. At first, I tried it with importing links. ISY went into endless loop for about 10 to 15 minutes on the last togglelinc, so I rebooted ISY, and removed all devices that I had added. I then added the KPL and Togglelincs back into the ISY, this time overwriting all links.

 

Well, that didn't seem to really work either, as I still had old links in the devices, which meant they were crosslinked before I even created any ISY scenes.

 

So I again removed all devices, and then factory reset the KPL and TGLs. Then I added them again using "overwrite links".

 

So currently I can control individual devices ok. But then I tried to create a scene for the Lower Hall, with both the TGL and KPL Button C (in eight button mode) as "controllers" as you said. But this didn't work. Turning the Scene on from ISY did nothing. And turning on the TGL did not activate the KPL button.

 

This happens even when the scenes created with no errors.

 

I then changed the KPL Button to a "responder" in the scene. But still no joy.

 

My brainlinc is hurting now.

 

Any additional guidance will be gratefully received.

[sloop]

i think the factory reset is a good idea - if you use the option (when adding a device) that the isy can 'crawl the network', it might find a link made outside the isy and follow it to another device, then another device and so on - i am not a fan of that option

 

when adding a resource to a scene, the isy won't let you make the same resource a controller of 2 scenes, so you should be ok there - but the isy has to know about the links - is it possible that there is a link (made outside the isy) that uses any of the resources as a controller?

 

how many keypads do you have? not to be insulting or anything, but are you sure you have the right one? i debated a long LONG time before renaming my buttons - because the sort order of the display would not keep them grouped together - silly question i know - just a thought

 

i think its a good idea to make all links through the isy if possible - if you have more than 417 links, you can't do that yet - but i have found that if the isy knows about all the links in the network, it will save me from myself by not allowing stuff like 2 controlling links

 

but - lemme summon the smart users - where are you randlinc? marklinc? anyonelinc?

[yardman 49]

Hello Slooplinc:

 

My KPL buttons should be in order. This is how I name them: ex: "Hall KPL A - Porch Light", "Hall KPL B - Garage",etc. That helps me keep track of things, because they stay in alphabetical order.

 

I'm only working with a very small subset of my entire network, as ever since setting up the ISY/PLM I've had Comm Failure problems. I've been in touch with Michel, and he was a big help, giving me suggestions and even sending me a beta PLM "Firm58". But this did not help, either. He's probably getting sick of reading my emails!

 

I've tried a lot; different rooms, the "piggy backed AccessPoint" trick, longer Request delay times,etc. It would seem like I was making progress for a while, but then I'd start having Comm Failures again at times. I think that the failures were contributing to my inability to make scenes, even when adding a device to a scene did not show an explicit failure.

 

But there finally is good news! I was able to finally crosslink, using your suggestion. But first I did a "remove modem", then deleted all devices from the ISY, so that I could start over. This seemed to clear out the ISY/PLM's brainlinc, and the allowed them to start playing happy with my switches' brainlincs.

 

More importantly I think, I was able to find a better "Requests" Delay for my system. Changing that to 300ms seems to have fixed my comm problems, even when using the Firm52 PLM. And I don't need the piggy backed AccessPoint, either. Yippee!!!

 

Hopefully this keeps working. I'll let you know. And thanks for the advice.

[sloop]

i had problems until i did a fresh start like that - the factory reset assured me there were no old or broken links - and i did all linking through the isy - ever since then it was smooth sailing

[yardman 49]

Oops! Spoke too soon about Comm Failures....they're back!

[sloop]

is the plm led falshing? lol - i am obsessed with watching it when linking

 

also, check the console (not the gui) for messages - the one with the [15] means the isy and plm ain't talking

 

have you exercised the plm heavily today? that caused mine to go on strike until i let it rest - i know you have a test plm, just curious if it might be the same problem

[yardman 49]

Hello Sloop:

 

You have mentioned the console a number of times now. How do you get to it?

[sloop]

there are 2 ways but i only know one

 

the second plug on the top of the isy - it looks like the one that goes to the plm - plug that into a pc serial port on your pc (i had to buy a serial to usb converter at circuit city - they had it in a cart to throw away so there is not much demand for them) - then open hyperterminal and open the connection to that com port

 

there is a way to telnet into it, but i have never done that

 

i keep it open when i am doing setup stuff - there are a few commands (case sensitive) you can issue and when an error is encountered, a message is displayed

 

this one

 

H_ERROR: -2 : 15

LOGGER: -2 : n=[null] c=[15] a=[null]

 

is the plm not responding to the isy

 

the userid/password by default is the same as the gui - the RS command boots the isy - it will list a few commands for you

 

this connection is optional and if done, is in addition to the other connections to your router and plm

[sloop]

its called the 'admin shell' - i have been calling it the console - old mainframe bigots embrace change slowly and reluctantly

 

let me try to find the telnet instructions

[sloop]

found michel's instructions in another thread

 

Since you cannot get to our admin screen, the only way to get this information is through telnet. To do so, please note the IP address of your ISY and:

1. Do Start->Run and type cmd on your computer

2. Type telnet [iSY IP address] 126

3. Type admin/admin for userid and password

[Michel Kohanim]

Frank,

 

With sincere apologies for tardy reply.

 

I must tell you that, at the moment, I do think that there are too many unexplainable issues in your dealings with ISY (which really trouble me):

1. Querying a device should only take one Progress Bar run. If it takes more, there is a problem

2. If ISY cannot control your scene, it means only one thing: your devices in the scene do not have the responder/slave links in them or the signal is not going out of PLM to the group

 

In short, INSTEON signals do not get to their destinations!

 

All of which lead me to suspect that in all likelihood we will never be able to have a stable system unless we figure out why!

 

So, the variables are:

1. ISY

2. PLM ... you have the Beta PLM so this shouldn't be the problem

3. INSTEON network/powerline/noise issues

4. One or more defective devices on the network

 

In order to ascertain which is the culprit, I would be delighted to send you another ISY and you can redo your experiments. If the other ISY also exhibits the same issues, then it would take the Master of INSTEON to figure out what is causing the signal loss.

 

Again, please accept our sincere apologies for all the troubles you've been experiencing.

 

With kind regards,

Michel

[Sub-Routine]

 

More importantly I think, I was able to find a better "Requests" Delay for my system. Changing that to 300ms seems to have fixed my comm problems, even when using the Firm52 PLM. And I don't need the piggy backed AccessPoint, either. Yippee!!!

 

Hopefully this keeps working. I'll let you know. And thanks for the advice.

 

Where did you find the option for Requests Delay? I thought 500ms was the minimum for Insteon (send/receive), but only nerdlincs need to know this.

 

You have confused me now!

 

Rand

[Michel Kohanim]

Frank,

 

With sincere apologies for tardy reply.

 

I must tell you that, at the moment, I do think that there are too many unexplainable issues in your dealings with ISY (which really trouble me):

1. Querying a device should only take one Progress Bar run. If it takes more, there is a problem

2. If ISY cannot control your scene, it means only one thing: your devices in the scene do not have the responder/slave links in them or the signal is not going out of PLM to the group. This is explainable if you have 300 m.s. between delays as nothing is written and ISY cannot figure which device is in error since the PLM keeps sending a nak continuously. 500 m.s. is THE MINIMUM!

 

In short, INSTEON signals do not get to their destinations!

 

All of which lead me to suspect that in all likelihood we will never be able to have a stable system unless we figure out why!

 

So, the variables are:

1. ISY

2. PLM ... you have the Beta PLM so this shouldn't be the problem

3. INSTEON network/powerline/noise issues

4. One or more defective devices on the network

 

In order to ascertain which is the culprit, I would be delighted to send you another ISY and you can redo your experiments. If the other ISY also exhibits the same issues, then it would take the Master of INSTEON to figure out what is causing the signal loss.

 

Again, please accept our sincere apologies for all the troubles you've been experiencing.

 

With kind regards,

Michel

[Michel Kohanim]

Rand,

 

You are 100% correct. The minimum delay IS 500 mS. Anything lower simply confuses the PLM and only "random" data is written to the network.

 

The commands to change the delay/timeout/baudrate have been removed from the shell menu system but they are still accessible if you know them!

 

With kind regards,

Michel

 

 

More importantly I think, I was able to find a better "Requests" Delay for my system. Changing that to 300ms seems to have fixed my comm problems, even when using the Firm52 PLM. And I don't need the piggy backed AccessPoint, either. Yippee!!!

 

Hopefully this keeps working. I'll let you know. And thanks for the advice.

 

Where did you find the option for Requests Delay? I thought 500ms was the minimum for Insteon (send/receive), but only nerdlincs need to know this.

 

You have confused me now!

 

Rand

[yardman 49]

 

More importantly I think, I was able to find a better "Requests" Delay for my system. Changing that to 300ms seems to have fixed my comm problems, even when using the Firm52 PLM. And I don't need the piggy backed AccessPoint, either. Yippee!!!

 

Hopefully this keeps working. I'll let you know. And thanks for the advice.

 

Where did you find the option for Requests Delay? I thought 500ms was the minimum for Insteon (send/receive), but only nerdlincs need to know this.

 

You have confused me now!

 

Rand

 

Hello Rand:

 

Sorry for the confusion. You change the the Requests Delay through the Admin shell. I don't think it appears in the menu, however. The command is upper case "CD" (change delay).

 

I spoke with Michel today, and he also expressed surprise that a delay less than 500 ms works. i don't know why it works, but it does seem to make a big difference for me. I made some additional tweaks last night, so now it is at 350 ms. And the AccessPoint had to be put back on top of the PLM. That seemed to be necessary when a large Togglelinc controlled incandescent can light circuit (with many lights) was turned on. This probably changed the low level noise on the system, making it necessary to move the AP back.

 

I know from experience with high speed digitizers and ion current multipliers that strange harmonics can occur when capacitances change or are mismatched on electronic circuits. Maybe there's some sort of noise that is worse at some times than others, and is is interfering with acknowledgments from the PLM to the ISY. After all, the ISY is running on its own power supply, whereas the PLM is running off of its own 12 volt supply. There could be some ringing on the serial line between them as a result. Possibly changing the delay helps with this.

 

It would be interesting to see if the same problem happens with the 99.9, or if it goes away due to both devices running from the same 12 supply.

 

What was compounding my problems was that I may have stumbled across a problem with how 2.4.13 is handling the "Remove Existing Links" option. After I related my experiences with Michel, he said that the links should have been overwritten, but in my case, it seemed as though my Houselinc links were persisting. If so, then that is a bug. Michel will look into this. So for awhile there, my "downloaded" links weren't working.

 

But it seems like I am making progress. I'm going to add a little at a time to the ISY control, since I have a reasonably large setup, and I don't want to get deep into it and then find that I'm having too many issues. But I am optimistic that eventually it will work as intended.

 

Thanks

[Michel Kohanim]

Frank,

 

I wanted to verify that there's indeed a bug in ISY when:

1. Using "Add New Insteon Device"

2. Choosing "Overwrite existing links"

 

Using the above scenario, existing links are NOT overwritten. This said, however, if you choose the "Start Linking" option and then choose "Overwrite existing links", then existing links are indeed overwritten. You can also follow up "Add New Insteon Device" with a "Restore Device" after the addition into ISY.

 

Thanks so very much for finding this bug. It shall be fixed in the next release.

 

Furthermore, it seems that 350 M.S. actually works all the time with PLMs v56 and above and intermittently with PLMs version 52 and not at all with PLMs version 4A. This is quite interesting and something that we would have to investigate more since, at the moment, this behavior is unexplainable!

 

With kind regards,

Michel