lhranch

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?