apostolakisl

My console I had open when I left work last night was still working this am. Very unusual. However, I was away from my computer for a couple hours and upon return, it was dead. That is typical. 20 minutes might be an exaggeration, but lasting more than a couple hours is rare. It doesn't die so fast that I have to reload it during a single usage, but to have it last long enough for me to be done with it and then come back to it later, well that pretty much never happens.

This has been issue for me from day one 10 years ago. The top bar gray's out. There will be hidden windows that I can "phantomly" close by hitting tab enter. Sometimes that brings the console back to life, but mostly it just lets me close it without doing a ctrl alt delete. There is no way this is an issue with my OS or computer since it has happened to me on every computer and 3 different OS's. Probably I have had it happen on a dozen different computers and it ALWAYS happens. If I leave the console up, it will never last more than 20 minutes.

I don't know about you, but my admin console rarely lasts long enough for me to close it while still functional. The console hangs all the time. This happens on all of my computers both remote and local through 3 versions of windows (xp, 7, and 10).

My original PLM never died. I don't know what the version number was, but it was a single band device (no RF) and lasted me many years and may still be functioning in the home of whoever the person on ebay is who bought it from me. I replaced it with the "new and improved" dual band device about 5 years ago. I have 2 of them, the first died, I bought a new one, then replaced the caps on the old one, then the new one died and I put the repaired one into service and fixed the caps on the second one which I keep as a spare.

I had made a suggestion a while back that when you delete a program but have not yet saved your deletion, that the program should stay on the list with a red x or something to that affect next to it. Something similar in concept to the green arrow next to programs that you created/changed but have not yet saved. It probably would also be nice if the "save" button at the bottom of the screen turned bright red or something to that affect when there are pending changes that need to be saved.

Probably forgot to hit "save changes" at the bottom left Unlike a new program or a change to a program, when you delete, there is not one of those little arrows indicating you still need to save the change, since when you delete there is nothing there at all. This is why the java thing is a pita. You are basically running a program on your computer to which you make all the changes. But none of these changes actually go to ISY until you hit the "save" which then uploads it.

Think of it this way. The whole purpose of the "And control device x is not switched off" is to include pressing the off paddle as a trigger to the program. Otherwise, the only trigger would be a press of the on paddle. You might include other control statements if applicable, like fade. Also, keep in mind, that "control" statements ALWAYS refer to an action taken locally AT THAT SWITCH. A switch that turns on as a result of responding to a remote command (scene) was not "control switched" anything. Here is another possible example where pressing "on" or "fade up" is true, and pressing "off" or "fade down" is false. IF ( Control device x is switched on or Control device x is switched fade up ) And ( Control device x is not switched off or Control device x is not switched fade down )

bumping this back to the front.

This has come up before and doesn't make a lot of sense they way it is presented in the admin console programming. First off, you use a command "adjust scene" to change the local on rate of a device. This is a bit misleading Second, you select from a drop down menu labeled "in scene", but there are a bunch of individual devices listed to choose from (in addition to scenes). This is confusing. It would seem that all devices that are capable of having their local on level changed by isy are listed there, provided they are also in a scene of any sort. It would therefore follow that if you have a device that you want ISY to be able to change the local on level, and this device is not already part of a scene, you would be required to create a "dummy" scene for it. Again, somewhat confusing. While I am sure there are reasons for this based on Insteon protocols, perhaps the console nomenclature could be changed so that it makes more sense.

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.

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.

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?