larryllix

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.

Correct. BTW: I feel the "Repeat 1 times" construct is an incorrect syntax as "Repeat 1 times" should mean to do the enclosed line twice (the first time and then the 1 repeat) , NOT a total of once as the repeat parameter number indicates. "Do 1 times" would have been more syntactically correct.

See my inline method in the post above.

I cannot remember the exact logic but IIRC you XOR a number with 11111111111b or FFFFFFF and then add 1 ...but you still need a test to see if it needs it or you will make a positive variable negative.

Repeat while var<0 var *= -1 Repeat 1 times .....

First line to enable PG3x doesn't function. https://polisy.local:8443/rest/pg3x.enable No website found.

Behind a paywall but That is not legal in Canadian Safety Code but I thought it was or still is in some American Electrical code(s). I remember there was a difference between EMT systems and full conduit pipe also.