Trying larryllix MS Program Suite

[lgilsenberg]

I've been messing around with the Insteon Motion Sensor (MS II) and trying to figure out how to provide both a fast response and different lighting levels.  I ran across @larryllix posting of @Xathros technique but I have been having a problem getting to run correctly and hoping somebody can give me some advice.  I am able to get the programs to adjust the on levels of the scene but the lights still come on at the 100% level.  I see the scene is adjusted but the motion sensor scene on levels are not adjusted.    Any thoughts?

 

[oberkc]

That is a pretty advanced program technique, and it will likely be little more than speculation without seeing your programs and scenes, as well as knowing what, and how many of each, devices are involved.  Given the time of the referenced post, it was most likely done on v4 software.  Is this what you are running, or are you on the newer, v5 software?   V5 software changes much in this area.

regardless, it is pretty common for folks to fail to grasp the nuances of scene controller/responder relationships and how insteon can define different response levels for each controller.  Adding the ISY into the mix does not make this any easier.  My best seculation is that it is here where your troubles are rooted.

Edited July 16, 2020 by oberkc

[lgilsenberg]

I am still running the v4 software.  

The scene (Guest Bathroom)  includes 3 devices:

- Guest Bathroom Overhead (Controller)
- Guest Bathroom Vanity
- Guest Bathroom Sensor (Controller)

When the scene adjust program is triggered:

- Guest Bathroom scene on levels are changed from 100% to 20%
- It appears that the scene levels are not propagated to the controller devices so they still turn on the lights at 100%

Is there another step I need to do to adjust the device on levels?  I am using the command:

•         In Scene '1 - First Floor / Guest Bathroom / Guest Bathroom' Set '1 - First Floor / Guest Bathroom / Guest Bathroom Overhead' 20% (On Level)

 

[oberkc]

41 minutes ago, lgilsenberg said:

It appears that the scene levels are not propagated to the controller devices so they still turn on the lights at 100%

I think this is exactly what is happening...and this is by design.  Consider the "scene" as a controller (the ISY/PLM).  Changing the scene only changes responses to when the scene is evoked by the ISY.  It has no effect on scene responders to other scene controllers (such as a motion sensor or a switch).

 

41 minutes ago, lgilsenberg said:

s there another step I need to do to adjust the device on levels?  I am using the command:

•         In Scene '1 - First Floor / Guest Bathroom / Guest Bathroom' Set '1 - First Floor / Guest Bathroom / Guest Bathroom Overhead' 20% (On Level)

I don't know about "another" step.  Rather, it might be a "different" step.  Unfortunately, I don't know the larger context about what you are trying to do and how..how you are allocating tasks to scenes versus programs.  Assuming that part of what you are trying to do is, via program, to configure the vanity lights turn to different levels in response to motion sensors scene command, you would need a statement such as:

In Scene '1 - First Floor / Guest Bathroom / Guest Bathroom sensor' Set '1 - First Floor / Guest Bathroom / Guest Bathroom Overhead' 20% (On Level).

If you want the reduced responder levels also to apply to the "overhead" controller, you would also need a similar program statement for the overhead device (I assume it is a switch).  The generic form of this program statement can be thought of as:

in scene 'scene controller device" set "scene responder device" XX% (on level).

Edited July 16, 2020 by oberkc

[lgilsenberg]

oberkc,

You are exactly correct in stating that I needed to change the controller scene.  I adjusted the program as you laid out and it works perfect.  I was surprised that I was able to programmatically adjust a scene in a battery operated device (MSII).  Thank you very much.  

[oberkc]

1 hour ago, lgilsenberg said:

I was surprised that I was able to programmatically adjust a scene in a battery operated device (MSII).

I am not sure, but I would not be surprised if the responder settings are stored exclusively in the responder device.  If so, you are not making any changes to the link records in the motion sensor.

[larryllix]

5 hours ago, oberkc said:

