Latest PowerHome Insteon Version

[Herdfan]

B would be responsible to replay to A that it got the command, while C, D & E would reply to B. If E did not repsond, it would be up to B to resend. I am mainly referring to the use of a PLC and not regular Switchlincs and KPL's.

I guess my theory on this is that working with the SH Timer software, just creating simple timer scenes seemed a whole lot more trouble than what was needed. For example, I wanted to turn on 2 lights at 6:15am. This involved 5 switches. So I had to link all 5 switches to the PLC although only 2 of these switches actually controlled loads. There is also a KPL that can control them as well. So had to go though and set up 5 individual commands to turn these lights on.

It would have been much easier if I were able to just send 2 commands to the load switches then they could repeat to the status switches. Not really a big deal with 5 switches, but as some of these scenes get bigger and more elaborate, having a PLC send out 20 commands, or for that matter adding 20 switches to a scene would be a PITA.

Having a Controller A send a command to Controller B to execute is no different than pressing Controller B.

 

[upstatemike]

I agree that having lots of keypads and slave switches can really multiply the number of links that must be created for scenes but I think the answer is just to make good tools to simplify that task. I worry that changing the protocol might produce some unforseen problems.

I also think it is important for people to start thinking of Insteon in terms of linked control points rather than in terms of load designations. In your example you are trying to make a distinction between switches that have a load and switches that are just acting as slaves (or subordinate companiaos for the PC among us). There is no such distinction within the protocol so it does not make sense to think of "the switch with the load" being the master and therefor the one you must control. You can't really expect the "master" switch to update its subordinate companions because there is no master-subordinate relationship in Insteon.

If you focus on your network of switches and don't worry so much about which ones have loads and which ones don't then things make a lot more sense. If you have 3 Insteon devices that are cross-linked to work together it really doesn't matter if one device has the load (as is typical with wall switches) or all of them have a load (as is typical with LampLincs) they work together in a predictable way.

If you start treating devices differently based on load v.s. no-load then things would probably get more confusing rather than less because there is no value at the protocol level for Insteon devices to know where the loads are.

I know everyone is used to thinking in terms of controlling a load such as a light but in fact we need to think in terms of controlling switches and groups of switches. If some of those switches happen to have lights connected to them then that is something you can track in a database somewhere. It is not something that the switches themselves need to be aware of.

 

[bpwwer]

While I think I am following the details of this discussion, I'm not sure I understand the benefit. Why would relaying a command be better than duplicating a group?

If A tells B to do something and B then tells C,D and E, then who is responsible for verifying the command was acknowledged? B? If E never responds to B, does B need to report that information back to A?

I think it would be better to keep things simple and just have the "duplicate group" feature.

The one big disadvantage of duplicate groups is just that, you might need many duplicates. If you create a large scene and have to duplicate it on a number of different controllers and then want to make a small change, you have to change it everywhere.

Software can make this easier but it would benefitial for someone who didn't have/want/need software control of their setup to have an easier way to do this.

 

[rocco]

If you start treating devices differently based on load v.s. no-load then things would probably get more confusing rather than less . . .

This is true.

But what the protocol is currently forcing you to do is to control 3 switches, when only one controls the load. If you add another switch for that load, you need to edit and re-duplicate all of the links in those switches and any controllers you have.

I feel what the protocol needs is a way to command the single "Light", not all of the individual "switches", and then allow the switches to track the light, regardless of whether they directly control the load.

I understand that SmartLab's goal was to keep Insteon "Simple", but keeping it simple is sure making things complicated.

 

[rocco]

Additional thought.

Though the best solution I have heard is to have an intelligent/automated way of duplicating the links, at some point the individual switches will run out of space in their link tables. Remember, SmartLabs designed the Insteon chips with a low memory footprint to keep costs down.

Does anyone know how many links an Icon or SwitchLinc can hold?

 

[Herdfan]

It is not something that the switches themselves need to be aware of.

I agree with this point. Again, I am more concerned from the PLC side. Why would a PLC, or its software, send out 20 commands when 5 could do. My point was why the switches don't have the capability to send their programming when appropriately triggered to do so.

In my above example, there is a KPL button that controls all five switches. Why can I not send a command to the KPL to have it "fire" button #3? The KPL knows what button #3 does, all I would be doing is telling it from a location different than my finger on button #3. So when I tell the software I want a certain scene, all I would need to do is tell it to "fire" KPL button #3.

I have 42 devices and I don't even know how many links, but it is in the hundreds. Just thinking of a simpler way to have software control things, that's all.

 

[upstatemike]

I can't think of a downside to that approach off the top of my head. Maybe one of the Insteon reps can offer an opinion?

 

