PLCGuy

Hi Javi Thanks for such a detailed reply. For some reason the forum didn’t inform me of your reply but now that I’ve seen it I’m going to try it out, especially your idea for the variables.

Hi Inspired by Javi's cool idea "Favorite Custom Toggle" in the UD Mobile Wiki, I started trying to develop a full-fledged lock management strategy for UDMobile and the EISY. In particular, the last comment in the sample logic "This is a simple example, a real installation should include checks for things like door open status" really seemed to throw down the gauntlet - it got me thinking about what a "Real Installation" should achieve. The following is my effort to date - I thought I'd throw it out to the UD community to critique and suggest improvements. First, what are the requirements for a "real" lock management system? Assuming the system is using Z-wave smart locks and an ELK alarm system for door status, these were the initial requirements that I came up with: Users should only be able to lock a lock if the door is closed. Users should have full visibility of the lock's status in a single lock object on the Favourites tab. The typical user will only work from favorites and there should be no need to for them to click around to other screens or objects determine status - it is best if it is all visible in one "Lock Object". At a minimum, users should be able to determine with a single look at UD Mobile Favorites if a door is one of the following states: closed and locked, closed and unlocked, open or in a trouble/fail/dead battery state The battery level should be displayed on the Lock Object, as that will impact the ability to lock It should be efficient to program and operate. (I have quite few locks, so I don’t want something that requires ten programs for each lock.) Q1: Did I miss anything? Assuming I didn't, achieving Req #1 was easy. I just added an AND condition to the If statement in the Lock Toggle program to check if the door was closed (aka “Normal” in Elk Alarm speak). Here is the revised version of Jari's program: Toggle KtchDr_Lock - [ID 00A9][Parent 0019][Not Enabled] If 'Door Control / ZW Locks / KtchDr_Lock (ZY007 Door Lock)' Status is not Locked And 'Alarm / House Alarm System / Kitchen Dr' Logical Status is Normal Then Set 'Door Control / ZW Locks / KtchDr_Lock (ZY007 Door Lock)' Lock Else Set 'Door Control / ZW Locks / KtchDr_Lock (ZY007 Door Lock)' Unlock // This program must be disabled or every time the KtchDr_Lock is unlocked (not Locked) the KtchDr_Lock will lock. // The status is "not locked" as there are multiple status values such as "unlocked", "locked", "Jammed", and "unknown". // Door open status must be Normal (aka closed) for the KtchDr_Lock to lock, otherwise it will unlock. Req #2 has been more of a challenge as displaying states that rely on more than one device requires using variables as flags. In this case I wanted to combine the door status from my Elk with the lock status from the Zwave lock. I'd hope to write a simple program that would mathematically combine the integer values coming from these two devices into a single door status variable. Maybe something like tghis: 0= Closed and Locked, 1= Closed and Unocked 2= Open 3= Trouble Unfortunately I wasn't able to dream up a math function to generate such a status variable because the Elk reports door status as: 0= Normal (aka closed) 1= Trouble 2= Violated (aka open) 3= Bypassed While the Yale lock report lock status as: 0= Unlocked 100= Locked ?= Jammed Instead I wrote a program that mashes together boolean logic with math operations, which IMHO is rather inelegant. This program checks if the door is both closed and locked and if it is, runs the Then branch to set the Door_Flag to 0. Otherwise it sets the Door_Flag to 1 if the door is closed and adds door status - the lock status is ignored in this case (which is a bit ugly). The flag is interpreted as follows: 0= Closed and Locked, 1= Closed and Unlocked, 2= Trouble and 3= Open (lock status unknown). Here is the program: KtchDr_Door_Status - [ID 0022][Parent 0021] If 'Alarm / House Alarm System / Kitchen Dr' Logical Status is Normal And 'Door Control / ZW Locks / KtchDr_Lock (ZY007 Door Lock)' Status is Locked Then $Ktch_Dr_Door_Flag = 0 Else $Ktch_Dr_Door_Flag = 1 $Ktch_Dr_Door_Flag += 'Alarm / House Alarm System / Kitchen Dr' Logical Status // The program checks if the door is both closed and locked and if it is, sets the Door_Flag to 0. Otherwise it sets the Dr_Flag to 1 if the door is closed (0) but unlocked (1+0) and 3 if the door is open (1+2) - the loock status is ignored.. // The flag is interpreted as follows: 0= Closed and Locked, 1= Closed and Unocked 2= Trouble and 3= Open (lock status unknown) // FYI Door Status values from the Elk are 0=Normal, 1=Trouble 2= Violated and 3=Bypassed. Then I headed into UD Mobile to build the Lock Object in Favorites. It took Javi's configuration design and pointed it to the Door_Flag, rather than the lock. I also had to adjust the Advanced Configuration Status to display the Flag. This is the configuration and the end result: It works pretty well and my family is happy with it. However it has some serious limitations: It doesn't display the battery level of the lock. It neglects all the other door and lock status info, which I'm sure will cause me trouble one day. The icon doesn't change because I couldn't find a representative icon for a smart lock that might indicate the various states. Yes I tried using the open and closed padlock symbol, but it just confused everyone. @Javi - please add more door icons or let us load our own. For example, sliding door icons in an open and close state would be very nice. I'd really appreciate any feedback and improvements to this design. If anyone can solve the missing features in an elegant way or come up with a clean math function I'll send you the $10 Starbucks gift card sitting beside me on my desk 😀

