kclenden

Or, perhaps, you fail to understand. Older Insteon devices do not manage things on their own. The dynamic management of hops was a later addition. Even then, my understanding is that doesn't happen between the PLM and devices (feel free to correct me on that). On that we agree. And I'll say it one more time and leave it at that - a clean system won't require retries or multiple hops.

Do I have a "kick me" sign on my back today.

There is a maximum of three hops allowed. If lessening hops was going to lead to such instability, then Insteon would have allowed one more bit for MAX HOPS and increased the max to 8. Lessening retries will hardly ever improve anything. A device only uses a retry if it doesn't get an acknowledgement. If it consistently doesn't get an acknowledgement then it isn't working. If it isn't working, you'll notice it and fix it. If you don't notice it, then its use of retries apparently isn't causing you to notice a degradation in your home automation. I've read the white papers many times. Typically I refer to them before making responses about how Insteon works. Thanks for not boring me with the details here. Your response both says that Insteon devices are smart and that the Insteon designers aren't. If those designers were smart, why would they include the ability change configuration parameters for devices that you say are smart enough to know when to send more or less? They included the ability because sometimes it helps, either for reliability or speed.

In my opinion, it's actually opposite. If MAX HOPS is set to 3 then all devices must wait for the time it would take for the message to be repeated three times before they can respond, whether they heard the message the first time or not. They must wait so that they don't try replying while another device is possibly repeating the original message which would cause message collisions on the power line. On the other hand, RETRIES are variable. If a device sends a message and immediately receives a reply, the communication is done. It's only if the original message is not acknowledged that the original device will resend the message*. So on a clean powerline devices that use a retry value of 3 will use way less bandwidth on the powerline than devices that use a max hop value of 3. * - Most Insteon devices that use RETRIES will default MAX HOPS to 1 when they originally send their message. If they don't receive an acknowledgement then when they retry sending their message they will increase MAX HOPS by one (up to a max of 3).

I'm pretty sure it has worked this way for as long as I've had my ISY, which admittedly is not as long as you have had yours. I'm not sure this scenario is why we have the difference between "Status" vs "Control". "Control" has always been described to me to mean local control of the device. Which is to say, if a switch is turned on by the ISY, or a linked device, the ISY does not see that as "Control" even though it often would be helpful if it did.

Any change in the sensor temperature will cause the IF to be reevaluated and the THEN possibly run again. That's just the nature of the IF THEN ELSE. Consider if you had a motion sensor and you wanted to keep a light on if it detected motion. In that case you would want the THEN to rerun starting the timer over again. In your case, you can accomplish what you want with two programs and a state variable that we'll call $sFridgeHot. Program MonitorHighFridgeTemp If $sFridgeHot is 1 Then Wait 5 minutes Send Notification to 'Alarm' content 'High Temp' Program CheckFridgeTemp If 'Fridge Multilevel Sensor' Temperature > 40.0°F And 'Fridge Multilevel Sensor' Temperature <= 100.0°F Then $sFridgeHot = 1 Else $sFridgeHot = 0 In this case the change in the sensor temperature from 40.2 to 40.6 would cause the state variable to be set to 1 again which is not a change, so the IF in the other program would not be triggered and the WAIT wouldn't be interrupted.

I was originally thinking that wouldn't be a problem because the ISY doesn't send an ON or OFF command if it already thinks a device is ON or OFF respectively. But this would be sending a scene command which I believe the ISY would always send. So I'd probably go back to your original programs and add a test of the button's state to the IF and add a second set of programs that would look to see if the button should be turned OFF. For example: If $sLED1.timer >= 90 AND KPL.G is OFFThen set ledG.scene OnElse If $sLED1.timer < 90 AND KPL.G is ONThen set ledG.scene OffElse

