hart2hart

Smooth update to 3.1.36.

Thanks for the information. I’ll be updating tonight. Are the correct steps and sequence? Upgrade packages Power cycle eISY to get full reboot Reinstall all node servers Restart node servers

It may not be relevant but just more information… you might use a state variable if you Disable the program as first step Set the state variable Enable the program

I’m with you. Maintaining codes from native app is fine and I’d likely never do it from eISY.

The support of UD and this community is world class. It may not be your favorite pick up the phone for every little thing. You get direct support of product creators as requested and the community is very responsive at providing a “simple answer” very fast.

Thanks @Goose66 for looking further. It appears we could meet a lot of needs with this api. I see lock, unlock, manage access codes, and event notification like when it’s unlocked and by whom.

There was a Ring nodeserver that ran in cloud on UD servers that would have done as you described. That was discontinued a year or two ago. Today you need an eISY to run nodes servers and replace the ISY994.

Something went wrong with your original plm restore. That’s been fixed now but it sounds like the devices do not have links to the plm. By doing update device on each device now you will likely be good. I’d do a device at a time and confirm eISY and plm are seeing star changes.

Is 70.1A.92 the address on the back of your new PLM? It appears that when you transitioned between ISY994 and eisy that something lost track of PLM addresses and doesn’t know you’ve swapped PLMs. If PLM replace works it will write all device addresses to the new PLM and then move through each device and write the new PLM’s address to them.

Thanks for the deep dive. I’ve been loving the locks and wife appreciates the smaller inside footprint. I’d likely be happy using either method if the api goose 66 located will work for more integration. I actually added my two 300 series Schlage be469 locks back into service by putting them an inch from the zmatter zwave antenna and then once interviewed by iox moving them to basement and garage. Hi

Found answer in NS Document. Thanks

@DennisC it was the remote access you mentioned. I had turned it on and it showed enabled but had never connected. Michel coached me to go back and look again.

I'm ashamed to admin it but I had the lat and long reversed in the params so if you see these error messages...

I had the same issue and resolved it by loading from the LAN.

Thank you. I’ll always help test.

@Goose66 Great NS. I’d like to see a feature so i can disarm using multiple codes instead of just the one code that is in params. This feature would support sending the being forced to disarm code. Thanks.

Does NS support the Caseta ceiling fan switch?

Installed last week and working flawlessly!

Thanks and that is an interesting solution. At this point, I'm using these two programs to catch and isolate Armed status into a State variable. If the programs have issues, I'll try your solution. Security:Set Armed If ( 'Security System / Security System:Partition' Partition State is Armed Away Or 'Security System / Security System:Partition' Partition State is Armed Away Zero-Entry Or 'Security System / Security System:Partition' Partition State is Armed Stay Or 'Security System / Security System:Partition' Partition State is Armed Stay Zero-Entry ) And $Security_Armed is not 1 Then $Security_Armed = 1 Else - No Actions - (To add one, press 'Action') Security:Set Disarmed If ( 'Security System / Security System:Partition' Partition State is Ready Or 'Security System / Security System:Partition' Partition State is Not Ready ) And $Security_Armed is not 0 Then $Security_Armed = 0 Else - No Actions - (To add one, press 'Action') I have equivalent programs for Armed Away and Armed Stay.

Again, Thanks for the insights, Goose66.

Thanks for the insights.

Bob, thanks for developing and supporting the node server. I implemented it just ahead of the weekend as part of move from ISY994 and Polisy to eISY. Working great!

Goose66, thanks for another needed node server that is working well in first couple of days. Two quick questions: 1) Is there a form of Set Query for each thermostat (I have 3) to ensure they have most recent values from keypads? I've found this beneficial as we can make changes at the keypad and IOx will see the results and adjust accordingly. Form history though, they sometimes got out of date so I periodically queried each thermostat to keep all in sync. Is this feature this already there and I missed it and if not can it be added (or do you use techniques to keep them closer in sync)? 2) An additional issue is that sometimes a thermostat will lose WiFi. Other devices I have will signal through their iOS app that connection has been lost but not the Venstar thermostats. Looks like you have this covered- Thank you. Is this the Thermostat Online function.

Goose66, I moved over to EnvisaLink-DSC from NodeLink. Glad to report success and thank you for the NS as all went well, but following are three questions and a request to ponder: 1) Is Panel "Force Update" a form of Set Query to the NS to update all data elements? 2) Is Panel "Alarm Panel Connected" the heartbeat that NS and Envisalink are talking? 3) I have not created firewall rules and in fact my security system is monitored by Eyez-On. In my case, is there an advantage either way to the NS param disablewatchdog? Which way would you set it? -- Why? Request to Ponder) I have many programs that use the status of the security system. An example and there are many others -- for that at home look, lights are turned on and off at times based on is the security system armed away. A big difference between EnvisaLink-DSC and NodeLink is that NodeLink represents panel status as Armed Away, Armed Stay and Disarmed so there was little traffic related to status changes. Envisalink-DSC has the armed statuses (with zero entry variants) and the very accurate Ready and Not Ready (vs Disarmed). I've got several interior motion sensors in the security system. The result is that every time you walk around, they turn on and then off. Given my setup, this translated to high volume of programs triggering (even if false) as the status changed usually between Ready and Not Ready. The result was multiple Random all on events an hour after I updated the NS dependent programs and restarted the node server. As I was converting the programs, I was a little concerned at the number of programs using the armed away construct as the list had grown over multiple years. However, I thought (wrongly) it had worked for years and I felt/assumed it would work with a different node server. When it quickly happened a couple times, I realized something was structurally different and isolated it to the status changes and how many/how fast they were occurring. I isolated the rapidly changing statuses to 3 programs that set integer variables (simple example below) and updated all the programs to use the variables as the programs real triggering event (except for one as we will see) was the other part of the If and the security status was secondary. The restructuring stopped the random all on events. Security:Set Armed Stay If 'Security System / Security System:Partition' Partition State is Armed Stay Or 'Security System / Security System:Partition' Partition State is Armed Stay Zero-Entry Then $Security_Armed_Stay = 1 Else $Security_Armed_Stay = 0 I quickly made several program updates to stabilize my lighting setup. However, by doing this, I could no longer see and diagnose the issue looking at the actual problem. However, through a review of text file of all programs (supported by a log and event capture), I isolated the source of the problem to one program being triggered on both the true and false side. The program was only updating a scene and a device but the number of times it was occurring and likely the much faster speed of the eisy executing the event translated to random all on events. I'll restructure that program, so it is only triggering a couple times a day and put Wait between the scene and device updates for when it does occur. The ponder moment is -- could another status be maintained by the node server that only presents armed and disarmed so this kind of "hidden" event is less likely to occur for me and others? Finally, I really like the new setup and thanks for the hard work to develop and support. Paul

Thanks Bob. I’ll look forward to the update.