Beginning of Feb, I posted a question "Assistance tracking down random triggered events". It was determined thanks to @IndyMike , this was related to the known issue of phantom ALL ON in older devices. One critical item identified that I needed to change out was MS II ...

Since I already have a couple of old alarm PIR's to a Shelly i4 Zwave module, which has been rock solid in basic functionality (PIR triggers Shelly on hardwired connection, Shelly sends basic open close to programs), thought I would replace the MS II with another PIR / Shelly combo.

As I have NO PROGRAMMING background, its been a slow learning process by coping examples found in the Wiki / this forum / trial & error, but in the end always found some function missing or something not working 100% of the time as expected. And as complexity grows and programs accumulated, diagnosing problems turned into deeper problem for me to work through. My whole deployment is lighting only, so no fancy addon's just basic lighting automation.

I retired recently and setup a lab in my office to start extended testing of modifications to or for new lighting solutions ... therefore before replacing the MS II, I wanted to fix some of the broken / missing functionality of what exists to today, e.g. motion override (disable the timer via switch paddle and auto delay timer reset when human traffic exists longer than the normal / default timed event.

I have success, but it took 5 programs to make it work as wanted ... so question to the forum : is this efficient ? is there a better way to write this ? do I just deploy and not worry, the EISY has lots of CPU Attached are my programs, there are notes for each program ... I would appreciate feedback if anyone would like to critique

Motion1.rtf

FWIW, earlier this year I retired anything Insteon that was a sensor, either iolinc, MSII or leak.

"All On" events are limited for me since the majority of my devices are "All On immune" i3 paddles and i3 outlets. I have some dimmers and micro modules which are susceptible to the all on, none of them have come on randomly, unexpectedly, since that time

I switched to yolink sensors. It does add a small but noticeable delay for motion lighting compared to using the MSII, but this trade off is better for me.

2 hours ago, jim_ said:

Beginning of Feb, I posted a question "Assistance tracking down random triggered events". It was determined thanks to @IndyMike , this was related to the known issue of phantom ALL ON in older devices. One critical item identified that I needed to change out was MS II ...

Since I already have a couple of old alarm PIR's to a Shelly i4 Zwave module, which has been rock solid in basic functionality (PIR triggers Shelly on hardwired connection, Shelly sends basic open close to programs), thought I would replace the MS II with another PIR / Shelly combo.

As I have NO PROGRAMMING background, its been a slow learning process by coping examples found in the Wiki / this forum / trial & error, but in the end always found some function missing or something not working 100% of the time as expected. And as complexity grows and programs accumulated, diagnosing problems turned into deeper problem for me to work through. My whole deployment is lighting only, so no fancy addon's just basic lighting automation.

I retired recently and setup a lab in my office to start extended testing of modifications to or for new lighting solutions ... therefore before replacing the MS II, I wanted to fix some of the broken / missing functionality of what exists to today, e.g. motion override (disable the timer via switch paddle and auto delay timer reset when human traffic exists longer than the normal / default timed event.

I have success, but it took 5 programs to make it work as wanted ... so question to the forum : is this efficient ? is there a better way to write this ? do I just deploy and not worry, the EISY has lots of CPU Attached are my programs, there are notes for each program ... I would appreciate feedback if anyone would like to critique

Motion1.rtf

I'm doing something similar for a motion sensor located in a small storage room in the basement with a fridge, and that also has a sink that I'll use for cleaning paintbrushes, etc. The idea is that I'll usually just go in to get or put something in the fridge, and I turn on a Hue bulb for a default of 30 seconds, but I want that 30 seconds to be extended if I'm still there and moving around. That's retriggering the timer. There are also fluorescent ceiling lights that I can turn on with an Insteon wall switch if I want more light, such as when using the sink. 75% of the time, the Hue bulb is enough for just going in for a moment. The motion sensor is placed behind the door, such that if I walk in and turn on the wall switch, the status of the wall switch will be known to be On before the motion sensor sees me.

My Insteon motion sensor is set up in the On-only mode, sending a On command every time it detects motion, and it's internal timer is disabled. This mode exists for the purpose of letting you create retriggerable routines in software. I have two programs for doing what I want. One program Looks for the On control events from the motion sensor and keeps retriggering the timer. Note that since I'm using two different lights, the status of the fluorescent light switch (B7...) is used as a flag to AND with the motion sensing, so that that switch needs to be Off for the motion sensor routine to turn on the Hue light.

MS motion sensor Hue light - [ID 0012][Parent 006A]

If

'MS Storage Sensor' is switched On

And 'B7 Storage' Status is Off

Then

Set 'Hue / Hue-Storage' On

Set 'Timers / t3_storage' Raw value 1

The second program looks for my 60 second time period to expire, turning off the Hue light:

MS storage turn off Hue light - [ID 00C2][Parent 006A]

If

'Timers / t3_storage' raw data 0 > 60

Then

Set 'Hue / Hue-Storage' Off

Set 'Timers / t3_storage' Raw value 0

Now a few things here: The "Timers" you're seeing here is a plugin I created, that increments once per second if it is set to any value other than zero. You could do an equivalent thing with a program like you did with your Timer Decrement program, except that it increments the variable instead of decrementing it:

If

        $sTest_Motion_1_timer > 0

Then

        Wait  1 second

        $sTest_Motion_1_timer += 1

The other thing is that you're using the same light for both motion sensor activated or manually switched on. That makes it a bit harder to disable the timer mode when manually switched on. You would need to modify my "And 'B7 Storage' Status is Off" with a status variable instead, and have two separate programs that sets the variable (such as to 0 or 1) whenever the condition of the light switch changes due to control events from that switch. It would be sleeker to follow the status of the switch with a single program, but the status of the switch would be changed by either manual switch activation or by motion sensing...you couldn't distinguish which the case it is.

The bottom line is: if the way you did it works for you and you understand it, stick with it. "Efficiency" becomes quite secondary.

Edited 13 hours ago13 hr by Guy Lavoie

16 hours ago, jim_ said:

I would appreciate feedback if anyone would like to critique

Well...I am not quite sure what you are trying to achieve here, or what hardware limitations exist, that requires (what appears to me) to be a relatively complicated set of programs. One thing I noticed, however, is that the first program calls to "Run Program 'Motion1 - Timer Set' (If)" but when I look at the program 'Motion1 - Timer Set' , there is no (if) clause.

But I tend to think like @Guy Lavoie , if it is working for you, I don't see a reason to modify the programs.

Edited 8 minutes ago8 min by oberkc