Here i am again asking for some direction. I am really disappointed in the logging in HE compared to HCA. In HCA, every time a device was issued a command, the log show the command and the response from the device.
I have the above rule and everything works EXCEPT for the Turn off at sunrise- I even added the 15 second delay and the additional off command and nothing..
Does HE really not check of a command was performed?
Does a second rule work? That rule in general should work. You extend logging by turning on debug logging for the device and logging for the rule itself. Otherwise basic logging is all that is needed to show that a light has come on or off. If you had every single thing logging that would be a colossal waste of resources.
In general, whether a "command" (by which I mean the underling Zigbee or Z-Wave messages the hub would send in response to a hub command like on() or setLevel()) was successful or not is handled by the protocol, i.e., at a lower level. Hubitat will not continue to check the state and retry, though you could certainly build an app or rule to do so. If you have a solid mesh network (Zigbee and/or Z-Wave, depending on the device), this shouldn't be necessary and could be indicative of a problem.
But we don't know that your problem is a device or network problem. It could be something with the app. Your logs are not helpful for determining this because you are looking at "info"/descriptionText logs from the device, which generally only show the states it reports from the hub (i.e., in response to a successful command from the hub, physical change, etc.). What you really want to know in order to start troubleshooting is whether the command was sent. Some devices will show this if you enable debug logging, but debug logging generally disables itself after 30 minutes, so with how widely spaced your rule actions are, this isn't likely to help you (and not all drivers do this, though most newer ones do).
What would be really helpful is to enable all logging for your rule, then look at logs for that app. In part, this will show you what rule actions it's running when. If you don't see one to turn off at sunset-20 (currently around 6:22 AM your time, it appears), then that could be an problem with the rule. That seems less likely to me because your rule looks fine, and splitting it up shouldn't really matter (it's all going to be a scheduled job, and reboots, etc. don't affect that--unless the hub is down at the time when it's supposed to happen, which would be an issue either way). But it would still be good to know where to start troubleshooting.
Hope this helps you get started.
break it up into separate rules.. there is no good reason to have it that complex and if the rule aborts or the hub reboots between sunset and sunrise etc. the rule will stop and the 2nd event will not fire.
i belive it would be more robust to have a rule for sunset and another for sunrise.
also recommend you make a separate 3rd rule for time is 11L30 pm..
I dont know why people ensist on trying to put everything in one rule.
Because it's personal preference. I'd rather have a single rule over multiple so that if I need to make a change (like adding/removing/swapping a device) I only have one place to make it and test. Your preference may be the way you described. Neither are a "wrong" way of accomplishing the same goal.
I do the same thing. I have 2 rules for sunset (indoors and outdoors) and another two for Dusk (both indoors and outdoors). I even have a basic rule that just turns on the coffee pot at a specific time, then another that turns it off later in the day. Personally I find it easier to view and modify limited rules when I need to.
What is HCA?
This is not the case (at least for reboots; not sure what "aborting" a rule means), though it's an occasionally-repeated misconception. What happens in either case is:
Home Control Assistant. That said You can turn on detailed logging for anything.
So it seems there are various concepts with how to implement.
now time to digest all this.
You just have to remember that every system is different and adjust mind set for it. As the old saying goes, "There is more than one way to skin a cat"
Well my initial thought was "compactness" One rule per process. But last night NO segment of the rule ran EXCEPT turning the lights on @ sunset. The porch light is still on, (should have turned off at 11:30) are still all on the driveway lights did not dim 50% - VERY frustrating.
So now I will break the rules install smaller segments and see what happens...
What did logs for the app (rule) say? One rule or two, that's going to be the best way to figure what's happening, as above.
are they zigbee or zwave switches. sounds like you may have some mesh issues.
I agree, since the rule appears to be properly written, and splitting it into two rules won't help if there's a device or mesh/network issue. But app logs are the only way to know what the app actually thinks it's doing (that's why I've hinted twice that turning them on and checking them--the app logs--is a good idea 
). If it's performing the action, you can eliminate the rule "not running" as the source of the problem, as outlined in: How to Troubleshoot Apps or Devices - Hubitat Documentation.
My zwave mesh is solid but not always 100%. For my key automations, rather than action, delay, redo action I now, after performing an action, check that the state is as expected and if not I redo the action (and send a notification that something didn't go as expected). The check/redo will loop a couple of times.
Not if he has mesh issues.
I'm with kahn on this one... The programmer in me cringes to see things mashed together, adding complexity with no benefit. For the code that Vincent posted, there are comparisons run that are completely unnecessary, since we know from the trigger that they will never be pass. I much prefer the KISS approach...
I'm not saying that it's wrong, per se, but it's confusing to me why one would want to check if time is sunset or time is 11:30 when, by the trigger itself, we know that neither of these conditions are true.
ya back in the days of hardcore programming a few extra comparisons in highly used code as in a compiler etc.. depending on how many calls can really show a system down..
Also when i see a Wait command i immediately think of a busy wait even though in hubitat it is not that and is scheduled.. For that reason i prefer simple if's if possible..
I also am just not sure what happens to a wait in the middle of a rule, i belive if the rule is reentered for any reason all pending waits are cancelled.. The multiple rules with a simple condition and if just seem more intuitive to me.. Also multiple rules vs a single one have been state to not slow down the system.
Download the Hubitat app
