mwester

Based on comments elsewhere in this thread, the newer Insteon PLMs appear to have higher value capacitors, but alas, there's no indication that they are any higher quality (same manufacturer, same type, same physical size, just higher capacitance). I, for one, am highly skeptical of their claim that the problem is fixed.

BTW, the "<>" icon in the toolbar when you post will format the selected text as code, which will make it far, far more readable.

My syncrolinc gave me similar issues -- kept losing the links table. I was actually going to write a program on my RPi to contact the ISY periodically to query and correct the links table in it. Then I decided that was fixing the symptom, and I should fix the problem instead. (Plus, I blew the fuse inside the Syncrolinc, which was a completely unacceptable failure mode for the pump it was monitoring.) So, I now use an A/C current sensor (a few bucks on eBay) and an IOLinc instead. Much nicer. (Search for "Neilsen-Kuljian D150" on eBay, or just look for "Current Operated Switch")

Y'all are just plain wrong! Electrical tape, light-dims, and all that still leave the dang thing BLUE! Power lights are green. That's the long and the short of it. Not just too intense, but wrong color! (Are ya listening, UDI?! Green! Make 'em green!)

BTW, once you complete this project, can you share your results? Specifically the resistor value you selected, and any tips for other interested folks who might like to try this? I'd like very much to get rid of the chunk of black electrical tape on mine -- which was my solution to that intense blue laser-beam emitted by the ISY. Dunno why manufacturers fell in love with those horrible blue leds; the soft green ones worked just fine and were far easier on the eyes.

Fire danger in basements is no greater than anywhere else - and egress windows/walk-out basements address exit requirements. Bronchitis? How? Proper HVAC installation ensures air quality is no different on any floor. CO2? See above. Radon? Tested, none here. Last house had a radon reduction system installed. Problem solved. SADS? How is the basement more dangerous? illegal? Say what? Is that what the Canadian government has been up to? Making laws about what floor is habitable? Good grief, talk about government overreach! Anyway, to help you stay on topic, why not just imagine that the OP wants a night light because his root cellar / freezer is down there, and it would help in those midnight snack runs!

Well, not yet. Once the 5.x release is out, cross-technology scenes will be available between Insteon, z-wave, and node-server-based devices (which would be one of the options for supporting the Hue). For now, though, you'll need programs and network resources.

There's no evidence that the capacitors are "higher rated" - just reports that they are higher capacity.

Ok, you're right -- "Enable Internet Access" is a poorly-named menu item that does not do what the name suggests. And even worse, what it DOES do is not supported by most current routers any more. And you're right about the Help/About text -- it too should not read "Internet Access Disabled", but should probably say something about your router not supporting UPNP. But since portal access has nothing whatsoever to do with either of those two items, just forget about those. The portal works in the OPPOSITE direction -- my.isy.io does NOT contact your ISY, rather it is your ISY that connects OUTWARD to the my.isy.io portal, and establishes the connection. So that message is telling you that your ISY has not contacted the portal. Which has nothing to do with the ability for you or anyone else to connect INWARD to your ISY from the internet. Since your ISY is responsible for establishing the connection to the portal, not the other way around, the error logs and information to debug this are on your ISY. The error logs, as MWareman suggested, are a good place to start. When mine refused to connect, it turned out that the problem was exactly as suggested -- the cipher set on my ISY was incorrect, and it was unable to establish a secure connection to the portal until I fixed it. The logs on your ISY tell the story.

Yes - the suggestion is to get a thermostat. It's the right tool for the job. Yes, we understand that you have a multisensor, and it has a temperature sensor in it. However, a thermostat does a lot more than just read temperatures, and that's where you're getting stuck on this thread -- all those other "bits" are hard to do. By analogy, I have several bicycle wheels in my garage. I want an automobile to drive to work this winter. But I don't want to buy one, because I already have four bicycle wheels, and all I want is to know how to put the rest of the car on top of those wheels. Clearly there's a lot more to making a car than just four wheels. And there's a lot more to a thermostat than a temperature sensor. So just buy a thermostat, and be happy! The right tool for the right job.

Er, three PLMs? Yeah, I'd agree that it's probably not the PLM. So, how about the cable? Head off to Best Buy or Walmart, and get a new network cable to use between the PLM and the ISY. And take a flashlight and check inside the female connectors for the serial cable -- might it be that there's a bit of stuff that got shoved in there that's preventing one of the pins from making contact (yes, that happens -- I'm embarrassed to say I spent an hour and disassembled much of a device a couple of weeks ago, just to find one of those little plastic "Made in Taiwan" stickers had ended up stuck in the female connector) Might it be the ISY? You haven't swapped that - and I think there's probably more debugging to do before you go there - but that's another thing in common that needs to be checked out. For that, the best thing to do is to do as stusviews suggests above - avail yourself of UDI's excellent tech support.

Generally (but not always) the green led is either dim or off when the PLM fails in the common (capacitor-failure) manner.

Expanding on Brian's excellent advice -- I use that same list to keep track of each unexpected event for each device, for example, each time I was forced to do a hardware reset on the device, or was forced to reload the links table to restore the device to operation. That's helped me identify with certainty a failing or troubled device (most useful for locations such as my kitchen, where I have multiple 3-gang switchplates full of Insteon devices, making it very difficult to remember exactly if the KPL that needs to be reset is the same one that needed resetting last spring, etc.)

Looks like the control with that one (C34) is a computer-based control -- so the wires are probably power and ground for the control unit, data-in, and data-out. There's no simple switch or relay that'll control that thing.

Er... you really do need to post manufacturer and model numbers (for both exchanger and the controller) for anyone to be able to help you out...

Awesome! Thanks!

??? What am I missing here -- what's the problem with engineered lumber?

Yes, events WILL be stored. For seconds, or milliseconds -- but the data WILL be stored for at least some point in time. And during that time, it's not under my control. Now, as for the second paragraph there -- I apologize. I sincerely did not understand that one is limited to one argument per topic. I retract all my concerns about security, and I guess I'll start another thread for that argument on this. Finally, I do apologize for offending you with my irrational and my inconsistent arguments. My training, if its any excuse, is in the area of software and systems security, and my experience arguing a case in front of a judge is pretty much zero. Sigh. Off you go then, enjoy an argument-free, conflict-free discussion, one that follows your rules as you make them up. [The above is, of course, sarcasm. This is not a legal court where arguments are presented to a judge - this is a forum, where ideas are discussed, explored, debated, and argued. There are no rules that state one is limited to one position or argument per topic. Nor are there rules limiting new ideas and thoughts. However, one IS free to make up their own rules as they wish -- but alas, nobody else is obligated in any way to follow those made-up rules. This discussion is an exploration of the issues involved in streaming events up to a cloud-based service; there are those who do not want to hear about any issues, and those who wish to marginalize those who bring up the issues in order to avoid discussing the technical merits. I hope that those who would implement can acknowledge the concerns of those who've brought up the issues, and implement the very simple mitigation that's been suggested.]

That's exactly what I'm asking for - a filter, so I don't have to use this feature!!!

I disagree. Reason 1: Fundamental security concept: Defense-in-depth. By analogy, you argue that there's no difference in putting your wallet, jewelry, etc. on the counter in your mudroom relative to putting that stuff away in a drawer in your bedroom (if not in a safe in your house). After all, you argue, if someone is going to kick in your door, they can just as easily go to your bedroom and find your jewelry as they can snatch it off the counter by the door and run. Clearly that's not true -- there IS value in making that stuff harder to get. Reason 2: Breaking into the portal and polling my device for data is quite different -- first of all, it requires a lot more knowledge and skill than just stealing a database or file with thousands of events recorded. Secondly, I can detect that activity at my firewall, if someone is polling my device -- I can't detect that someone has stolen that information at the portal, nor can UDI detect that. So clearly, security principles suggest that the former is the correct way to handle things. This very discussion illustrates what I've observed. People will rationalize all sorts of compromises on basic security concepts, just to gain convenience. Nowhere in this thread have I threatened ANYONE's convenience -- I've asked ONLY that it be filtered so that those of us who DO care don't have to drop the portal altogether.

Well, ok, I can see that data is free and bandwidth is unlimited, at least according to the posters on this thread. According to the logic above, I'd never bother with a dripping tap, because we'd calculate the number of drips per hour, the volume of each drip, calculate the gallons per month, decide that based on the personal experience of the other posters on the forum that anyone concerned about the bill for that amount of water has their water service delivered from Iran, and therefore is an idiot and should be dismissed as such. Fine, so bandwidth is unlimited. And data is free. Let's talk about security. Ah - no let's not. Most times we discuss security here, somebody p***es and moans that they don't have anything to protect and the vulnerability is of such low risk that the person bringing it up must have their security delivered via drone from Iran, and is therefore an idiot and should be dismissed as such. But regardless of forum opinion, I DO care about drips in my faucet. And I DO care about useless, unnecessary uploads of data -- both from a cost standpoint, and as I consider my discomfort with this concept further, I've become concerned about the security aspects of uploading every event on my ISY up to the portal. Doing that, frankly, makes the data the Google collects with Nest inconsequential! But, hey - I get it. Few here take security of IoT seriously. So, a big Thank You to Gary Funk for the obvious solution -- since I'm the only one who cares, I should just cancel my portal subscription. When this misfeature gets implemented, sans filtering, I shall do exactly that.

Bandwidth, and in particular limits, include packet overhead - so the few bytes blow up to a lot more by the time the event is wrapped in the XML tags by the ISY, and the TCP and IP headers are added. So filtering is absolutely necessary.

I've been playing with the Adafruit ESP8266 "Feather" HUZZAH -- it's basically arduino-like, but has built-in WiFi. I flashed the MicroPython firmware on it, and that works marvelously for integration with the ISY. I was planning on writing something up on this at some point... but time is an issue as always! [edited to add: to date, I only have it updating variables via REST on the ISY -- but I'm toying with the idea of trying to implement a low-power, low-speed, low-update-rate, low-everything Node Server...]

You have to be in the right version of firmware for the network module to show up -- 5.0.2 won't work, but 5.0.4 will. Don't know about the 4.5.x series though...

I get Teken's point -- I have customers who ask questions that make me wonder why they're asking, and make me eager to dig in further. But sometimes, it's just best to answer the question that was asked. On topic -- I have a mudroom/screenporch/garage setup that's similar, and I think this is a pretty neat idea. In particular, when unloading groceries from the car it would be nice if the blasted door would stay open, and even nicer if I could tell Alexa to release the door maget as I enter with my arms full of the last load of groceries. Essential? Not hardly. Convenient? Neat? Fun gadgetry? Yep!