larryllix

The On cycle time has never been a problem.

OK. It is coming back to me more. I enabled the "send On and Off" and tested the MS II. It works properly and no Off time out causes problems, as you are finding. However the time On delay time does not function according to setting. The closest I could come was the increased delay with motion is about half of the setting delay. Eg. with your 20 second delay, if motion is detected at 18 seconds the resultant "lights off" will result at about 28 seconds. Not that big of a deal but not according to setting implications. The problem starts when you enable "send On" only. I experimented with this last night by increasing my On time to 40 seconds, and found after the lights turn off as long as you keep moving in the room the lights will never turn on again. X seconds of no motion must be detected before the MS II is not blind and will react to motion. This is a bug in the design IMHO. This was never a concern for Insteon (and they appear to have ignored complaints) as the full On and Off signal style works with their Insteon Hub (having no smarts), but smarter response logic from an ISY box require "On only" to retrigger program logic. I dim my brightness levels in the evenings, and sleep hours, as well as, shorten my On times, thus Off signals would just confuse some of this. As a workaround, I use a short On time, so that the Off/ Blind time is not as long.

@IndyMike OK. My MS II, that definitely displays this bad behaviour, is a V.47 R3.4, Date 17 19. As far as I can remember I tested them all for this behaviour and they all do it. So much for not being on the bleeding edge here. Labour dispute just before Insteon collapse? * * * Ohh... The firmware revision (V.47) is from the IoX device page and may not be correct but rather the version UDI supported at the time they wrote the code. * * *

Thanks. I'll have to check those revisions and dates. Mine are all from the old Insteon before my reports were sent. Strange how I always seem to get the versions with the defects. I guess too much "bleeding edge". However I only use one of my three MS IIs as a light operator where this is really annoying. Mine are all on USB power so the frequency of sending ON only isn't important for battery life. A very short On duration creates a very short OFF duration also.

As per other MS devices, and the Insteon MS I, I would expect the MS II to NOT lock itself out and NOT to never report motion, as long as it keeps seeing motion while off. I expect any MS device to report motion as it sees it, and NOT lock off lights until it stops seeing motion. In your example of 20 seconds, after the MS has timed out, and shut off the lights, if you then start walking back and forth, retriggering the OFF timer, it will never turn the lights back on until no motion is seen for at least 20 seconds. I believe you are not seeing the difference between the Off command and the Off duration.

The MS portion uses the same timer for on times and off times. This means once your MS times off it cannot sense motion until the off timer times out. Of course, that never happens as long as the MS keeps sensing motion and lights on and/or detection never happens in a busy room. The only way I have found to make them useful is by using a very short time delay setting, with On only, and let ISY sort out the frequent On signals. I was hoping the new Insteon management would fix this bug as the unit is the best I have found so far. Sent from my SM-S711W using Tapatalk

UDI did a hack to support this model and stated without a proper API, they would no longer do this for any new device. I don't know if the new Insteon ever supplied them with a proper API, but many bugs still exist in the MS II or support drivers. I use them for MS only, and they work reliably most of the time, but with some workarounds in technique from the MS I. Sent from my SM-S711W using Tapatalk

It sounds like Matter will be supported over the ZigBee network anyway. None of this was made clear to me and do much confusion has been spread around everywhere. Sent from my SM-S711W using Tapatalk

OK. I found another OnOff module in my system and it shows exactly the same controls. In the program page lines with XXX On show an option below and percentages of 0% and 100% are options there also. Bug in the IoX system, brought in somewhere in the polISY / eISY conversion of the software?

Middle aged Insteon device. Newer than the ApplianceLinc, but not i3 I don't think?

Well that was my first thought that I confused the device characteristics table. I didn't use the REPLACE function, only the search and replace device name. I deleted the line and replaced it in various ways but it persists. Note my screen shot of the device's page. The header shows the device type while the same page shows the On percentage box. I think I recall an old thread where there was some usefulness to have percentages instead of On/Off but very vague to me now.

First I have noticed this. I just converted a dimmer to an OnOff module (relay contact) because it was making the motor hum. I know this is not recommended but it works for many devices that are not just a motor. Anyway, I noticed that the On commands are now offered a parameter. In this case one is a percentage On. Looking more closely, only 0% and 100% are offered but you can set the OnOff relay module to On @ 0%. Is this an intended thing, or some carry over from so many updates in ISY / IoX bug?

Not quite in this case. It work would the other way around but not when the Door Light status changes to ON status. This is because any device's "switched ON" always evaluates to False, except when the program is invoked by that "Switched ON" line itself. The static status of the Hall Light itself is not relevant, or being tested, in the case of this "switched" construct. Hall Light status is ON would allow the Door Light status changing to on the run Then.

