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.

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 Geddy - I probably knew that a decade ago when iIfirst programmed my isy-994. I forgot that the partly green icon indicated the program was not currently running, but last ran THEN code. My bad...

I just migrated from an ISY to an eisy and have a very simple program that is triggered by a scheduled IF and is staying always True. You can see in the screenshot below that the time of day is 7:44:23 PM and the program is still true and has been since 2:00:00 AM. I've tried disabling the program, rebooting the eisy, etc and I always that the program remains true once it is triggered at 2:00 :00 am the next morning. I had expected the program to be False at say 2:00:01 am. Am I missing something or is this a bug?

Never mind... found the answer and all seems to be working well 😄 WaterLvlCalc - [ID 0012][Parent 0013] If 'Alarm / House Alarm System / KitchenKeypad' is switched F4 Then $ElkWtrVoltage = 'Alarm / House Alarm System / Water Level' Voltage Volts Wait 2 seconds $WtrGallons = 10 $WtrGallons *= $ElkWtrVoltage $WtrGallons *= $SlopeDiv10 $WtrGallons -= $Offset $WtrLvl = $WtrGallons $WtrLvl /= $GallonsPerInch Set 'Alarm / House Alarm System' Display Message $State_LvlCalc = 1 Wait 10 seconds Set 'Alarm / House Alarm System' Clear Message Else - No Actions - (To add one, press 'Action') Wait for a trigger to calculate cistern $WtrGallons (= 10 x $ElkWtrVoltage x $SlopeDiv10 - $Offset), $WtrLvL = ($WtrGallons / $GallonsPerInch), and then display the level on the Elk Keypad

Is there any way to take the voltage level from an Elk Zone and use it in an eisy math function? I currently have an exceptionally ugly set of IF statements in my old ISY-994 that has 100 variations of the following: =================================================================================== Chk02xVolt - [ID 0036][Parent 004D] Folder Conditions for 'Chk02xVolt' If Elk Zone 'Water Level' 'Voltage' >= 2.0 Volts And Elk Zone 'Water Level' 'Voltage' <= 2.9 Volts Then Allow the programs in this folder to run. ----------------------------------------------------------------------------------- Chk020Volt - [ID 0016][Parent 0036] If Elk Zone 'Water Level' 'Voltage' is 2.0 Volts Then $ElkVoltageX10 = 20 Else - No Actions - (To add one, press 'Action') Test if the Elk Voltage is 2.0 Volts and if so, set $ElkVoltageX10 to 20 (i.e. ten times the voltage) ----------------------------------------------------------------------------------- and so on... Is there a nicer way to do this in the esiy using the Elk Node Server?

I'm working on migrating from my old workhorse ISY944 to a shiny new eisy with the ZMatter Dongle. I have been stuck at 5.0.16C for a while because I have a 300 Series Z-Wave board, and while Michel was very generous in offering to help get me a loaner 500 Series Z-Wave board, I decided it would be simpler to do a restore from a 5.0.16 back up to the eisy and rebuild my Z-Wave network from scratch. Now I've completed a restore from a 5.0.16 backup to the eisy, and that went pretty well. And I was about to manually remove all my Z-Wave devices from my ISY994 and add each to my eisy. However, I noticed that all the restored programs in my eisy that reference Z-Wave devices are pretty much a mess. This is more of an issue as some are relatively complex, and frankly, I don't remember all the details of creating them (yes, I'm guilty of some pretty poor documentation in my old ISY logic). So, I was wondering if I could use the "Shift Primary to another Controller" option I see in the ISY's menu to move my old 300 Z-Wave network to the new eisy, or is that just asking for trouble? Finally, I remember using a text editor to do bulk edits to some 50 ISY programs about a decade ago. That could also solve my Z-Wave program migration challenges. However, I don't remember how I did that. Can someone remind me? Thanks

I really doubt that a regular USB-RJ45 console cable will work. The pinouts for the RJ45 on the 2413S PLM are non-standard versus what a typical RJ45 Console Port looks like. I've attached pinouts for both below:

Hi I'm using UD Mobile on an iPad running iOS 15.1 that is connected to a ISY-994 Pro running 5.0.16 firmware (can't upgrade because I'm waiting for my 500 Series Z-Wave board). I'm seeing a strange issue when I try to use Mapped Values Logic to Configure Colors for a Z-Wave lock in my Favorites. I will set the logic to use a state like "Locked" but when I save the app changes the state in the logic to whoever the state of the device is at the current time and not the value I entered. I've added a few screenshots of this below that show what I'm saving and the resulting colour logic immediately after (the lock in question is unlocked as I do this). If I lock the device, then the Mapped Values logic changes. Regards, Eric

The Phoenix Contact Pi enclosure is super cool. That is almost enough to convince me to try a Pi for industrial applications.

