Vyrolan

If you have a lot of noisy devices and/or signal suckers, the powerline communication can be rendered completely unreliable. The devices don't even have to be in the same room...some device somewhere else in your house could be pumping out lots of noise and disrupting Insteon powerline communications. As for the RF, even without metal boxes, they can be extremely situational as to how they are mounted, what's near by, what else is in the wall, etc. I, for one, have metal boxes yet still have very good RF communication between my dual band devices (as shown by the 4-tap test), but other people struggle when the devices have direct line of sight across short distances. Such is the nature of RF in my opinion... RF is very finicky and there's not much you can do about the problems. Powerline can be finicky, but there is a very clear course of action with the filters that can give you nearly perfect reliability. How big is the room in question? How far is it "across the room"? What else is in the room as far as furniture, appliances, lights, etc, etc? When you say "can't communicate" or "can't communicate with a switch in the same double gang box as another switch", do you mean you have the two switches linked and the responder doesn't change when you hit the controller? Does it never work or just sometimes work or what? All you say is "can't communicate" and we have no idea what you're actually trying to accomplish... You ask "what could possibly be wrong with my setup" but don't tell us anything about how you actually have it setup... If you had spent as much time describing your situation and the problems you're seeing as you did slinging insults at Smarthome, we could probably be more helpful. Countless others have little to no problems with the devices.

It is purely cosmetic for the sake of keeping those devices visually linked together since they are the same physical device. Without grouping, you could move different buttons from a Keypad into different folders and name them such that you don't even remember they're all the same Keypad.

They blink if responders don't ack so you know there is an issue. How long are you supposed to wait? What if the messages gets to the destination on the first hop, but the ack fails and needs multiple hops? Also, the later hops aren't sent by the originator of the message...they are sent by all who received the first hop. How are all of those supposed to know not to send if the first hop was received by the destination? They would all need to receive the acknowledgement to know to stop...and that's asking a lot for reliability. Also, they would need the ability to queue up these "to be sent as later hops" while waiting for acknowledgements. Further, how does a device know when a transmission is complete then? If 1 hop is sent, then all who receive it queue it up (they won't send hop 2 until they know there's not an ack in your scenario), then is that just dead time? Can another device send a different message in the middle? Now you're interleaving the messages....everything that hears the second device's message is queuing up two messages that may or may not be sent based on whether or not acknowledgements are received. If they can't interleave, then you're just injecting waiting for nothing...actually slowing things down instead of speeding things up. For the worst case when two devices need all the hops to communicate each way, waiting just 1 unit of time for acknowledgements would add 300ms total. Another example is a Triggerlinc communicating with a powerline-only switch. On the first hop which is RF only from the Triggerlinc, there is no way it was received because the destination is not dual band...so by waiting for the acknowledgement you're just slowing things down. Ditto for any two source/destination that rely on other dual band devices to bridge phases. To be honest I think you are drastically underestimating the complexity. It would add a ton of complexity to the devices to be able to preempt the send with an acknowledge, and even in good scenarios it would save very minimal time. That's also assuming you only wait 1 unit of time for the acknowledgement which would be wrought with problems without adding a ton of complexity. A big part of the reliability of Insteon is the simulcasted repeats where the signals add to each other...leading to the "more devices you have the better it works" situation. With complexity of trying to preempt that process, it would probably be the exact opposite where more devices yields less reliability. The "fire and forget" of X10 was always considered a problem because you never knew for sure what was happening. In general, it's always better to know if your message was received than to just assume it, so I imagine some of that is future proofing for devices that may do more advanced communications. I'd certainly want the ISY to receive acknowledgements so it can retry or it can at least let me know it failed to communicate. (I actually wish the ISY did more around them.) The acks can also contain data...the acks may not be that useful for "On" and "Off, but they sure are for "Query". Well hops and retries are separate. Retries I can kind of agree with as being a bit excessive for anything beyond linking, but we deal with intermittent communications issues on these forums all the time, so I wouldn't say the chance is that slim. Who knows who actually said that... Variations are attributed to many people including Albert Einstein.

Not really...that's one of the weaknesses of the ISY. Your computer does not have to be on for the ISY to work...you only use the computer to program the ISY via the Admin Console...once you save changes and close the admin console, the computer is totally unnecessary. Not really...the programming of the ISY is very custom and not very reusable. Among other problems, there's no good way to export or import programs, so it's hard to really have a library of pre-written programs. It's again one of the weaknesses.

Yes. You want acknowledgements for linking. If you are using set buttons to setup scenes, you for sure want acknowledgements so they can let you know if a communication was missed lest you end up with some really messed up scenarios. The powerline is not full duplex...it's only half. There cannot be two messages at the same time since they all share the carrier. Think of it like the radios where when you are pressing the button to send, the other guy can't talk back. You might hold the button and say, "The mission is a go...I repeat, the mission is a go." Now someone hearing the other end can't push their button in the middle and say "ok, we got you the first time". They have to wait until you are done transmitting (including your repeat) before they can speak back. That's exactly why radio communications end with "Over". That's essentially the way of saying "I am done transmitting; you may transmit now." For Insteon devices, the "Over" is implied to be after the last hop. So the receiving device gets the message with 2 hops left, he must (and will) wait out those 2 hops so he knows "the other guy has stopped transmitting".

