MrBill

Isn't Tuya one of those that requires use of their free cloud server? (a business model that can never work long term)

get some Wago's with the lever... Use mine for every new device (photo credit actually goes to @Teken because I never took a picture of mine)

Correct. The ISY is event driven, and if an event occurs it can interrupt a program. Wait, repeat and maybe another object I'm not thinking of at the moment in a program create a pause that gives the chance for the program to be interrupted without completing. It catches programmers off guard, but at the same time it has it's benefits... from another current thread If Motion is switched On then turn on light wait 5 minutes turn off light else (nothing) will turn the light off 5 minutes after the LAST time the motion detector triggered because the wait gets restarted each time the motion is tripped.

I see this is correct today. Yesterday I must have mis-read somewhere. I actually started on Amazon before heading over to shelly.cloud to use the search filter. (was happy I did head over to shelly.cloud tho...with all the 50% off items I ended up placing an order 🤣)

Is this still true with 'Motion' is switched on, (i.e Control rather than Status)? This was exactly why I wrote the simple example with Control as opposed to status, which it looks like from the screenshot he did use Control. I supposed i should have supplied an 'AND motion status is off' to save Insteon traffic, but i suppose that would also allow this program to run false, not sure what it should do then. My current wonder tho is if OP has the Motion in a Scene as well as using this program. I don't use Insteon motions so I'm unsure of the settings but I believe some users do Scene On and Program Off for faster turn on when reacting to motion.

definitely.

From the Vantage Vue Pro2 manual: Rain Storm Rain Storm displays the rain total of the last rain event. It takes two tips of the rain bucket to begin a storm event and 24 hours without rain to end a storm event.

Shelly 1 can be powered by 12v DC. It's wifi, no hub and local control. (be careful Shelly 1 Plus needs 24V min) Not sure if there's a node server without looking, but it would be easy to control via network resources. Be sure to read the directions, pretty sure they ship configured for 120V and a jumper block needs to be moved for 12v. They are on sale at Shelly for less than Amazon (even with Prime Day).

There are two different Z-wave modules that were sold for 994... the 300 Series Z-wave board, reports z-wave version 4.55.00 in the admin console under Z-wave > Z-Wave version, Also has a Blue Led on the back of the ISY near Port A-- If it's not lit up it's hard to tell it's a Blue LED unless your shining your phone flashlight on it. This board is not compatible with firmware beyond V 5.0.16V. If you have this board you must downgrade the firmware to 5.0.16C. the 500 Series board reports version 6.81.00 or something close to that in the admin console under Z-wave > Z-Wave version. It does not have a blue LED. If that's the case please Upgrade your firmware to V 5.3.4. This is an easy upgrade from 5.3.1... just backup and then load the new firmware file, the ISY will reboot there should be no other issues. Please let us know which z-wave board you have. I doubt eisy will be out of stock for very long.... sales@universal-devices.com can likely predict when the will return to stock.

In the screen shot above we can tell the program is still running: the Solid Green folder says the wait hasn't timed out yet at that point. Remember if the motion is re-tripped the time starts over. I say keep your program as is for test purposes, but shorten the wait down to say 30 seconds... then watch for the folder to time out and see if the lights go off.

Insteon motion sensor hardwired i believe re-triggers more quickly. Which means you can use shorter wait windows if you like... wait is essentially wait until X minutes after last motion. Battery motions however retrigger on an infrequent interval to preserve battery.

After a PM discussion with someone.... back for: Chapter 3: edit the program (hint: only have one program if $test in the IF statement, multiple programs may cause unexpected results so EDIT the original program) If $sTest = 1 then $sTest += 5 Wait 1 minute $sTest += 100 else wait 5 seconds $sTest += 1000 Set the variable back to zero then re-enable the program (we left it disabled in Chapter 2) Now manually set the variable to 1, it will change to 6 almost instantly, then about 5 seconds later it will be 1006. What happaned? 1+5 is 6... the wait had just begun when the ISY Re-evaluated the IF statement, its now false so the current wait ends and then else begins to run.. where we wait 5 seconds just to be able to watch the variable change. --- Chapter 3B: now disable the program again. Set sTest to 1 again... note that it doesn't automatically increment to 6 at this time... then run it manually. it will increment immediately to 6 and after 1 minute the value will be 106. In this case Else never runs.

Also tell us what kind of motion, I assume insteon battery powered.... But i typed a long answer to someone once and it turned out there next post was "except it's a ____ motion and none of that makes sense." typical simple motion/light program is something like: IF Motion is switched on (hint: use CONTROL in the dropdown, not STATUS) then Set 'light' on wait 5 minutes set 'light' off else (nothing) if the motion is re-triggered during the wait, the wait will be restarted. But there are many variations based on how you actually want the automation work.

