apostolakisl

Exactly. Just remember "Control is . . ." statements are only triggers on the exact thing listed. Nothing Else The "control is not. . ." language is easy to remember as just the same as "control is. .." but opposite result (its a double negative) Also Remember if you have multiple triggers for a program (either other if statements or an external trigger), "control is" will ALWAYS be false whenever one of the other triggers activates. Similarly, "control is not" will always be true. Control statements are confined to the precise instant of the control event (someone pushes a switch). So breaking down the logic for an on press on the above example. IF Control device x is switched on - - - true, the on paddle was pressed And Control device x is not switched off - - - true, "off" event never happened (false), but this is opposite, so its true. Result - Then runs Now for an off press IF Control device x is switched on - - - false, the on paddle was never pressed And Control device x is not switched off - - - false, "off" event happened (true), but opposite, so its false. Result - - Else runs

Your guess is correct. Another program calling this program is a trigger event and will reset the program. You will never have multiple simultaneous running "then" or "else" executions.

What he said. The Then and Else clause are referred to as "atomic", meaning not separable (like in the old days before we understand nuclear fission), EXCEPT when a wait or repeat is encountered. These two commands separate the then/else clause into multiple atomic units. So, in short, once an atomic section of a then/else starts, all items will be executed. If during the micro-second of execution, another trigger occurs, the program will still finish the current atomic unit, and then start over. For example Then Repeat every 10 minutes do thing 1 do thing 2 do thing 3 wait 5 minutes do thing 4 do thing 5 do thing 6 The above has two atomic units. things 1,2, and 3 is the first, things 4,5,and 6 is the second. The thing 1,2 and 3 essentially happen instantly, but at the micro-second level, they may occur in any order. Regardless, all three things will happen once that section starts. If, in the midst of things 1,2,3 being executed (during that micro-second), a new trigger happens, still all 3 things finish, however, the "wait" will be a terminating point for this execution of the program (it starts fresh on the new trigger). Or, the repeat would also be a terminating point if the trigger event happened during/after things 4,5,6 and before things 1,2,3 repeated. Keep in mind, that atomic sections may execute in any order. So if your thing 1,2,3 are math functions where the result of 1 is passed to 2 and then 3, you might not get the answer you expect. Although typically they happen in order, it is not a 100% thing. If math function 1 is way more complex than math function 2, then 2 may execute before 1 finishes.

Based on the fact that this thread is 2.5 years old and I haven't seen anyone have a failure after replacing the caps, I'm thinking the caps are pretty much it as far as problem parts? I have a repaired board that is running now for about a year or so. Only time will tell for sure. Not sure how long you would say these should last before feeling like "OK, that's pretty much all you need". 100 years is no doubt over-kill, but what about 10? 20? I'm going to say 10 would put it at a number that I would say is plenty. There is a reasonable chance that after 10 years, you'll be ready to move on to new technology. Maybe not.

Certainly try a new cable. But odds are very very very (did I say very?) high that the PLM is dead. PLM's are a universal point of failure beyond 2 years of age. Just because the led is on, doesn't mean it is working. The green led on one of mine was on even though it's capacitors were bad. Personally I repaired 2 plm's via the capacitor replacement.

How old is your PLM? A little over 2 years I bet. Try rebooting ISY/PLM and restoring your PLM, does it work now? If yes, then your PLM is on its last legs. It might hold the links for a few minutes, or a few days, but it will happen again. You need to either get a new one or replace the capacitors as per the thread in here about that.

Yup, that was my reasoning as well. Wanted a non-admin user/pass for ifttt

Actually, those do all look like fake news.

Look, here is the deal. The answer was NO. NO. It wasn't anything else but NO.

