Jump to content

Recommended Posts

Posted

Well, it's been almost one year to the day since I received my ISY and first Insteon modules and I wanted to share some thoughts on what I perceive as the good and bad thus far.

 

1. I have to start by stating that Micheal and the gang at UD provide AWESOME support. You can tell that they're dedicated to this product just by looking at the updates! Hand's-down, their customer service is some of the best there is.

 

2. Coolness factor - While I'm not a programmer, I'm definitely a guy who revels in the latest tech. The things a person can do with the ISY are pretty astounding! You should see the faces of my guests when I turn on my stereo, family room lights, and dim the kitchen with one press of a button!

 

3. Security - While I do feel that I was somewhat duped when I bought what Smarthome labeled as the "ELK M1 with Insteon Compatibility" (Not UD's fault, SH branded this in a way that made a LOT of people think it was more than it is.) Nonetheless, using programs to notify me through both the ISY and ELK has made me much more confident that I'll know if there is trouble (ie break-in, fire, etc.). Plus, I can keep tabs on the housekeeper and dog-sitter when they're there!

 

4. Now for the first negative....time and effort. I'm somewhat tech-savvy, and learn quickly, but I've found that searching through forums to be both a help and hinderence. Not that learning something new is a bad thing, I've just spent more time reading and testing that I thought would be needed. For example, I've spent most of my weekend (probably 16 hours) configuring my newly-installed garage sensor. I rendered myself lost when trying to contemplate the status of devices vs. actual status (ie Sensor "ON", Trigger Reverse [Wiki shows "Trigger Off"], Relay "ON", KPL programming, etc.).

 

5. This goes along with #4...I don't know how, specifically, but it would be nice to see the Wiki organized in a way that is more efficient to us common folk. More/better tutorials on items like setting up new devices to run a certain way, programming logic, using/configuring the Networking Module, and general troubleshooting would be awesome. Take LED brightness on KPL's as an example. There is a Wiki page with a very brief explanation of creating scenes for the LED buttons, but it wasn't until I stumbled upon a post by LeeG that I learned that using brightness levels in programs is a bad idea. Again, I don't have a specific layout in mind, just something that might enable the average user to avoid opening 12 tabs in Firefox with different forum posts, then having to disseminate between them to find the best/right way.

 

These are the things that come to my mind when looking back over the past year. I hope that any criticisms are taken constructively, as I definitely feel that the pros outweigh the cons. I don't mind spending the time so long as my intended results are working. It's just that when they don't, finding out why can take a LOT of effort and this might surprise/deter the guy who gets into the world of HA thinking that it'll all operate his way out of the box.

 

With all of that said, I completely understand how busy the UD team is making improvements and responding to customers. That's what I appreciate the most and it's the main reason why I'll keep visiting these forums and remain a UD customer as new modules are released. Without fail, the ISY is the best choice to manage all of my devices.

Posted

Hello backinthelab,

 

Thanks so very much for your thorough review and not only we take your criticism constructively but also we appreciate it very much: without feedback like yours, we would not be where we are today.

 

We are very well aware of lack of documentation and we are working on it slowly and only at off hours when we have not much else going on.

 

Again, thanks so very much for your feedback and rest assured it is taken quite seriously.

 

With kind regards,

Michel

Posted
Take LED brightness on KPL's as an example. There is a Wiki page with a very brief explanation of creating scenes for the LED buttons, but it wasn't until I stumbled upon a post by LeeG that I learned that using brightness levels in programs is a bad idea.

 

Yes, I just learned that the hard way. I spent a good half hour last night and ended up having to completely remove my kpl from ISY factory reset it and then add it back rebuilding all the scenes to fix it.

Posted

@LeeG - I have it working, yes, but put an asterisk by "working". KPL buttons respond and activate, however, I have a problem with the sensor updating it's status. I put a band-aid on this issue by writing a sensor query program that relies on the relay status changing for now, and it works some of the time. I haven't had a chance to actually get up to the device for local programming/resetting. Here's my config if you have any ideas:

 

i/oLinc 2450 v .36

Sensor is the 3-wire one from SH

(purchased these items separately but they're the same as the kit)

 

Sensor is wired with green/black wires to N/O and GND, shows a status of ON when door is closed. Relay is in Momentary A with Trigger Reverse activated.

 

If the query program doesn't catch it, I can manually query the sensor and it will return the correct status.

 

Aside from updating sensor status, the other issue (and confusion could be causing this one), is having other devices like the ELK respond to the door opening. Since the i/oLinc is in Trigger Reverse, I'm not sure if my programming is backwards. For example, I have this program to flash my hall lights when the door is opened. It currently is working when the door closes, which is messing with my head:

 

If
       Program 'Closed' is False
   And Program 'Open' is True
   And Status  'Upstairs Hall - Primary' is Off

Then
       Set 'Upstairs Hall - Primary' Fast On
       Set 'Upstairs Hall - Primary' Fast Off
       Repeat 0 times

Else
  - No Actions - (To add one, press 'Action')


 

Program "Closed":

If
       Status  'My Sensors / Garage Door - Sensor' is On

Then
  - No Actions - (To add one, press 'Action')

Else
  - No Actions - (To add one, press 'Action')

 

Program "Open" is the same but looking for OFF status.

 

I'm unsure if I should be looking to poll the opposite status? I ask because the ELK has a program to say, "Garage Door Is Open" when sensor is turned off but, again, this is currently working when the door closes.

 

Anyways, that's what's currently going in my struggle. Any ideas would be greatly appreciated, I've read a 1/2-dozen threads but they seem to confuse me more!

 

@Michel - Thanks for the prompt and polite reply (per usual!). As I stated in my first post, I know you guys are working hard on other aspects of the ISY and my comments are just ideas for the future of how ISY users might be able to find information faster. Another added bonus is that you might free up some of your time as wouldn't always have to be on the forums! :wink:

Posted

backinthelab

 

The I/O Linc Sensor should be showing a reliable On/Off status under the Admin Console I/O Linc Sensor node. Querying the relay in any Momentary mode is difficult because the timeout value is going to turn Off the relay in a few seconds. Let’s get the basic I/O Linc working which should make Programming much easier and no band-aid required.

 

Does the I/O Linc Sensor node reliably show sensor status? If not does the I/O Linc Green status LED correctly show the status reliably? If not then the magnetic switch location/installation is where to look. If that is the same magnetic switch that comes with the garage kit it is a wide gap switch which normally works even under the most adverse conditions. If the I/O Linc Green LED is always correct but the Admin Console Sensor node is not accurate the normal powerline analysis is appropriate. Perhaps the circuit the I/O Linc is powered from is noisy or too far from other Insteon devices to reliably reach other Insteon devices to be repeated. If the Admin Console never shows Sensor status change then device or PLM link records are in question. The I/O Linc Sensor uses Insteon Group On/Off commands (Scene commands) which require correct link records on both ends for the Group messages to be seen by the ISY PLM.

 

Only when the I/O Linc Green LED is correct all the time and the Admin Console Sensor node is correct all the time is it useful to look at the Programming side.

 

I'm sure you know but just in case if the Trigger Reverse is an issue then simply use the other wire (red/black?) which reverses the Senor state without the need for the Trigger Reverse option.

 

Lee

Posted

The sensor status doesn't update correctly in the Admin console, however, I did confirm that the green LED is functioning properly on the relay. The magnetic switch is working well as installed, and there is an access point plugged in directly on the other side of the garage wall. So, it appears that all fingers are pointing to the PLM, which doesn't surprise me since I've had issues before that made me question it's stability.

 

I'm at the office now, but any tests I can run when I get home to prove this out?

Posted

Does the Sensor node status change some of the time or not at all? If some of the time then communication between the I/O Linc and PLM location is in question. If the Sensor node never changes status then link records, either in the I/O Linc or PLM are suspect. A Show Device Links Table request for the I/O Linc should show a Controller link record (E2) for Group 1 pointing to the ISY PLM address. The PLM must have a Responder link record (A2) with the I/O Linc address and Group 1. Program execution will never be reliable until the Admin Console is showing consistent status updates. I am assuming the Admin Console is showing accurate status changes for other devices. Not clearing the Java cache after an image update can also prevent status updates from appearing in the Admin Console. The Sensor messages can be viewed using the Event Viewer at Change level 3 – Device Communications Events if there is concern the Admin Display node status may not be updating correctly.

Posted

LeeG, thanks so much for your help, it's greatly appreciated!

 

I ran a Show Links for both the Sensor and the PLM. I believe I'm reading them correctly, but wanted to post the I/O Linc's results just in case. I also ran "Compare" and it appears that the results might point to something???

 

[Record mismatch] 0FF8 : A2 00 12.9F.9A FF 1F 01

[Record mismatch] 0FF0 : E2 01 12.9F.9A FF 1F 01

[Extra record] 0FE8 : A2 15 12.9F.9A FF 00 00

[Extra record] 0FE0 : A2 06 07.F3.1A FF 00 00

[Extra record] 0FD8 : E2 01 07.F3.1A FF 1F 01

[Extra record] 0FD0 : A2 07 16.76.C2 00 00 00

[Extra record] 0FC8 : E2 01 16.76.C2 FF 1F 01

[ignore] 0FC0 : 00 00 00.00.00 00 00 00

Posted

Sure looks like the I/O Linc link records are not what the ISY thinks they should be. When I run a Compare on my I/O Linc it shows [identical] along side of each displayed link record. I would do a Restore Device (right click on Sensor node) and run the Show Device Links Table and Compare again to verify. The objective is to see consistent and correct status updates of the I/O Linc Sensor node status on the Admin Console. I don’t care about the Admin Console display itself but without that being correct ISY Programs do not have accurate information about the I/O Linc status. Once that is achieved then attack whatever symptom is left if any.

Posted

Ran a Restore and now a compare results in all "Identical" but the last entry which has an "Ignore". Still, no luck with updating properly in the Admin Console.

 

What's happening is when the door is closed (Sensor ON) and I turn the Relay ON to activate the door, the sensor status and the relay status both remain ON and don't change without a manual query.

 

But something else is happening that is odd. If I don't query the nodes and leave them both ON when the door is opened (incorrect status), then activate the door again, the sensor WILL turn OFF when closed. A query would then show actual status of ON, but it DOES change status in the Admin Console when going from closed to opened but not the other way around. Weird, huh?

Posted

The [ignored] entry is the end of active link list marker which is in the device link database but the ISY does not keep in the ISY database so it will show ignored. That is normal.

 

The relay node will not change state from On to Off when the I/O Linc turns the relay off automatically in one of the Momentary modes. The I/O Linc does not notify any device about the automatic relay Off associated with Momentary mode so the Admin Console relay node stays at On unless a Query or the Off Admin Console button is clicked or a Scene Off is initiated where the I/O Linc relay is a responder.

 

In the example I assume the door does Open but the Admin Console does not reflect a state change for the Sensor node. The fact that the Admin Console Sensor node changes to Off when the door closed tells me the On/Off commands from a Sensor state change are the reverse of what you want. The Senor node shows On in the Admin Console, the door opens and the Sensor in the I/O Linc changes to Off state and sends an On command. Not the command you want issued when the IO Linc Sensor turns Off but I think a command is sent to the ISY. When the door closes and the Sensor state at the I/O Linc turns On it now sends an Off command which is expected since it sent an On command when the door opened and the state change sent an On command.

 

When you said the Sensor is On when the door is closed, is that the Green LED on the I/O LInc is On when the door is closed? If so it sounds like the Trigger Reverse option is in effect causing the I/O Linc to send an On command when the I/O Linc Sensor turns Off (Green LED Off). Turn the Trigger Reverse option Off and try cycling the door. It may be necessary to cycle the door twice before the I/O Linc Sensor and the Admin Console Sensor node are in sync.

 

Ignore the relay status not changing, that is normal. The I/O Linc does not send a notification when it automatically turns the relay Off because of Momentary mode.

 

I think once you get the appropriate On/Off command sequence you want things will be working as far as the I/O Linc and Admin Console are concerned. There may be program issues we have not looked at yet by design as I did not want any more variables involved than absolutely necessary.

Posted

Lee, you're the man! Performed a Restore and switched the sensor wires to red/black instead of green so I wouldn't have to rewrite all of my programs. It's working great now!!!

 

Thanks a million for your help, hope you have had a great Thanksgiving!


×
×
  • Create New...