I am not sure, but I would not be surprised if the responder settings are stored exclusively in the responder device.  If so, you are not making any changes to the link records in the motion sensor.

No links can be adjusted in the MS, only settings in the responder(s). These MSes cannot be adjusted when not in the linking mode. UDI used a scene name that doesn't exist to differentiate between scene style controls. It was always a little weird but it works and makes scene adjustments available.

I am not sure this will work properly using an MS II. If you link the MS II directly to a lamp the MS II will turn the lamp off as well, or if ON Only is selected, the MS II will never send another On trigger to restart the Wait statement until the MS II stops seeing motion for it's delay time, plus stops seeing motion for the length of it's Off time as well. Yeah, the MS II sucks. There may be a way to use this technique to just block the MS II and use both On and Off events sends.

[oberkc]

7 hours ago, larryllix said:

UDI used a scene name that doesn't exist to differentiate between scene style controls.

It seems to me that the definition for "scene" has evolved over the years, and has always depended on perspective.  IIRC, "scenes" were originally defined within insteon as a controller with one or more responders.  The ISY defined scenes that could include multiple controllers, including the PLM.  In effect, ISY scenes could include multiple insteon scenes.  I don't notice insteon using the "scene" term as much in more recent years.

Perhaps this has caused some confusion?

[lgilsenberg]

I thought I had this working . . . I thought wrong.

I am finding that the light in the bathroom turns off despite there being movement in the room directly in front of the motion detector.  

I am on 4.18 still because 5.x writes to the controller (MS) and the responders during adjust scenes and I don't want to continuously queue up writes to battery operated devices.

Any thoughts?  I've changed the wait from 45 seconds that was listed in larryllix post to 10 minutes but the light keeps turning off at the end of the wait period.

Program:

Motion Sensor Setting:

 

[larryllix]

12 hours ago, lgilsenberg said:

I thought I had this working . . . I thought wrong.

I am finding that the light in the bathroom turns off despite there being movement in the room directly in front of the motion detector.  

I am on 4.18 still because 5.x writes to the controller (MS) and the responders during adjust scenes and I don't want to continuously queue up writes to battery operated devices.

Any thoughts?  I've changed the wait from 45 seconds that was listed in larryllix post to 10 minutes but the light keeps turning off at the end of the wait period.

Program:

Motion Sensor Setting:

 

You are using the MS II units. Not going to work well. If you select "On commands only", the MS II will only send one On command while the internal timer has been retriggered within the last timeOut set time. (0.5 minutes). Once the internal timer times out with no motion sensed for the 0.5 minutes then the MS II must see no motion for another 0.5 minutes before it will reset again.

These MS II units are not good for Insteon scenes in ISY. As the sole control source for a lamp, turning it on and off as a dumb Insteon Hub would use it, it may work well, but for ISY intervention the only way anybody has found to make it work with a lamp properly  is by not using Insteon scenes between the MS II and a lamp. The response time will be slower then.

Both the MS II and the original MS have an internal, retriggerable timer. The difference is that the original MS sends an On command every time it is retriggered. The MS II doesn't. Also in the MS II the off cycle is dependent on the same Internal timer timing out by not being retriggered with motion. That right...the MS II will never send an On command until the MS II doesn't sense any motion for the timeOut time.  It's a design error by Insteon. One is used for a scene with light in my laundry room but is set for a long timeout and is a PITA. It's on USB power and that doesn't change the operation.

I have three and only use them for detection of occupancy for security, and determination of home or away

[lgilsenberg]

So it sounds like MS II is not a great idea to monitor occupancy for scenes.   The good thing I take out of that is the ability to select any motion sensor and not rely on Insteon alone. Is there a motion sensor you would recommend for controlling programs?

[larryllix]

1 hour ago, lgilsenberg said:

So it sounds like MS II is not a great idea to monitor occupancy for scenes.   The good thing I take out of that is the ability to select any motion sensor and not rely on Insteon alone. Is there a motion sensor you would recommend for controlling programs?

