mwester

Mine finally showed up - several days late. I think because it rattled so badly they were afraid they broke it and didn't want to deliver it? Both cards (WLAN and the 32GB SSD card beside it) were loose and rattling about. I popped them back in. The WLAN card popped right back out at me. A few moments with a pair of tweezers fixed the little springy retention clips for both cards so they won't be popping out so easily. Box looks very nice - love the logo on the front. Shame, though, that I didn't even put the cover back on -- it's got a whole bunch of connectors there that are just crying out to me. Step one: put a proper text editor on it. That was going to be the emacs-nox package, but I settled for uemacs, since "df" claims there's only 4GB of space there. I'm not familiar with zfs - what happened to the rest of the 32 GB SSD? The resolv.conf is not quite what I think we'd like -- it provisioned an IP address fine, but put the local DNS server at the end of the list. It also ignored the domain name provided with the DNS server. So, it couldn't resolve any of my local hostnames with the domain name because it got a negative response from 8.8.4.4 first -- and it couldn't resolve any local hostnames without a domain name correctly, because it tacked "udi.com" on as the domain name. That was an easy edit, but I expect I'll have to fix it each time it boots. Next up - attaching a serial console, and seeing what it does with an SD card in the internal slot, testing a 128GB msata SSD I've got lying around in that third slot, and then seeing what magic might happen with the sata port and an external hard drive. Given all that, it would be good to know how one would recover the Polisy after I manage to destroy the root filesystem by doing something foolish... what's the plan there?

Afraid? No. Are they disappearing? Well, my opinion is that they certainly seem to be on the decline. We've talked about the evidence, some here discount it, some don't. For me the key item comes down to the fact that the Insteon protocol has seen no progress, no revisions, nor even any hint of changes to address the fact that the power-line has become a very hostile place for devices that depend on a quiet zero-crossing, as does the current Insteon protocol. As we all modernize our home (LED lighting, switching power supplies, etc.) and add solar power, and add ever more electronics, the probability that Insteon will work in any given home will become less and less. While at present, security is largely rejected as a concern by members of this forum, the industry as a whole is being pressured to implement some level of security -- another area that would require an Insteon protocol revision. So if you net it all out, it sure does look like the long-term future of Insteon as a technology is in doubt. As some here point out (which I think is self-evident, but apparently not?), nothing is going to make your Insteon devices stop working if Insteon or Smart Home goes under. However, as consumers upgrade kitchens, replace lighting, and do other work around their homes, they'll find their Insteon network reliability ever decreasing, and I think Smart Home has done themselves a terrible disservice by not having a "Next Generation" product available for upgrade -- those dollars will go to some other manufacturer. It's not too late -- perhaps they've a super-secret development project that they're almost ready to reveal, with a plethora of new devices, and new protocol featuring immunity to the zero-crossing problems, de-coupling of the RF from the zero-crossing, security, and perhaps even a "bridge" device to bridge comms between the old and new protocols. One can dream. (Alas, I'm a pragmatist, and dreams don't do it for me -- so I'm migrating to another technology that works better in my home.)

Actually, some of your posts HAVE been quite abusive -- in subtle, passive-aggressive manners. Also, quite a number are rather offensive. And as for agreeing -- I quite recall a recent post where you flew in with a response deriding me for things that, in fact, were not even present in the post! I don't doubt that YOU think your posts are all fine -- in fact, I'm certain you do think that. I see it quite differently, and find your attitude and approach, especially when it comes to my posts, to be "trollish" -- in particular, I can guarantee that ANY post of mine that contains either the words "Insteon" or "ZWave" will elicit an immediate negative counterpost, whether appropriate or not! This doesn't add value to the board, and serves to annoy not only me but I'm quite certain others are weary of it as well. But you're quite right -- just like the loud boorish person at the other table in the restaurant, you have the right to say whatever you want, whenever you want, and however you want. I've asked you several times now to cease, and have offered a suggestion that I think would help. That's all.

I'll ask you, once again, to please put me on your ignore list. You'll be happier, your blood pressure will be lower, and since basically all you ever do is highlight how worthless, pointless, or in-error my posts are, you'll clearly not be missing anything if you ignore them. You clearly are unable to ignore or pass on by posts you don't like, that's exactly why the "ignore" option exists. Please - help us all be a happier bunch -- put me on your ignore list, and let's move on.

I too have wondered why Insteon hasn't licensed the technology -- if they don't have the desire or capacity or capability or funds or whatever, perhaps someone else does. On the other hand, perhaps nobody is that interested in power-line signaling anymore -- it has some serious issues when it comes to co-existing with modern energy-efficient appliances, devices, and even bulbs. But that's an academic question in that I'd love to know the answer, but the answer isn't going to change what I have to do (which is, I have to figure out how to make the most of my existing Insteon investment while gradually migrating to a technology that looks like it has active support, innovation, and a future). As for the fan question -- I wonder if it's as simple as the fact that the old-fashioned AC motor ceiling fan is on the way out, being replaced with more efficient DC motors? The best one can do with generic switches of any type or manufacture on those DC fans is to turn them on or off entirely -- you can do that with a simple relay. They all use proprietary (usually RF) means to switch speeds and direction, alas. Still, despite that inconvenience, I'd not swap my ceiling fans for those old AC fans! I use an Insteon SwitchLinc on the one in the master bedroom, but I could have easily tucked an Inline-Linc in the canopy if I needed to (oops - they discontinued the Inline-Linc, I think -- so hopefully your fan motor won't overload the micro on-off which apparently replaces it...) Edited: "Zwave hasn't progressed in 10 years" says a poster on this thread... I think that about wraps it up for this topic -- the IDF (Insteon Defense Force) has been fully activated and mobilized, and all dissenters from the One True Insteon Way(tm) will be silenced!

