MrBill

None of your nodes show because ISY on Polisy is a different ISY. BTW: There is no Z-wave adapter available yet for ISY on Polisy

@Michel Kohanim How is location/time zone being determined? Time is correct. Sunset is not. Sunrise is not. they should be: (this screenshot from ISY-994 and is correct.) There is no change location button. Also the City blanked out is a nearby larger metro area. My hope is that we will soon be able to use exact longitude/latitude as we can in the current production models. Is the Change Location button coming back?

Worked for me! Excellent. I ordered a 2413u for testing.... but it will be the end of the week at least.

@asbril See Michels linked post below. You need to manually add it to finder after you start ISY launcher:

Run ISY launcher and see if you have a new entry in finder..... (mines is the 4th line...) then open the admin console on that one if you do.

I agree google is better at searching this forum.

to paste code, right click the program name in the program tree, and select Copy to Clipboard. Then click into a post and either just hit Ctrl-V (paste) or click the "<>" symbol in the toolbar first, and then Paste into the 'code' window that pops up. I believe your problem is as I alluded to here: and apostolakisl also mentioned If the status of the door changes during the wait, then the program will stop and not finish. The method to get around it is to use two programs (and there is two choices there as well) Program checkfrontdoor If frontdoor is violated then run program frontdoorviolated (then) else (nothing) Program frontdoorviolated (disabled) If (nothing) then turn on entry light turn on garage light $GarageEntry=2 wait 10 minutes $GarageEntry = 3 turn off garage light turn off entry light $GarageEntry=0 else (no else) In this program, the end will be reached if the door becomes no longer violated while the waits are running. However if the door is re-violated during the wait the program will start again from the top. One more version: Program checkfrontdoor If frontdoor is violated then run program frontdoorviolated (then) else (nothing) Program frontdoorviolated (disabled) If (nothing) then Disable checkfrontdoor turn on entry light turn on garage light $GarageEntry=2 wait 10 minutes $GarageEntry = 3 turn off garage light turn off entry light $GarageEntry=0 Enable checkfrontdoor else (no else) In this version we added the disable and enable to the then body, this will cause the first program to ignore more violations until the second program finishes. The second program should be always disabled, disabled programs still run when told to by another program, but not because the condition in the IF statement became true.

This forum allows sections of the Front Page to be collapsed... the problem is only the everyday users/power users would understand that, the casual user or consumer of information would never figure out where to look. If I was the admin, the only set of boards on the front page that would be collapsed by default would be the archived/read only section at the bottom.

see Michel's post in the thread below where I asked that question. You should open a ticket with UDI concerning that, I suspect there might be a timeout that you're hitting based on the size of your z-wave network. (very similar to what happened with Home Assistant after you upgraded to 2021.6 --Since @Javi had a thought in that thread that lead to the solution he may here also.)

I've yet to ever see a forum with that many sub-topics displayed on the front page. The casual user would be lost. The front page would also portray a stagnate community to the casual user. One (10 year long chapter) of my life was professional community (forum) administration at a SV startup for enterprise level forums. At one point clients included all 4 major cell phone providers, several anti-virus software manufacturers, 2 major hard drive manufactures, several computer makers (choosing words to dance around an expired NDA that I usually honor anyway). A best practice that we preached was to eliminate sub-forums that didn't receive 3-5 new posts a day on the average. I don't know all the abilities of the forum software package but it appears to be fairly complex with untapped potential. I'd bet that indeed tags could be enforced in a node server support section, and select members could be deputized to assist keeping the posts tagged correctly.

112 today.... 224 in X amount of time... someday 500... the method is not scalable.