Yes - almost identical. Now what is really strange is the Elk Node has now reconnected and seems to be fine. The only changes I made bbefore it started working again was: a) to upgrade the packages on the EISY, which necessitated a reboot. But I had tried a reboot earlier. b) to change the user name on the EISY admin account name from Admin. But I assumed that the Elk Node would not care about the EISY admin account - maybe it does. And I subsequently changed the name back and it doesn't seemed to harmed the connection this time. Either way, the system is working well now, but I'm not a whole lot smarter Thanks for reach out!

I did - maybe I'm missing the obvious, but other than the host IP address (which is correct) there isn't any setting in there that I can see that could cause the Elk Plugin report "Disconnected". Interestingly, it seems that the logs are also failing. When i try to get the log I get this message "File not found: /var/ployglot/pg3/ns/00221b9026077_5/logs/debug.log Any troubleshooting ideas? I suspect this is a trivial fix (as nothing much has changed), but without logs or any other settings I'm a bit stumped.

On the weekend i replaced my decade old Apple Airport Wifi mesh system. All IP addresses remained the same and the transition seemed to be flawless. Then 48 hours ago the EISY lost contact with my Elk system. All I can determine is the Elk Plugin report "Disconnected" when I view it in the Polyglot 3x console. Frankly it has been so long since I set this up, I don't even remember where to enter the Elk's IP address in the NodeServer. What are the troubleshooting steps I should be following to solve this? Thanks.

Oh... That is the way it is now. All five of my 2634 outdoor modules are in "Lighting / Exterior / Xmas Lights Scene". The other scenes in my example program are controlling other Insteon devices (mostly 2477S and 2477D) and doing a great job of it. That is the weird part - other scenes with 2477S and 2477D devices (on the same leg of my panel) work great with a single command. As long as my program repeats the command for this scene to turn on several times, eventually all the modules turn on.

Thanks JEC6613 for these suggestions. I'll try them and report back. Hi Lilyoyo1 - did you mean I should create five scenes, one per module? I certainly can do that. I could also just delete scenes all together and send commands directly from the programs to the modules. It's a bit more verbose, but I'm no longer using scenes controlled by physical Insteon controller devices like push buttons. My KPLs have died over the years and now the EISY, ELK and UDM controls almost everything, so I only use scenes to organize devices (as shown in my above logic example). If that is a bad idea, I can delete them. Would it be worthwhile to just delete all the modules from the EISY (I assumes that would also delete them from the PLM) and then factory reset each module?