A couple high level points about the start that @larryllix is suggesting: You cannot control individual LED's on a keypad, but they can be added to scenes and then you can control the scene. So Larry is suggesting that you create eight scenes (ledA.scene - ledH.scene) where the only member is the corresponding keypad button. You need a variable to hold the number of minutes left on your timer. Since you're going to want to react to this timer (e.g. turn light off when it reaches 0, etc) you need to make it a STATE variable not an INTEGER variable. That is why Larry prefixed the variable name with a small "s" (e.g. $sLED1.timer instead of $iLED1.timer). When you duplicate the programs for the buttons on the right sided of the keypad, you'll need a second timer variable (e.g. $sLED2.timer). The first four programs Larry provided take care of illuminating appropriate keypad button lights according to how much time is on the timer. They don't, however, take care of turning the keypad button light off as the timer decrements, so I would change all four by adding a command to the ELSE section. For example: If $sLED1.timer >= 90Then set ledG.scene OnElse set ledG.scene Off This will do a couple things. As your timer counts down, when it goes to 89, 59, 29, 0 it will turn off the appropriate keypad button light. It will also keep the lights in sync. Let's say there's 57 minutes left on the timer (so both buttons A and C should be off) and someone presses button C. You don't have any programs looking for a keypress of button C so the ISY won't do anything, but the actual button hardware will illuminate button C which would put the lights out of sync with your timer. Luckily, when the timer drops to 56 the appropriate program will run and turn OFF keypad button C.

Here's a link to the wiki email substitution page: https://wiki.universal-devices.com/index.php?title=ISY-994i_Series:EMail_and_Networking_Substitution_Variables Have you tried typing http://<your isy address>/rest/nodes/ into a browser to see what properties are assigned to water sensor nodes?

I'm assuming you'd have the MS II setup to send ON and OFF commands. Then after receiving an ON, you'd change the link between the MS II and Lamp to "ignore" so that when an OFF finally comes, the Lamp won't see it, but the ISY will. There are at least a couple issues with this. One issue is the scene update bug in V5 whereby the ISY tries to write to the controller when only the responder link needs to be updated. While the MS II will be awake after sending an ON, you might not be able to update its link with the Lamp before it goes back to sleep because of other Insteon traffic on the power line. If it goes back to sleep, the ISY won't be able to write to it (even though is really doesn't need to). Some people workaround this by disabling writes to battery devices. Another way would be to power the MS II by USB instead of battery. Another issue is one of complexity and murphy's law. A power failure after you've interrupted the link between the MS and Light would leave things in a bad state. So you'd probably need to use a variable that is saved to the ISY permanent memory to track when the link has been interrupted and then have a cleanup routine that runs on power-up if the variable indicates it's needed. With enough MS II's in the system, you end up with a mess of cleanup variables and programs. Additionally we don't really know what the MS II will do if it's in the middle of tracking motion and it receives a Link Table update from the ISY. Will it continue to run its internal timer so that it eventually sends an OFF? Will it just kill its internal timer and never send an OFF? Will it kill its internal timer and immediately send an OFF? Still, it's probably worth it to give it a try.

It depends on how much control you want over the scene. If you are willing to give the MS II complete control so that it is responsible for turning the scene ON and OFF, then you can rely on the MS II timer to determine when the scene is turned OFF. Many people want more control than that. If that's the case, then you could probably use two MS II sensors. With two MS II sensors, you could make a direct link between one of the MS II sensors and the devices you want turned ON. Set that MS II to send only ON commands. Then use the second MS II sensor, which is not directly linked to the devices being controlled and should be set to send both ON and OFF commands, to determine when there has been no motion for the specified time. This would allow you to have the speed of the first MS II turning ON the scene, but program control over when it is turned OFF. Sort of an expensive way to accomplish the goal, but if nothing else does what you want...

Sure, but then he wouldn't be able to use his ISY to track how many hours the pump runs and then wouldn't be able to estimate how much water he's using. Without that data, his anxiety level would surely spike and his health might fail. Best to keep using the IOLinc. ?

I was just about to suggest a latch. As I see them, the requirement looks like: Float Position Lower Limit Sensor Upper Limit Sensor Refill Valve Both Up OFF OFF Turn Off Lower Up, Upper Down OFF ON Ignore Lower Down, Upper Up ON OFF Not Possible Both Down ON ON Turn On So if you use the Lower Limit sensor as the SET signal for the latch and invert the Upper Limit sensor signal and use it as the RESET for the latch, the output of the latch could then be used to control the IOLinc.

How are your MS powered? If any of them are battery powered (i.e. not USB powered) then v5 actually introduces a problem. It seems that in V5, when you adjust the setting of a responder in the scene, the system writes to both the responder and the controller, even though there shouldn't be anything to write to the controller. If the controller is battery operated then it's probably asleep when the system tries to adjust the scene, and the write is queued. People have reported their ISY becoming slow and/or unresponsive after enough writes to their MS have been queued, though UD says that the system only saves the last write in a queue. The workaround for this problem is to disable writes to battery operated devices, but this can only be done if you have the Pro version. And even if you can disable writes to battery operated devices, you'll eventually have to turn writes back on when you actually want to update a battery operated device's settings, and people report that the queued writes from earlier can then cause problems. Here is a link to a discussion if you're interested:

The it seems the obvious answer is to use Celsius in the summer and Fahrenheit in the winter. ?

My experience with Luminance has been good, but I'm probably using it differently than you. I have my MSII setup to only signal motion at night. That has worked perfectly for me. In the MSII options you can set the Luminance Level that represents Night. To figure out what level should represent Night, when I first install a MSII in a location, I have a program that queries Luminance every time motion is detected. If the MSII signals motion and I don't think it's dark enough to be Night, I adjust the MSII Night Level option. Once I have the Night Level set where it only signals Night when I think it's night, I quit querying the MSII for Luminance. So in my experience, the MSII internal use of Luminance Level seems to be very reliable, even if the Luminance Level it reports when queried by the ISY isn't reliable. But I'm just one data point.

It seems reasonable to come to that conclusion, but doesn't SSL require a certificate to accomplish encryption? Perhaps that comes with the Portal.

No guesses as to why it's inconsistent, but a couple questions. First you're using a GET (as opposed to a PUT). Does reading the page really change the occupancy mode? While the ISY will allow you to execute a GET, it doesn't do anything with the response. Second you're using port 443 which implies SSL encryption. I don't know if ISY network resources support SSL. Perhaps other will pipe in on that.

I don't think so because the OP said he wanted the light to stay on until he opened the door again to come in. After trying it and having the light go out before he actually walks through the door he might want to change it, but based on what he said I don't think it's a typo.

Looks better but still doesn't look good. By my count the "Hops Left=" worked out to 0 times hops left = 3 14 times hops left = 2 8 times hops left = 1 9 times hops left = 0 If there was direct communication between the device and the PLM you should see Hops Left = 3. That didn't happen a single time. But that's not unusual if a power only device is dependent on a RF device to complete the path to the PLM. What's concerning is the high number of Hops Left = 0 because what comes after that is Failed Communication. It's also concerning that 55% of the "Hops Left" were less than 2 because that means that even if your device is relying on an RF device to complete the path there is something else that is requiring yet another device to push the response along. So either you have a noisy power line, or a device with a weak transmitter. Given the devices you've listed in the shop, if none of them are behind a filter, it's reasonable to conclude that a noisy powerline is the issue, but that doesn't account for the problems the device had in the old location, though it sounds like the old location could have its own issues.

Should that be 'If "to" time is before "from" time'?

Doesn't the day start at 12:00 AM?

Without any other conditions in your IF, that program will only run twice: At 10PM - it will run the THEN Sunrise the next day - it will run the ELSE If you add other conditions (that are triggers) then "between 10PM and Sunrise the next day" becomes a filter that determines whether the IF evaluates TRUE or FALSE and consequently whether the THEN or ELSE is executed.

I agree with this, but would add that if a KPL button did send a "control switched on" message at power-up, you should see that in the ISY log. If the ISY acted on what it thought was a KPL button press, it should have logged it, so if you don't see it in the log, you can probably eliminate that as a likely culprit.

Insteon devices do not support separate user access levels. Neither, AFAIK, does Z-Wave. So at best UD would be building security into their device that can not be replicated at the device level. That would merely provide the illusion of security not much better than @metal450 can currently obtain by not showing his guests the Admin Console but merely showing them the web portal. If his network is setup properly, someone having the admin credentials to his ISY couldn't use them unless they had credentials for his WiFi or physical access to his ethernet network. If they have that access, then he clearly trusts them more than a random stranger. Surely he can trust them not to download a rogue copy of the Admin Console to start programming his ISY. If this goes beyond the ability to program, and it's individual device and scene control that he wants to be able to grant, then that would take a lot of effort on UD's part AND would only provide the illusion of security. It might provide a little bit of protection against someone accidentally turning something ON or OFF that shouldn't be turned on or off, but he can pretty much already do that by putting devices into separate folders based upon the access level he wants to grant. Additionally, I doubt even a plurality of forum members, let alone less technical ISY users, would rank separate user access levels very high on their wish list. UD only controls the firmware to the ISY. They don't control the Insteon, Z-wave or Zigbee device firmware. Building security into the ISY level, but not the underlying Insteon, Z-wave or Zigbee firmware only gives the illusion of security which at best might reduce accidental device control. As mentioned above, there are already ways you can do that via folders and device naming.