No one searches or looks for past posts due to the level of disorganization in this forum. After all who would go to a thread titled "Serial PLM discontinued according to smarthome" to find this post. I even suggested the same day: But typical for the disorganization found here, we've continued to the drag the original intent of this thread off-topic. Unfortunately properly managing an online forum takes a dedicated person and a fair amount of time. Pouncing on posts that drag a thread off topic and moving them to their own thread in the correct sub-forum. Conversely, pouncing on posts that have currently open topics and moving them into the thread they belong. Another "best practice" in support forums is to automatically lock threads without a new post in 30 days. This forum is all over the place, no one knows where to find anything. It also suffers from "too many choices", that is people can't guess the correct place to post because there are way too many sub-forums for the size of the community. Worse yet, some nodeservers have dedicated sub-forums and some don't, yet it would be a real mess if all 112 nodeseverves had their own sub-forum. I happen to agree with @whywork (although they actually didn't say rename anything) that reclassifying the Polisy section would be good... "Geek Batch" is outdated... It the equivalent of including the word "new" in a name.. time itself expires the title. However since that's really more about Hardware, I think Geek Batch should get renamed Polisy Hardware and OS, then immediately beneath that add the subforum ISY on Polisy. The problem with a new sub-forum named "Polisy Nodeserver" is that there is already an entire section named "Polisy Nodeserver".

Have you tried restarting the ISY? Next suggestion would be to check the error log (Tools > Error Log) and see if there are any clues there. Another question is what does the program do? Post examples... If any of the conditions change during the wait state, it will end the wait state. This is by design and not a bug.

To elaborate on versions people are spitting out.... 5.0.16C is the last ISY firmware version that works with a series 300 z-wave board. If your admin console has a z-wave menu, and Z-Wave > Z-Wave version = 4.55.00 then this is the version you need. You might also think about a z-wave upgrade board from UDI, with possible discounts base on the age of your ISY. If there is no z-wave menu at the top of the admin console, or the answer to Z-Wave > Z-Wave version = 6.81.00 then go to version 5.3.3 Be sure to read all the instructions. Generally upgrades go quick and easily these days, the exception is if your ISY Programs use "Adjust Scene", all of those programs will require a manual fix.

I helped someone else work this out, and I can't find the thread to link. the short answer is you need multiple daisy chained programs: Program: Door_is_unlocked If Status door is unlocked then Run program User_1 (if) Program User_1 (disabled) If access code is 1 then notification user 1 else Run Program User_2 (if) Program User_2 (disabled) If access code is 2 then notification user 2 else Run Program User_3 (if) .....and so on A disabled program runs if run by another program, but not if the IF condition is met. The problem with using 'ZW 003 Schlage Door Lock' User Number is 1' alone is that the user number doesn't always change, and to activate an If statement it needs to change.

log into https://alexa.amazon.com (from a computer browser) and delete every device and scene, then tell Alexa to Discover devices.

You just need to buy Pro upgrade. It's a soft upgrade, no hardware required.

ahhhh I see... anytime I try that browser I seem to have problems...

You sure? I have 5.3.3 installed on my no-PLM ISY and i just downloaded the file again: granted I didn't try to install that file but the LINK to download works.

Restore Device does work, or at least in should. How were you using it? Typically restore device is used after factory resetting a device to put the links back into the switch that the ISY thinks should be in the switch. Yes the GUI really needs some UX help. Fancy talk for they need to remove things that aren't used. And personally I'd use labels for each setting to the LEFT and move the SET button to the RIGHT side of the dropdown and call it SET or SAVE.

The write changes button isn't the answer anymore and the answer is not intuitive!! Set the dropdown on the RIGHT, then Press the button to the LEFT of the dropdown. In other words the buttons shown here are On, Beep, On Level, Ramp Rate, and Backlight. Yes those are buttons not just labels and Yes they act as the Set button for each parameter. Additionally there is a bug with Backlight. The dropdown starts at zero, that does not represet the current value set in the module. If we set this device to say 50%, the change will write to the device correctly when we press "Backlight" Now we move to another device this dropdown will lie and say it's 50%... It's NOT... it's whatever was last saved in the device. etc... Finally when the admin console is restarted the backlight will again show 0%, but that's not whats stored in the device. In other words you can accurately send values to the device using the backlight drodown and button, but they value displayed by the dropdown is never accurate unless you just now set the value. I really wish UDI would make this process more intuitive, and fix the backlight GUI bug, this is a repetitively explained in the forum.

