kclenden

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.

I don't think the issue is validating more than one set of credentials. It's more likely the necessity of defining a security structure and then building it. First you have to define what levels of access are going to exist, then define which devices and actions fall under which access levels, and then create a structure and methodology to enforce the different levels. Sure, based on what you're asking for, you could probably just create two levels (one with total control and another that lets you do everything but program) but you effectively already have that based on whether you're using the Admin Console or just web access. More likely, even with just two levels of security, you'd want the ability to assign devices and scenes to either the ANY (anyone can control) or ADMIN ONLY (only Admin can control) level. To do that, you'd have to modify the UI, and underlying ISY operating system. You'd have to review every possible usecase and decide how security should handle it (e.g. should an ADMIN ONLY device be allowed to exist in a scene with an ANY device?) And even after doing that, you'd be left with a kludge since Insteon doesn't support different levels of security, so even just having the lowest security level (ANY) would give you a theoretical avenue to controlling ADMIN ONLY devices that you're not supposed to be able to control.

@larryllix You may be right, but your test is not an apples to apples test. Your test uses two variables for which the ISY knows everything because it created them. The OP is using a node that was not created by the ISY and comparing it to precision represented by trailing zeros after the decimal point. I can easily see why the ISY would handle your variables differently than it handles the OP's comparison. A problem with that conclusion is that the OP says that if the node value is first put into a variable, and then the variable is used in the IF the programs run correctly. The ISY seem to be able to understand the node value well enough to put it into a variable, but not understand it well enough to use the node in a direct comparison. One possible explanation for that is that the ISY takes a zero (whose precision it doesn't fully know) and forces it into the precision of the variable it is being assigned to, while doing something different when using the node in a direct IF comparison. I'm sure there are other explanations, but only @Michel Kohanim or @Chris Jahn can tell us.

That might indicate that the ISY is rounding the IF conditions "i.e. 0.400" to the precision shown by the node (i.e. 0). Mathematically, probably the correct thing to do since you can't infer more precision than is present, but not what one might expect based on common sense. What happens if you add an additional check to the IF to make sure the node isn't 0? Like so: AA Weather Test - [ID 004C][Parent 0254] If 'PolyGlot / WeatherPoly_Acuparse / WeatherPoly / Precipitation' Daily Rainfall >= 0.400 Inches And 'PolyGlot / WeatherPoly_Acuparse / WeatherPoly / Precipitation' Daily Rainfall < 0.550 Inches And 'PolyGlot / WeatherPoly_Acuparse / WeatherPoly / Precipitation' Daily Rainfall is not 0 Inches Then - No Actions - (To add one, press 'Action') Else - No Actions - (To add one, press 'Action') @Michel Kohanim can you explain how the ISY deals with precision differences between different components of an IF comparison?

I applaud your diligence in trying to run down unexpected results before submitting a bug report. I see two problems with this approach though: Let's say you factory reset and reload everything and now the programs work. What has that done? It's left you with a working system that you can't trust because you don't know what caused the original problem or when the problem might come back. Additionally you've removed any evidence that UDI might have been able to collect to determine the root of the problem. Your time is worth something. If you've narrowed down the problem to something that you can repeatedly duplicate then why not notify UDI to see if they can duplicate it on their system? Either they do, in which case you'd have been wasting your own time resetting and reloading everything, or they don't in, which case they might want to look at your system while it's still in a state that you can repeatedly demonstrate the problem. I'm not saying your way is wrong, but I'm saying it's right either. ?

But his original programs didn't use a variable in their IF statements. They made comparisons directly to 'DarkSky / Forecast 0' Rain Today Inches. So there could be no unknown interactions causing a program to run TRUE when it should have run FALSE. In an earlier post, he indicated that he checked the "Last Run Time" of the programs after his tests which would tell him if one of them might possibly have affected the test variable. And finally, all of his programs set the variable equal to 'DarkSky / Forecast 0' Rain Today Inches. So even if they had run inadvertently, he would still be seeing the value his wanted to see. Your suggestions for more testing would certainly arrive at a more definitive conclusion, but I don't think they are necessary for before he submits a bug report to UDI.

Then I would classify the problem as a bug in the ISY coding. Perhaps the 'DarkSky / Forecast 0' Rain Today Inches value is a different precision and IF comparisons simply round the program constant to match the node precision. Or maybe this is only a problem when 'DarkSky / Forecast 0' Rain Today Inches is equal to 0 in which case maybe it's not really a 0 but a NULL value and the ISY doesn't handle that in its IF routines but does handle it during variable assignments. Whatever the underlying cause, it appears the ISY handles it correctly for variable assignments, but not for IF comparison.

