linuxguy
Members-
Posts
132 -
Joined
-
Last visited
Profile Information
-
Location
Boston, Mass
-
Occupation
retired SW engineer
linuxguy's Achievements
Member (3/6)
0
Reputation
-
Hi Michel, Yes, that was my first thought, and I checked them as soon as I got home. Everything was just as it should be. Since I expect to be using remote access on a very limited basis, perhaps I should not bother with SSL, although I'd like to do it if I can. If I remove the certificate using the Java control panel, will that put me back in operation? EDIT Rand, I am using port 1443. I have the ISY configured for it, and the routers port forward it. Before I started messing around with SSL, I could log in successfully. I just wanted to be clever and set up the SSL. :- (
-
It looks like I really blew it. I recently logged in remotely for the first time in MANY months. I got all of those warnings, too, but eventually did get logged in. But I thought maybe I should "get with it" and set up the SSL certificate. So I came home and did it locally. But it was a struggle, and I finally managed to save a UD.DCF file, about 1195 bytes. Now I am unable to log in remotely at all. The browser can't even find a web page, let alone think there's a security risk. So then I thought I'd "delete" or somehow "un-create" the certificate. Doesn't seem to be any way to do that. BTW, as you would expect, I have no problem logging in locally. What do I try next?
-
After my timers started firing an hour late, I checked the ISY an sure enough, its still on standard time. Now I also have a SOAP program which reads the "GetSystemTime" function, and converts the "NTP" parameter (the ten digit number) to local clock time and date. At this point that program produced EST, correctly, as it has all winter. So I went to the ISY admin console and manually set the clock ahead one hour, and checked the DST box. Now my program is TWO hours ahead of EST (one hour ahead of DST). So I went back to the Admin Con and changed the clock back to EST, and unchecked the DST box. At this point I expected to be back where I started. Not! My program now reads DST, and the ISY reads EST. Please help me understand what is happening. How does ISY handle DST and the NTP number? Are they kept separately (and an hour apart when necessary), or does the NTP number shift an hour when DST changes? This is not a problem, as I can set the ISY AdCom to DST and let the NTP do what it pleases. BTW, during all this investigation, I cleared both the Java cache and the browser cache numerous times.
-
A month or so ago I replaced my faithful ISY-26 with an ISY-99i. Just changed the ISY, didn't touch the PLM. The changeover was smooth and painless, and I am now happily running 2.7.0 on the 99. Now I'm thinking I'd like to upgrade the 26 (from 2.6. to 2.7.0 (just to have a more up-to-date "standby" ISY). Question is, with only one PLM, will all the swapping around (from 99 to 26 and finally back to 99 again) get me into trouble? I'd rather have a "stale" 26 than a PLM problem. My PLM is about 18 months old, and runs FW 52. Thanks,
-
Release 2.6.15 (RC1) is now available
linuxguy replied to Michel Kohanim's topic in Previous Releases
petesc2, I'm not trying to start an argument here, and I've never used a xenon lamp. However a quick googling seems to indicate that a xenon lamp is basically an arc light (not gas discharge). Arcs of any sort are good generators of high frequency radio waves. In fact, as you may know, in the very early days of radio, the transmitters were arc devices. While xenon lamps with no transformers may have many desirable features, I believe the possible generation of line noise would come from the arc lamp itself, since transformers inherently are not noise generators. I would expect a transformer might act as a crude filter, and perhaps reduce somewhat electrical noise reaching the power line from the lamp. I studied the web site you referenced, and they mentioned something about a "low noise" lamp. It was unclear to me if that referred to acoustic noise or electrical noise. As I said earlier, I have never used a xenon lamp of any sort, and I have no idea if they tend to make acoustic noise or not. I am not attempting to say all the symptoms you describe can be explained by line noise generated from the xenon lamps. However, I have found that a device on an Insteon dimmer is never REALLY turned FULLY off, even when you turn it "off" or ramp it down to zero. In fact there is a very small current which flows through the load device at that time. I believe the Insteon "relay" devices do not have this. It may be in your case this small "off" current is enough to generate some power line noise. I know that's a stretch, but. . . I think you said the problem exists even when your lamps are off. Is there any way you can temporarily disconnect all the xenon lamps, and put an ordinary incandescent lamp on the circuit(s)? If you have the same problems, then for sure it is not Xenon lamp generated electrical noise. If the problem goes away (or changes significantly) then a line filter might help. Perhaps other forum members have had experience using xenon lamps and can tell you if they had any line noise problems. -
Release 2.6.15 (RC1) is now available
linuxguy replied to Michel Kohanim's topic in Previous Releases
Perhaps just remote chance, but are your kitchen lights ordinary incandescent, or a more exotic kind which often generate power line noise? I have seen strange things happen and it was all caused by line noise. Do you have or can you install filterLincs on the light circuits? Just a thought. -
Release 2.6.14 beta is now available
linuxguy replied to Michel Kohanim's topic in Previous Releases
Michel, Sorry if I'm missing the obvious, but will the REST module work with the ISY-26, or only the 99? Thanks, LG -
As usual, the install went smooth as silk. After a few quick checks, the admin console seems to be its normal self. However, something is causing my cgi-bin scripts using web services to fail. My command line programs seem to work okay, though. I haven't had a chance to dig deeper, but will keep you posted. Going by past history, I suspect I have a bug that wasn't activated by 2.6.7, but 2.6.8 found it. Edit: Everything's fine. I forgot to start my daemon processes. LG
-
jtara92101, I sincerely hope your "rant" was the result of frustration. Your experience with the ISY is unfortunate, but a long way from typical. For most of us, the firmware upgrade process runs flawlessly, every time (my first upgrade was from 2.3 to 2.4). I have never had the need to re-install an earlier version, so I cannot address that issue. If you browse this forum, you will be hard pressed to find dissatisfaction with Universal Devices or their products. From my observations on the forum, it would seem that most of us feel this is a good product, not "the least bad of a bad set of choices". Perhaps this is because many of us have had a hand (indirectly) in the product -- contributing suggestions for product enhancement, as well as reporting bugs and verifying their fixes. As time goes by, we see evidence of our input in the product. See how far you get along this line with Smart Home and Insteon products. If you're lucky, they'll acknowledge your email, after a while. You will not find another manufacturer of any product with the tech support provided by UDI. The response is prompt, and we are listened to. Michel is eager to help, although he wears several hats and is busy with many other matters. The ISY is just one part of a rather complex system -- the Insteon devices, the PLM, the ISY, noise generators on the power line, and the computer and its OS, for starters. Some problems reported on the forum are the (unknowing) result of difficulties in components other than the ISY. Michel does his best to help us with these, also. So what do I have to gain by good-mouthing UDI and their ISY? Nothing, except my ISY doing a better job. I would encourage you to stay the course for a while. Between ISY tech support and the forum, you can get all kinds of help. I can assure you that if you have ideas for a better way of doing things, they will be seriously considered. LG
-
I have found the cause of my problem: When the ISY sends a long sequence of events after the initial subscription, it pauses after about four or five events, and then resumes sending. When my ASYNC connection detects this pause, it processes all the received data, and then starts another read. It appears that when 2.6.6 paused, it was (always) precisely between the end of one event and the start of the next event. However, 2.6.7 pauses at this location sometimes, and at other times it pauses in the middle of an event. My event processing code expects to receive only whole events, and can't cope with an event split between two transmissions. So I have to rework my code to accept split events. Hope no one else has this problem. LG
-
I am having trouble getting subscribed. I haven't had a chance to do an extensive investigation yet, but so far I can't get through the initial "avalanche" of events when you first sign up. I thought it might be a timing problem (ISY sending events faster than I can handle them), but so far it doesn't look like that's it. I'm using the same code that runs flawlessly with 2.6.6. I will do more investigation, but I was wondering if anyone else is seeing similar problems. LG
-
Release 2.6.5 is now available (RC4)
linuxguy replied to Michel Kohanim's topic in Previous Releases
This sounds very familiar. For many months I have had to totally shut down my firewall to use the UDI/27 applet. I figured it was because I run Linux, but since it can happen with Windows, I guess the condition is more widespread than that. Its not a problem for me, in fact it might even be a security feature . Linuxguy -
Sounds like a lot of good stuff in the pipeline. I would humbly suggest that if you are changing the telnet port to 23 (which I think is a good idea), then you should say so in flashing red lights. Many folks may miss this and wonder why they can no longer login on port 126. Linuxguy
-
Thom, Just want to add a testimonial to the success of FilterLinc's. I have about 30 devices and had severe comm problems. I recently found my Verizon Fios box and the associated Verizon wireless router were putting out a ton of noise. Feeding them with a FilterLinc changed my comm success rate from about 1% to about 99%. I have now ordered more FilterLinc's, and am going to put the squeeze on that last 1%. Linuxguy
-
I hope this thread is still active. I have recently obtained a Verizon FIOS account, and sure enough an ActionTec MI424WR. I wonder if you have it all figured out by now, and perhaps someone was kind enough to write a consolidation of what works ( a Wiki page would be great). My Verizon furnished DNS is 70.243.0.12 (first) and 71.250.0.12 (second). Definitely different than what you found. My router's IP from Verizon has remained the same since my account started (about two weeks), but I suppose they'll change it when I least expect it. As Michel knows, I run only Linux operating systems, and my LAN is static IP only. I'm not sure if this will make things easier or harder. In any case I was pleased to find this thread, and hope it will help me. There is obviously a lot of info posted already, and I'm sure it will take me a while to digest it. Any suggestions or comments would be welcome. Linuxguy