I only use the MS1s as I have no Zwave. The Insteon scene is the only MS ==> Lamp that I have heard of that responds with a fast enough speed for room entry lights. I have three MS2s. I use many WiFi devices also but not for MSes. I have found and purchased many extra MS1s to replace any MSes that burn out. I have used some LioN 9v batteries that have burned out some MSes now with their 11.6v output. Not doing that again.

The MS II is useful for non-immediate light requirements, security, and occupancy (home/away) detection, and I have now moved my 3 x MS IIs to those usage styles. I don't use any other fields in the MS IIs, as I find them mostly nonsense and unreliable, so far. Any other protocol of MS will have to go through ISY and will never be as fast as the Insteon/Insteon scene interface.

[kclenden]

13 hours ago, lgilsenberg said:

So it sounds like MS II is not a great idea to monitor occupancy for scenes.

It depends on how much control you want over the scene.  If you are willing to give the MS II complete control so that it is responsible for turning the scene ON and OFF, then you can rely on the MS II timer to determine when the scene is turned OFF.  Many people want more control than that.  If that's the case, then you could probably use two MS II sensors.

With two MS II sensors, you could make a direct link between one of the MS II sensors and the devices you want turned ON.  Set that MS II to send only ON commands.  Then use the second MS II sensor, which is not directly linked to the devices being controlled and should be set to send both ON and OFF commands, to determine when there has been no motion for the specified time.  This would allow you to have the speed of the first MS II turning ON the scene, but program control over when it is turned OFF.  Sort of an expensive way to accomplish the goal, but if nothing else does what you want...

[lgilsenberg]

22 hours ago, larryllix said:

I only use the MS1s as I have no Zwave. The Insteon scene is the only MS ==> Lamp that I have heard of that responds with a fast enough speed for room entry lights. I have three MS2s. I use many WiFi devices also but not for MSes. I have found and purchased many extra MS1s to replace any MSes that burn out. I have used some LioN 9v batteries that have burned out some MSes now with their 11.6v output. Not doing that again.

The MS II is useful for non-immediate light requirements, security, and occupancy (home/away) detection, and I have now moved my 3 x MS IIs to those usage styles. I don't use any other fields in the MS IIs, as I find them mostly nonsense and unreliable, so far. Any other protocol of MS will have to go through ISY and will never be as fast as the Insteon/Insteon scene interface.

Thanx for the feedback on the MSII and the MSI idea.  It's too bad the MSI are not more widely available, I really like the "instant on" with programmatically adjustable scenes and timers.  I'm going to try keeping the 30 second timeout, changing the wait to 15 minutes to see if the number of times the light unintentionally turns off is tolerable.  If not, I'm afraid without a reliable supply of MSI, I will be either trying one of two solutions:

 

1) the double MS II concept that @kclenten laid out.

"With two MS II sensors, you could make a direct link between one of the MS II sensors and the devices you want turned ON.  Set that MS II to send only ON commands.  Then use the second MS II sensor, which is not directly linked to the devices being controlled and should be set to send both ON and OFF commands, to determine when there has been no motion for the specified time.  This would allow you to have the speed of the first MS II turning ON the scene, but program control over when it is turned OFF.  Sort of an expensive way to accomplish the goal, but if nothing else does what you want..."

Very creative solution but I'm not sure how this would work in a larger room where multiple sensors are required to capture occupancy.  

 

2) Try Z-Wave sensors to handle on and off in larger rooms.  What I would give up in terms of "instant-on", could be made up by the flexibility of programming and accuracy of multiple sensors in a room.

I'm not sure if I will run into a new layers of complexity by having multiple sensors in a room.  I guess I'll jump off that bridge when I get to it.  If I go this route, does anybody have any recommendations for a z-wave sensor?  The Aeotec Multi-Sensor 6 seems expensive at $60 each.  I'm hoping to find a good alternative that hopefully will ignore small pets.

 