I hate to add a another topic to the Insteon Communication Issues thread, but I have a problem with my five Outdoor On/Off Modules (2634-222 V.43) this Christmas that is new to me. The problem is that I have to turn the scene these modules are contained in on multiple times before they all are actually on. Turning them off via the scene also has the same issue - at least one module will be skipped each time the scene command is executed. For the past decade, I have had all the modules in a single scene called Xmas Lights Scene that is turned on every night a sunset (along with a number of other scenes). It is a very simple program and it works flawlessly with the other scenes. It has also worked every year until this year. The modules are also plugged into the same outdoor circuits that they have been plugged for ten Christmas seasons. 2 Evening Program - [ID 000A][Parent 00A5] If $State_Schedule is 2 Then Set 'Lighting / Exterior / Upper Patio Scene' On Set 'Lighting / Exterior / Ocean Patio Scene' On Set 'Lighting / Exterior / Xmas Lights Scene' On Else - No Actions - (To add one, press 'Action') Turns ON all exterior lights at sunset when $State_Schedule is set to 2. What has changed is that I've replaced my PLM with a new rebuilt unit from Insteon and upgraded from ISY-994 to EISY (IOX v.5.7.0). Any thoughts on how to resolve this? Currently I just run the same program several times, but that is hardly an elegant solution.

Hi SteveB I've been having exactly the same issue with my Elk Node Server so I strongly suspect that this is PG3 issue and not an issue with the individual node server plugins. Now my Elk NS actually started to work correctly on the weekend after several attempts at reinstalls from the PG3 portal and at least 3 reboots of the EISY. I'm unsure exactly what got it working in the end but it might have been a "Restart" from the Elk Node Server Details page immediately after a Reboot of the EISY. I definitely did not have any luck deleting and reinstalling the Elk NS - it started working after a restart or reboot event. I also caught the issue before my trial expired, so don't blame yourself for missing the trial expiry date. That doesn't seem to be related.

Hi Dennis I see that @SteveB is having the same problem with his Ecobee Node Server So I strongly suspect that this is PG3 issue and not an issue with the individual node server plugins. Now my Elk NS actually started to work correctly on the weekend after several attempts at reinstalls from the PG3 portal and at least 3 reboots of the EISY. I'm unsure exactly what got it working in the end but it might have been a "Restart" from the Elk Node Server Details page immediately after a Reboot of the EISY.

Hi I just noticed the following ELK Notices message on my Elk PG3 dashboard: "The subscription for this node server will expire tomorrow" Now after testing the Elk Node Server in my new EISY, I fell in love with it and purchased a subscription last month (Order 3HD38148JM4462532). What step have I missed to get the purchased version installed and the trial version disabled? Thanks.

Thanks everyone. I removed the KPL and wired it to a line voltage pigtail. It appears to be toast. .

Thanks but that is exactly what I want to avoid. As I noted in my question, “every time a new tradesperson needs access to our home, I spend at least a half hour manually loading in the new access code into the locks and the ELK”. So resetting my six locks and then having the approximately two dozen users re-enter their access codes in each lock would be a wonderful way to waste a few days of my time. I want to manage the various users, not start all over.

I have an old Insteon 2486D KPL in an area that recently underwent some renovations. Now my EISY won't connect to it. I noticed the electrician never connected the red load wire, which makes sense as I don't think it was connected before - I can't think of a light the KPL might have controlled directly. However maybe it was connected - can a KPL work without a load? If so, what should I do with the red wire. Just cap it off?

I have a half dozen Yale Z-Wave locks and an Elk M1 Alarm System which has been installed now for about decade. While the system works well, one of my ongoing frustrations is trying to coordinate the Users and User Codes between these devices. Every time a new tradesperson needs access to our home, I spend at least a half hour manually loading in the new access code into the locks and the ELK. Plus, with a decade of adds, removes and changes, I'm sure the user numbers and codes are an inconsistent mess across these devices. So I was wondering if anyone had any ideas on how to programmatically manage users across these devices. Even a way to dump the list of user numbers and codes from all the Z-Wave locks would be nice. Bonus points for a way to assign user name strings in the EISY - I haven't noticed any options for assigning string variables in the EISY. Any suggestions are greatly appreciated.