Folks, I've successfully migrated most of my devices and rules from Wink to HE over the last few days and have hit something of a roadblock. Multiple users have suggested I add End-Ifs to terminate an If, and I see examples of rules with complex If-Then-Else syntax, but for the life of me I can't find where to create such complex rules. And before anyone jumps on me for not reading the documentation, I read the entire Rule 4.0 document and, in any case, I wrote my first computer program in 1966 and continued programming until after I retired in 2000, most of it in IBM mainframe Assembly Language, and I know well how conditional logic works. I simply must be missing something significant in the rule creation process but, for the life of me, I can't find it. Specifically, I had lots of "robots," what Wink called rules, which turned on groups of lights when a motion sensor became active, with different light levels for different time periods. One example is my bathroom. From 5:57AM to 7:15PM, I want the two Zigbee lamps to come on at 100% level and from 7:16PM to 5:56AM the next morning, I want them to come on at 1% level. Wink doesn't have If-Then-Else, so I accomplished this with two rules, with a third rule to turn off the lights after motion has ceased, with a delay of two minutes. My first step was to duplicate this in HE Rule 4.0 with three analogous rules, but results are sporadic, possibly due to the lack of the End-If that I can't figure out how to insert. I'd like to combine the two turn-on rules into one, with time ranges as secondary conditions but, as I say, I can't find how to add an Else clause.
It's under the actions second of your rule. You select "conditional actions" the ELSE-IF's and END-IF's appear after you've created the first "IF (condition) THEN"
Is that a motion sensor? You could have a rule like that, or it would be better to use the Motion Lighting app over rule machine for motion sensor driven lighting events.
Thanks. Yes, it's a Dome Z-Wave motion sensor. Can you tell me why that would be, aside from the simplicity of set-up? Remember, I'm still trying to learn the system and, as a programmer, I like to see the logic spelled-out.
I thought of that, but it occurred to me that the rule wouldn't know which state the sensor is in. Of course, I could specify "changed" and then query the state in the If-Then-else structure, but the complication is that I want the bathroom lights to stay on for two minutes even if the sensor becomes inactive, and that adds some complication, I think. Jeff
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).
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
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.
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.
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.
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).
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!).
(good reason I'm a microbiologist now)
