Need a tutorial of how ordinary device installations work

[Harold]

I have had a system for 10 years. But I have never really understood how it works. Some times it works; sometimes not.

The published manuals skip over simple explanations of how things work to go on to higher level processes and techniques. They skip over simple needs.

I have spent many many hours trying to figure out how things work. But I have not found resources I can understand that explain in understandable terms how things relate to each other in the product. There are some posts that try to explain things, but not sufficiently. There is nothing I have found to provide an understanding of how the low level processes work and interact with scenes, devices, etc. They are not simple, but not really explained in depth. They skip over details; assume understanding that does not exist as a new user,  jargon completely not understandable to a simple user. A whole lot of the information is simply directed to people that are a whole bunch more knowledgeable than myself.

The explanations of how scenes, devices, and use work together are just not clear to me. There is a significant vacuum for basic understanding. Forum posts (that may or may not be found) are not the solution.

Users should not be expected to try things to make it work because understandable  documentation is not available. The terminology is somewhere between obscure and not understandable.

I may be ignorant (and frustrated). And perhaps too stupid to deal with things. But I have spent many many hours trying to get relatively simple systems to work. Clearly, others have not been constrained by available documentation. Me, not so much. This can have significant marketing impact. How many potential customers give up after trying a few devices and not "getting it".

Would you please provide documentation in a single file with explanations of "how things work" usable by an ignorant user. This means at the detail level.

Another point about user friendly: I edited my post. The two options after I edited the post are Cancel and Edit topic. Why can this not be finished/post/save. Why, "edit topic"! Not a simple, understandable "finished"? A characteristic of much of the documentation.

[Goose66]

Well as to your latter point, the forum software is a third-party product and not developed or documented by UDI.

As to your first point, there have been many requests over the years for an ISY 994i for Dummies book, but nobody has step up to the plate on this one. UDI is not a vertical player in the home automation market. They make a single device that supports a variety of devices, both natively (Insteon, Z-Wave, Zigbee, Elk, etc.) and indirectly via the Node Server API in 5.0 firmware. 

I would suggest that you first learn about the types of devices you are using. For example you talked about Scenes and Devices and how these relate to each other. Generally this relationship will be a product of the device protocol (e.g. Insteon) and not something that comes from the ISY 994i. Once you have an understanding of, e.g., Insteon devices and scenes, how they are set up, how they operate, and the like, it will be easier to understand these concepts in the Administration Console of your ISY.

And, as always, if you have specific questions, just ask - someone in this community has an answer I am certain.

[Techman]

2 hours ago, Harold said:

I have had a system for 10 years. But I have never really understood how it works. Some times it works; sometimes not.

The published manuals skip over simple explanations of how things work to go on to higher level processes and techniques. They skip over simple needs.

I have spent many many hours trying to figure out how things work. But I have not found resources I can understand that explain in understandable terms how things relate to each other in the product. There are some posts that try to explain things, but not sufficiently. There is nothing I have found to provide an understanding of how the low level processes work and interact with scenes, devices, etc. They are not simple, but not really explained in depth. They skip over details; assume understanding that does not exist as a new user,  jargon completely not understandable to a simple user. A whole lot of the information is simply directed to people that are a whole bunch more knowledgeable than myself.

The explanations of how scenes, devices, and use work together are just not clear to me. There is a significant vacuum for basic understanding. Forum posts (that may or may not be found) are not the solution.

Users should not be expected to try things to make it work because understandable  documentation is not available. The terminology is somewhere between obscure and not understandable.

I may be ignorant (and frustrated). And perhaps too stupid to deal with things. But I have spent many many hours trying to get relatively simple systems to work. Clearly, others have not been constrained by available documentation. Me, not so much. This can have significant marketing impact. How many potential customers give up after trying a few devices and not "getting it".

Would you please provide documentation in a single file with explanations of "how things work" usable by an ignorant user. This means at the detail level.

Another point about user friendly: I edited my post. The two options after I edited the post are Cancel and Edit topic. Why can this not be finished/post/save. Why, "edit topic"! Not a simple, understandable "finished"? A characteristic of much of the documentation.

 

You may want to take a look at the UDI WIKI   https://wiki.universal-devices.com/index.php?title=Main_Page