Actually it just waits. Imagine you had a bunch of people in a room and you were doing Insteon-like repeating. Somebody shouts, and everyone who hears that shouts a repeat...you're trying to get the message across the room. The protocol may be to repeat 3 times... The original shout is "Message 2"...1 second later, everyone who heard it shouts "Message 1"...finally 1 second later, everyone who hears those shouts "Message 0" and it's complete. If the target person heard the original shout (he heard the original "Message 3"), he will have to just stand there and wait 2 more seconds while all of the repeating of the shout is going on. Then once everyone is done and quiet, only then would he acknowledge that he heard it. Insteon is dual-band so two kinds of communication...to extend the metaphor, imagine the shouting is powerline, and a bunch of people (but not all) have signs and so they can hold up a written message as well...the signs are the RF. People with signs that hear a shout (or see a sign) both repeat it by shouting and by displaying it on their sign. Either way though, the "target" must wait for all the repeating to end (silent room with no signs displaying) before it can send its acknowledgement. Of course, this all happens super duper fast in the Insteon world. You're looking at a quarter of a second or so for all of that to happen. =p

This is very intriguing, but I see no "attached script". (Also the link for sox is wrong...pointing to espeak's page.)

Reviving an old thread here...sorry... So I too am interested in the concept of the sofa sensor (or bed sensor). I was looking around and found these: http://recoraco.thomasnet.com/item/bed- ... /item-1147 They seem like a solid little sensor, and they also sell them as double sensors in series (which is what you'd want so one under each cushion to detect two seats with 1 sensor). That one is their "bed" sensor but they also sell "chair" sensors that are square mats. I found the one in the link above online for a decent price, and according to the schematic drawing (here) linked on that page, it's a great fit for an IOLinc. It says >10K ohms open and <100 ohms closed so I think it would easily trigger an IOLinc's sensor. I guess if you had a sectional, you could use several of them and use an EZIO to have easy occupancy checking of the whole thing! Bonus points for activating different lighting scenes or audio settings based on which seats are occupied. =p I may buy one of the above to try out with an IOLinc as a crib sensor...they claim the activation wait is ~3 pounds, so a baby on the mattress should be sufficient?

Only if you put something in both "then" and "else" clauses. For clarity, I was referring to the actions taken by the Motion Sensor (one switched On and later one switched Off) not the program(s) that respond. I definitely think as you have been pointing out that it's generally multiple programs in all practical uses since you want to override the Off if a switch is manually changed...or whatever other conditions/behaviors/etc you'd like.

Very true. No, the built-in timer is reset with each subsequent motion. The Off is not sent until no motion for the duration of the configured timeout. The only difference between the two is that Sensing Mode sends out a continuous stream of On commands as motion is sensed rather a single On when motion is first sensed. It seems like all programs just do something when it's switched On (the first On when motion is first sensed) and then something when it switches Off (no motion for duration of timeout). I don't see the value of the continuous stream of On commands...like I realized in the last post, maybe they are useful if you have it in On-only mode.

Or...just have the Motion Sensor turn them On with a scene but use programs to control turning them off...a bit tricky but doable. I wish the motion sensor had the separate on/off nodes like the triggerlinc does. What you described is exactly the behavior of sensing mode unchecked. Both modes do what you say. With sensing mode checked, it continuously sends more On commands as it continues to see motion...eventually sending a single Off when no motion has been seen for the timeout. Without sensing mode, it sends a single On when motion is first detected and a single Off when no motion has been seen for the timeout. So what you "like" is just the normal function of the Motion Sensor...not sensing mode. As I said, I've yet to see a use case where the continuously sent over and over On commands are of any use...in situations like you describe, they are completely unnecessary and only serve two purposes: causing more insteon traffic, and draining the motion sensor battery from sending them. So I stand by "silly" for sensing mode. Actually, I guess sensing mode could be one convenient way to handle the scene on, programmatic off thing. Set it to On only and sensing mode. It will never send off, so have a program reset the timer each time the On is sent. You'd get instant On from scene and programmatic Off simpler than other workarounds.

Don't use the "Sensing Mode" option for the motion sensors IMHO. IF you hit the switch to take it to 100%, you are still in the motion sensor's range so it should not be sending any more "On" commands to set it back to 50% until you have left the room, the motion has timed out, and new motion is detected. With the silly "sensing mode" option checked, then it spams On commands constantly and you get the weird behavior you describe. I've not had any situation with sensing mode that worked like one would want. Also, having the motion sensor directly activate the scene for the lights has the very big advantage of turning the lights on much faster than an ISY program. If you use a program, the signals makes it to the PLM then the ISY which runs a program which tells the PLM to send a signal which finally turns on the lights....it can be a noticeable delay over 1s.

As a small aside, you have in your conditions On,On,On,On,On,Off....I think you mean On,On,On,Off,Off,Off... You should also check for Fast On and Fast Off.....and potentially also check for Brighten and Dim for dimmers....to fully check for all local control. Essentially you want to check On, Off, Fast Off and Fast On for every switch to see if anybody changed anything.

If he does have an old device that requires a power cycle to change the level, then he won't be able to change it twice a day with his program. He'd have to replace the switch with a newer one that better handles the adjustments on the fly.

That is not possible. Sending emails is far easier than receiving them. There would also be a noticeable delay...using email like that would take several seconds to go through before the light came on.