[Herdfan]

Dave,

Have you tried using the software with a KPL button that is not in toggle mode and sends only the ON or OFF commands? If so, does it work just like normal or do I have to do anything special?

I have a KPL in the garage by the door into the house and I want an ENTRY button that always sends and ON commands to certain lights. And I want an EXIT command that sends an ALL OFF command for when we are leaving.

I want to tdo the same in the MBR that will be an ALL ON button so if I am out of town and my wife hears a noise or something, she can turn on all inside and outside lights with one button press.

Thanks.

 

[dhoward]

Herdfan,

No, I havent played with non-toggle mode yet. Ive been pouring over the manual though trying to understand the KeypadLinc and it's capabilities so I can fully support it. From what Ive read though, there is no difference in the database entries between non-toggle and toggle mode. Rest assured though, I will be playing with it shortly.

There is currently an open request on the Insteon Developers board for a memory map of the KeypadLinc. Once this is made available, developers should be able to set the KPL's buttons as toggle or non-toggle through software instead of the manual method we have now.

Keep in mind that the one thing that PowerHome cant currently do (will very soon) is link a KPL button to itself.

Dave.

 

[upstatemike]

Why can I not send a command to the KPL to have it "fire" button #3? The KPL knows what button #3 does, all I would be doing is telling it from a location different than my finger on button #3. So when I tell the software I want a certain scene, all I would need to do is tell it to "fire" KPL button #3.

I don't think the KPL actually does know (or care) what button #3 does. It just knows who is supposed to acknowledge that a Button #3 command was heard.

I wonder if the same thing could be accomplished if instead of getting the KPL to fire Button #3, the software assumed the identity of the KPL and sent a Button #3 command using the KPL's insteon address?

I suppose there would be issues with the acknowledgements (since the software doesn't know who is supposed to respond to this KPL's Button #3 command) but maybe it could be done without requiring a firmware change to the KPL (which I'm pretty sure would be needed to do what you are asking).

 

[Herdfan]

Dave,

Got the toggle mode ON to work great. Wife is very happy. The only issue I have is that I can only link one button on a KPL. For example, I have a PANIC button in our MBR now and it lights up almost every ligh in and out of the house. But there are a couple of KPL that are also load controlling that I can't link for status since they are linked for load. Not a huge deal as I can manually link them if I want.

I will have to do a manual link for my ENTER button since it needs to light 2 buttons on the KPL. Not a big deal.

The OFF mode is a different story. I can't get it to work. I followed the manual and starting putting it into non-toggle mode from the off position. Then the manual starts talking about linking an OFF command. So I'm not sure what to do or how to make PH link it.

I tried a back-door approach to see if it would think it was in the ON state in toggle mode. If I could keep it in the ON state in toggle mode, then a press should send an off command. Well, you can't keep it in the ON state. I tried linking 2 lights to it and it to them. If I turned them on from their location, it was indicated on the KPL button, but if I only turned one OFF, the KPL button went to OFF as well even though one of the lights was still ON.

Oh well. Still very pleased with the software.

 

[dhoward]

Herdfan,

I'll play with my KeypadLinc tomorrow. I know when I read the KeypadLinc manual, it sounded like toggle on wouldnt be to hard but toggle off required sending an "off" command (presumably from another "linked" device or button on the KPL itself) to make the toggle off. It was pretty confusing.

I'll get that multiple button and cross linking to a KPL itself issue resolved here real soon. Might have the patch by this weekend.

Dave.

 

[SmartLabsMike]

Additional thought.

Though the best solution I have heard is to have an intelligent/automated way of duplicating the links, at some point the individual switches will run out of space in their link tables. Remember, SmartLabs designed the Insteon chips with a low memory footprint to keep costs down.

Does anyone know how many links an Icon or SwitchLinc can hold?

Each device can hold 417 links. :lol:

Obviously due to multiple scenes, Keypads and ControLinc will fill up faster than a switch or a lamp dimmer.

 

[Herdfan]

Dave,

I just want to say that the device replacement function is the best thing since sliced bread. I woke up to a dead device this morning and although I knew the software would make things much easier than the old manual linking, I had no idea it would be so easy.

It took less than 3 minutes to add the new device to the list and use the "Replace Device" function. All my old links were repopulating in the new device.

Thanks again.

 

[dhoward]

Herdfan,

That is awesome news! Sorry to hear about the dead device, but glad that PowerHome was able to make its replacement relatively painless.

Ive tested the function but have never had a need to make use of it yet (knock on wood). Glad to hear that it worked out for you when it was necessary.

Appreciate the good news. Look for more PowerHome improvements to come shortly.

Dave.