Startup/UptimeCounter - [ID 008D][Parent 0126][Run At Startup] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Wait 9 minutes Resource 'ISY.Reboot.Notification' Wait 1 minute $iUptime.Counter.old = $iUptime.Counter.curr $iUptime.Counter.old Init To $iUptime.Counter.old $iUptime.Counter.curr = 10 $iUptime.Counter.curr Init To $iUptime.Counter.curr Run Program 'Start HeartBeats and Misc' (Then Path) Wait 5 seconds Run Program 'Startup/UptimeCounter' (Else Path) Else Wait 10 minutes $iUptime.Counter.curr += 10 $iUptime.Counter.curr Init To $iUptime.Counter.curr Run Program 'Startup/UptimeCounter' (Else Path) Wait 9 minutes to make sure the modem and router had time to recover (if this 'run on startup' was restore from PowerFail this delay is needed for the modem and router to come up before send a notification) then wait 1 min so notification goes out before counters reset (yes they reset too quick without a wait) I use this program. It's my only 'run at startup' program, although it runs others. Having only one 'run at startup' allows a tiny bit of load reductions at startup (see last paragraph for reason). The initial 9 minutes was to make sure the modem and router came back online first (although those devices probably never lost power). I initially was counting uptime in hours, but revised it to 10 minute blocks when I realized there should be a 10 minute delay in section (A). Traditional linux systems count uptime in 1 minute increments but 10 minutes increments were good enough for my purposes. Once the Then block completes once at startup, the else block loops forever. (in 5.x there is a repeat statement that could also be used but this program existed before that was available and this works just as well.) My systems fairly large, there are usually "UDQ queue full" errors on startup, I've found when manually restarting the ISY it works best wait for the reboot notification before starting the admin console. I don't think there is a method for the ISY to restart nodeservers yet. Edit to add: The date/time that $iUptime.Counter.old was last changed is also a handy reference point if you want to know when the ISY was last restarted without having to convert minutes to hours/days/etc then do calendar math... (yellow high-lite on the variables page shows the approximate date/time of the last restart)

yes... your ISY will have a unique long unique URL that looks something like this: https://my.isy.io/isy/77722bbbb555555069dba03f09795e63e57f02b6d7cbebebede80c0a22e334076 (I randomized that one) If used in a rest call such as https://my.isy.io/isy/77722bbbb555555069dba03f09795e63e57f02b6d7cbebebede80c0a22e334076/rest/nodes which will also require credentials, but unlike local rest calls its not looking for the simple local credentials, instead use your portal credentials. Edit to add: the unique url can also be used with the admin console remotely... Manually add to finder with /desc on the end. When the admin console opens with it's normal credentials request use your portal login credentials, the typical simple local credentials will not work remotely.

Yep... portal subscriptions are far more secure than opening your own ports and dealing with certificates.... the open port/certificate methods are really kind of out-of-date, but some people are holdovers that still use them and some people prefer them instead of cloud dependencies, and some people just plain refuse to spend on subscriptions (I'm in that camp most places... except UDI's because of it's low price point.) Start here.

Clciking Purchase modules should take you to an URL with www.universal-devices.com/my-account/?uuid=uuid: etc. Once there however it lands on "General" and you need to click "My Products" Just to make sure, its the admin console Help > Purchase Modules: EDIT TO ADD: I was already logged in to the UDI site today because I used the support portal (tickets) just a little bit ago. As I recall tho, the Purchas modules may not work right if you are not logged into your account on the website. Log into universal-devices.com then execute the admin console link to purchase modules.