Well no, you can open an app and turn on logging, and then go back to the Apps List. That won't do it. Hitting Done is the key step. This is true for most apps.
1 Like
So this rule started working again after doing that. Do you have an idea what might be cause them to stop working in the first place?
Not a clue, Stuff happens with computers and software. Some of it, when repeatable, is worth investing energy to understand and root out. Some of it is not, or there is such scant evidence to go on that it's impossible.
I've had automations that run every day, and have for years, including my front landscape lights turning on at sunset and off at sunrise -- never misses. I have others that sometimes mysteriously have a hiccup.
Did you ever enter 3:00 AM into that rule? Looks like you did. I bet if you changed the time selection from sunrise to at a certain time 3:00 AM would be there. Somebody put it in, and then changed to sunrise.
With v2.2.3.148 I have an issue with negative offsets for RM.
Have a rule working fine for some time that fires at sunset.
After adding an offset of -10 minutes it additionally fired 10 minutes before sunrise.
This happened three times until I removed the offset.
Can you confirm this behavior?
You need to show a screenshot of the rule, and of its App Status sections for Event Subscriptions and Scheduled Jobs. Logs would also be helpful.
Thanks. Just added the offset again.
As far as I know, it will be scheduled at midnight, right?
So, here's the current state after adding the offset, will report back with some logs tomorrow:
Did you hit Done after changing it?
Also, I would suggest you just use a simple Certain Time tigger, instead of the Periodic for every day.
Thanks.
Yep, I hit "Update Rule" and also "Done" after changing the settings.
Hm, turning the lights on during winter at 6 pm makes sense somehow, but not in the summertime?
As I said, I will report back tomorrow.
1 Like
What does that have to do with days of the week?
Ah, now I see what you mean, I changed the trigger like that:
But what's so different between what I did?
2 Likes
For some reason it worked this time, too bad logging was disabled when the error occured.
Thanks @bravenel.
This thing is not stable. I have a brand new rule that I wrote a couple of week ago and it abruptly stopped (partially) working a few days ago. Also logging stopped working.
Here is the rule - the rule is supposed to turn on two devices when a door opens - it now just turns on one device (Stairway LED Strip) but is no longer toggling on the 'Dining Room Credenza Lights'. Additionally, as you can see the logging is enabled but it stopped logging on 9/29.
Rule events
I have a stand alone rule for 'Dining Room Credenza Lights', that turns it on during the night time, and that continues to work and there are no issues to control Credendza lights with Zwave switch as well, so I know that all is good with the lights itself.
Not sure if it's related to this bug, or Sunrise/Sunset in general.
This morning I noticed both my Rule Machine 4.0 Sunrise trigger and my simple automation rules sunrise 'lights off' didn't execute. After some searching in the forums, and finding issues with DST, I checked the hub time (properly set to U.S. Eastern time) and my hub location. The hub location was properly set, but the sunrise time showed 8:41 AM (7:26 was the correct sunrise). I was checking the status between 7:26 and 8:00. After adjusting and moving the location (I set a zip code, which moved it to the center of the zip code, then moved it back over my address), the sunrise time updated to the correct sunrise of 7:26AM.
A simple click on the update button prior to moving the location did not adjust the sunrise time (I tried that first). I noticed the zip code was missing, I added that in which moved the location to the center of the zip code. I manually moved it back over my house, then took a snapshot which I intended to post to document the problem. That's when I noticed the sunrise had been updated to the correct time.
It would appear the sunrise/sunset triggers may not be a fault within the rule machine or simple automation rules, but maybe in how Hubitat updates these values within the core system itself. No idea how these are linked or related, if the sunrise / sunset times are calculated within the individual apps based on time zone/location, or if they come from outside the apps.
Interestingly, the settings in the Rule Machine app lists the last event time as 07:41, 11 Oct, an hour earlier than the location sunrise time which originally showed up in the HE settings location page. This would appear to be a DST adjustment, except the wrong direction unless the settings documented standard time and the HE location sunrise is adjusted for DST. 7:41 was closer to the actual value which was creating more confusion. It is also possible this was set when I manually ran the action, which I did one time while checking the status this morning.
Here are the app settings. The purpose of the app is to set a global boolean variable 'day' to TRUE at sunrise, then if MODE is not set to away, set the mode to day. I use it with two other similar rule machine apps to set Evening (30 minutes before sunset) and Night (30 minutes after sunset).
Aside - I find working with RM powerful but challenging. You have to set the conditions, then use them as a part of a conditional IF / THEN, but you can also set new conditions within the conditional. Initially I thought conditions were set as a part of the task, and could be used in lieu of triggers, etc. Worked my way through those details. Now the RM interface with each task, editing condition expressions and tasks can get confusing quick. Not sure if that resulted in what appears to be a lot of excess in the settings below for what I thought was a rather simple rule.
Day Built In App
Settings
Name Type Value
| actSubTypeMain.2 | enum | Set Mode |
| actSubTypeMain.3 | enum | Set Variable |
| actSubTypeMain.4 | enum | Set Variable |
| actSubTypeMain.5 | enum | Set Variable |
| actTypeMain.2 | enum | Set Mode, Variables or File, Run Custom Action |
| actTypeMain.3 | enum | Set Mode, Variables or File, Run Custom Action |
| actTypeMain.4 | enum | Set Mode, Variables or File, Run Custom Action |
| actTypeMain.5 | enum | Set Mode, Variables or File, Run Custom Action |
| atOrBetween1 | bool | true |
| ending1 | enum | Sunset |
| logging | enum | ["Events","Triggers","Actions"] |
| modeMain.1 | enum | 1 |
| modeMain.2 | enum | 1 |
| modes2 | enum | ["4"] |
| myVarsMain.3 | enum | Day |
| myVarsMain.4 | enum | Night |
| myVarsMain.5 | enum | Evening |
| not1 | bool | false |
| not2 | bool | true |
| origLabel | text | Day |
| rCapab1 | enum | Time of day |
| rCapab2 | enum | Mode |
| starting1 | enum | Sunrise |
| tCapab1 | enum | Certain Time |
| time1 | enum | Sunrise |
| valBoolMain.3Day | enum | true |
| valBoolMain.4Night | enum | false |
| valBoolMain.5Evening | enum | false |
Event Subscriptions
Source Event Handler Filter
| Pooler Hub (Location) | sunrise | sunrisesetHandler | false |
Application State
Name Value
| actionCancel | false |
| actionDone | true |
| actionListMain | [4, 3, 5, 2] |
| actionsMain | {2={wait=null, delay=, modes={}, method=getSetMode, indent=, rule=0, label=IF ( NOT Mode is Away TRUE) Mode: Day , cond=2}, 3={wait=null, delay=, modes={}, method=getSetVariable, indent=, rule=0, label=Set Day to true , cond=0}, 4={wait=null, delay=, modes={}, method=getSetVariable, indent=, rule=0, label=Set Night to false , cond=0}, 5={wait=null, delay=, modes={}, method=getSetVariable, indent=, rule=0, label=Set Evening to false , cond=0}} |
| actLabelIndent | |
| actNdx | 6 |
| allVars | {Evening={val=false, type=Boolean}, Night={val=false, type=Boolean}, Day={val=true, type=Boolean}} |
| allVarsO | [Day, Evening, Night] |
| capabActDone | false |
| capabDone | true |
| capabsfalse | {2.false=cond, 1.false=Time between Sunrise and Sunset, 3.false={}} |
| capabstrue | {1.true=When time is Sunrise, 2.true={}} |
| certainTimes | [] |
| condOper | cond |
| connectors | {} |
| cutAction | [] |
| editCondIf | |
| eval | {1=[]} |
| firstR | {1=true} |
| gvList | [Day, Evening, Night] |
| hasAll | false |
| hasCompleteRule | false |
| hasCondition | false |
| hasDevice | |
| hasElse | false |
| hasRuleAct | false |
| hasWaitEvent | false |
| howMany | 3 |
| howManyT | 4 |
| inIf | false |
| inRepeat | false |
| installed | true |
| installedCapabs | [EnergyMeter, Polling, PowerMeter, PushableButton, GarageDoorControl, ReleasableButton, HoldableButton, Notification, Outlet, Lock, DoorControl, Battery, SwitchLevel, Switch, PresenceSensor, Configuration, ChangeLevel, Actuator, Sensor, Refresh, LockCodes, ContactSensor, DoubleTapableButton, VoltageMeasurement] |
| lastEvtDate | 11-Oct-2020 |
| lastEvtTime | 07:41 AM |
| lastEvtValue | 0 |
| locationBlocked | [] |
| lvList | [] |
| --- | --- |
| ndx.false | 3 |
| ndx.true | 2 |
| nestedBlockMain | [] |
| nestedIfMain | [] |
| nestedInIf | [] |
| nestedLabel | [] |
| nestedRepIf | [] |
| nestedSkipAllMain | [] |
| oldConst | |
| oldConst2 | |
| paramNdx | 1 |
| paramsDone | false |
| parens | {1=0} |
| prevState | {PB=true} |
| private | true |
| refreshActions | false |
| repeating | [] |
| ruleNdx | 1 |
| selectActionsParams | {thisStr=Main, label=Day} |
| simpleCond | false |
| skippingMain | false |
| subscribedVariables | [] |
| timeFormat | hh:mm a |
| timeTriggers | [] |
| timeTriggersW | {} |
| token | 0 |
| trigCustoms | [] |
| usesTime | false |
| varUseList | {} |
| waitB | {} |
| waitBL | {} |
| waitBV | {} |
| waitCondNdx | 1 |
| waitConds | [] |
| waitEvents | [] |
Welcome to the community!
That's what makes RM powerful. I have learnt that to make life easier (and to troubleshoot) to make multiple small simple rules than to create a big complex one. More often than not, you can still achieve your intended goal(s) with having separate rules.
The problems continue and rules that used to work just fine, just abruptly stop working. I have examples of those but first something related with Mode - Once again, my mode didn't change correctly . Based on my location and device settings, sunset today was 6:51pm
Per my mode settings, I should currently (7:50pm EST) should be in 'Bedtime' mode but I am stuck in 'evening'
I also don't see this going to 'MorningPrep' either based on these event logs.
@gopher.ny is this related with Time jumps as well? Just wait for 2.2.4 to come out?
Realistically, yes. At this point, 2,2,3 is locked, 2.2.4 development is well underway, and the update includes both safeguards for large time jumps as well as significant built in app revisions. Once 2.2.4 beta has gone through a few iterations, I can temporarily add you to the beta testers list, and we can run the entire setup and revisit each issue if/when it occurs.
Edit: I checked the logs and see a recent hub restart that happened while not connected to internet, which in turn has set the time back by a few hours. Yes, that will mess with time based events, and that's exactly what time jump safeguards should take care of. While these safeguards make simplistic assumptions about how long the hub can stay down, they at least provide a contiguous timeline, which is an improvement over current situation.
Ok, Yes, please add me there. A question though - if this is software issue, impacting time based events, shouldn't it affect a lot more users than just few of us.
In my case, I don't think I ever rebooted my hub w/o internet up & running.
Here is a non-time based event in rule machine that also randomly stopped working. Logging was turned on, but the logs don't go back far enough today to see what went wrong. Screen Shot 2020-10-14 at 7.32.46 PM|600x500
So it seems now that I am having random rules just stop working. I have to go in and "Update Rule" to get them to start working again. This is worse when I reboot the hub. Seems I have to go through and "Touch" they rules to make sure they will start working again.