The Wiki should help answer most of your questions and includes Instructional Videos

 

[lilyoyo1]

Unfortunately with HA there really isn't an way to detail something that has a multitude of options and variables. What books are available can cover basic use but depending on the user cannot cover all avenues. It's impossible.

It's too easy to get caught up in terminology. What works for one may not work for others. Whether it's talking about automation or editing a post, it's the end result that matters not the words that are used. The best thing is to come up with your own words that you can use to help understand and keep track of how things work.

When it comes down to devices it's very simple from a basic standpoint. Devices turn off, on, and/or dim. All you are doing is telling them what you want them to do.

The device that tells another device what to do is a controller. You can call it a controller, master, primary, boss, CEO, whatever you like to help understand it's roll.

The device that reacts to a controller is called a responder. You can call it a responder, slave, secondary, worker, or any other name. The end result doesn't change its roll.

An example of a controller/responder relationship would be a keypadlinc and a dimmer switch. The keypad would be a controller while the dimmer would be a responder. If you wanted button "B" to turn on your dimmer, you would set "B" as a controller in the scene and the dimmer as a responder. The end result is that the light turns on when the B button is on and turns off when you turn off the B button.

You can build upon this by adding additional devices. Simply add devices to your scene as responders and set the state that you want them to be in when you hit you B button. 

For example, you want your LR can lights to be at 50%, soffit lights to be off, and your LR lamps to be at 75%. You would set button B as the controller, add the additional devices as responders and set the parameters for them in the scene and controller. 

Don't let the system frustrate you. Not everything is for everyone. I tried to show my girl once and she thought it was rocket science. When she tells me about her job, I feel the same way. 

[TrojanHorse]

I’ve heard that rocket science is relatively easy. Rocket engineering is what’s hard. Getting the equations to work the way you want / expect with your materials is where rubber meets the road in car speak.

That said I don’t fully understand exactly how my car works in complete detail. But I can drive it and maintain it. And I know enough to do it well. A good chef may not know thermodynamics but it doesn’t matter if he knows enough to make great food.

I can appreciate the desire to fully understand the underlying details. That said, what knowledge/understanding is missing that prevents you from enjoying your HA? What doesn’t work?

Ask any questions you like. Are you using Insteon, Z-wave, both, etc? You don’t need a full understanding of these protocols to use them. Just need to know enough to avoid / solve problems.

Don’t wait for a “Dummies” guide. Probably ain’t happening. Just ask what you need to know and get going!


Sent from my iPhone using Tapatalk

[Brian H]

If you want some basic information on how Insteon works.

There are some white papers on Insteon.com

https://www.insteon.com/technology#documentation

The UDI Wiki is a great site for information.

[firstone]

On 6/17/2018 at 7:34 PM, Harold said:

...

The explanations of how scenes, devices, and use work together are just not clear to me. There is a significant vacuum for basic understanding. Forum posts (that may or may not be found) are not the solution.

Users should not be expected to try things to make it work because understandable  documentation is not available. The terminology is somewhere between obscure and not understandable.

I may be ignorant (and frustrated). And perhaps too stupid to deal with things. But I have spent many many hours trying to get relatively simple systems to work. Clearly, others have not been constrained by available documentation. Me, not so much. This can have significant marketing impact. How many potential customers give up after trying a few devices and not "getting it".

...

 

Unfortunately, Insteon is not very intuitive protocol. And especially when it comes to linking. You can try to read Insteon documentation and learn a little. 

Could ISY do a better job hiding complexity from users? Maybe. Probably. By all means, if you have any suggestions, make them to admins.

In a short term, if there's something you need specific help with, ask on this forum. I"m sure someone can quickly help you.

 

But, yes, linking sucks. For example, if you have 2 keypads controlling one wall switch, you need:

switch controlling keypad a button x and keypad b button y.

Keypad a button x controlling switch and keypad b button y.

Keypad b button y controlling switch and keypad a button x.

 

There's really no reason why this could not be hidden from end-user. But still, if you take a little time to understand, you can get it all working.

 