.

 

 

[larryllix]

25 minutes ago, lgilsenberg said:

Thanx for the feedback on the MSII and the MSI idea.  It's too bad the MSI are not more widely available, I really like the "instant on" with programmatically adjustable scenes and timers.  I'm going to try keeping the 30 second timeout, changing the wait to 15 minutes to see if the number of times the light unintentionally turns off is tolerable.  If not, I'm afraid without a reliable supply of MSI, I will be either trying one of two solutions:

1) the double MS II concept that @kclenten laid out.

"With two MS II sensors, you could make a direct link between one of the MS II sensors and the devices you want turned ON.  Set that MS II to send only ON commands.  Then use the second MS II sensor, which is not directly linked to the devices being controlled and should be set to send both ON and OFF commands, to determine when there has been no motion for the specified time.  This would allow you to have the speed of the first MS II turning ON the scene, but program control over when it is turned OFF.  Sort of an expensive way to accomplish the goal, but if nothing else does what you want..."

Very creative solution but I'm not sure how this would work in a larger room where multiple sensors are required to capture occupancy. 

2) Try Z-Wave sensors to handle on and off in larger rooms.  What I would give up in terms of "instant-on", could be made up by the flexibility of programming and accuracy of multiple sensors in a room.

I'm not sure if I will run into a new layers of complexity by having multiple sensors in a room.  I guess I'll jump off that bridge when I get to it.  If I go this route, does anybody have any recommendations for a z-wave sensor?  The Aeotec Multi-Sensor 6 seems expensive at $60 each.  I'm hoping to find a good alternative that hopefully will ignore small pets.

I am still formulating another method using the MS II devices but haven't worked on it yet.

We should be able to have the direct link with a light device to allow a fast on time with motion.
Then ISY can detect the NS On signal and interfere with the MS --> Lamp scene link. I haven't tried it yet but this was introduced with one of the V5 beta releases.
The delay inside the MS II would have to be very short as they present other problems in that they will not reset for the same time delay without motion either. Yuk. Design flaw IMHO.

After the desired time the scene would have to be modified by ISY again. Hopefully, this wouldn't wear the eprom in the lamp device (guessing about 2-3 years?) out but it could be the cost of doing business like this.

Edited August 4, 2020 by larryllix

[kclenden]

7 hours ago, larryllix said:

Then ISY can detect the NS On signal and interfere with the MS --> Lamp scene link.

I'm assuming you'd have the MS II setup to send ON and OFF commands.  Then after receiving an ON, you'd change the link between the MS II and Lamp to "ignore" so that when an OFF finally comes, the Lamp won't see it, but the ISY will.  There are at least a couple issues with this.

One issue is the scene update bug in V5 whereby the ISY tries to write to the controller when only the responder link needs to be updated.  While the MS II will be awake after sending an ON, you might not be able to update its link with the Lamp before it goes back to sleep because of other Insteon traffic on the power line.  If it goes back to sleep, the ISY won't be able to write to it (even though is really doesn't need to).  Some people workaround this by disabling writes to battery devices.  Another way would be to power the MS II by USB instead of battery.

Another issue is one of complexity and murphy's law.  A power failure after you've interrupted the link between the MS and Light would leave things in a bad state.  So you'd probably need to use a variable that is saved to the ISY permanent memory to track when the link has been interrupted and then have a cleanup routine that runs on power-up if the variable indicates it's needed.  With enough MS II's in the system, you end up with a mess of cleanup variables and programs.

Additionally we don't really know what the MS II will do if it's in the middle of tracking motion and it receives a Link Table update from the ISY.  Will it continue to run its internal timer so that it eventually sends an OFF?  Will it just kill its internal timer and never send an OFF?  Will it kill its internal timer and immediately send an OFF?

Still, it's probably worth it to give it a try.

[larryllix]

4 hours ago, kclenden said:

I'm assuming you'd have the MS II setup to send ON and OFF commands.  Then after receiving an ON, you'd change the link between the MS II and Lamp to "ignore" so that when an OFF finally comes, the Lamp won't see it, but the ISY will.  There are at least a couple issues with this.

One issue is the scene update bug in V5 whereby the ISY tries to write to the controller when only the responder link needs to be updated.  While the MS II will be awake after sending an ON, you might not be able to update its link with the Lamp before it goes back to sleep because of other Insteon traffic on the power line.  If it goes back to sleep, the ISY won't be able to write to it (even though is really doesn't need to).  Some people workaround this by disabling writes to battery devices.  Another way would be to power the MS II by USB instead of battery.

Another issue is one of complexity and murphy's law.  A power failure after you've interrupted the link between the MS and Light would leave things in a bad state.  So you'd probably need to use a variable that is saved to the ISY permanent memory to track when the link has been interrupted and then have a cleanup routine that runs on power-up if the variable indicates it's needed.  With enough MS II's in the system, you end up with a mess of cleanup variables and programs.

Additionally we don't really know what the MS II will do if it's in the middle of tracking motion and it receives a Link Table update from the ISY.  Will it continue to run its internal timer so that it eventually sends an OFF?  Will it just kill its internal timer and never send an OFF?  Will it kill its internal timer and immediately send an OFF?

Still, it's probably worth it to give it a try.

I have moved my MS IIs away from direct light applications now so my drive to find a resolution has left the building, for now.
I think UDI fixed the write battery devices with scene link updates in v5.1.0. I know it was on the table as a bug but I haven't tested it in v5.1.0 for the above reason.

Yes, I don't like all these cheap work-arounds because I, like IIRC you are, prefer more structured programming approaches that I wouldn't get tossed out of school for.

Edited August 5, 2020 by larryllix

[MrBill]

1 hour ago, larryllix said:

I think UDI fixed the write battery devices with scene link updates in v5.1.0. I know it was on the table as a bug but I haven't tested it in v5.1.0 for the above reason.

I'm not certain you're correct, but I haven't loaded v5.1.0 to test because I don't think it's included for this reason:

  

On 8/1/2020 at 7:53 AM, Chris Jahn said:

No, unfortunately apart from the bug fixes listed, this build only has Z-Wave changes.

and that list appears to include:

On 7/31/2020 at 11:03 PM, Chris Jahn said:

Fixes in this build:

0000739 - Support Fast On/Off for Insteon Hidden Door Sensor Heartbeat report

0000741 - Groups/Folders occasionally have the same node address

0000742 - Additional status values related to Weather

0000743 - Add units of measure VA, VAR, Date/Time NTP

0000744 - Precision conversion used in comparisons is incorrect in some Program Conditions

0000745 - Cannot change to Z-Wave external antenna

0000746 - Support multiple node status updates on a single REST call

0000755 - Z-Wave certification changes

0000757 - Show all commands on the node view in the Admin Console

 

Since I have no Z-wave and that bug doesn't appear to be addressed I haven't loaded the update.

[larryllix]

12 minutes ago, MrBill said:

I'm not certain you're correct, but I haven't loaded v5.1.0 to test because I don't think it's included for this reason:

  

and that list appears to include:

 

Since I have no Z-wave and that bug doesn't appear to be addressed I haven't loaded the update.

You may be right, but MIchel had advised me it would be fixed shortly. I also wondered that it was intended to just have the "Battery Writes" turned off and leave it in as it seems to work OK and give the user manual control over the process.

The open linking window time technique doesn't appear to work at all because the "Battery Write" disable also locks out the program auto-update technique out also. The time gap between updating a scene via ISY and an MS seeing motion can really cripple my ISY every day and sometimes for weeks in a seldom attended room.

Manual updates for a battery operated MS seems to be the only logic that is ever going to work anyway.

In the past many of the ISY fixes were never listed in the updates posted.

Edited August 5, 2020 by larryllix