markens

Thank you @paulbates -- that thread refreshed my memory about looking for the "URL to ISY" URL in the tools/ISY Information menu. That gives me what I need for accessing the REST API via the portal. I couldn't find any reference to this when searching myself.

I'm bringing up a new eisy to replace a faithful ISY994i. In general, it's going ok so far, although not without a few hiccups My head is spinning from sorting through so much info about the process. I've searched for info about REST commands, but still have some questions: (1) I use the REST API on the ISY for commands from other devices. My ISY has a custom TLS certificate. I saw somewhere that the eisy does not support custom TLS certificates. Is this still the case? I can work with the self-signed cert on the eisy. But: will the REST interface continue to be supported on eisy? I remember seeing somewhere that this may not be the case. (2) I have a portal subscription. It seems using the portal is the preferred method for remote access to avoid port forwarding. I know about using the portal for access from UD Mobile, and for web access to admin functions on the ISY/eisy. But I haven't been able to find documentation on using some of the other portal functions that are available in the menus on the portal web interface. Certainly related to this: how do I use the portal to funnel REST API requests to my eisy? A pointer to relevant documentation would be much appreciated. Thanks! --Mark

I've used Namecheap for many years. They allow renewals out to a total of ten years, although without any significant (if any) discounts. At least for .com domains.

I had looked at this wiki page, but missed the key word "deactivation" and related section (focusing on the portal sections further down). This indeed seems to answer my question, thanks.

Hello! I finally got around to trying out ISY portal and node servers on my ISY 994i (firmware 5.0.16c), using the portal trial license. It's interesting technology, but doesn't look like it adds anything useful for my particular installation. So I'd like to remove the portal module and let the trial license expire. I've searched for instructions but can't find anything relevant. Neither can I find any menu items which might do this. Can someone point me to the right stuff? Thanks.

Thanks! I was hoping this was the answer.

I just had an old 2486D keypad (8 button) die. A factory reset does not bring it back to life; no leds and no response at all from the buttons. I've got an even older 2486D (from 2006) that I swapped in as a replacement, which is good for now. But it doesn't have "modern" features like settable led brightness. So I've been looking at this same question of replacement. Current product from Smarthome seems to be the 2334-222 as mentioned above. The 2334 appears to come with generic opaque "SCENE A" (etc) buttons. Custom etched are available, but I'd like to use my current clear buttons. They are currently still available and in-stock at Smarthome (2401CLB) and listed as being for "Insteon Keypads." Does anyone know if these will, indeed, work with the new 2334-222 keypads? Perhaps with an existing ("old") button frame if they don't work directly with the new switch? Related: Do the old color change kits (white/ivory/etc, similar to current 2401IV8) work on the new 2334-222? I have lots of these and it would be useful to use on the new switches if possible. But still want to use the clear buttons! The Smarthome website is somewhat confusing about compatibility. Thanks for any info!

This is such a simple example, but it really illustrates the power of ISY and insteon with regard to remodeling. I just added some long overdue path lighting in my front yard. Control of them was never an issue. Plugged the (dimmable) power supply into a lamplinc and added it to the ISY's front porch light scene. Done! No messy wiring to do and it works exactly as I want it to.

No, a windows 7 machine. I run the admin UI as a standalone applet (via jnlp link) as suggested, not in a browser.

Thanks, Michel. I did exactly as you suggested, and also disabled antivirus while running the admin app. Sadly, there is no change in behavior: anything I type in the find box still yields empty results. Everything else works fine! What now? Thanks.

I have the same problem reported in the original post in this thread: I click Find and enter a city, but the resulting "Areas containing xxxxx" window shows no results. This happens for any value I type in the find box. And it hasn't magically started working for me! I just upgraded to a new 994i PRO with 4.2.10 firmware and UI. I updated to latest java (windows 7 machine) and cleared the java cache with no change. What does work for me is entering four-letter airport codes of major airports (KXXX) directly into the Location ID box and clicking Save. I then get current data for that airport. What have I missed and how can I get Find working? I'd like to use a station closer than the nearest airport, which isn't close enough to be useful. Thanks.

LeeG: Thanks for the description of how one might use a 6-button frame in 8-button mode. That is quite useful info!

Are you asking if you can independently control the light in the bottom button of a 6-button KPL? If so, the answer is "no." The following info is the result of testing I've done on my KPLs to see exactly how they respond. The top/bottom buttons on a 6-button KPL are somewhat different than the others in that they, together, represent the local load (device 0) and cannot be controlled separately by the ISY. Note there is only one ISY device for both buttons; they are not independent. How the lights work in those buttons depends on the toggle mode set in the firmware. Luckily, the ISY makes it easy to see and set that option. I don't know if the following is true for older 6-button KPLs, but it is for newer ones: As shipped, the KPLs are in toggle mode. For 6 button KPLs, this means that the top ON button illuminates when the local load is on, and the bottom OFF button illuminates when the local load is off. This is true whether the load is controlled locally by the top/bottom buttons, or remotely via ISY or other switches. You can see this option in the ISY by selecting one of the KPL's devices and then click "Buttons Toggle Mode." For device 0 (the local load) the option will be shown as "Toggle" mode. It's easy to modify the behavior so that the top ON button comes on when the local load is on (and goes off when the load is off), AND keep the bottom OFF button off at all times: Simply change the toggle mode of the 0 device to "Non-Toggle (On)." "Non-Toggle (Off)" seems to do the same thing for this device. So you can control whether the bottom button is illuminated or not when the load is off, but that's about it. If anyone has different info, I'd love to hear it. Thanks!