Contrast it with some devices that hide everything. If they work - great. If not you're stuck. I bought UE alexa integrated speaker. Something doesn't work with Pandora. I've been trying to get support for several weeks. It week after week of dumb (and poorly worded) canned responses, ranging from re-pair it, re-install app, etc. to "this is not supported functionality". After I've asked them to stop sending FAQs to me and connect me to an engineer, I've had a request to reinstall everything and request to verify firmware version, to verify my country. Still ongoing.

 

 

 

 

[larryllix]

1 hour ago, firstone said:

<snipped>

Contrast it with some devices that hide everything. If they work - great. If not you're stuck. I bought UE alexa integrated speaker. Something doesn't work with Pandora. I've been trying to get support for several weeks. It week after week of dumb (and poorly worded) canned responses, ranging from re-pair it, re-install app, etc. to "this is not supported functionality". After I've asked them to stop sending FAQs to me and connect me to an engineer, I've had a request to reinstall everything and request to verify firmware version, to verify my country. Still ongoing.

 

You have to love those ones. I complained to ecobee tech support that they moved my spec'd  address across the country  and then stopped weather updating as the location was not associated with any weather service between their cloud website and their weather service.

I got back to "disconnect the power from each stat and let them reboot, to recalibrate the temperature sensors."

Google Home was better. I got back "we do not support ISY Portal".

[lilyoyo1]

2 hours ago, firstone said:

 

Unfortunately, Insteon is not very intuitive protocol. And especially when it comes to linking. You can try to read Insteon documentation and learn a little. 

Could ISY do a better job hiding complexity from users? Maybe. Probably. By all means, if you have any suggestions, make them to admins.

In a short term, if there's something you need specific help with, ask on this forum. I"m sure someone can quickly help you.

 

But, yes, linking sucks. For example, if you have 2 keypads controlling one wall switch, you need:

switch controlling keypad a button x and keypad b button y.

Keypad a button x controlling switch and keypad b button y.

Keypad b button y controlling switch and keypad a button x.

 

There's really no reason why this could not be hidden from end-user. But still, if you take a little time to understand, you can get it all working.

 

 

 

 

 

 

I think both insteon and zwave are ready to understand if you take the time to understand how relationships work (controller/responder). If a person wants to know how it works, those details can complicate things tremendously if a person is not technically inclined. 

Using any particular controller is what introduces complexity. However once understanding how your particular software works for the basic things simplifies everything greatly. 

Take linking for example. Your description of linking is more complicated than the actual linking itself. If one understands relationships, they would simply add all devices to the same scene as a controller and be done with it. At that point you can configure light levels, ramp rate, etc should you choose. 

It would be nice if things were easier to link. Unfortunately systems don't know what we want to do so we have to tell it what we want. While that may seem complicated on the surface, the fact is, this allows much greater options than would otherwise be available. In that sense, automation can be as easy or as hard as you make it. 

[Harold]

First -- TrojanHorse. Around 1963 I designed a package for an ionosphere rocket probe. Mine flew. It was better than the professor's package for the task, and the rest of the class. I kind of understand rocket engineering. ? But U-D, not so much.

I am just not getting it. I am not doing it right and I am not understanding what I am doing wrong. I believe I grasp the controller/responder thing. But when I set up a set of linked devices, things appear that do not seem to fit what I was trying to do. If I specify a controller, it fills in responders which is some cases makes no sense to me. There is a key understanding I am not grasping.

I am not trying to "understand" what UD does. I just want to know enough to use it (yeah, I know). Clearly there at least several people out there that have figured it out. I have not even touched the "programs" part. At this point, I just want to control a bunch of plain vanilla lights.

I am just not getting the relationship among controllers/responders and scenes. I saw a post about how to visualize what happens in the interrelationship,  but I am just not getting how to do more than the one example to multiple controllers and responders. I have a number of lights that are controlled by multiple controllers. Example; a controller for kitchen lights that need to be controlled by half a dozen individual control buttons on various devices. I have a set of stairs. Bottom switch is a  simple Insteon switch. Top is button 1 on an 8 key controller. They will not work together.

I keep changing things but ultimately they just do not seem to work like I think they will on a larger scale. I have read large portions of the documentation; to no evident avail. I am not simply being too lazy to read.

I am sorry to be so confused. But I can't seem to help it.

