MrBill

it's not a bot, but it's definitely a pre-spaming spammer post... that's why I asked one invalid question along with some he probably can't answer ?

That's odd. Which model controller? What software version? Is the node turned on or off? what error message are you getting, it can't be the one shown above, that's something else.

Before I wrote yesterday I scanned the nodeserver list.... I missed Ping (it's not one I use), that's likely exactly what you're looking for.

I'd still put something in the ELSE of the last program in the daisy chain.... In theory you will never see that message, but without it you could in theory miss an event if something weird happen to the user. You could include the ${sys.node.XXXX.YYYY} replacement for the user number just so if you ever do see it, troubleshooting is instantly easier.... The end result of an empty ELSE at the end of the daisy chain of users is that Murphy Law will apply when you desire it least.....

As I recall you have Polisy, you could note that wireless tags aren't updating AND something else isn't updating or some combination and the program could perhaps assume that the internet has disconnected, but maybe that only means Polisy froze up (which doesn't often occur). Maybe tell us more about why or what programs need to disable and there might be a better answer? There's also another route you could take... it's not cheap tho, I use a Ubiquiti Edgemax router with a failover Wan... if the cable internet goes offline it switches over automatically to an LTE modem. I don't have a backup plan for if that connection fails also, but so far it's never happened and if conditions are such that it did we might want to put our head between our knees and prepare to .........

@mangoIf you didn't think of it, I would recommend you create a NR for "user unknown" and fire a notification using it in the last Else at the end of the daisy chain of users. Without it, if for some reason there is not a user match, there is no notification.

Thinking about this more, the double trip likely comes anytime the user number is changing. When the same user that last operated the lock the User isn't changing. If both change you get the double.... Implementing as I suggested above should resolve the problem.

The problem is that both conditions are Status, any status change causes the program IF block to be re-evaluated. The double notification likely comes when one updates before the other, but not when the other updates before the one. One way to solve the issue (Disclaimer, someone else might have a better idea.. I'm flying a bit blind because I don't have any z-wave....or locks...) is to use one program to catch the trigger then send it through a series of DISABLED programs to catch the user.... If 'Front Door / ZW 002 Front Door Lock' Status is Locked Then Run Program 'Door User 10' (If) Else - No Actions - (To add one, press 'Action') ------------------ [Door User 10] Locked Guest - (DISABLED) If 'Front Door / ZW 002 Front Door Lock' User Number is 10 Then Resource '[FrontDoor U10] Locked Guest' Else Run Program 'Door User 11(If) ------------------------------- etc.... so the First program is enabled and it catches the lock or unlock... then just daisy chain together a string of disabled programs to figure out which user it was..... If you're not familiar, a disabled program will still run when called by another program, it however won't run itself based on the conditions in the IF statement changing.

Post your ISY program, click the name in the tree, then right click it and choose copy to clipboard, then paste it into a forum message.

I guess I am missing missing. I should have said:

Just email support@universal-devices.com they will fix you up. I’m pretty sure adding that two years for a polisy is a manual entry. Some users have multiple ISY’s, there would be no way to guess which account should be credited.

Scene editing did change a little bit between v4 and v5, but not substantially (except a ‘copy’ button for scene attributes). I suspect your problem is that you don’t realize there are multiple places to configure the scene attributes. The root level of the scene (when you click the scene name itself on the tree) are the scene attributes when the ISY (admin or program) is the controller. Now click each red controller name, these are the scene attributes when the selected controller is used to activate the scene. Check each controller to ensure the attributes are configured as you expect the scene to operate. This is actually a great advanced feature, scenes can behave differently based on which controller was used. For all off did you also change the button attributes to non-toggle off only?

With @Brian H's comment, the two programs below should work. If 'Fireplace-Sensor' shows up in the 'control' menu, I'd use that rather than Status for the first line of the If. If Status 'Fireplace-Sensor' is On AND Status 'Fireplace-Relay' Off Then Set 'Fireplace-Relay' On Else (nothing) If Status 'Fireplace-Sensor' is On AND Status 'Fireplace-Relay' On Then Set 'Fireplace-Relay' Off Else (nothing)

I'll have to let someone else give you IOlinc advice.... I don't use that item. I also probably wouldn't have used the iolinc for the fireplace. I typically just use a relay with a 120v coil and have a ON/OFF module turn the relay on or off. At my house I wired the relay in parallel with the wall switch so that flipping the wall switch would still turn on the fireplace (since it's millivolt this provides means to turn the fireplace on during a power outage). At my son's house his fireplace the fireplace won't work without AC power, so they chose to have me wire the relay in series so that they could use the wall switch as positive off during the summer etc). You're program as written won't work using the IOlinc because you're using a momentary switch, but as I said I'll let someone else advise since I don't actually use that product. By the way... the fastest way to paste programs into the forum is to click on the Program name, then Right click and choose Copy to clipboard. then simply paste it (control-v on windows) into a forum message. good luck.

I actually didn't understand your program the first time, but I just didn't spend enough time, it does seem to be an elegant single program solution. I can't think of the exact instance but I've had to add the wait... It may have been my goodnight routine that is long and has many Insteon, a few Network Resource, and at least one run another program in it, the problem was debugged years ago and I don't remember which item didn't run but adding a wait before resetting the variable solved the issue. whatever works the 10 second wait doesn't create any overhead......

hmmmm, i didn't have trouble.... https://products.z-wavealliance.org/regions/2/categories/10/products?company=731 https://products.z-wavealliance.org/products/2893 https://products.z-wavealliance.org/products/2583?selectedFrequencyId=2

