mango

MrBill you are being most helpful thank you. I am not local to the ISY at present. It's simply a case of formatting, and probbly something very simple that I am not understanding. One of my locks is ZW002, so for battery level my command would be: ${sys.node.ZW002_1.BATLVL} From memory the body line consists of: token=x&user=x&message=x Where and how do I place 'Battery Level = ${sys.node.ZW002_1.BATLVL}' ? Everything I tried last night resulted in a TCP400 error and the message could not be sent.

Sorry another question: Is there a trick to adding ${sys.node.ZWXXXX.BATLVL} to the body of a pushover resource?

so...I have 6 physical user numbers including guest, but I also need to add user 0 for times the door is locked manually from inside or without code from the outside (pressing the Schlage button). Each user requires only 2 notifications, unlock and lock. I could further develop the project with lock jammed and unknown (Z-Wave comms error?). Is there a battery level node?

I have already used the copy function wherever it may be, thankfully. So, having lots of network resource entries has no impact on the ISY other than taking up space, correct? An entry is only called into being to run then put back freeing up resources once more?

Thanks both. I only have 6 possible users including guest so I may go with @MrBill 's suggestion. This I assume should also allow me to assign separate pushover icons per user which may be visually a plus. Coming from the land of BASIC programming many moons ago....

Hi all, Please go easy with me. Some of this is way over my head. Having recently installed some Schlage BE469 deadlocks, I have been able to setup pushover and email notifications for doors locking and being unlocked. I now want to display the user and am having difficulty making sense of how to go about it without creating a large bloated mess. Last night I've realized I may be able to do this very cleanly with the use of the correct variable syntax, but I am unsure how to apply this: ${sys.node.ZW###USRNUM} would return the correct user number. How would I convert user numbers to actual names? Any tips and hints gratefully received.

Thank you.

Perhaps a factor, but not the reason. Go back in time and you can plot the demise, prior to any global excuse.

I'm a total outsider and all I can see is Instion oblivion. I mean, who can't?

I'll buy some shares.

Thanks for the reply Lilyoyo1. I am aware of tagging but don't like doing that on forums asking for help unless it is really important. I feel if anyone chooses to contribute or follow up they will. They don't need a prod in the backside from me ? Regarding zwave, it's a cottage address and right now I have good comms between 2 zwave locks and the ISY which is located roughly in the middle. No repeaters or any other zwave devices yet.

Hmm, I wonder if this was posted in the wrong forum. I posted here specifically to address any possible zwave nuances in programming, my apologies if so.

@all For me, hearing the issue seems to return after a random tweak makes it work indicates a faulty router. 2c. It should just work out of the box, ISY networking set to default and being DHCP, static or DHCP assigned.

I'm out of gas, sorry. Re-reading your OP, you say an Echo also stopped working? Then you may have to investigate the router in depth.

Turning on UPNP on both the ISY and the router may also glean some more gold.

The tplink AC4000 looks like a beast, wow. I can only assume the new router is doing some sort of blocking of the ISY from LAN to the WAN, as internally on your LAN it appears to be working properly. I would check there, maybe even open up a DMZ to test.

Have you tried setting it to DHCP to test?

Your HTTP and HTTPS ports should be 80 and 443 respectively. Also, change DNS to 8.8.8.8 (although 8.8.4.4 should also work)

Is there anything specific to zwave I need to be attentive to in programming (such as timeouts / retries / redundancy etc.)? My lock has appeared as 6 nodes - the primary for locking / unlocking / setting the codes, and then 5 what appear to be alarm nodes. Are the alarm nodes specific to separate alarm-type programming? I assume they are just state variables if they go off?

Hey Bill, Thanks this is the sort of thing I need. I understand your logic.

Zwave version: 6.82.01

Hi all, I'm a newbie to ISY Zwave and Zwave Schlage locks (moving from a Schlage Sense Bluetooth/IP lock). I am presently installing front and back door BE469s. I have attempted to search here for some inspiration on how to manage the locks. A few months ago I found some valuable resources with examples of programming, but now am unable to find anything. Would anyone have some programming examples to share for their setup? My goal is to have a front door KPL button say 'DOORS LOCKED' - for it to hopefully work as controller and responder - to light up when both doors are locked (door sensors showing doors are closed), and for the button to be able to lock both doors if not locked (sensors closed). Also I would like to use pushover (which I have just setup today) to log door activity. I think I have that one worked out.

Hi, did this ever get resolved? Using UI and Firmware 5.3 with a new BE469. Am unable to get options but lock is working. 6 Nodes showing.

Interesting thread all, thank you. I'm towards the lower end of the intellect here and usually just lurk and 'steal' (borrow / learn) ideas for ISY functionality. For that I thank you all. I am not a coder or programmer and am still fumbling with the basics of conditional logic. As a complete outsider to the Polisy debate I would like to offer my fly-on-wall take: I've been on the scene quite some time, started with X10 and enjoyed using the ISY99 when Insteon was on the up. Now I have two properties both with ISY994s and quite a bit of kit. It is Insteon, not UDI who are the catalyst for this issue. Insteon have failed in so many respects, in pretty much everything they do. A company that used to be a leader in the field has just shriveled up and is (in my view) continuing to slide lower into obscurity. The writing is on the wall. For those of you who have invested heavily into Insteon, keep buying up all the spare stuff you can and run your system(s) for many more years to come, but be understanding that it will come to an end. If UDI is to keep its head above water, it need not attempt to throw precious development time into supporting new Insteon products (I doubt any are coming anyway). It's pure economics. They will support existing kit and assign Insteon functionality to the Polisy. That's pretty much it.

Okay thanks!