[Techman]

1 hour ago, Harold said:

First -- TrojanHorse. Around 1963 I designed a package for an ionosphere rocket probe. Mine flew. It was better than the professor's package for the task, and the rest of the class. I kind of understand rocket engineering. ? But U-D, not so much.

I am just not getting it. I am not doing it right and I am not understanding what I am doing wrong. I believe I grasp the controller/responder thing. But when I set up a set of linked devices, things appear that do not seem to fit what I was trying to do. If I specify a controller, it fills in responders which is some cases makes no sense to me. There is a key understanding I am not grasping.

I am not trying to "understand" what UD does. I just want to know enough to use it (yeah, I know). Clearly there at least several people out there that have figured it out. I have not even touched the "programs" part. At this point, I just want to control a bunch of plain vanilla lights.

I am just not getting the relationship among controllers/responders and scenes. I saw a post about how to visualize what happens in the interrelationship,  but I am just not getting how to do more than the one example to multiple controllers and responders. I have a number of lights that are controlled by multiple controllers. Example; a controller for kitchen lights that need to be controlled by half a dozen individual control buttons on various devices. I have a set of stairs. Bottom switch is a  simple Insteon switch. Top is button 1 on an 8 key controller. They will not work together.

I keep changing things but ultimately they just do not seem to work like I think they will on a larger scale. I have read large portions of the documentation; to no evident avail. I am not simply being too lazy to read.

I am sorry to be so confused. But I can't seem to help it.

If you install a device as a Controller it becomes both a controller and a responder

If you install a device as a Responder it is only a responder.

A scene can contain both controllers and responders. When you turn a scene on or off it triggers all the devices contained within the scene. The ramp rate and on level for the devices in a scene can be set in the scene.   If you have a switch and a keypad button in a scene and the button is set as a responder then the button will light when the switch is turned on but the button will not be able to turn on the light unless it's a controller.

Can you give a specific example of something you're trying or want to do.

 

[firstone]

If you really want to understand protocol, this is the spec:

 

http://cache.insteon.com/pdf/INSTEON_Developers_Guide_20070816a.pdf

 

ISY hides some of the complexities but it's pretty close to a physical protocol. Not sure if it's going to help you of confuse you even more, unless you invest significant amount of time into it. 

 

Like others (and I) have said, if something doesn't work, ask about specific problem and someone will help you out.

[larryllix]

2 hours ago, Harold said:

First -- TrojanHorse. Around 1963 I designed a package for an ionosphere rocket probe. Mine flew. It was better than the professor's package for the task, and the rest of the class. I kind of understand rocket engineering. ? But U-D, not so much.

I am just not getting it. I am not doing it right and I am not understanding what I am doing wrong. I believe I grasp the controller/responder thing. But when I set up a set of linked devices, things appear that do not seem to fit what I was trying to do. If I specify a controller, it fills in responders which is some cases makes no sense to me. There is a key understanding I am not grasping.

I am not trying to "understand" what UD does. I just want to know enough to use it (yeah, I know). Clearly there at least several people out there that have figured it out. I have not even touched the "programs" part. At this point, I just want to control a bunch of plain vanilla lights.

I am just not getting the relationship among controllers/responders and scenes. I saw a post about how to visualize what happens in the interrelationship,  but I am just not getting how to do more than the one example to multiple controllers and responders. I have a number of lights that are controlled by multiple controllers. Example; a controller for kitchen lights that need to be controlled by half a dozen individual control buttons on various devices. I have a set of stairs. Bottom switch is a  simple Insteon switch. Top is button 1 on an 8 key controller. They will not work together.

I keep changing things but ultimately they just do not seem to work like I think they will on a larger scale. I have read large portions of the documentation; to no evident avail. I am not simply being too lazy to read.

I am sorry to be so confused. But I can't seem to help it.

You have a history of smart logic. ISY logic just may not feel natural to you yet but with some program experimentation the fog will clear like any other style of project.

One of the learning flow problems is people may have started using Insteon links that can bypass the simple logic that ISY programs use. This complicates discussions. Start writing test programs in ISY using a simple SwitchLinc and a lamp on a plug-in placed close to your console. I am suggesting your forget about Scenes just yet, and for now. They will come as a result of extending your simple programs.

