Trying to move RM 3 over to RM 4. I have a motion light to turn on with a motion. After it is on and no motion the delay will turn it off. It will cancel off if motion trips before light times out.
It is not working right. The light turns on, then turns itself off after 30 seconds. Then back on again with motion.You can see it throws a java error. My first rule writing is probably to blame but I don't know what I did wrong.
app:24492019-08-25 04:08:46.603 pm infoAction: ELSE-IF (OFC Light(off) is on(F) AND Mode in Evening, Night(T) AND Zone 085 - OFC Occupancy inactive(F) [FALSE]) THEN (skipping)
app:24492019-08-25 04:08:46.517 pm infoAction: Dimmers per mode: OFC Light Evening : 40 Night : 22
app:24492019-08-25 04:08:46.511 pm infoAction: IF (Zone 085 - OFC Occupancy active(T) AND Mode in Evening, Night(T) [TRUE]) THEN
The easy answer is "Use Motion Lighting instead," which has this feature built-in. Before digging into Rule 4.0, I'd recommend taking a look at the documentation, which has an example nearly identical to the one provided to you above, including showing how to use the new "cancel" feature correctly in this situation.
But to keep it in RM, you have a couple options depending on how you actually want to do this:
Check if any/all (depending on what you want) of the lights are on first; if so, don't turn them on in the rule (and also not off if that is also something you want)--this looks about like what you did in 3.0 and could be handled with an extra condition in your IF in 4.0
If you want the rule to not change level after you press some "on" button until you press some "off" button, create another rule (Button Device trigger would give you a Button Controller-type UI and may work well here) to set Private Boolean true on this rule when that on button is pressed and false when the off button is pressed, then don't have this rule turn on (or off if that's also what you want) these lights as long as that boolean is true (you could probably add it as another trigger here too with little extra damage, but I don't see the point of trying cram everything into one rule)
something more creative you can probably think of on your own but I can't since you know better how you actually use these lights and switches
I just used what he has up there as well...i just finished it about an hour ago and seems to work even after manually flipping the switch it triggered back into the rule. In smart things (havent done it in HE yet) i made virtual switches.
V auto home
V media
V lights
V alarm
V motion
what i did for example, in every light action rule i tied it to a V lights and V motion. if my liv room and kitchen (lights both controlled by motion) i didnt want the rule to run at all I would turn of the V motion switch. by leaving the v lights switch on tho all my other lights would still trigger by rules. this came in handy when i would have a party and everyone would go outside so i would turn of the v motion switch so the lights in the kit/liv rm wouldnt trigger the motion rule but the other lights would. i also made it to auto turn on the V switches after 2 hours .
the v alarm switch was good for when guests were visiting overnite. with the v switch off my alarm wouldnt actiavte on presence and such. in a nutshell these v switches zone your rules so you can operate them manually if needed. maybe this wil help when you want to manually turn a switch on by hand and can bypass that rule.
PS. the v auto home was very handy when i had major issues with my 100 rules or so as i put this as the main switch for every piston (webcore). i would simply turn V auto home off and all my rules (pistons) would not run which let me start one by one up at a time to see if they were working correctly.
this also may be helpful even tho its not for lights is same idea and using else-if. after 30m if liv motion is inactive and the tv is on i have alexa say that as listed. if the motion becomes active it cancels and reset the timer. also alexa wont trigger until 30 minutes has passed of motion inactive.
I tried to understand the docs, but I]m not really getting it.
I tried Simple lighting before and found it to be unstable. Sometimes working and then somwtimes not. So I prefer to just use RM for everything.
That being said, I only want to add the function of using the wall switch (push button) as well. With the Fibaro dimmer, a quick double push of the switch will turn on the dimmer to 100%. But if I do that now, and then I trip the motion again, the RM rule fires and dims the light to it's setting.
I would like to be able to go to the button, double press it, and my room stays at 100% until RM sees no motion in the room and does it's thing which is to turn off the light. That's about it.
In that case, a conditional that checks for the lights being on (and skips setting the level on them if they are) should work, assuming you really just care about whether the lights were already on and not whether this button in particular caused that state. You wouldn't need to change anything for the "off" actions. You'll need the basic format that @vjv has for his rule (also basically what's in the docs), except you want "Set Level" like you had instead of "On" (basically, what you're missing is the "Cancel Delayed Actions," which makes the "(cancel)" thing actually do something). You also don't need "OFC Light turns on" as a trigger--all you need to do is check whether it's already on in your actions, which you'd also need to add. Putting that all together, I think something like this would work:
IF (Zone 085 - OFC Occupancy active AND mode in Evening, Night) THEN
Cancel Delayed Actions
IF (OFC Light Off) THEN
Dimmers per mode: OFC Light
Evening: 40
Night: 22
END-IF
ELSE-IF (OFC Lights is on AND OFC Light is on AND Mode in Evening, Night) THEN
Delay 0:08:00 (cancel)
Off: OFC Light
END-IF
Note that this won't turn off your lights if they got turned on by this automation in evening or night mode and then the mode changes to something else, even if your time expires. There are workarounds I could think of (like setting the rule's private boolean to True if this rule turned the lights on and checking for that [instead of mode] before turning them off and setting it back to false). If you care about the button in particular and not just the lights already being on, I could see the boolean getting used for that instead. You could also use custom (local or global, depending on where you want to be able to access them) variables for the latter, all depending on how exactly you want to implement the exact behavior you want.
Ha, because I made a mistake. I was thinking about exactly how I wanted to do that and if I needed that in there and changed my mind enough times that this was the result. (Honestly, you don't really need either one of them at all--turning off a light that is already off is generally harmless--but it might save you a bit of network traffic. If you have an older Z-Wave switch that doesn't report physical status changes, you actually might want to take it out. And while we're at it, you could take out all of those conditions and make it a plain ELSE if you just wanted the lights to turn off any time they were on even if it wasn't turned on by this automation or in the "right" modes.)
Logs show this looping a hundred times. Here is a section......
app:24522019-08-31 06:57:26.469 am infoAction: Dimmers per mode: DIN Light
Evening: 99
Night: 30 (skipped)
app:24522019-08-31 06:57:26.463 am infoAction: IF (DIN Light(on) is off(F) [FALSE]) THEN (skipping)
app:24522019-08-31 06:57:26.425 am infoAction: Cancel Delayed Actions
app:24522019-08-31 06:57:26.423 am infoAction: IF (Zone 009 - Dining PIR active(T) AND
Mode in Evening, Night(T) [TRUE]) THEN
app:24522019-08-31 06:57:26.369 am infoLight Dining Triggered
app:24522019-08-31 06:57:26.355 am infoLight Dining: Zone 009 - Dining PIR motion active
app:24522019-08-31 06:57:16.724 am infoAction: Delay 0:02:00 (cancel)
app:24522019-08-31 06:57:16.721 am infoAction: ELSE-IF (DIN Light(on) is on(T) [TRUE]) THEN
app:24522019-08-31 06:57:16.702 am infoAction: END-IF (skipped)
app:24522019-08-31 06:57:16.700 am infoAction: Dimmers per mode: DIN Light
Evening: 99
Night: 30 (skipped)
app:24522019-08-31 06:57:16.695 am infoAction: IF (DIN Light(on) is off(F) [FALSE]) THEN (skipped)
app:24522019-08-31 06:57:16.675 am infoAction: Cancel Delayed Actions (skipped)
app:24522019-08-31 06:57:16.672 am infoAction: IF (Zone 009 - Dining PIR active(F) AND
Mode in Evening, Night(T) [FALSE]) THEN (skipping)
app:24522019-08-31 06:57:16.620 am infoLight Dining Triggered
app:24522019-08-31 06:57:16.607 am infoLight Dining: Zone 009 - Dining PIR motion inactive
app:24522019-08-31 06:57:08.276 am infoAction: END-IF
app:24522019-08-31 06:57:08.274 am infoAction: Off: DIN Light (skipped)
app:24522019-08-31 06:57:08.270 am infoAction: Delay 0:02:00 (cancel) (skipped)
app:24522019-08-31 06:57:08.267 am infoAction: ELSE-IF (DIN Light(on) is on(T) [TRUE]) THEN (skipping)
app:24522019-08-31 06:57:08.246 am infoAction: END-IF
app:24522019-08-31 06:57:08.243 am infoAction: Dimmers per mode: DIN Light
Evening: 99
Night: 30 (skipped)
app:24522019-08-31 06:57:08.224 am infoAction: IF (DIN Light(on) is off(F) [FALSE]) THEN (skipping)
app:24522019-08-31 06:57:08.173 am infoAction: Cancel Delayed Actions
app:24522019-08-31 06:57:08.170 am infoAction: IF (Zone 009 - Dining PIR active(T) AND
Mode in Evening, Night(T) [TRUE]) THEN
app:24522019-08-31 06:57:08.069 am infoLight Dining Triggered
app:24522019-08-31 06:57:08.055 am infoLight Dining: Zone 009 - Di
Here is the light device's event log......
|level|99|%|DIN Light was set to 99% [physical]|DEVICE|physical|2019-08-31 06:58:07.437 AM HKT|
|switch|on||DIN Light was turned on [physical]|DEVICE|physical|2019-08-31 06:58:04.884 AM HKT|
switch off DIN Light was turned off [physical] DEVICE physical 2019-08-31 06:58:04.076 AM HKT
level 35 % DIN Light was set to 35% [physical] DEVICE physical 2019-08-31 06:58:00.163 AM HKT
level 57 % DIN Light was set to 57% [physical] DEVICE physical 2019-08-31 06:57:57.050 AM HKT
switch on DIN Light was turned on [physical] DEVICE physical 2019-08-31 06:57:53.895 AM HKT
switch off DIN Light was turned off [physical] DEVICE physical 2019-08-31 06:57:52.749 AM HKT
switch on DIN Light was turned on [physical] DEVICE physical 2019-08-31 06:57:51.373 AM HKT
switch off DIN Light was turned off [physical] DEVICE physical 2019-08-31 06:57:50.651 AM HKT
All this log traffic just to turn on this light is crazy. It does turn on and appears to function correctly, but if I run a rule to turn on say 5 lights at once, HE is getting lost in translation so to speak. What do you think?
do your lights work as expected? if so you have the actions, triggers and events logs enabled on the rule. thats what it looks like to me. as far as the device logs itself im not sure.
I do have logs activated so I can see what the rule is doing. AND its DOING too much before turning on the light.
The motion lighting should be handled in 1 rule. I don't want double rules to perform a simple lighting function.
I need a motion lighting rule that turns light on with motion. Sets this light according to mode. Turns off the light after a period of no motion.
Finally, if I go to the physical switch to change level. the rules will not force the light back to the rule dim level. Time off remains the same.
That's it. Should be easily done in one RM4 rule. I am also new to RM4 and I think bertabcd was on the clean approach the this rule. Logs indicate the 1st IF is looping probably due to the "cancel delayed action". But I am not sure.
Looking back at your rule in post 12, the indentation suggests something is malformed. I've never used "Dimmers per mode" as a rule action before, but I'd assume they should be indented to the same level, not one farther left, so unless this is a display problem in RM (doubtful since it appears correctly in a previous post), perhaps that's the issue--or at least a side-effect of something else that might be causing your problem? I might be missing something else but don't see any problems with what you have.
You could try deleting and re-creating the offending action, but re-creating the whole rule might be the best way to be extra sure. (It's probably a bug that you were able to make this in the first place, but it's hard to formally report it if it's not reproducible, so when I encounter odd things I normally just start over unless I remember how I got myself into it and could help staff figure it out.)
I went through all my lights and recreated the rule totally. The spacing looks the same but I will just watch it a few days and see how the logs are doing.
Before digging into Rule 4.0, I'd recommend taking a look at 
I was thinking about exactly how I wanted to do that and if I needed that in there and changed my mind enough times that this was the result. (Honestly, you don't really need either one of them at all--turning off a light that is already off is generally harmless--but it might save you a bit of network traffic. If you have an older Z-Wave switch that doesn't report physical status changes, you actually might want to take it out. And while we're at it, you could take out all of those conditions and make it a plain 