I contacted my insurance agent (Farmer's) to inquire if Farmer's would deny a claim because of connecting the alarm system to home automation/internet in the event that this was related to a failed alert. She got back to me with a definitive "no", the claim would not be denied. I would point out that this is HOME automation. Not military, banking, high value commercial automation. Those policies would be written differently and likely require that certain protocols be followed. The fact that I have a myriad of ways to turn on my alarm system means my alarm actually gets turned on. As I think you implied earlier, this is in all likelihood the most common reason that an alarm fails to detect an intrusion When I leave my teenage kids home alone, I can arm "stay" even though I am leaving by pushing a button in my car, or I can arm away if no one is there. A button next to my bed instantly arms to night mode. I can arm my alarm from my harmony remotes, or I can tell Alexa to arm it. All together, this means that my family and I pretty much always use it. To fear an internet guru hacker is interested in hacking my alarm and then actually robbing me just doesn't strike me as being in the top 100 ways I might have a home intrusion. If I were hacked, I would imagine it would be some looser in Russia or something getting his jollies with no intention of actually coming to my house.

I was just playing with the additional user configuration. I can't get it to work. I have always used my admin user/password and that works fine. But when I tried to setup additional users . . . no go. I click on file, setup userid/password, user 1. I enter a username and a password twice. It asks me to confirm. I confirm. I logoff and try to logon with those credentials and it says failure. If, the user and password did work, what is the value in having additional users? Are these users restricted from changing settings? I'm on 5.0.8. And yes, the UI is also 5.0.8. I checked the user manual pdf and wiki and I find nothing about the additional users.

First off, the only security system that works is the one that gets turned on. The easier it is to use, the more it gets used. While connecting your panel to the internet opens a small window of opportunity for those who might do you harm, it closes a huge hole that exists when you don't use the panel at all because it is inconvenient. So to a purist, perhaps this is blasphemy, but in real life, it is what works. But furthermore, I'm not sure you understand how this works. 1) Alexa does not get your alarm password 2) Alexa does not even communicate with your alarm 3) ISY communicates with your Alarm 4) IF ISY has no program on it to disarm the Elk, then there is nothing you can do to remotely trigger ISY to disarm it unless you actually hack into ISY 5) Even if you did have a program on ISY that disarms Elk, someone would have to know the ISY API and which program to trigger (Alexa would know this if you programmed Alexa to know it, which is why I don't) 6) Elk created the XEP and intends it to be used as it is being used in this example. 7) Anybody who owns a webpage you have ever gone to, knows your IP address, and if they were a store where you put your address to ship you something, then they know which IP goes with which physical address, nothing unique to Alexa/Amazon here. If you use ISY portal, you don't even need to open any ports. 9) Professional Elk installers will open ports so they can manipulate your panel remotely, per actual Elk policy. In short, Elk is a respected security platform and none of this stuff is a hack on the Elk, it is all as intended. An insurance denial as you claim is quite unlikely for a homeowner. Even if you actually gave out your password, like to your cleaning lady, on purpose, and she robbed you, your insurance would not be denied. Or if you didn't turn your alarm on at all, or you didn't turn your alarm on and didn't lock your door, your insurance would still cover you. Home owners insurance does not stipulate precision use of UL listed security system to cover a homeowners policy.

My point is. . . RELATIVE RISK Connecting your security system to an IP backbone using standard encryption technology is going to be way down that list of relative risk. There are just SOOOO Many things you should be considering before that when it comes to security. Doing obviously silly things with that IP connection is no different than doing silly non-tech things like leaving your key under your doormat. It doesn't make the lock bad.

I'm not entirely sure what your end point here is. ISY and Elk shouldn't be connected? Amazon Echo shouldn't be connected to an ISY? ISY shouldn't have programs that respond to Echo? ISY shouldn't have programs that respond to Echo and execute something on Elk? Your examples above are true, mostly obvious situations where someone chose to do so something with a high probability of failure. In short, life is all probability. Whether you connect your Elk to ISY/Echo/Wahtever or not, there is always a probability of failure. In short, once you connect your Elk to the internet, you have crossed the bridge of an internet hack. I doubt that adding a link to ISY changes that probability in any realistically significant way. Personally, I would avoid giving echo a path to disarm the system cause it seems like yelling at echo to disarm your system will at some point be heard by someone who will now be able to shut off your system too. Once Elk is on the internet, adding an ISY link seems pretty trivial. If you are so in desperate need of security, there are a lot more likely failure pathways having nothing to do with your automation connectivity. The simple fact is, home alarms have response times of at least 10 minutes to cops there. That is lots of time to get yourself killed/kidnapped, or get a bunch of stuff stolen. And the bad guy needs nothing but a good kicking leg. Circumventing a home alarm system would be easier to do by just showing up at the house with basic knowledge of how they are installed rather than trying to hack it through IP.

This is what I used in May, nearly a year ago. It is still working.

You can search for my name. I listed current part numbers on a repair I did maybe 6 months ago. You need mid-level soldering skills to do this. The soldering is not micro stuff.

Javi, Thanks for pointing that out. I got it working. Not sure how much I need to worry about security. Add a self-signed certificate? Not sure how hard that is. Change the port? Not sure that really does anything. Or, do nothing? Not sure if pointing port 80 to EG webserver opens up much of an opportunity to hack the network. The html pages I have written are super basic. Just displays a message, with 2 hyperlinks, so that I can trigger 2 different macros on EG. EDIT: I have to say, this webserver is looking like a bit of fun. You can turn your phone in to a remote control for your computer pretty easily and quite responsively. If only I was better at creating web pages.

I port forwarded it. (it being port 33333 of the remote router directing to the LAN IP, port 33333 of the EG computer)

