larryllix

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.

I use scenes and programs like this, Alexa...turn on xxxx lights Alexa...turn on dim lights Alexa... turn on very dim lights Alexa...turn on TV lights (slowly dims and colour tunes bulbs before bed every 30 min.) Alexa...turn off xxx lights These all control programs that may operate scenes and/or WiFi bulbs together. Create scenes with useful levels, as needed, and work with them.

Typically, in industrial electronics, contact devices have two current ratings, one for resistive loads and one for inductive loads. Since you are controlling a motor, you have an inductive load and the rating of the contacts should have been stated as much lower. This is due to, as @Brian H posted above, when you break the current flow to an inductor/motor, it has an 'electrical inertia' that doesn't want the present current to change and results in an inductive voltage spike coming from the load. When the contact opens the current will tend to keep flowing and will arc across the contact until it extinguishes or the contact either melts together or melts itself clear. When replacing the device I would install some heavy duty MOVs across the motor windings, to absorb some of this counterEMF that the motor may produce. The common ones I have dealt with mostly were rated at 20,000 joules @ 220V. You must remember it has to withstand the peak of the 120v waveform. 130v x 1.414 = 183v

There is a file in the ISY that dictates the UUID number that acts up with some older ISYs. UDI had a fix for me. I can't remember how but one module needed to be updated or retimed.