Add a few more devices into the Then section and watch them all operate. 
Add in some Wait 5 seconds between lines and see what happens.
Write yourself another program to blink a visible light/lamp and call it from the first program, Use a repeat construct. and no If section.
Now add a few other trigger inputs to your first program and Or them together. test and simulate each input and observe the colours the admin console shows you for debugging.
Change the triggers to AND between them and test again. Why will they never work?

Keep going. ISY is your friend, training ground, playground and sandbox, and you can't hurt it. Ask questions here!  If you test using a critical device you can delete your test program(s) or just disable them when you are done for the day. SAVE!

 

 

[oberkc]

Harold,

Larryllix just briefly mentioned something that is too important to ignore and needs repeating.  Since you have the ISY controller, be certain that you are not linking (creating scenes) devices manually, based upon the instructions that come with each of the insteon devices.  Do ALL the scene creation and linking via the ISY admin panel.  Doing otherwise can create unexpected results.

Keep in mind, also, that other factors can contribute to scenes not working.  It is possible that you have your scene set up correctly, but communication problems may be causing things to act unpredictably.

I agree with the others.  Describe what you are trying to accomplish with scenes, and there is no doubt in my mind you will get more help than you can stand.

[TrojanHorse]

Harold,

 

There may be other issues but can you confirm that after you’ve created the scene, you’re then clicking on the RED italicized scene controllers in the scene and then hitting the button in the middle of the (edit: screen) that says “Copy scene attributes from [your scene]”?

 

 

 

Sent from my iPhone using Tapatalk

 

[Harold]

Various answers. No I have never made manual changes to devices. ISY only.

It has been awhile. I have cleared out pretty much all of the scenes and reorganized some button assignments. I have found a few errors in naming/assigning. I am pretty sure the problem is me.

I am still having a few problems where the  device can not be communicated with. Yeah; rotten grammar. Not sure why it happens. But I motor on.

My quest continues.

[Harold]

Still plugging along. I essentially started over. With just as much success. I am clearly doing something wrong. But I still have not figured out what. I put this stuff together about 10-12 years ago. Much of it has not been exercised.

TrojanHorse: I really have no idea what you said. I can't find any settings to do what you have described.

I have not created any programs. The only thing I have worked with are devices and scenes. I believed that was sufficient - but then, I am not getting anywhere.

I get devices that get the red exclamation mark. Don't know why. Don't know why it goes away as a fiddle around. And sometimes the devices work just fine with the red explanation marks.

Little green men symbols show up a lot. The documentation says this shows an item requires writing updates. But I have no idea what the "updates" are. I have tried repeatedly turning on the "write changes" including remote controls.  I have three remote controls in the system (2440). They used to work. I set them up 10 years ago and haven't touched them until this exercise. One remote is just for a single task and I have not tried to update it. There are two other remotes. I have repeatedly gone through the "write updated to device" many times. One remote works for 2 of 5 functions that used to work, and the other failed to work with anything it used to. I have clearly screwed something up.

As I try things I get the little green things, and they move around. No idea what they want.

It is simply not economically feasible to tear everything out and start over with another system. If there is a better one. Overall, I misunderstood original marketing that said the devices were dual band. After I bought a whole bunch, I found out that that meant; someday, but not the ones you bought. I have a large number of the Insteon devices. Plus a bunch of actual dual band devices.  A lot. I am trying to get the house into a condition that my wife can deal with if I die and sell it without having to strip out all of the Insteon stuff. Aggravation may speed up that scenario.

I really feel stupid. My old brain (nor my mare) ain't what she used to be. It is really annoying. It used to work quite effectively. I do appreciate your willingness to help. Does anyone have pills for this?

I will continue to try to figure out what I don't seem to be absorbing.

FYI - I just posted on the communications problem forum. You can read it, but the essential point is a wall switch on a line with an arc fault protector and does not work like the others on the same set of equipment. I have manual control, and Keypadlink control. But 1 out of 4 essentially the same functions do not work on that one switch when commanded by the Remotelinc.

[oberkc]

