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 22 hours ago22 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 9 hours ago9 hr by oberkc

If a program doesn't have an IF clause then the THEN clause will always run

16 hours ago, Guy Lavoie said:

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:

Hi Guy ... appreciate your feedback, but what really caught my eye was > [ "Timers" you're seeing here is a plugin I created ]. Please expand on " a plugin I created " as I am curious about testing "plugins" ....

One challenge has always been to overcome, the speed of detection vs human movement speed. With the MS II was directly linked to a Insteon switch (no program) it was always hit and miss ... the motion trigger could be instant or a person could be half way down a hallway before the trigger. I tested PIR trigger via Zwave years back and when the Shelly released the i4, moved all but one of my basement motions. Trigger times are much more consistent than with the MS II and hence why I only have one MS II left and why this whole phantom ALL ON question came to be. I'm off to fish in a wire to where the MS II lives for the new PIR

Well, plugin development is a whole other subject, and I've only experimented with it a few months ago. I'd like to learn how to create and share useful ones. This involves learning to program in python, which in itself is a challenge. I'll get to it in due time. Documentation is very sparse. I mostly figured out the little I know through reverse engineering. I started off with a timer plugin because my previous home automation controller (the ADI Ocelot) had them and are an integral part of programming.

The speed of detection of IR sensors will always be variable, because of the way they figure out the change in IR energy being reflected. There is a certain "ignore" time built into them after detection or else you would get too much traffic and false triggers. I'm glad the Insteon ones have that On-only mode, allowing your own program to decide what to do with continued detection.

@jim_ I have a number of hardwired alarm PIR motion sensors throughout the house all connected to a DSC alarm panel. I use the DSC plugin to connect these to the eisy to control insteon lighting via a number of different programs depending on the locations needs. Once the PIR has detected motion (as indicated by the red LED illumination), the triggering of the lights is very quick. The only delay that I notice in this setup is with the PIR sensors. Sometimes they activate very quickly, sometimes slower. The PIRs have sensitivity adjustment and I could adjust those but so far any delays have not bothered me