zxplod, you're right on -- innovation is key, and Insteon has shown little over the past 3 - 5 years. The arguments by the Insteon fan-boys might be valid if home automation was a mature marketplace, for instance like your gasoline-powered automobile where there's little true innovation left to be done and the battle between the vendors is about "glitz" and "glitter". But that's clearly not the case in HA. In addition to new device types (where Insteon has actually removed devices - like the 10v dimmer device, and the siren), there's also the need for protocol enhancements (RF that works without synchronization with the power-line, for example, as well as the need for protocol extensions to provide security) -- and Insteon has shown no initiative in either of those areas. Swipes at other technology by pointing out their shortcomings doesn't eliminate the shortcomings of Insteon -- it does, however, point out that the entire industry is pretty suspect.

Search the forum for mentions of the "all on" problem.

There are two firmwares for the ISY -- one will put the ISY into a "safe" (non-operational) mode when the PLM fails, the other does not -- both will work with z-wave and (if your PLM is working) with the Insteon devices. So, if you switch firmwares, you'll at least keep everything else running when the PLM fails (until you can switch those last few devices over to Z-wave or other technology).

Physics is certainly different in my house. Even (especially, actually) when people aren't present, the temperature stratifies... so comfort in my house is improved by running ceiling fans in several of the rooms during the times of the year when the forced air isn't running often...

Hmm... a defective logic board perhaps? If you're concerned about a rogue remote, does the unit have a "lock mode" or "vacation mode" that you can enable to effectively disable the remotes?

See my earlier post, particularly about the long wires and noise pickup... Edited: By "unplug" do you mean the 3.5mm plug that looks like a headphone jack on the IOLinc - if so, isn't that the sensor in, not the relay out that would switch the GDO?

Do you have a yard light? Any other loads, on your lot or nearby that switch on or off at about that time of day? A marginal circuit on the long length of wire between the iolinc and the GDO, combined with the electrical characteristics of the iolinc, might be just the right thing to trigger the GDO to think you've pushed the button when it picks up some radiated electrical noise. One way to test might be to get a completely different cable (say, a length of gigantic romex -- something completely unlike the little micro speaker wire they often give you for the GDO buttons), and use that to temporarily replace the existing wiring (disconnect the existing wires altogether, both connections to the GDO). Often a different gauge wire with different electrical characteristics, following a different cable run, will change the noise pickup enough to figure out if that's a possibility. If that changes things, then first check the connections on the old cable, and use RF chokes at the GDO end on both conductors as a first step to cure. The noise might also be coming in via the GDO's power plug -- a good filter will address that, look for a power strip that advertises not just surge suppression, but also noise reduction. Ugly, but plug that in temporarily to see what changes, and then you can decide if you need to find something smaller/nicer or if that's not the problem.

