larryllix

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.

I suspect there was a time in history where the metal pipe and boxes were used as a grounding system and no copper conductor was required. Later this became outlawed and a separate grounding conductor was required. In @Brian H comment above we used to raise the 208v up to 216v in an attempt to make it more compatible with240v appliances (stove burners and baseboard heaters run too cool, etc..) but that made the 120v phases run at 125vac. Still within utility specs, but sure makes a lot of complaints about high voltage until people get better lightbulbs. Many bulbs didn't like the 125vac on 120vac rated bulbs and popped them after a few days to a few weeks. I am not sure how it affected the new LED bulbs. They came after my time.

I had a receptacle On/Off module go erratic and produced an Insteon Scene On command occasionally, when sent a simple On or Off. It happened about 7 or 8 times over a few years or more. Since I recognised the lighting pattern, I always thought it was just a bad program somewhere, but could never identify it's source. Eventually, I was examining my Log and found some bad packets from this particular module instead of the ACK expected from it. The time coincided with the latest erratic Insteon scene occurrence. In a first ditch effort to nail it down further, I simply unplugged the on/off module and plugged it back in again. I could not ever figure out why power failures didn't do the same thing, but years after (as I type this), I just realised that the difference may have been the inductive motor load I had plugged into it. When I did it manually, there would have been no inductive load (humidifier) attached. After power cycling the module, it never happened again for about the last 5 years. I post this example because I believe ALL ONs are just another form of Insteon Scenes, that can be produced by any module in your system. Other Insteon modules could then see this, and repeat it into the closest valid Insteon signal code. Insteon has demonstrated that it really doesn't have any signal security, despite what has ever been proposed in white papers.

Yeah, I moved and downsized, but it saved me a bulk package of batteries every year and the hassle of changing some of them on ladders.

The ISY Portal can only use analogue values to be accepted as motion detectors and door/window detectors as binary values. However, several analogue point levels could be converted to binary values and perhaps used by Alexa from that driving a series of events/routines.

Sure. EISY can do all basic math and a few advanced math functions. and send the results almost anywhere. Much easier to program than an arduino unless you are familiar with the system.

I use many MagicHome WiFi RGBCW bulbs. When I changed routers (ASUS) , despite all he same SSID name, password and security protocol (WPA/WPA2), all the bulbs needed to be reconnected with the new router. IMHO, there has to be some other security detail that is never discussed inside the WiFi protocol. When I changed the router back (Netgear) later the same thing occurred. In short: maybe try factory resetting each bulb and reconnecting it to the new router.

Your logic and troubleshooting sounds good. Try using the reverse logic as such: And 'Generic / Rachio-Sprinkler' Watering is Not On

If 'Generic / Rachio-Sprinkler' is a program can it be 'off' status?. How long will the status of the door open sensor be 'On' and will it ever coincide with the following line?

Try turning your output powers to about 25% and check again. Some of these router's antennae cannot handle that much power without distorting the waveforms IMHO, and work much better with less power output. Alternatively, try turning down just the 5GHz strength and leave the 2.4GHz turned up.

It says it is for motors so it should work. For the MOV, it is a small flat lollipop shaped item that would require a space inside the motor or even a large size plug. I assume there are no terminal blocks involved in the wiring somewhere? For contacts it's the current that is critical for turning things on and running. It is the voltage that is critical not to arc across the contacts for turn things off. Motors are a biotch for both aspects. We dealt with a lot of DC devices so a 240 vac contact would suddenly be rated at 24vdc max. I watched a few contacts melt before my eyes while new engineers discovered this the hard way. High voltage DC contacts (yeah 120vdc was 'high') involved magnets to attract the arc into quenching cages and other magic. As @ELAposted above the Insteon specs have always been missing the full spec., hiding the motor/inductive capacity of their devices.