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
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.