This illustrates everything that is evil about the cloud model for IoT -- you get a whole bunch of all well-meaning individuals and organizations together, and with the best of intentions (even noble, in some cases -- saving the planet is certainly a wonderful ideal, isn't it?) -- and they end up creating something that kills goodwill and trust at a minimum, and hijacks otherwise-perfectly-working HVAC systems at worst. My concern has never been that these companies would suddenly, one day, wake up, laugh nefariously, and set out to damage their customers. My concern has always been the opposite -- that one day, someone at one of these companies would decide that they know better than I, and for my own good, and with the best of intentions, they would proceed (just as Ecobee has done) to force their will upon my equipment, my home, my property, and ultimately attempt to force their will upon me personally. Take this to heart, folks -- never use a cloud-based service for anything other than convenience (i.e. if you or your house can't survive with it unplugged, don't put it in the cloud!)

http or https?

Been there -- my case was an ancient farmhouse so i wasn't too worried about how my solutions looked, you may need to take some care, though. Here's what I learned: a) Hard-wire everything important. Avoid Insteon, WiFi, or anything else that doesn't have its own separate wires for communication. The problems with wifi are obvous, but it turned out that Insteon was very sensitive to generators (translation: didn't work at all on the admittedly-low-budget generator I bought). b) Instrument everything you can! I put in a small Linux device (pre-dated the Raspberry Pi, but that's what I'd use today if I had to do it again), so I had lots of room for wired buses. One that proved unexpectedly invaluable was the string of one-wire temperature sensors that I had. I ran a couple to the basement, wired to the water in and out pipes on the boiler to monitor the heat there -- I put one on the wall near the main thermostat -- the rest I just stuck in various rooms where convenient as I tacked up the wire running from the thermostat wall to the garage door, then out to the basement stairs, and in (yes, ancient old house -- the basement stairs were outside...). Turns out that a massive temperature anomoly being reported actually was telling us that a window had been broken (tree limb after a huge fall storm). I was unable to instrument the heating oil tank (you should be able to get options for that on your propane tanks, though) -- but over the 5 years, I was able to easily predict the oil level by collecting the run-times for the boiler from the thermostat and boiler instrumentation. c) Cameras. Not for thieves -- we left worst of those behind in Chicago! Rather, just so we could observe the house remotely -- snow load on the roofs after a storm was one concern. Generally, though, it helped me prepare for a visit -- does it look like I can get into the driveway, or should I expect to park on the street and shovel for a couple hours (after driving for the better part of a day - yay, what fun!). Note what's absent -- no controls. I deliberately avoided that temptation -- there was quite enough to go wrong without me adding gadgetry that might fail and add to the problems. I actually removed the set-back thermostat in the house, and replaced it with an ancient mechanical Honeywell thermostat -- reliability. It might have been nice to arrive to a warm house, but we preferred to live with a bit of a chill for a few hours rather than risk something going wrong with an electronic thingummy and having the house freeze. (Power was unreliable - and glitches were common -- I'd already observed that I generally had to reboot the cable box every time we arrived after a summer storm, so I wanted as little computing equipment running as possible - and what I did use, was on a UPS.) Oh -- one big concern was water - the plumbing was prehistoric... I started by turning off the well pump when I'd leave the place, which worked great in the summer. In the winter, I worried about a couple of poorly-insulated pipes that had a history of freezing, so I started draining the house pipes as well -- that was probably reasonable given the house was a "short term" thing -- but the de-pressurization and re-pressurization of the plumbing proved to cause a lot a headaches (read: leaks in pipes and fittings). If I had to do it over again, I'd spend the time to insulate those pipes, and settle for just turning off the water pump. Note that plastic piping (cpvc or pex) won't have such a problem with that...