Insteon, and most other, devices are updated by events that happen at the sensing end. For Insteon lightswitches and many other Insteon devices, status is the current status of the electronic dimmer circuit and sends updates when it changes, "control switched" is the current status of the actual switch paddle and sends updates when it changes (pressed). Querying a device asks for the current status of that particular circuit or part and the paddle switch would always send "not pressed" so is not supported with a "status" control. IOW, it is two devices in one box and uses two different styles of update syntaxes to identify which one you want.

This only happened to me (sometimes for months at a time) years back and hasn't happened, to me again, until a few days ago. I figured it was new software installed and would just need rebooting/relinking to "catch up". However it appeared to fail for 4-5 minutes and then finally reconnected.

This doesn't sound correct for these cases. If the subscription failed, how could the Alexa app still show the device's status as operating on and off, but the routine not obeying the status change? The app server knows the status changed so it appears all communications with the portal appear to be functioning properly. This problem is still happening. It just happened to my system again right before my posting about it. I deleted the skill and reinstalled it. However, it took about 5 minutes to reconnect the routines to the status points this time. That delay didn't happen formerly. EDIT: OK. now it makes more sense. My bad! Reading your post again, I believe you are saying there are two different comm channels/methods for this status. One for simple indication and one for Routines.

However, when I, and others, had problems a while back, pseudo devices would be operating inside the Alexa app despite Routines not triggering. There may have been some problems corrected in the Portal but this indicated the fault was inside Alexa server software IMHO. Further when we complained to Amazon, after they totally denied any responsibility, the problem would go away and Routines would resume working unmodified.

For lighting scenes I create a state variable for each room. Then I build a folder full of different lighting levels and routines using Insteon scenes, programs and NRs to accomplish whatever I want in lighting or in one case automatic time based dimming. In my variables I define several "constant" definitions such as: $cMODE.OFF= 0 $cMODE.VERY.DIM = 1 $cMODE.FULLON = 9 $cMODE.WHITE.FLASH = 99 etc... Each room theme folder program has a single condition to detect it's value like this LivRm.theme.dim - [ID 003A][Parent 0043] If $sTheme.livRm is $cMODE.DIM Then ...set levels to DIM Else - No Actions - (To add one, press 'Action') When you want to set a lighting scene to whatever a single line of code from anywhere (Alexa, automatic programs, etc..) it takes two line of code like this to turn it on LivRm.green.initiate - [ID 0049][Parent 0017] If // Alexa vocal initiated Then $sTheme.livRm = $cMODE.RESET $sTheme.livRm = $cMODE.GREEN Else - No Actions - (To add one, press 'Action') When you need to know what scene is being used only a single test is required. No convoluted logic is required with cross testing between programs. When you want to "borrow" a set of lights and restore them it becomes simple and reliable, like this to flash lights at midnight and restore the original levels again: LivRm.lateWarning - [ID 00AB][Parent 0017] If Time is 11:59:30PM Then $LivRm.mode.saved = $sTheme.livRm $sTheme.livRm = $cMODE.RESET $sTheme.livRm = $cMODE.RED.STROBE Wait 3 seconds // $sTheme.livRm = $cMODE.RESET $sTheme.livRm = $LivRm.mode.saved Else - No Actions - (To add one, press 'Action')

I had thought it was testable in ISY, in the past. Now I see all the controls to program change those statuses but no conditional access status. IIRC True and False were going to be defined as system variables, as an addition years ago, but expansion became paramount to UDI when Insteon was threatening collapse.

Mostly I, and others, got denial, and blaming of UDI, but then routines started working again. AS with others, we could see status points being activated and changing in the Alexa app but the routines would not trigger. Best of luck.

Years back I found this had to be done quickly as the Alexa skill sees the devices missing and disables or removes all routines based on these pseudodevices. Knowing that they can be re-enabled but it can cause a lot of confusion until you find out why.

My favourite for almost any program/state/lighting scene now is to create a State variable and a program that controls the enable/disable. Now you can control it via any program, and test it via any program with one line. No worrying or complex logic to see if programs may be mis-nested or confusing each other. If StateVar /= 0 Then enable Program X Else disable Program x

There goes our snooze time!

Yes, many programs use infinite looping to create timed counters and cycle furnace fans and humidifiers etc... It will run until a power down or interrupted somehow, usually a human editing the program. Many schemes to restart these infinite loops have been used for power up conditions.

That used to not function at all.