mwester

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!

I was told, indirectly, that my comments about bandwidth concerns were not welcome on this topic. Nevertheless, I feel compelled to comment -- has anyone checked just how much traffic there is in the Insteon event viewer over the course of a day? And all of those events are supposed to be sent, in real time, out my internet connection to the portal -- to be queued up to be delivered to some remote app that may not even be powered up? That costs money - to me, starting at my uplink. To UDI (and thus to me next time my portal subscription needs to be renewed) when they need more AWS machines to handle all this traffic. And so little of this, so very very little, is ever going to be delivered! Clearly the filtering (there has to be filtering) has to happen at the ISY.

Nope, the network module doesn't do anything for those. I looked at the API for those some time ago -- they contact an Amazon-owned service, which then calls to your AWS-hosted service to deal with the event. In other words, in addition to being dependent on Amazon's cloud-based service, the device would also be dependent upon your own cloud-based service -- which ultimately could contact the UDI portal, which could relay the event to your ISY. That's three separate cloud-bases services, all hosted in Amazon's cloud -- just for a button in my house to send a message to the ISY in my house. Yikes! Rube Goldberg would be proud of the state of IoT these days...

I'm imagining the possible snarkiness that might be evident whenever Alexa is asked to call upon Google for assistance...

Whatever you end up doing, please please make it "opt-in"!! I really do not want to have to compete with my ISY for outbound internet bandwidth! Now, I know its probably peanuts to all you in the big cities with your 100 Terabyte/Second fiber optic links to your houses, but many of us in the smaller towns have far, far slower links and suffer with the horrors of data limits on top of it. A constant stream, 24x7, of ISY events going to the portal will add up over a month.

Can you buy a google home yet? I read an article (from a not-so-reputable-looking site) that claimed google will have contractual language prohibiting any company who has created an Echo integration from participating in the google home ecosystem... I expect that from Apple, but not from da google.

Cloud Messaging? Is that like when airplanes write something overhead at special events? Seriously, anyone have any URLs to what these things are?

Safe mode usually means your PLM bit the dust. And the 2-year thing sort of confirms it -- SmartHome's PLMs die (due to poor component selection) right at the 2-year mark -- see the the PLM repair thread here for more info. At this point, you can try unplugging the PLM and ISY, then plug in the PLM, wait a few seconds, and power up the ISY. It might work for a few hours or days while you wait for a replacement PLM. Once you get your new PLM (good for another two years), make sure you follow the replacement procedures and do NOT do a DELETE PLM (or all is lost and you get to start from scratch!).

Nope - I've a few of these, along with a whole other variety of KPLs, and they all work pretty much the same in scenes. Perhaps if you can be a bit more clear about what "they don't work" means, it would help try to figure out what might be wrong. As for the one that shows the status of the garage door, isn't that exactly what it should be doing?

Doing nothing apparent to us on the outside. I guess there's a small chance they "get it" that power-line comms are getting more difficult and that their RF solution is crippled by coupling to the power-line. Perhaps they "get it" that the world needs at least some semblance of security on the RF and power-line messages. And perhaps because of that, they're busy redesigning all their products for some new magical 'v3" insteon comms mechanism, and once they bring that market, they'll be well positioned to release a bevy of new products to take on the creative z-wave stuff already on the market, and even surpass them all. And, perhaps my dogs will both sprout wings and learn to fly.