They should be the same thing, but the Docs site document was copied from the original Community post and lacks some of the screenshots in that post that were intended to be included, so I always link people to the forum instead.
The challenge with RM isn't just programming, it's knowing how Hubitat's app and device model work (and the UI is a bit constrained due to the app model they modeled after that of another platform that only had a mobile app for this purpose). You can write actual Hubitat apps in Groovy, but that's probably even more challenging at this point. Motion Lighting can't easily handle your 1% thing, though, so you might need RM. Mode Lighting might be able to, depending on your needs and if you're using modes (or want to).
As usual with Hubitat, there are lots of ways to do the same thing. Good luck whichever way, and feel free to ask for help if you need it! There are a lot of helpful people in the Community forum.
Bert, I'll take that as a challange! I taught myself Cornell U.'s home-grown language, CUPL, in 1966, Fortran later that year, IBM 1130 Assembly Language in 1970 for my first programming job, then IBM mainframe Assembly Language, IBM 3705 communications controller Assembly Language, PL/1, SNOBOL, LISP, DEC PDP10 Assembly Language, and countless others over the decades until I stopped programming in 2004. I've written hundreds of thousands of lines of code. As I say, I'll take the challenge!
The first computer I saw/used (in India) was a PDP-11. I actually learnt MACRO-11 (circa 1984). Your message brought back memories of my inadequacies (good reason I'm a microbiologist now)
To add to the challenge, Hubitat's developer docs are...lacking. The "easiest" way to learn is to already know how to develop on the classic (not the new/AWS-endpoint) model on SmartThings, then--step 2 and quite easy--learn what the few changes are for Hubitat (namespaces in both apps and drivers, Button capability for DTHs/drivers, etc.). Or, alternatively, learn the classic model on SmartThings, then resume at step 2.
Both apps and drivers on Hubitat and ST are written in Groovy, but both provide a bit on top of Groovy for you and also sandbox you a bit (don't provide access to specific classes, etc.) to prevent you from damaging the system as a whole. ST documents this here, and while Hubitat's implementation details are likely a bit different (and it's proprietary on both platforms so we don't really know), the end result is basically the same.
I have no doubt you can do this, but I again encourage you to get used to the platform first and how the device and app models work for an end user. And going back to the original topic of just automating devices, using built-in apps first will give you a good idea of how that works and what users expect to see in a Hubitat UI. I know developers who skip RM entirely and prefer to just write a custom app instead, which used to be me before Rule 3.0 (RM was a lot more limited back in those days!).
You're missing the "cancelable" (on the delayed action) and "Cancel Delayed Actions" (I'd put it right after your first IF before the time check) things from his rule, but other than that, it looks good to me. Without these, your rule will turn the lights off two minutes after motion is reported as inactive every time motion is reported as inactive, regardless of whether it's become active again in the meantime (i.e., scheduled jobs are not erased unless you tell them to be erased, this being the most common method for a simple delay).
However, I misunderstood the intent of your rule with the way it was originally written. You actually could use motion lighting for this (I thought you wanted them to dim to 1% instead of turning off). You wouldd need to use it in conjunction with mode and set a level per mode (say 100 for day mode and 1 for evening or night mode--you can create as many modes as you want and schedule them to change automatically using Mode Manager or another rule). I'm not sure if you had considered that possibility, so if not, it's just something else to think about!
The ELSE above and ELSE-IF as you've written it are logically equivalent. Either works, but I'd prefer the ELSE myself since it's fewer clicks and also one less place you need to change something if the timeframe changes.
As is often the case with Hubitat, there are multiple ways to do the same thing. (Have I mentioned Motion Lighting yet? )
Folks, I spoke too soon. Yesterday during the day and last night, the delay worked just fine. This morning, though the delay is still in the rule, it is being ignored and the lights go out immediately as the motion sensor reports that motion has ceased.
As for the cancelable switch, I did try it and resolved to go back and try to figure it out, but when I first wrote the new rule, and added the cancelable switch, the delay was ignored and when I removed it, the delay began to work properly. This may be pure coincidence as the delay, as I say, is now being ignored.
I will try rebooting the hub, now, and see if the delay function returns. If so, I'll suspect a bug in RM 4.0, unless some other evidence turns-up.
I just discovered something potentially significant. In the device list, I looked at the bathroom sensor and found that there were several rules but it is still part of listed at the bottom of its entry. There were to test rules and a bunch of other bathroom rules which I had tried and rejected over the past few days. if I look in the apps list, the only rule which has anything to do with the bathroom is my new one. So, I have two more questions. First, is there a known issue regarding rules remaining active after being explicitly deleted? Second, is there something I'm missing about the removal of obsolete rules? thanks again for all of your extremely valuable help. Jeff.
Ok, but these have not been cleaned-up in several days. Since I can still access them, via the links at the bottom of the device description, I'm going to try to remove them explicitly, now, and see if that helps anything.
As I've been once bitten and am twice shy, now, I hesitate to say this, but I believe that adding the "Cancel Delayed Action" clauses did the trick. My working hypothesis is that, when I or someone else was in the bathroom, every time the sensor state changed to inactive, even if it immediately changed to active again, the delays in the turn off clause each started a task, and that the tasks accumulated, turning off the lights when they expired.
I'll report back again if something changes, but I think this finally does it with this rule and my similar but more complex upstairs hall toggle rule. So, what do you kind folks think? Is my hypothesis valid?
Yes, that is what I said above and is how delays and delayed actions in Rule Machine works: nothing cancels them unless you do something to do so. This behavior is also documented in the docs I linked to, though unfortunately some of those are written from a perspective as if you knew Rule 3.0 first.
I would strongly encourage you to see how "regular" apps work in Hubitat first. This is advice I suggest to everyone and is never intended as an assessment of anyone's skill or knowledge. Most people would check if a built-in app can meet their need, then turn to Rule Machine or a custom app if not. Seeing how "regular" apps work (Rule Machine is technically one under the hood but quite different in how it's used, so it's not really a good example...) will also help you write better custom apps if that is a path you choose some day. In any case, it will also get you used to Hubitat's event-driven model (e.g., I strongly suspect your claim that the lights turned off as soon as the sensor went inactive is not accurate if you were to verify the timing of these events but rather a guess based on timing and a result of the un-cancelled delays; playing with regular devices and apps first will help you get used to how to check for these things using live and past logs and event history).
That being said, you could have had this automation up and running in seconds with Simple Lighting or Motion Lighting, but if you live alone and don't have anyone else to keep happy, RM is fun to play around with, too.
Yep, it's just me and six cats, alone in a large Victorian, so no one minds and, indeed, this is fun for me, having been an Assembly Language programmer for decades. Part of my job as Systems Programmer was helping Applications Programmers with their own problems. They mostly coded in COBOL or PL/1, but I could write machine code faster than they could code in their higher level languages, for the most part. Playing with RM 4.0, I've already gotten fast at running through the odd (in my experience) rule editor, which is a nice benefit. I will try the other lighting apps, eventually but, as I say, as long as you folks don't see this as a bother, it's fun.
(good reason I'm a microbiologist now)
)