Did it run false for values of 0.500 and greater? It seems like there is some funkiness going on with how the ISY handles comparisons between a node value and a program constant. What happens if you change your process and first set a variable to equal 'DarkSky / Forecast 0' Rain Today Inches and then use that variable in your program's IF statement?

Nothing has changed. This was in their confidentiality request:

Not sure if you're still working this issue, but everything you've posted suggested that there is a communication problem between the ISY/PLM and the Balance Dimmer light. When you send a single device On/Off, I believe the PLM uses Insteon retries if it doesn't get an acknowledgement from the device. I know for certain that when you send scene On/Off, the PLM does not attempt any retries. And definitely device to device (e.g. switch to Balance Dimmer) communication uses retries. You should open the Event Viewer and set the level to 3 and then try having your program control the light, both as a single device and then as within a scene). That should give you some idea about what kind of communication is going on between the PLM and the Balance Dimmer.

In the "Family models declaration letter".

I don't think the IGs were listening. It's described as a 4-button KPL.

Do your home and cottage ISY's using a different path to the internet? Any chance that sending through comcast, gmail and att are using TLS and you haven't checked the TLS option on the ISY?

That seems like logical thinking. What ports are you using for SMTP. Most ISP's block some email ports. Here's an example: https://www.xfinity.com/support/articles/list-of-blocked-ports

Yep, that's what I suggested. ?

Well duh! Seems pretty obvious now that you say it. ? So I could get rid of four repeats: Bathroom Light Auto Off 2 - [ID 00B6][Parent 0001][Not Enabled] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Repeat 60 times Wait 1 second Set 'Inside / Hallway / Hallway Bathroom Light' Beep Repeat 1 times Set 'Inside / Hallway / Hallway Bathroom Light' Fast Off Set 'Inside / Hallway / Hallway Bathroom Light' Fast On Set 'Inside / Hallway / Hallway Bathroom Light' Fast Off Set 'Inside / Hallway / Hallway Bathroom Light' Fast On Wait 3 minutes Repeat 60 times Wait 1 second Set 'Inside / Hallway / Hallway Bathroom Light'' Beep Repeat 1 times Set 'Inside / Hallway / Hallway Bathroom Light' Off Else - No Actions - (To add one, press 'Action') Although doing it this way prevents you from canceling in between light blinks, but they happen pretty quickly so not really an issue.

They are the only way I could find to get out of the previous "Repeat", but they do have the added benefit of being a time slice surrender.

After evaluating all the feedback, if you still want to implement your two programs, here is what they would look like with my suggested changes, and a couple more: Bathroom Light Auto Off 1 - [ID 00B7][Parent 0001] If 'Inside / Hallway / Hallway Bathroom Light' is switched On Or 'Inside / Hallway / Hallway Bathroom Light'' is not switched Off Then Stop program 'Bathroom Light Auto Off 2' Set 'Inside / Hallway / Hallway Bathroom Light' On Wait 30 minutes Run Program 'Bathroom Light Auto Off 2' (Then Path) Else Stop program 'Bathroom Light Auto Off 2' Set 'Inside / Hallway / Hallway Bathroom Light' Off Bathroom Light Auto Off 2 - [ID 00B6][Parent 0001] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Repeat 60 times Wait 1 second Set 'Inside / Hallway / Hallway Bathroom Light' Beep Repeat 1 times Set 'Inside / Hallway / Hallway Bathroom Light' Fast Off Repeat 1 times Set 'Inside / Hallway / Hallway Bathroom Light' Fast On Repeat 1 times Set 'Inside / Hallway / Hallway Bathroom Light' Fast Off Repeat 1 times Set 'Inside / Hallway / Hallway Bathroom Light' Fast On Repeat 1 times Wait 3 minutes Repeat 60 times Wait 1 second Set 'Inside / Hallway / Hallway Bathroom Light' Beep Repeat 1 times Set 'Inside / Hallway / Hallway Bathroom Light' Off Else - No Actions - (To add one, press 'Action') I did find another bug in your original Program #2 - you didn't have a WAIT 1 SECOND during the second round of 60 beeps. I also used FAST OFF and FAST ON for the light blinking to avoid any local ramp rates that might be associated with the bathroom light. Finally, I avoided using a double tap because my guests have enough trouble with my paddle switches let alone learning to double tap. Also, I understand the need for all the "Repeat 1 times" after programming this myself. ?

The way the OP has written the program, I don't think simply pressing the ON again would cancel the waits in Program #2. It would restart Program #1, but it wouldn't stop Program #2. Certainly not before the 60 seconds of beeping ended because pressing ON will make the status of the light ON which is what the second program evaluates in its IF and going from ON to ON doesn't retrigger a program that is looking at STATUS.