Motion Lighting is a much smaller app with a designated purpose. So it is less resource hungry, and will run faster. In general, the recommendation has been to use specific apps (if available).
2 Likes
So far, I have had no resource shortages and response time has been superlative, but I will Pause my rule and try it later, today. I'll report back with results. Thanks, Jeff
1 Like
Guys, is it a Wink high bleeding somewhere ? Looks like Titanic to me
Hubitat Team : 
I would change your rule to.......
IF
Motion active
AND
Time between x and y.
THEN
If you use 'changed' then if the sensor changes to active the light will turn on.
When motion changes to inactive the else section is true and the light turns off.
You might like to put delays in there too.
1 Like
Thanks. I wasn't certain that would work, but I will try it. Jeff
It doesn't add much complication--a rule that uses a "changed" trigger and an IF/ELSE in the body to act differently according to the sensor state is a quite common paradigm for a Rule 4.0 rule. You can see many examples in the documentation: [Released] Rule 4.0. I'd highly recommend reading this before you go too far. There's an example with motion lighting that is almost exactly like what you want (except you appear to want to just dim the light to 1% instead of turning it off, unless you didn't mean to do that).
I'd second the advice to try Motion Lighting if you haven't already given it a chance--maybe let the event-driven nature of Hubitat and the various commands and attributes exposed by its device model sink in a bit before diving into the deep end creating rules? Then you'll be more familiar with how they work and able to write rules more easily. The built-in apps are numerous and powerful, and I'd consider Rule Machine (itself a built-in app) a powerful tool available to help you create custom logic that is not possible using one of them.
2 Likes
Bert, thanks. I read the entire Rule 4.0 document on the documents site, but I didn't see the document you linked to. And, yes, I do mean to set the brightness to 1%. One of my six cats likes to go into the sink and drink from the faucet, which I leave on a low-volume drip, and he will actually come wake me if the bathroom is dark. But if I let the lights come on at full brightness, the light wakes me. As for diving in, after all of those decades as a Systems Programmer, I'm pretty good at diving in. I just found the organization of the rule creation process a bit opaque, and the main Rule 4.0 document doesn't spell-out the process as the document you just sent me the link for does. In any case, I do understand why it's set-up this way. With Wink, or any of the other HA services of which I'm aware, rules creation is done in the cloud using powerful central systems, but HE must rely upon a tiny system with an html front-end, which limits the level of assistance the system can provide. I think I have the process down, now, finally realizing that it's a line-by-line process to build the rule. But, as I said, I will try Motion Lighting, at least for the bathroom. My upstairs hall rule(s) are a good deal more complex, involving two sensors and RGBW lamps, but I have a good start and I doubt that I'll have much more trouble. Complicating all of this for me was a wind storm we had on Halloween which dropped a tree across the 13,500 V. primaries of two transformers. The resulting surge blew-out $3,000 worth of appliances of a neighbor closer to the transformers but, in my case, it caused a ten or fifteen second voltage drop before the power failed completely. When my whole-house generator kicked-in, every Zigbee lamp in my house was either reset or damaged, and it has taken a long time for the Zigbee mesh to be re-established, with lots of resulting anomalies. For example, one of the two Z-Wave sensors for the upstairs hall lights stopped triggering events, even though it's powered by a 123 lithium cell. I can only assume that the Z-Wave mesh was also affected. In any case, I excluded and removed the device, added it again, fixed the rules, and it worked for about one day. Now, I can see it changing state via the Devices app, but the triggers don't work. Since the HE hub also lost power (though I expect that its 5 V. DC wasn't affected), so I'm considering saving the configuration, resetting the hub and loading back the configuration. Anyhow, that's off topic. Thanks again for the help.
Jeff
1 Like
I have my bathroom motion lighting turned off in "sleep mode.
Instead, I have these GFCIs in my bathrooms. Built in nightlight with a photocell. Just enough light to keep the kitties happy (and me when I stumble into the bathroom at 5:00 AM).
2 Likes
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.
1 Like
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!
Regards,
Jeff
3 Likes
Jeff -
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)
Ashok
1 Like
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!).
Good luck!
2 Likes
Bobbles,
How's this, do you think? It works perfectly, though I haven't tested the night effect, yet.
Thanks,
Jeff
1 Like
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!
It should be more like this so that actions are cancelled if motion continues and you can distinguish better between the 2 time windows.
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? 
)
1 Like
Bert,
You have, indeed, but I'm not going to consider that until I learn all of the quirks of RM 4.0, and there appear to be quirks a-plenty!
Jeff
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.
Thanks again for all the help,
Jeff
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.
They can remain listed under the device but as they are deleted they do not do anything.
Did you rewrite your rule?
Maybe post it for people to have a look at.
3 Likes