I have a similar situation with a mud-room light. It needs to be on in the evening for a few hours, and stay on (so the dogs can see their dog food bowls). It needs to turn on when the outside door is open, and turn off when the door is closed. It needs to be turn on automatically if someone enters from hallway, and stay on while the room is occupied (laundry, perhaps). The solution for me is a door sensor and a motion sensor, and a switchlinc dimmer for the light. A series of programs are triggered by time-of-day, by the motion sensor, and by the door sensor. Each program sets the light to a specific brightness (very close together so the human eye can't tell the levels apart) -- this allows any program to determine if the light is already on, which other program set it to on by the specific brightness level. Thus, when the program goes to turn it off again, it knows if it should do so or not. As a specific example, consider the motion sensor tripping at 9:05PM -- it will find that the light is already on at 99%, and will leave it that level because that's the level for the dog's evening timer. Thus the motion sensor won't end up plunging the dogs into darkness. However, at 11PM, if I walk into the mudroom to let one of the dogs out, the motion sensor will turn the lights on at 98%. Opening the external door will run a program that will note that the lights are at 98%, and won't turn the lights off on me when I close the door. Turning on the light from the switchlinc results in it being set to 100% on -- and none of the programs will turn it off if they find it set to that value (because you turned it on manually). You get the general idea I'm sure -- use the brightness level to record who and why it was turned on, so you know when what program is allowed to turn it off.

Love the sail switch -- that's an excellent example of a simple "hack" to effectively create a new insteon device type!

Updating a single value or variable in the ISY every 2.5 seconds is a bit much -- it would work, but in my experimentation, the updates were often delayed a bit, and sometimes the ISY would simply not be ready and the update message would be dropped (this would happen all the time during the 3AM query, and often when the system was busy with other intense updates). My point being that something like a full update of the entire screen for a weather station is probably far too much for the ISY to handle -- perhaps once per minute might be a better way to do it (I'm not at all sure that the 30-second long-poll time in Polyglot would be long enough).

You'll get lots of opinions on this. There seems to be a school of thought that says your home automation system should keep track of absolutely everything about your schedule and movements and preferences and should adjust and tweak the HVAC to suite you. There's another that says your HVAC system should be isolated from your home automation system, either because it's not necessary, and/or because the risk that a failure in the programming or the hardware of the home automation system may result in damage to the house due to the HVAC failure or mis-control. I'm in the latter camp -- where I live, a failure of the heating system could do massive damage to the house in below-freezing weather, so I prefer to have no direct control of the HVAC by the ISY. However, the house is also new, with radiant heat in the floors, and lots of stone and tile -- the point being that it's actually more efficient to have a single set-back per day, and that being just a minor couple-degrees tweak. So, put all together, there's just no compelling reason to connect the HA and the HVAC systems, and there's actually a very good reason to NOT connect the two together. I can envision, however, a more southerly-located house with less thermal mass -- and such a house might be different. If it were practical to cool the house by 6 - 10 degrees in an hour, then perhaps being able to have a geo-fence at your work location trigger when you leave work, and start the A/C might be useful if don't have a predictable work schedule (if it is predictable, well, then a set-back thermostat would work equally well). Perhaps if the HVAC is not well-tuned, or perhaps undersized for a house, or perhaps if there were add-ons to the house, then automating duct boost fans might be useful. Perhaps if the windows were not solar-reflective glass, and lacked an awning, then a light/lux sensor might be useful to compensate in advance for the heat gain through the glass -- or perhaps it could automatically draw the curtains. So my personal thought -- if your house is newer, well-constructed, and has a well-tuned and properly-sized HVAC system, then you're only going to screw it up by automating it... on the other hand, if it's not all of the above, then there may well be things you do better with some "smarts".

I'd also make a point to swap the power supply and see if it might be a marginal power supply -- they've been known to cause all sorts of mayhem as they go bad. The ISY can take a wide range of input voltage, so you should easily be able to find one you can "borrow" from something else in the house for a test.

There are many ways to attack a system, and username/password is only one means of doing so. I am sure I am about to enrage some of the forum members here, but I mean no disrespect to UDI -- merely stating the truth, and that is that it is not known how the ISY's protocol stack will stand up to attacks compared to (for example) the Windows or Linux stacks. The latter two have been heavily tested by many researchers, with numerous tools ranging from static code analysis through protocol fuzzing. And, we're *STILL* finding bugs and issues in those stacks. My point is that it seem probable that there are unknown issues in whatever code is running in the ISY, and for that reason, fronting the ISY with something like the UDI Portal makes a lot of sense - far, far more sense than opening up whatever that protocol stack is to the internet. So, while we're on the topic, one of the other reasons I'm looking forward to the Polisy (gah, that spelling makes me crazy!) is that it'll be running a codebase that while not as common as Windows or Linux, is still known to be one of the best and most robust network stacks out there. I'd be willing to expose a Polisy port to the internet - but given the lack of knowledge out there about the code running on the ISY, I'd never expose an ISY port to the internet. Again, it's not about password or user ids... there are MANY other ways to attack a remote system.

A USB-to-Serial adapter won't do the job -- USB requires a connection to a host, and the PLM is an endpoint, not a host. I explored the use of a Raspberry Pi as a communications relay back when I had need to view the data-stream and timing between the PLM and the ISY. It works, but it's really quite the wrong way to do it. Given that PLMs self-destruct after two years, it's not a bad idea to buy a new one, especially if you've had that USB one plugged in for a year or so already.

Having the Polisy side-by-side to an ISY is pretty much like an RPI - that is true. I'm eager for when the Polisy will subsume the ISY functionality -- for me that will mark the point where node server will really start to live up to their potential. (The show-stopping issue for me is that the very limited TCP/IP stack in the current ISY is not carefully enough handled in Polglot, so under load messages and updates are dropped).

Important things like home automation controllers should NEVER rely on wifi -- so mine will be wired in. That leaves the WiFi (and bluetooth) free for me to do all manner of interesting things -- like listen for specific WiFi hot-spots or devices (in a pure "monitor" mode), for proximity detection. I've a few ESP8266 devices that do interesting things, and when they blow their little firmware brains out and reset themselves to their default empty firmware, they start broadcasting on Wifi as a hot-spot -- listening for that will quickly alert me that one or the other of those devices has gone all wonky again (hey, what do you expect when you pay $5 for a microcontroller with WiFi built in???) Another though is that right now when the home network goes kerplunk, the ISY can't be reached -- so turning the WiFi into a WiFi hotspot for the sole purpose of letting a browser connect to manage the Polisy is also on the list. Depending on the chipset used for the WiFi, I think I can do both monitor and hotspot at the same time, but if not, it'd be easy to "mechanically switch" that on, for example by plugging in a USB stick with a special code on it to signal that it should enter hotspot mode. What can't you do with an open device like this?? Node Servers are great, but they're just the start.

Donate it to your local school.