lhranch

You're right -- the old one was a 2476D, which I replaced with a 2477D. The dual band stuff wasn't quite available when I started installing modules. That could explain why it didn't do well out in back of the pool, but it's not doing well on the bench next to me, either. In trying to take the advice to "Open the AC and set the error logging to level 3. Activate the offending switch via the AC and watch the level 3 logs for errors," I've tried the menus, the manual, and the wiki, and can't find anything about how to set an error log level to anything. The only thing I can apparently do with an error log from the AC is dump it to a spreadsheet file, which doesn't seem conducive to watching errors go by in real time. I can't even find anyplace that tells me the version of the AC I'm running, though I updated it sometime in the past couple of months. (My ISY itself is running 4.7.5). Is there some other tool I don't know about, or a URL that explains stuff I can do with the error log?

I recently replaced a wonky Insteon 2486D with a newer model 2334. The Admin Console shows me an "LED Brightness" button for the old unit, but not the new unit. After noting that this feature was not present in the website description of the new unit, I was under the impression that the new unit didn't offer it, but I was referred to the full user manual that explains how to set the backlight manually, and indeed that works. Is there some reason this feature is not available through the AC as it is for the older units, or is it somewhere else?

I spoke too soon. Now I'm seeing (on the old switch in the testbed) exactly the same connectivity issues reported earlier. I start up the ISY Launcher, and half the time the first thing it tells me is "Warning: Cannot communicate with Old Pool Sw (MAC). Please check connections." Yet, all the controls in the device window work (On, Off, Fast, the rheostats) so clearly the hub can communicate, although every so often it gives me the same complaint again, but then next time it will work. The associated switches and iPhone app all work, maybe not the first time, but no more problematically than other devices in the household. What's the best way to figure out what is going on?

Is there any way to find out from a hub whether a remote Insteon device (simple switch) is reachable by powerline, by radio, or both? I just replaced a Decora-style dimmer switch in an awkward outdoor location. The new switch seems to be working better, and I have the old switch on a testbed in my shop where it, too, appears to be working (but of course it is now on the indoor grid and much closer to other radio-band devices). The old switch suffered from bizarre connectivity issues reported earlier, and the reset procedure didn't fix it (in fact, it took it entirely offline, though both the reset switch operation and the location were so physically awkward that I cannot be 100% sure I performed it completely). I am curious to determine if the failure mode was that one of the switch's comm interfaces went bad and the other path was just naturally spotty, so I can figure out whether the old unit is worth saving for an application where only the remaining path is required.

No. It's clear some people are not understanding what the valid point of confusion is here. I've worked on OS system date, time and time-zone APIs over the past 50 years... and two major questions the coder always has needs to have specified is, "when is a time expression evaluated, and what is it evaluated relative to?" This is especially important when you choose whether to express and store time values as either strings (to be evaluated later) or binary clock values (evaluated at the present time and place), and when to perform the conversion. For example, I use a personal financial package that routinely screws up regularly scheduled deposits and withdrawals when I am traveling with my laptop. It stores scheduled transactions dates as binary times, evaluated at the time and place of the schedule's creation. So instead of logging a scheduled transaction on the 13th of each month (it chooses midnight), when I am traveling, it often logs it on the 12th late evening because I am in a different time zone, and then all the accounts fail to balance. I've fixed this type of problem in various OSes. So these are details I am sensitive to that most people might overlook. It's easy to look at a program that turns on at 7 PM and turns off at 5 AM the next day, and predict (assume) what it will do, if the only triggers are passing through those clock times. But if you knew that a trigger could occur at 3 AM that would invoke this code, it's hard to determine for sure whether the condition would evaluate true or false unless the manual tells you (or you stay up late and test it). At 3 AM on any given day, is the time between 7 PM (relative to what day?) and 5 AM on the "next" day (again, relative to what day)? Now that I know that there is an implicit "of any day" in the expression, it makes things clear. So perhaps I "overthink" such problems, but it's from hard experience of the downsides of failing to think them through beforehand.

Thanks. Maybe I did that long ago.

I have a few different models of keypads in my system, including the 2486D and the 2487S; also a 2440 large gray remote. My 2486D has been acting increasingly wonky over the past few weeks, and stopped working totally today, so I replaced it. I had a 2334-222 in stock which was dual-band and in the right color, so I used it. I added it to the ISY, did the right-click "replace" trick to move the old programming over to the new unit, and it works pretty well. What struck me was that every other multi-switch device (including my old, broken one) has always appeared in the admin console as a folder-like object, with the (usually direct-wired) main button at the top, and the rest of the buttons indented under it. But the new device shows as a bunch of peer switches. I restarted the admin console a couple times and it looks like they are going to stay that way. Is there any significance to this? Note in the image Barn, Garage, and Portable, in the old format, and Nook, in the new format.

Yeah, I understand all that. My point is: If you read the rule as saying "8 PM on any day to sunrise the next day," the operation is clear. If you read the rule as saying "8 PM today to sunrise the next day," it is absolutely unclear. The actual wording of the rule is totally ambiguous as far as what it means, and the manual doesn't discuss the issue.

Now see, here's a nugget of information I didn't have: the hub always queries all devices at least once every 24 hours. So it looks like I really don't need to run a timed loop to check my circuit breaker (once a day is plenty fine for me).

It is a remote light switch, as I mentioned in the post to which you responded. In particular, a Decora dimmer switch.

I'm happy to think of it that way, now that I have an assurance that this is in fact how the hub thinks of it. ?

I check it programmatically a couple times a day. The breaker doesn't typically trip except during storm activity (it is a GFI that feeds a remote gazebo). I installed a remote light switch out there so I can walk to it safely at night if I need to. The actual issue I'm defending against is having a long, undetected power outage to an irrigation controller that is also on that circuit, which would result in damage to a bearing orchard. I lost one tree due to the irrigation being out, and I don't want to lose more. It's not like I'm sending it ten signals a minute. I was only interested in knowing whether I had to poll the device for the hub to realize that it wasn't responding, or whether stuff the hub did during the course of a day would notice that the device wasn't responding and trigger the mail program.

The whole point of the program is to see if a circuit breaker has tripped, which would certainly be a source of bad comms and missed events.

It becomes ambiguous the minute "the next day" becomes "today." That's really the crux of my problem statement.

Well, yes and no. In my case, there is another program that does a few things, and as the last thing, runs this program to reset the lighting to its "resting state" for the time of day. Now, that other program can be triggered at any time (it's linked to a motion sensor). Again, if motion is detected between 10 PM and midnight, I would expect everything to run fine. The question is, if motion is detected at, say, 1 AM, and this program gets run as a consequence, is it going to choose the ELSE because "well, it's not after 10PM today"? @larrylix, above, says it will run THEN; @lilyoyo1 says it will run ELSE. I think to be safe I may just bust up the boolean into "between 10 PM and midnight OR between midnight and sunrise" and just avoid the ambiguity of "next day."

If I write a program that begins: If the current time is between 10 PM and sunrise the next day... I expect it to work properly between 10 PM and midnight of the current day; but is it going to work if invoked after midnight of the current day?

This shouldn't be a hard one... Say I write a simple program, the semantics of which are: If I can't get a status reply from device A, send me a piece of mail saying that the circuit breaker has popped again. (The actual program would need a state variable to send the mail only once, etc., but just assume this simple example.) Do I have to set up another program to schedule that program every half hour or whatever, or does the hub somehow (in the course of whatever it does all day) notice that it isn't hearing from that device, and run that program itself?