Green symbols suggest that the ISY is trying to add a given device to a scene (or take it out of a scene) but cannt, for some reason.  Red exclamation point suggests that the ISY cannot communicate with a given device.  Both are signs that you have some condition causing interference with communication between devices.  Until this is solved, you will continue to have problems.

I have not gone back to review prior advice and response, but focus on this aspect.  Your system will continue to misbehave

- PLM MUST be on a circuit without other electronics (or electronics filtered using filterlinc).

- communication between legs of your electrical system must be established.  This can be done with range extenders, signalinc, dual-band devices, etc...  

There are other factors that can cause the comms problem, but this needs to be your only priority.

[Harold]

That is what I thought the red guys were. The strange things is they come and go. That could be intermittent interference. Right now I am free of red ones. Not my fault as far as I know.

That was also my interpretation for the green ones. It's that "for some reason" that is the stumbling block. The documentation says little helpful. Have you any suggestions of how to identify the green guys actual problem. In devices they generally appear on each item on the device. In scenes they are scattered. I have not deciphered a way with the various displays to figure out what specifically they want.

Would it be a help if I attached some files so you can see what I am doing? If so; which ones.

[oberkc]

No, not your fault. 

No, files will not help.

red exclamaion points and green symbols are likely, in my estimation, the same problem(s).

 Most helpful, to me, would be to address two points made earlier.  To go beyond generalities and get into specifics, describe how you have addressed these two issues:

13 hours ago, oberkc said:

 

- PLM MUST be on a circuit without other electronics (or electronics filtered using filterlinc).

- communication between legs of your electrical system must be established.  This can be done with range extenders, signalinc, dual-band devices, etc...  

 

[Harold]

I have no access to a circuit without electronic devices.

I have added a dual band switch and 2 access points.

Nothing changed.

I am reasonably certain that there are dual band devices on both legs of the power.

I am going to replace the switch that behaves oddly. See what happens. And continue the march.

[oberkc]

Well, then.  The first thing I would do is to filter all electronic devices tha t are on the circuit that includes the PLM.  I, as an example, use a single filter for a bunch of devices, including UPS, computers, modem, router, etc....

The second thing I would do is to refresh your memory from the manual of the access points on how to confirm you have communication between the legs of your electrical system.  It typically involves four quick taps of the set button on one device, followed by an observation of other dual-band devices.

 

[Brian H]

I have my computing equipment on an UPS. The UPS is in the filtered outlet of a Filterlinc and the PLM for the ISY994i is in the front unfiltered outlet. The PLM isolated from the computing equipment can be a good start to getting better communications. If they are hardware version 1. The white LED flash pattern is what you will see. The newer hardware revision 2 will be RED  if communicating and on the same phase. Green if communicating and on the opposite phase. Hardware V2 link below. If you have a revision 1 {white label on the back} I can dig out the information in my archives if you need it.  If it is a hardware revision 2. Give us the information on the white labels and how they respond to the tests. The hardware revision 2 are built on the same basic main board as the 2413S PLM with the same power supply issues as the PLMs. I had to rebuild my Access Points because of power supply issues.

http://cache-m2.smarthome.com/manuals/2443.pdf

Other Dual Band modules will flash their LEDs if they  are communicating and on the same or opposite phase of the incoming power. Some use the four tap sequence to start the Beacon tests from them. Others may use the Flow Chart sequences from in the full users manuals. If you have not had a chance to download the full manuals for your modules. They can be a great help and best to have them all.

You may have to do some tests. Unplug some of the electronics or turn breaker off and see if things improve. Then maybe a few added filters on the offending gear.

 

[Harold]

I don't understand an earlier post -

after you’ve created the scene, you’re then clicking on the RED italicized scene controllers in the scene and then hitting the button in the middle of the (edit: screen) that says “Copy scene attributes from [your scene]”?

Could someone explain what this does. I certainly have not done it. I don't recollect seeing it in the manual. I tried it on one item; did not seem to do anything.

[oberkc]

As I understand, this would duplicate the responder ON levels and RAMP RATES for this controller to match that of the scene level.  Remember, scene responder levels can be different for each-and-every controller to which they respond.  For example, you may want a responder to go to 50% when controlled via the ISY (scene level) but to go to 70% when controlled by a keypad button.

Did you get your comm problems fixed?