markens

Michel, Okay, I understand this part. But it doesn't (I think) answer my question. Expanding the quote a bit and restating my question: What do you mean by your earlier statement "As long as you do not have any links in your ISY" in this context? Seems to indicate that there must be no links in the ISY before it can write ISY's links to the PLM. What am I missing here? Thanks, --Mark

Michel, Sorry for being dense here, but what do you mean by "links in your ISY"? The rest makes sense to me. Thanks, --Mark

That's pretty easy to add to what you have, something like this: 'Leave (Daytime)' If ( Control 'Dining Rm Entrance' is switched Off Or Control 'KPL Button A' is switched Off ) And From Sunrise To Sunset (same day) Then ... --Mark

Michel, I'm running 2.7.7, for all operations mentioned in first post. I thought this might be the answer, but didn't want to risk it before knowing for sure. Does the Restore PLM option simply rewrite all links to the PLM from its internal device state, removing stale links in the process (similar to Restore Device for a device)? Thanks, --Mark

Apologies if this is answered somewhere else, but I can't put my hands on the info right now. So... I installed several new switchlincs today, to replace V.35 units giving me some problems. Everything worked as expected until I checked the PLM links table after I was done programming. And I found two dead links there for each of the switches I had removed (PLM group 0 and 1). My main question: Given this situation, how does one remove dead links in the PLM when there is no matching device remaining in the ISY? How I got there: - Physically removed old switches and installed new switches. - Added new switches to ISY with slightly different names from old. - Added new switches to appropriate scenes and adjusted program references to new devices. (Could not use "replace device" function because new switches are evidently seen as incompatible devices.) - Removed old switches from ISY; they were removed from scenes and My Lighting ok, but saw "incomplete removal" error after each one. Perhaps because of attempts to remove cross-links from devices which were no longer there? I wanted to leave the old switches in ISY until new switches added, to make it easier to go through and add new ones to the right scenes and adjust programs. Secondary question - Is there a better way to have done this device swapping? Interesting that all the scene links were removed from the PLM ok, but not the base group 0 and 1 links. ??? I solved it for my situation by temporarily connecting each old switch to power, then adding to ISY followed by removing it. This removed the errant links from the PLM, and all is good. But there must be a way to do this from the ISY without the devices present. Right? BTW, the new switchlincs (v.38) seem to have solved the issues I was seeing with the v.35 switches. Not a single error so far. Thanks, --Mark

Michel, I thought about this process a bit more, and have several more questions I'm hoping you can clarify since I can't test on my 2.7.7 ISY: - When selecting the Generate Certificate Request to CA option, is the current SSL operation of the ISY affected at that point? I.e., will a currently installed self-signed cert continue to work? (Say a CSR is generated and a resulting signed cert is never "received" into the ISY.) Specifically, does the private key generated at this point overwrite the existing private key components in the ISY, rendering the previous certificate unusable? - If the ISY is affected, then presumably the old cert file could be restored, or a new self-signed cert be installed. - Does Generate Certificate Request to CA generate a new private key every time this is selected? (So every generated CSR has a new private key associated with it?) Thanks, --Mark