The trouble is, I do mind running a Pi for I/O management in a home automation system. IMHO, while Pi are fun for hobbyist projects (I have several), they aren't built for long-term 7x24x365 operation. The power supplies for the Pi get quoted with an MTBF of about 50,000 (which isn't very good), and MTBF data for the Pi itself is non-existent. Neither gives me warm fuzzy feelings. Now to be honest, my use case is a little harsher than most. We use home automation supporting the neighbour's water cistern systems. We also use it in our vacation rental properties to make our renter's experience more fun (and to stop people from trying to air condition the desert). But when core components fail, neighbours and renters are never happy and I'm 3000 miles away and can't help them. And the local electrician can't help at all. In fact, the whole reason I decided to try the MIMO2+ was because I was sick of replacing over-priced IOLincs that fail regularly. But adding a nodeserver to do basic I/O handling just adds another failure mode in an already fragile system. IMHO it defeats the vision for robust home automation. On the other hand, I've never seen an ISY fail (kudos to Michael and Team) and most low-cost PLCs come with MTBFs of 100,000 or better. So a combination of PLCs and ISY with no Pi would be a perfect solution for our use case. Now I've ranted about this in the past, so feel free to just press delete on this post I just keep hoping that reliable I/O for home automation won't stay a dream forever.

I updated to v.5.0.14 software yesterday (Dec 8, 2018) and BOTH relays were working flawlessly as momentary NO contacts. I didn't test the other options on the MIMO2+, as the motorized curtains that I was trying to control wanted two pulse inputs, one to open the drapes and one to close them. Now on a separate topic, a simple Modbus TCP stack in the ISY would rock. It breaks my heart to pay almost as much for a cheaply built 2-relay I/O block as I would for industrially hardened PLC with 16 I/O. In a previous life, I was responsible for creating a very in-depth Modbus/TCP DPI firewall (www.tofinosecurity.com) and I'd be happy to support developing a Modbus/TCP module. It would only need to support the two Class 0 Function Codes, namely FC 3 - Read Multiple Registers and FC 15 - Write Multiple Registers. Anything more would be pure luxury. And if there was a module in existence, I'd be happy to pay $49 for it. As well as solving the I/O problem (especially stable Analog I/O), most modern PLCs support full floating point math with functions like SqRt, Sine and Cosine. Modbus would allow me to get the math out of the ISY and into a robust PLC that will probably still be running long after I am not.

Just an update on the tank level project. First, we rewrote the whole level system logic as per apostolakisl's great suggestions. Stripped down the voltage comparison programs and created only one calculation program. Yes there are 83 voltage comparison programs , but they are easy to create with ISY Import/Export and a text editor . All state machine strategy is gone. // ChkWireBreak - Test if the Elk Voltage is under voltage (1.9 V or less )and if so, set $ElkVoltagex10 to -999 (i.e. error) If Elk Zone 'Water Level' 'Voltage' <= 1.9 Volts Then $ElkVoltageX10 = -999 $State_WireBreak = 1 Else $State_Wirebreak = 0 // Chk020Volt - Test if the Elk Voltage is 2.0 Volts and if so, set $ElkVoltagex10 to 20 (i.e. ten times the voltage) If Elk Zone 'Water Level' 'Voltage' is 2.0 Volts Then $ElkVoltageX10 = 20 // Chk021Volt - Test if the Elk Voltage is 2.1 Volts and if so, set $ElkVoltagex10 to 21 (i.e. ten times the voltage) If Elk Zone 'Water Level' 'Voltage' is 2.1 Volts Then $ElkVoltageX10 = 21 . . . // Chk100Volt - Test if the Elk Voltage is 10.0 Volts and if so, set $ElkVoltagex10 to 100 (i.e. ten times the voltage) If Elk Zone 'Water Level' 'Voltage' is 10.0 Volts Then $ElkVoltageX10 = 100 // ChkOverVolt - Test if the Elk Voltage is over voltage (10.1 V or greater)and if so, set $ElkVoltagex10 to 999 (i.e. error) If Elk Zone 'Water Level' 'Voltage' >= 10.1 Volts Then $ElkVoltageX10 = 999 $State_OverVoltage = 1 Else $State_OverVoltage = 0 And the 83 programs are arranged in 8 folders with voltage range conditions, so it is easy to watch what has executed and when. For example all ten test programs for Elk Zone 'Voltage' between 2.0 Volts and 2.9 Volts live in this folder called Chk02xVolt. Folder Conditions for 'Chk02xVolt' Add conditions to limit when programs in this folder are allowed to run. If Elk Zone 'Water Level' 'Voltage' >= 2.0 Volts And Elk Zone 'Water Level' 'Voltage' <= 2.9 Volts Then Allow the programs in this folder to run. The calculation logic looks like this: //Wait for a trigger to calculate $WtrGallons ($ElkVoltagex10 x $SlopeDiv10 - $Offset), $WtrLvL ($WtrGallons / $GallonsPerInch), and then display the level on the Elk Keypad If Time is 12:00:00AM Or Elk Keypad 'Main Keypad' 'F4' is Pressed Then Set Elk Zone 'Water Level' Query Voltage Wait 2 seconds $WtrGallons = $ElkVoltageX10 $WtrGallons *= $SlopeDiv10 $WtrGallons -= $Offset $WtrLvl = $WtrGallons $WtrLvl /= $GallonsPerInch Set Elk Area 'House' Display Text on Keypads, Content 'Elk_WaterLevel' Second, after a fair amount of testing, it seems that Elk Voltage Levels act differently than other Elk variables when used as triggers. I have a post requesting verification of this in the Elk portion of this forum: viewtopic.php?f=17&t=12637 This seems to be working, so we have our fingers crossed... By the way, the Wait is needed so that the voltage check routines have time to do their thing before the calculations are done. In summary, I have to agree with Autonow when it comes to analog I/O handling: The ISY rocks in terms of handling dimmers, KPLs and like (and the service also rocks). The Elk does give you cheap digital I/O, something not available in the Insteon world. But if you have any analog needs or rougher digital needs (like pumps) or moderately complex math needs, better buy a small PLC.