I am trying to trigger a computer running event ghost that is not on my lan. I can't seem to get it working. I have no probs triggering computers within my lan using ISY/EG. What I did 1) Port forwarded 33,333 to the LAN IP of the computer running EG (the remote computer) 2) Set ISY to send a UDP to the WAN IP address of the remote network computer, port 33333 3) test it and nothing happens. I am using essentially the exact setup that works when EG and ISY are on the same LAN, I copied my network resource and then changed the host to the WAN of my remote computer. I copied the event ghost tree from the LAN computer to the remote computer, so all of those settings are identical. I was able to self trigger EG on the remote computer, for whatever that is worth. I can confirm that the port forward is working as I tried an experiment by setting remote desktop to listen on port 33333 and I could connect. What could I be missing here?

It sounds like you either need to subscribe to a dynamic dns service (like dyndns or no-ip) or get ISY portal. If power went out and your home gateway was assigned a new ip by your ISP upon reboot, there is nothing that ISY can do about that. A dynamic DNS company keeps track of your current WAN IP address by running an application on some device inside your network that informs the dynamic dns server of your current WAN IP every time it changes. Many routers have this application built in, as does Elk XEP. The dynamic dns company allows you to assign a URL to your home and it translates that URL into whatever your current IP is. Your URL choice is limited to the format they provide you, unless you want to buy your own. For example, a URL might be joe-blow.no-ip.biz where the "joe-blow" part was of your choosing. ISY portal service works by a plug-in on the ISY that opens a connection to the ISY portal. Because the connection originates at your end, the fact that your home IP address changed doesn't matter. The portal is owned and operated by UD on some server somewhere and its address never changes, so both you and your ISY can always find it on the internet. The service costs $50/2 years which allows UD to operate the server. The portal then relays all communications between you (when you are outside your home) and your ISY. As far as your LAN. You can configure your ISY to have a fixed IP, but be sure to keep good records of what you have assigned to what address. If you duplicate and address you will have problems. Also, you must set your router's DHCP to a range that does not include the IP addresses you are assigning your ISY (and other stuff). Generally speaking, assigning devices fixed IP's within the device is not the best way to do it. The best way to keep a LAN device on the same IP is typically to use a feature most routers have. This is called DHCP reservation, and it allows you to set your router to always provide any given device the same IP. In this case, you leave your ISY set to receive a DHCP address from your router. Your router will then always give it the same address, the address you told it to give it in the dhcp reservation configuration page. The router will recognize your ISY by its MAC address and it is the MAC address that you use to configure the router's reservation.

Can you arm/disarm from the ISY main console? Perhaps try going to config/elk and hit refresh topology. I too have Echo set to arm system. I see no security flaw in this. I suppose if you had no keypads in your house to see the red light and just trusted that it happened, you might be trusting too much. But I say "amazon trigger alarm on" and it turns on and I see red lights on all my keypads. If you had no keypads visible you could easily write a rule in elk to do something when it becomes armed to confirm that it got the message. Like send a text or chirp the siren or speak something or who knows what else.

I built an 8 outlet controller, but this thing would be easier. I wrote it up in here a while ago. I used a 4 gang electric box, 4 duplex receptacles with the tab that ties the two outlets together broken off, and wired each outlet to one relay each. Then I used my CAI webcontrol board to control the 8 relays. I had to use a relay board with the opto-isolated deal that only draws minimal current since cai can't power the 30mA or so that relays pull. Anyway, I wrote code on the CAI itself that controls the 8 outlets. The purpose is to turn on the outlets on a schedule with each one having an external hard drive attached. This was for running backups, one for each day of the week, with the hard drives powered off while not doing a backup. I could have also used the ISY network module to turn the CAI outputs on/off (and thus the relays) if I had wanted. Comparing what I did to the controller I started off this thread with. 16 vs 8 relays, cheaper (less then 1/2 the price per relay), only controllable externally (web) vs either local programming or external.

I actually pulled out the relay boards with those same songle relays. They are 10a 120vac rated NO/NC. It would seem that the relay board and the webcontrol board are 2 separate pieces. The webcontrol board is less liked than the relay board as I read comments. Looks like you should be able to control with ISY network module simply sending http commands. Example: http://192.168.1.4/30000/00 turns relay 1 off. http://192.168.1.4/30000/01 turns relay 1 on. So you have to divide by 2 since the relays get consecutively numbered with 2 commands per relay. And it looks like you need 12v to power the relay board and 5v to power the web board. The 12v part is pretty much 100% correct as I have similar boards and I know for a fact the relay coils use 12v

Based on the photos of the relays, which appear to be the same as relays I have on other things, as well as the screw terminals, they are spdt (both normally open and normally closed options, and are 10amp each.

I accidentally came across this on ebay http://www.ebay.com/itm/SainSmart-Web-TCP-IP-10A-Relay-Remote-Control-Kit-with-Network-Web-Server-16-/262734678764?hash=item3d2c350aec:g:bQ8AAOSwImRYOLx1 16 relay board with an IP interface. I would expect that with the network module you would be able to control these relays with ISY avoiding Insteon issues and getting a nearly instant response. I haven't actually tried this, but you certainly aren't going to find a cheaper way to have 16 relays run by ISY.