This would require client certificates (which allow clients to be authenticated to the server). Michel should confirm, but it's very unlikely that the ISY performs client SSL authentication. So the answer to your question is no; username/password is still required to authenticate computers trying to access the ISY. (The server certificate installed in the ISY allows the ISY to be authenticated to the client, the other direction. It also enables encrypted communications so eavesdroppers cannot see your data, including the username/password.) Again, Michel should comment on the error received. But this is an advanced function that you probably are not set up for. Are you prepared to send the ISY's Certificate Signing Request to your Certificate Authority to be signed? If the answer is no (or you don't know what this means), then you should stick with ISY self-signed certificates and avoid using any of the "CA" options. --Mark

Michel, Success. I extracted the UD.DCF file from my latest ISY backup and reinstalled it using the utility. All works as before. Thanks, as always! --Mark

Michel, That's what I thought -- thanks for the confirmation. However: Since the menu item from within my 2.7.7 admin console took me to that same new SSL utility, does this mean that it's broken for everybody who is running less than 2.7.10? I'm not quite ready to upgrade to 2.7.11, so is there a URL to access the old SSL utility that will work in 2.7.7? 1. Thanks! 2. Didn't know that. My crypto experience is more on the SSL side than java -- should have used the google before making the comment! 3. Good, thanks. --Mark

I meant to ask you to clarify this: I would assume that you gave yourself a domain-based name at TZO.com (something like somename.tzo.com), not a numeric ip address. Is this the case? If so, then this is the name you should enter into the ISY SSL utility when generating a self-signed cert. Then, when you use that https://somename.tzo.com (or whatever) URL in your browser to access the ISY via this mechanism, you should not get a "hostname mismatch" warning. --Mark

Brief answer: All web servers that communicate via SSL (https) must have a security certificate available which is used as part of the secure communication with the client. The certificate is usually cryptographically "signed" by a trusted Certificate Authority according to stated authentication policies. All modern browsers come with a set of "root" CA certificates that are, by definition, trusted to sign server certificates. This can happen either directly (CA signs a server cert), or via a chain of trust. The browser warns you if there is any break in that chain of trust, from the installed root certificates all the way down to the particular server certificate for the current https page being loaded. This is how the client knows that the server is who he says he is (for example, you're talking to the actual web server for your bank). And it's why the browser warns you of any anomalies in the chain of trust, or other problems with verification of the certificate. Note that in all cases (whether you trust the certificate or not), the underlying web traffic is encrypted with a key unique to that session, known only to your client and the server. So nobody else can see the clear text traffic regardless of whether you trust that server or not. This is why a self-signed certificate is useful (since you would presumably trust this self-signed cert that you know you generated). Enter the ISY: It could use a generic, default certificate. But you would have no idea whether you're talking to your ISY or someone else's ISY. By running the utility to install a unique cert in your ISY, you now know for sure (once you accept and install that cert in your browser) that you're talking to the same one every time. This is just the basics. SSL certs can be used in increasingly complex mutual authentication schemes. For example, a company could issue client certs signed by its own corporate CA. Installed in a browser or other client, now the server can know that the client is authorized to receive services. And it goes on from there... --Mark

Michel, I've gone through the new cert signing process and have lots of comments. Bottom line is that the cert stuff appears to be ok, but the utility is not installing any cert to my ISY (self-signed or CA-signed). First: please verify that this process should work with 2.7.7 firmware. If not, that probably explains the problems I'm having! Here's what I'm seeing: - touch and go at first. SSL utility appeared to crash the first time I tried to import a received cert ("Information" popup was blank and nothing further happened; closed and restarted, got "Can't find private key" error. Started over.) Here are results of my last runthrough, which was clean until the end: - The CERTIFICATE REQUEST generated by your utility appears fine with the CA. But why is the following attribute included in the request, especially the email address? Requested Extensions: X509v3 Subject Alternative Name: email:ncp.edu.pk The CA ignored it, but I still wonder why it's included in the request. - CA signed the request ok, and returned the signed cert, in the following text format: -----BEGIN CERTIFICATE----- [. . . . .] -----END CERTIFICATE----- This is what I pasted into the ISY utility to receive the certificate. Is this what you're expecting? (Specifically, you're expecting a pem-encoded CERTIFICATE rather than a p12-format certificate intended for a browser. Right?) - The utility appeared to accept it, although the UD.DCF save file was not written to my local computer. ISY rebooted. http access fine, but still no response on port 443. I'd be happy to send you privately the actual cert request and signed cert if you would like to see them. What now? At the very least, I'd like to get a self-signed cert installed again so I can access the ISY via https! Thanks, --Mark

Michel, Couple more things: - You may want to look at the appropriateness of the "Publisher Name" chosen for the Java certificate used for signing your SSL classes. "The Legion of the Bouncy Castle" doesn't really give me much confidence. If the code path did not include "com.universal-devices" I would not have accepted it! - I tried running the SSL config utility directly from my 2.7.7 admin menu. Looks like I got the same SSL utility, with the same "non-working" SSL port after installation of the self-signed cert. --Mark

Michel, Several quick comments: (1) The UI of the SSL config utility includes empty ISY tabs (Main/Program Summary/Program Details/Configuration). I don't remember these from before. Should they be there? (2) "Install Existing SSL Certificate" menu choice -- is this the method to reinstall a self-signed cert previously generated (and saved) by this utility? If so, are versions compatible between firmware updates? (3) Before trying the new CA functions, I simply tried to generate and install a new self-signed cert. This failed. I had a perfectly good cert in my ISY which worked before this process, and after the reboot it looks like port 443 is not available ("no connection" error from client). Help please! How do I get back to a working ISY self-signed cert? I'm running 2.7.7 firmware if that matters. (And if it does matter, why doesn't the config utility check for this and refuse to function if there is a version mismatch?) Thanks, --Mark

That was fast! I'll take a look later today or tomorrow and post comments. In many respects, ssl certificates are black magic. Especially when attempting to use them for more than their most basic capabilities. No disrespect, but just because you don't see why they're necessary does not make them useless! As for the warnings, you don't say specifically what warning you're getting. I suspect it's one of two, though: (1) cert signed by non-trusted source, or (2) the common name in the cert does not match the site address you used to connect to the site. The following explanation might get a bit technical, but I hope it's useful: A self-signed cert will always generate warning (1), unless you have installed a CA cert (generated separately from the CA signing your cert) telling the browser that you trust it and all certs signed by it. Or, you can also "accept" the self-signed cert directly into the browser as permanently trusted, in which case you shouldn't be warned about it again. Reason (2) is also very common. This means that the cert is issued to CN (common name, or site name) xxx.yyy.com, but the URL you use in your browser to actually connect to the page is something different. This mismatch is generally considered a bad thing (one site trying to masquerade as another), which is why the warning is issued. Some browsers will let you override this warning as well, while others won't. --Mark

I've used low voltage transformers for years with both X10 and Insteon dimmers. Good quality transformers that are rated for use with dimmers should have no problems. One caveat: "2-wire" X10 wired-in dimmers won't work with transformers (the dimmer must have a white neutral wire). Lamplincs should work fine. I've never seen a problem with operation or lamp life using 100% light level. I use a default ramp rate of .5 seconds on my current Insteon dimmers. Previous X10 dimmer was instant on, also with no problems. Quality of the transformer could make a difference here I suppose. My only problem over the years was a 300W transformer apparently burning out after its secondary breaker tripped and the X10 switch tried to turn it on. So I concur with Clarence that the transformer should not be turned on with no load!

Careful, you might want to check this. I'm pretty sure that a "From-To" time condition by itself causes the IF to be evaluated exactly twice: Once at the start time (result TRUE) and once at the end time (result FALSE). If there are also other conditions in the IF that cause the conditions to be evaluated (such as a switch control or status), then the logic value of the From-To time condition is indeed taken into account at that time as well (TRUE during the period, otherwise FALSE), which allows conditional handling of those events. To illustrate, the following (perhaps not very useful) example program will always turn the light back on if it is turned off during the time period. This also illustrates how switch status can "override" a program: if from 5p -10p and status 'light' is off then set light on else The IF is evaluated whenever the status of the light changes, plus at 5pm and 10pm. The result is TRUE (execute THEN) if the light status is OFF between 5pm and 10pm, otherwise FALSE (execute ELSE, if any). Note another side effect of this program: When the light is turned on via the THEN, the status change from OFF to ON triggers another evaluation if the conditions. The time is presumably still within the specified period (TRUE), but the status condition is now FALSE due to the switch status. So the program will continue to execute the ELSE if anything is there. This behavior is often not anticipated, and is a common source of problems in programs.

Thanks, Michel! --Mark

You never explicitly confirm that your ISY is connected to a router (wired or wireless), which is what is actually connected to your DSL modem. Assuming this is the case, the ISY doesn't care about what the external dynamic address is from your ISP. So there's nothing the ISY needs to do when that IP address changes. Or is there some other situation you're describing?

Yes, I had no problem using your utility. The cert generated this way is what I currently have installed in my ISY. And I think it's great that you provide such a convenient utility to take care of this chore, handling 95% of the needs of UDI customers. Again, far beyond what most suppliers do! But the point in this thread is that your utility self-signs a certificate that it generates, using its own CA information (which cannot be changed via your utility). I'm talking about installing a certificate that I generate externally, using my own CA, and that I sign. I think that's what Jeff is talking about, too (at least, generated and signed by a CA external to UDI/ISY). Does your utility use openssl tools to generate its self-signed certificate? If so, it should be very straightforward to extend to allow installation of user-supplied X501 certs. Not a huge issue for me, but I wanted to chime in on the subject to help clarify the request. --Mark

In addition to the free CAs mentioned, it's trivial to generate (free) self-signed X501 certificates. These can also be "introduced" to browsers for secure connections. I do this for my personal domain (web server and clients). Michel, I'm not sure what the problem is here. If a certificate is supplied in standard X501 format, why can't the ISY simply store it and pass it on to the client during the SSL conversation? If there isn't enough horsepower in the ISY to do this directly due to ISY format issues, then perhaps a conversion/installation utility based on openssl could be used. --Mark

Much better to link them via the ISY so the ISY can monitor the status. If you want them cross-linked ("3-way" control), then add both switches to the scene as controllers in the ISY. See here for more details: http://www.universal-devices.com/mwiki/index.php?title=ISY-99i/ISY-26_INSTEON:How-To_Guide#Scenes

I think everything you said is consistent with what's been said in this thread (by me, at least), up to your last paragraph quoted above. Your example of a scene with a KPL button and an ApplianceLinc is not a good one in this context, because the ApplianceLinc cannot serve as a controller in a scene. Therefore, it's irrelevant whether the KPL button has a responder link in that scene or not. But it's absolutely true that a KPL non-load button (for relatively recent KPLs, at least) can handle both controller and responder links. And they can easily serve as responder-only devices. I use a number of such buttons in my setup in exactly that capacity, with no problems whatsoever. And that functionality would be severely crippled if the buttons did not light up! --Mark

Yes, exactly. I was trying to clarify the ISY behavior in this situation, that one does not have to manually create all the links like you mention is required in powerhome. Those leftover links obviously cause difficulties when transitioning! --Mark

Your statement is correct about needing to add both devices as (only) controllers in a cross-linked scene. What I was trying to say, however, was that the ISY automatically (and transparently) adds the required responder links in each of those devices in this same situation. So: The ISY only shows the devices as controllers in the cross-linked scene. But the devices themselves each have controller and responder links written to them. Exactly as if you manually cross-linked the two devices in a setup without the ISY. --Mark