To me, you have described the crux of the matter. If Elk voltage is a trigger, then that would explain my troubles. And I think it could cause havoc with this program too, because if the system has any "level bounce", then this program would fail to completely execute, because the bounce in Elk voltage would cause the program to be reevaluated midway through the first THEN stage, but then the AND condition might not be true, so it would head off to ELSE. If Elk voltage isn't a trigger, then all is cool. Interestingly I can't get this problem to happen any more, so I can't really test any solution now. Go figure...

Maybe I am a little slow this morning, but I don't get how this would work. Can you explain?

Wouldn't changing the $State_LvlCalc value immediately cause the program's IF statement to be re-evaluated and be found to be false. If I understand ergodic's great postings on State Machines and Triigers (http://forum.universal-devices.com/viewtopic.php?f=26&t=5731) this is exactly what would happen. Now to me, Maddbober83 seems to be on the mark: I will try this and see what happens. Frankly I would have split the conditions and body programs like ergodic suggests, but that would have resulted in 160 programs Two questions for Michael - 1) Is there any way to stop a program's IF statement from being re-evaluated? In the PLC world (and in general programming) I can mask interrupts when executing a some code I don't want to be interrupted. Can I do that in the ISY? 2) Is the evaluation of an Elk variable handled the same way as say a state valuable?

99.9% of the time, it works great. The only two things that trigger the process is the time of 5:00 AM or pressing F4. The F4 was added as way to force a cleanup, when this error occurs. It never seems to fail - only the time tigger causes thw error. Go figure. Yes, $WtrGallons is how much water in the tank. $SlopeDiv10 is the scaling factor divided by 10 (to effect a decimal shift to allow integer math to be used). It is initiallized in the variable table and never touched again. basically the math is: $WtrGallons = ($SlopeDiv10 * ElkVoltage) - $Offset And since I can't actually assign a ElkVoltage reading to a variable, I assign a constant everytime, based on the compare to the "Elk Zone 'Water Level' 'Voltage'". Thinking about it as I write this, my guess is what is going wrong is that two of the ChkxxxVolt programs are going true at almost exactly the same time, resulting in something like this: $WtrGallons = ($SlopeDiv10 * ElkVoltage1 *ElkVoltage2) - $Offset . Perhaps the water level is oscillating between say, 3.1 and 3.2 just at 5:00 AM. When I get back to the customer, I will see if that math works out to equal the error values.

The voltage is getting from the sensor to the ISY correctly - no issues there. So I agree the problem is somewhere in our ISY programs - that is what I am asking for help on. And I agree that the CAI solution would be ideal, if I was to do it again. it might be what I use. But the CAI is not the horse we got onto (after carefully asking for advice on this forum and others). Now we have to live with the consquences of our choice and do the best we can, which is fix the ISY program. As I noted earlier, the issue for our company isn't the cost of the CAI board (that is cheap) but rather the cost of labour for installation, configuration and long term support. Its another trip for our electrician to the site, another power supply (sorry - no wall warts allowed in a pump room - their MTBF stink), another day for one of our techs to learn new product, another day for someone to change the design documents for long term support and so on. This gets expensive. Plus it is one more CPU device and one more power supply to fail, so it reduces the overall reliability of the system. A cistern pump room is not a nice temperature controlled environment, so reliability under non-office conditions is critical (note: we did a lot of checking to ensure the Elk board and level sensors will survive the conditions). So as ugly as it was, we decided that it would be cheaper to write the compare programs. Bottom line is that going to the client with a significant rework of equipment is not going to fly at this stage. It's just life in the design and installtion business. So I need to fix the ISY logic

If only I had known the fun we would have with the Elk/ISY option, I would have gone with the CAI... But we didn't know and now we have to live with the consequences which is ISY 83 programs Now thanks to the fact that I can export and import ISY programs, writing 80 similar programs isn't hard with a text editor. But the number of programs isn't currently my issue. It is the logic race issue inside the ISY and I don't think this would be solved by the CAI. Anyone have ideas on that?