The problem that the original programs in this thread solve, or the reason we need to programmatically know if a DST shift has occurred is because looping running programs stop when the time shifts and needs to be restarted. Typically such things as wireless sensor heartbeat programs that have 'wait 25 hours' as a program statement...etc... I had loaded the TimeData nodeserver once before but deleted it shortly there after because the ISY already calculates sunrise and sunset that is enough for my needs One reason to use the the original @kclenden programs might be that you don't want the overhead of a nodeserver for just a single DST flag. The ISY updates the Sunrise/Sunset tables once a day and I'm not sure why I would need a nodeserver that does it every hour instead. Meaning that my sole reason for having the nodeserver would be the DST flag. I see that the nodeserver also provides for a shift in season (Spring, summer, etc) but I don't use that programmatically in anything. I think you would need to use this in conjunction with a program and variable to avoid runs during restarts etc. If 'Nodeservers / ISY Time Data' DST is True And $iDSTFlag = 0 then ...do whatever Wait 10 seconds $iDSTFlag = 1to $iDSTFlag Init =1 And If 'Nodeservers / ISY Time Data' DST is False And $iDSTFlag = 1 then ...do whatever Wait 10 seconds $iDSTFlag = 0 $iDSTFlag Init = 0 the wait could probably be 1 second but i usually use at least 10 when changing a variable that was used in the IF statement of the same program. The first program by @LFMc above that runs at 3:00:02 two problems that I perceive..... First, the time should be greater than 2 seconds after the shift...Why? The program runs based on ISY time.... if polyglots time is more than 2 seconds different the shift may not yet have occurred, so 3:02:00 would be a better choice. Second, if we are restarting critical programs 3:00 is 2 hours after the "fall back" time shift. That might be fine for most programs that are in an infinite loop, but it might not be too. For example: something that might be running a pump for 1 minute every 15 minutes and might need to be restarted sooner.

in a single google attempt, second link clicked I found this manual. On page 20 it says: I wouldn't necessarily assume someone from this community has that thermostat either.

I think every time I've chased the error down its been http timeoute. Repeating tho that's always NR/ISY failing... I think the largest problem is in disappearing Pushovers is internet related... resulting in timeouts because 1) my crappy rural connection drops packets... 2) pushover hick-ups.. and doesn't respond 3) other internet related issues where a human user would just hit retry. in other word, lack of response code.

are you trying to access the WAN address from inside or outside the network? The part that I bolded makes me wonder if you inside using the WAN address. If so your old router likely made use of 'hairpin turn' or 'hairpin NAT' allowing you to test from your local Lan using the external address and the new doesn't. If so. try testing from a connection outside the LAN. Other trouble shooting thoughts. 1) Use a port scanner like ShieldsUp to make sure port 443 is open. 2) verify the local IP is of the ISY is the same that you forwarded to. 3) verify your WAN IP by asking google "what is my IP" 4) Be certain your external IP is route-able.... I haven't heard yet of a case where spectrum assigns non-routable addresses us GNAT or Carrier Grade NAT but more and more ISPs assign residential customer GNAT non-routable IPs (usually 10.x.y.z something) especially to new customers.

The forum never flagged your Monday post as new for me, I just saw it for the first time now and it's below the unread replies line-- weird. I don't know what the node server sends because most of mine aren't using it yet, (i still have more network resources than I do node server.) when the ISY fails to send a network resource there is usually a corresponding timeout in the ISY error log. The problem is it's hard to recreate failed to send or I would do it just to find out. I don't know for a fact but it would seem like HTTP 200 OK would be success, anything else could be considered fail. pushover's API documentation disscusses error responses here: https://pushover.net/api#response As such it would seem, that 200 is good, anything in the 400's is bad, and of course http timeout is bad. I'll work on adding any thoughts to the github issues this afternoon.

Since your on V4.9 I'll go ahead and give you the next steps before you answer. Put each of those devices in linking mode (push the button in each device until the light blinks) and get the admin console to write those currently queued writes... we want to see the normal Icon's for the device and not the grey 1010's your seeing now: That should solve your problem... if it comes back from normal usage (not an admin console change) then we need to further discuss the "adjust scene" question. I suspect getting those instructions that are queued written out to the device will solve your problem. In the future anytime you see one of the little gray 1010 icon's you need to get the device into linking mode so whatever is queued can be written. The reason I asked the Pro vs Standard question is with pro, there is an extra button on the ribbon that lets you tell the ISY "Hold on to those and don't try to write them" with the standard version you just need to get them written to the device.

Yes, I use it quite frequently. Click the program name in the tree then right click it and select Copy. Rename the program and edit as needed..... Speaking of editing... I'm going to revise my post above... in the first program i did no wait time, I'm going to revise that, to get the first program away from bouncing on a switch being turned off..... that requires bumps to the other 2 wait times as well. Editing above now...

There was a bug that I don't believe ever existed in version 4.x. (so it should not be the problem here) It did exist in V5.x releases for about 2.5 years but is fixed in the most current releases. You missed one question, are you using "adjust scene" in programs?

No errors there. But I note that you have some wireless sensors that the ISY is attempting to write to. Before going further here, what version firmware are you using? (Help -> About) And do you have programs that use 'adjust scene' that include those door sensors as controllers? Finally it appears that you don't have z-wave is that correct? and that you're using the non-pro version of the ISY software? correct or false? The specific suggestion will make depends on your answers......