Success. As I discovered and posted previously, the ISY is prepared to use exactly one SSL cipher suite: SSL_RSA_WITH_RC4_128_MD5. So any server it communicates with must allow this suite. In openssl (and apache) terminology, this is suite RC4-MD5. Most server configurations probably allow this by default, which is why the ISY https "timeout" problem is spotty. But ciphers using MD5 are considered undesirable at this point, and many security-conscious sites have disabled them. I forced RC4-MD5 to be accepted on my server, and the ISY is now happily talking to it. Yay! --Mark

Hi Michel, Thanks for the clarifications. OK, I'll stay with 2.8.16 until I'm ready to play with variables. I'm so blind! Thanks. Good to know. Just to make sure, this means that self-signed certs are ok as well? Also good to know. Well, it turns out things are a bit more complicated than that. Yes, browser is on same home network as ISY, and server sees requests from the same IP address. And both http/https requests work from the browser, and http from the ISY. Investigating ISY https request further: The server is seeing connection opening and traffic exchanged (SSL negotiation). Using ssldump, I now see what the problem is: The ISY is prepared to use exactly one SSL cipher suite: SSL_RSA_WITH_RC4_128_MD5. My server is prepared to accept many cipher suites, but not that one. Hence the SSL handshake fails. I will now research why my apache server is configured to exclude this cypher suite. Most likely I'll simply enable it and things will work fine. I'll report back with my findings in a few days. Thanks, --Mark

I am also seeing problems with https net resource calls, and this seems a good place to post some questions: ISY99 running 2.8.16. (Is this a problem? Is outbound network resource handling better in 3.x?) I have a bunch of http GET resources which work fine. My goal is to shift them over to use https to the same server prior to adding some additional resources. The SSL environment on the server is self-signed certificate, and it listens on a non-standard https port (say port 3000) instead of 443. For my test [A], I simply changed one of my net resources to use https instead of http, and changed port 80 to 3000. Saved new config and click Test. Get popup with error: TCP client connection timed out, net module rule 2. Status monitor says "Net-Resource: Failed connecting to ." Error log is error -140002 Rule 2. This is consistent no matter what timeout I set in the resource conf page. Changing back to http/80 works fine again. So another test : I created another resource to a different virtual host on the same server. Tried with http/80 and it worked fine. Changed to https/3000 and got the same timeout error as above although this time rule 6. What is rule 2? rule 6? Only difference between host configs is that the hostname specified in the self-signed cert is the same as the one called for test , and does not match for test [A]. So this implies there could be a cert validation issue. How strict is the ISY on validating server SSL certs, for both self-signed situations and those where the cert hostname doesn't match the called hostname? (Obviously this doesn't provide optimum security, but it serves my purpose and works fine in other environments). I tried calling other https resources such as google.com, and got the resource moved error as reported by j0dan. Please help me understand the environment in which https resources should work and what restrictions I need to be aware of. Thanks! --Mark

Another data point: I just got a low battery indication from my 2420 (rev 1.1, 0909). It's been in service for a year, outside in my driveway. The battery was the original "GP super alkaline" that came with it. Interesting observation: I have the 2420 jumpered to turn off the LED indicator on motion. When the low battery indicator activated, so did the LED (with its double-flash). I think this is indeed the correct behavior (so you'll see a low battery indication regardless of whether ISY sees it or not). Good to verify this. Yes, this is correct. All you have to do is to replace your battery and then issue a Query on the low bat node in the Admin Console. I tried this without success on my 2.7.15 ISY99i. It appears the ISY simply ignores the query request for this device. (Yes, the 2420 was in SET mode; clicking the options button successfully returned the correct device paramters.) Is there other magic to be done to make the query work? I was able to clear the low battery status in the ISY by disabling the device, then enabling it again. So it's reset, just not using the QUERY technique. Thanks, --Mark

There are ways to automate this which may be of interest to you. You can get a hostname (such as xxx.dyndns.org) from a service like dyndns which can be automatically updated whenever your home router's IP address changes. Some routers can be configured to do this automatically, which makes it all transparent to you. Then, you just use this hostname in MobiLinc instead of the numeric IP address. If your router doesn't have the ability to automatically update dynamic hostname, there are other ways to update it. But at this point it's probably just as easy to update MobiLinc manually.