From your post 3 posts up it sounds like your ethernet port might have taken a hit... if a 994 does die that's probably why... the ethernet port took a hit.

@tmorse305 the reason node servers don't auto upgrade anymore is so that your installation won't break if it gets restarted for some odd reason... {picture yourself on the beach in Mexico with a nice cold beverage in hand and the power goes off at home, when eisy restarts if it upgraded to a node server that doesn't work correctly it will just not work right until you get home. The logic is if the current version is working for you then don't potentially break it with a software update.}

@Kevin N to illustrate the above here is a test situation you can create. First create a State Variable called something like sTest and leave its value at zero. Now create a simple program: If $sTest = 1 then $sTest += 5 Wait 1 minute $sTest += 100 Save your new program and then go back to the State Variables page (yes it must be a State Variable for this demonstration), Manually change the Value of the variable to 1. Notice that the value immediately increments to 6 as expected, but the wait never completes and it never becomes 106. Chapter 2: now disable the program. Set sTest to 1 again... note that it doesn't automatically increment to 6 this time... then run it manually. it will increment immediately to 6 and after 1 minute the value will be 106.

That is a default program that was included when 994's shipped. It's apparently no longer included, and as i mentioned above some people like having it, some people don't like it. I've personally always used it and not had problems. The purpose of it, if the ISY gets out of synch with the actual state of a device, the query all will bring it back in synch. You need to study up a little on how Programs work, although I explained it above let me try again. This program: will never finish. Here's what happens: When the If is evaluated True because both Sensor and Relay are both OFF, the first thing that happens is the relay turns on. Because "wait" or a break in the program is next the program will stop, because the IF was re-evaluated -- the wait 20 second will never complete and the set relay off will never happen (at least from this program, you might have another program that's misfiring because you don't understand how If's are re-evaluated constantly). To fix this program you can use the two program example I provided above. If your intention is this program is being called from the portal you can also likely simply disable this program and it should still run from the portal (I've never tried that tho actually). Disable only disables the auto sensing functionality of the IF statement... it doesn't prevent the program from running when run from another program, or run manually, so likewise the portal (Alexa) should still be able to run the program.

eisy is your only choice, unless you buy Polisy on the secondary (ebay) market. Polisy components became unavailable. eisy is faster and has more memory than your 994, other than that it works pretty much the same way. Also 994's rarely die... I'd try a new wall-wart and/or new MicroSD card. The power light can be on, and it can still be a bad power supply... You can try any power supply that outputs anywhere between 5 volt and 30 volts,center positive, 2mm barrel connector.

sudo asks for the password once every 15 minutes, or better stated, after 15 minutes of sudo inactivity password will again be prompted.

@ryan.mercer Good to hear you got it figured out. FYI for the future tho... Tools > Error log is another place with helpful information. Admin Console > Tools > Error Log

What's in the error log at exactly that same time stamp? .

You're not supposed to need to do that. The magic has always worked well for me, we have many echo's. Apparently the feature is called Spatial Perception, it's always worked well for me, here's a thread.

As pointed out 3am is the time the default Query All program runs. Lots of debate on whether this program is needed or annoying. I personally use it, it does however stress the Insteon network and use a lot of a 994's processing power... especially on larger installations. Are you using two different Amazon accounts or something? I have echo devices all over the place, and yes sometimes multiple devices wake up on the wake word, but they manage to figure out on there own which one is hearing best and the others click off and don't execute. If the 'sensor' detects when the door is open it appears that it really opened much earlier at 9:14PM, or is the sensor inverted? Keep in mind that statements joined by an AND mean 'at that moment', and keep in mind that either CHANGING will trigger the possibility of the program Running. With garage doors is somewhat problematic because the sensor status doesn't change in one direction until the door has travelled, in the other direction the sensor will change almost immediately. The other problem here is the program itself running is causing the program to retrigger. In other words, if the IF triggers the program and then begins to run, the very first thing in the program is to change the Garage Relay's status.. WHICH causes the program to STOP and STARTOVER. to protect the body from the IF you can use the classic two program method... If Sensor is off AND Relay is off then Run Program 2 (then) else (none) Program 2 (disabled) If (none) then disable program 1 turn on relay wait turn off relay enable program 1 Program 2 is always disabled. Disabled program do run when run by another program or run manually. Program 2 is also disabling program 1 while it's running to protect from being restarted by a re-trigger. I'm not entirely sure how you have this setup so I'm having a bit of difficulty following how your program is supposed to work, but it's failing because it gets re-triggered as soon as it starts running.

I'm going to assume that the use ISY portal box ended up checked. I don't use android, I'm going to ask the moderator to move this over to UD Mobile as this appears to be more of a UD Mobile issue than an eisy issue.

@rick.curl it’s unclear if you are using the ISY portal or forwarding ports. You don’t need both. If you have portal use that and you don’t need to forward any ports to ISY.