mwester

Kinda sorta mostly. There's no way to configure or set up the tags or the tag manager locally... so you need their cloud server for that. However, in that setup you can give the tag manager a local URL to a system of your choosing, and once that's done the tag manager device will operate locally (even if the connection to its cloud server is missing). So, the node servers (and other things) that one uses with these devices are local, but the system as a whole is dependent on a cloud-based service. I use a few of these for non-critical things -- I despise cloud-based services (look at what's happened with the Nest, as well as with a few of the providers that have ceased operation) but I rationalized these things based on their low price and the fact that they mostly work locally. If the provider starts charging for their service, or go under, well, the tags are pretty much disposable at that price point.

Yes, it has bluetooth -- like all modern computer wifi/bluetooth combos, it shares the antennae with the wifi. One could reasonably expect that the antenna issue might affect the bluetooth, but in as much as the bluetooth is not yet enabled on the Polisy, it doesn't matter at this point. One the driver is sorted out and all that, there should be an update to the Polisy that would enable the bluetooth functionality - no idea when that might be, though.

Just a guess - but it sounds like maybe you didn't update your UI to match the new firmware release? That's the first thing I'd check when you seem to have so many things "gone missing".

Never looked at mine, since I don't use the wifi (folded up the antennas, and ignored them...) - but same here. I believe the correct terminology for those connectors is SMA and RP-SMA (for Reverse Polarity SMA). And no, it's not normal to attempt to connect an SMA with an RP-SMA - as you note, the center pin (the antenna) will never connect, so it's pointless. The manufacturer's site doesn't state conclusively if mixing the two was intentional, but I'd have to assume that it wasn't intended - probably the one pigtail from the card to the chassis is wrong. It might be really convenient to have one of each -- the SMA is the "standard" connector, but a lot of routers early on used the RP-SMA (Linksys for example). So I have a few higher-gain antennas with the RP-SMA connector that should fit very nicely - and add a bit of range to the wifi. But for those who don't want that, perhaps swapping one of the antennas out, or using an adapter is the solution. A glance at Amazon shows dozens of adapters all about $5/pair -- and likewise, numerous RP-SMA wifi antennas, at all sorts of prices (not all of which are legal in the US per FCC rules, but that doesn't seem to stop the sellers! )

I'm betting you're using a Mac. Your browser is automagically expanding the "zip" file and showing you the contents. You'll want to download the zip file as a single file. Not being an Apple-person, I don't know how you do that - just that many on this forum have encountered this same problem. So if you need more info, I'd suggest a deeper search for firmware issues with Macs might find exactly the solution you need.

No big deal -- a lot of the early units got bounced around worse than that in shipping (mine arrived with BOTH the wifi and the SSD cards loose!). Just pop them back in place. The hardware designer chose to use spring clips rather than screws to hold the boards down, which is great for hobbyists, but as you've noticed, not so good for shipping.

Alas, no -- the ISY does not at present support the use of anything other than the primary admin account.

Sigh. Ain't that the truth -- and not just for hobby-related things, I have this problem at work too. I blame it partly on things like twitter -- we've an entire generation entering the work force that can't read anything longer than 144 characters. Anything more, and they want a video (!), or preferably, they want me to do it for them. The following acronym makes me "see red" -- anyone using this in an email or IRC chat even at work will find the conversation suddenly cut short due to "network issues": TL;DR Just typing that makes smoke come out of my ears... (I now return you to your regularly scheduled forum...)

I'm with simplextech on this one. I've seen too many cases of what I term "GUI-First" development, wherein the phone or tablet is the primary focus, and as a result, the actual functionality of the solution ends up suffering, or in a couple of cases, the core functionality atrophies into the smaller set of "whizzy" and "cool" things that one can do from the limited tiny GUI display and the user-level-assumptions that go along with that. I'll toss out an extreme idea here. I'd like to see the ISY/Polisy solution architected rather differently: a) Core functionality supported by a CLI that drives a REST API to do the work on the Polisy and the ISY. This functionality would include: - adding/deleting/managing devices and scenes - diagnostics and health - uploading "compiled" programs and network resources a) which implies that programs would have a text-based "source code" that would be "compiled" for one's ISY/Polisy This would address a large need for being able to manage and version control large implementations - particularly good for installers, for example. b) Core UI management functionality supported by a browser-based GUI that does a useful subset of the day-to-day activities involved in managing the Polisy/ISY. - includes uploading programs and network resources, but not authoring same c) An "authoring" UI built on anything UDI likes, that would allow GUI-based program and network resource creation, much like the current Java-based IDE does. d) A mobile solution that is a stripped down version of item b above, unless perhaps item b can be coded to work on both -- although I have to say that I find phone GUIs ported to a full-size web browser to be hard to use, annoying, and make me want to run to the command line instead... but to each their own. e) A authorization-limited version of the REST API should be exposed for general user use, along with a "web toolkit" (examples and a library) that would facilitate technical users creating tablet-based or phone-based or even PC-based apps to do user-level actions to control the automation. This would exclude management, and development activities, and thus should be a very small set of functions. The fact that it has a separate user (or better yet, auth key) would ensure that even if someone reversed the app, that person couldn't gain access to the admin level actions for the Polisy/ISY. I'm dreaming, of course... but if there's one thing I'd like to NOT see, it would be having UDI try to port the entire ISY experience to a phone. Please, please, don't go there.

Normal.

Excellent use-case that illustrates the challenges of programming something that humans would find so easy to do! A human being given a thermometer and the task to turn the fan on and off as you describe would have no troubles with understanding what to do, and handling the exceptions (e.g. the water warms up to 30, and never gets any hotter, nor colder -- eventually the human would turn off the fan and go figure out what happened... but alas, you'll have to sort out that (and other) failure cases on your own with the IS). So, first thing to note is that as you've already described, the obvious choice (a range of temps to trigger the on/off) isn't going to work. So, start by re-thinking that a bit. What *really* triggers the on and the off, if it's not the absolute temperature? I'd investigate the idea that it's the *direction* of the change in temperature as it crosses those select absolute temperatures that might be useful: if the temp now is greater than 25, and 30 seconds ago it was less than 25, then we're on the way up, and the fan should be turned on... opposite for turning off. Next, I'd strongly suggest adding some timeouts just in case. How long is long enough for the fan? And perhaps an alarm -- if you have a spare button on a KPL, one might illuminate that if the fan has been running too long. As for implementation, there is some dissension on the forum... some might favor writing this in as few programs as possible, maybe using folder conditions to do so. I find that becomes inscrutable and difficult to debug, so I would simply create a folder for "Bathroom Auto Fan" or something like that, and add a bunch of programs to that. I'm sure that you'll have plenty of folks offering detailed programs, so I'll refrain from doing so... mine are a bit complex, since they include auto-off timers, alarm states, and the like (I use this technique for the roof-deicing cables, door entry/exit alarms, bird-bath heater control, sump pump monitor, etc.)

Look up the parameters that this device supports (should be available from Zooz, I'd expect). Most vendors support a means to send a parameter to the device to change the nature and frequency of reporting -- some are easier than others, but I've had no problems adjusting my reports to the 5 minute range (I really don't need updates every 30 seconds - the temp and humidity don't change that fast!)

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.

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...