It's probably already present in the received message, although not in the body. If your email reader allows it, look at the message headers (or full message). There are a series of Received: lines which follow the progress of the message, showing the IP addresses of each relay. The earliest one most likely includes both the internal and external addresses of your ISY. Mine looks something like this: Received: from 172.iii.iii.iii (xxxx.xxxx.net [66.eee.eee.eee]) by yyyy.yyyy.com (8.14.2/8.14.2) with ESMTP id o8JIxxxxxxxxxx for user@yyyy.com; Sun, 19 Sep 2010 11:40:38 -0700 172.iii.iii.iii is my ISY's internal address, and 66.eee.eee.eee is my home network's external address.

Great question. A port scanner will obviously find open ports on your server, no matter what they are. But many (most?) probe attempts are simply sent to default ports for the service. So running on non-default ports can help shield from those. I personally run private services on my server (such as https and ssh) on non-standard ports. It's easy to set up and use, and the benefits seem worth it to me. Note that on most router/firewalls you can set up a non-default port for https on the internet-facing side, and forward internally to a standard port (443) on the ISY, leaving it at its default.

Hi Mike, As you noted in your update, the LL I tested is not dual band. Using the kill-a-watt, I saw no-load readings of 7VA with PF=.14. Multiplying this out yields .98W, which is in the ballpark of the .898W average I measured over the week (subject to all the various precision and rounding issues). Its an interesting question, of course, as to how accurate the kill-a-watt is for this sort of measurement. Mine is repeatable, at least. One thing I noticed is that all my recent devices all show similar instantaneous measurements (2476D, 2476S, 2456S3, 2456D3). I did not measure a KPL, and am quite interested in those results. Also would be interesting to measure an access point long-term. I just tried instantaneous test of an access point, and the readings are not stable at all. I have one old X10-only lamplinc which I measured, and got closer to what you saw: LampLinc 2000SC (rev 2.1), measured 5VA PF=.07 (calculate .35W). Also measured a 1626-10 filterlinc: 11VA PF=.01 (calculate .11W). --Mark

Interesting numbers. I also did a long term test, using a kill-a-watt with a newer LampLinc (V2 2456D3, rev 4.3). Also no load. My numbers were a bit higher: consumption: .15 kWhr time: 167 hr avg power: .898 W subject to similar error analysis that IM described. It will be interesting to see what you find for a KPL. --Mark

As I see it, apostolakisl (and others) are asking fairly precise questions, and are getting fuzzy answers that are true primarily for specific, non-generalized examples. But exactly what constitutes a change in a condition? The subtle point being that different types of conditions "change" in different ways, and there seems to be no authoritative list defining them. This is essentially what Michel said. I am trying to say this is not a precise way to define the behavior, and leads to confusion for people who don't already understand it. Specifically, defining the behavior in terms of previous or new logic values of the IF conditions doesn't get to the heart of the matter. Ultimately, the rules that determine how and when a condition gets (re)evaluated ("triggered") don't depend on these logic values at all. So why define them in those terms? And the question is: precisely what causes each type of condition to be (re)evaluated, with the side effect of terminating an already running program? I've seen plenty of examples using various conditions, but no concise list of this nature. I think it would be a great addition to info in the wiki. --Mark

Sounds like port forwarding in your router is configured to forward port 443 received from the WAN (dyndns address) to the changed port on the ISY. Perfectly valid configuration, although evidently not what you want. What happens when you try to access the ISY locally via its LAN address? --Mark

To amplify a bit on Michel's reply (since precise details are important in this discussion): Yes, with the clarification that Control events "trigger" only when that specific event is received, not for any Control action for that switch. For example, a "Control xxx is switched On" condition triggers only when that switch is physically turned on, not off. Status events trigger whenever the status changes, no matter what status is being tested for. Wait terminates if and only if the condition turns to false. During the wait, if the condition does NOT change (regardless of the permutation of the events that keep it true) then the program continues with its current execution and does NOT restart from the beginning I think two different concepts are being confused here: program status vs logical result of IF conditions. It seems that apostolakisl is asking about program status, and Michel is answering with respect to IF conditions. But beyond that: Michel, your answer does not seem to jibe with results I observe in my ISY. Specifically, I have a very simple program: If Control '[fdoor E]' is switched On Then Send X10 'H7/On (3)' Wait 15 seconds Send X10 'H7/Off (11)' Else Send X10 'G1/Off (11)' The only possible logical result of the IF is TRUE (since it is "triggered" only when the "switched On" event is received, and should do so every time that event is received). The switch is turned On and the THEN waits. Turning the switch off does not affect the wait (as expected). Turning it back On after, say, 10 seconds does cause the Wait to terminate: program Last Finish Time and Last Run Time are both updated to this time, and the program summary shows it running the Then. 15 seconds later (as confirmed by event viewer and Last Finish Time) the Wait completes and the X10 command is issued. So all values stay TRUE, but it is apparent that the program has restarted from the beginning due to the received event. edit: I updated the test program above to make it even clearer what's happening when looking at the program summary page and event viewer. --Mark