mwester

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.

vi is to real text editors as a bootloader is to operating systems. That said, I'd agree that everyone should know at least the bare basics of VI.

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!)

Some tests with a collection of USB sticks shows that, in general, the current FreeBSD kernel on the Polisy cannot handle USB 2 storage devices plugged into the front panel USB ports. It works just fine with USB 3 storage devices. I've not tested with actual disk drives - just memory sticks. And I've not yet tested the internal USB 2 ports (need to dig up my motherboard cables for that connector -- why is that when you don't need things like that, you're tripping over them, but when you need them, they're nowhere to be found???). I also tried the USB 2 sticks with a USB 2 hub connected to the ports (a solution that I've used for flakey USB-2 devices on laptop USB-3 ports in the past) - no difference. So it suggest the problem is the USB 3 chipset or an OS driver bug... Here's the kernel messages from one such device, for those interested: ugen0.2: <USB Flash Disk> at usbus0 umass0 on uhub0 umass0: <USB Flash Disk, class 0/0, rev 2.00/2.00, addr 1> on usbus0 umass0: SCSI over Bulk-Only; quirks = 0xc100 umass0:2:0: Attached to scbus2 (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (probe0:umass-sim0:0:0:0): Retrying command, 3 more tries remain (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (probe0:umass-sim0:0:0:0): Retrying command, 2 more tries remain (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (probe0:umass-sim0:0:0:0): Retrying command, 1 more tries remain (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (probe0:umass-sim0:0:0:0): Retrying command, 0 more tries remain (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (probe0:umass-sim0:0:0:0): Error 5, Retries exhausted ugen0.2: <USB Flash Disk> at usbus0 (disconnected) umass0: at uhub0, port 4, addr 1 (disconnected) umass0: detached For comparison, here's a USB 3 device that works: ugen0.2: <Kingston DataTraveler 3.0> at usbus0 umass0 on uhub0 umass0: <Kingston DataTraveler 3.0, class 0/0, rev 3.00/0.01, addr 1> on usbus0 umass0: SCSI over Bulk-Only; quirks = 0xc100 umass0:2:0: Attached to scbus2 (probe0:umass-sim0:0:0:0): INQUIRY. CDB: 12 00 00 00 24 00 (probe0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (probe0:umass-sim0:0:0:0): Retrying command, 3 more tries remain da0 at umass-sim0 bus 0 scbus2 target 0 lun 0 da0: <Kingston DataTraveler 3.0 > Removable Direct Access SPC-4 SCSI device da0: Serial Number 002618887F9BF050584230A0 da0: 400.000MB/s transfers da0: 7377MB (15109516 512 byte sectors) da0: quirks=0x2<NO_6_BYTE>

Yep - has the "mount_smbfs" command but missing the kernel module for smbfs... (Can we request this kernel module as well? - Thanks!)

Love to see the "unix2dos" package in the feeds -- provides both unix2dos and dos2unix utilities, which are rather nice for those moving files/content about. The kernel modules for the automounter would also be appreciated -- it would be nice to have the system automount a USB stick when one is plugged in. A long, long time ago, in a galaxy far, far away, on a network device that also offered no console for the average user, for our beta test units, we devised a means to extract logs and IP information from the device that involved a USB stick with a very specific directory layout. Applying that to the Polisy, one might envision a USB stick, empty except for a folder named "UDI" or "POLISY". Upon plugging that into the unit, and waiting for a prescribed period of time, one might unplug that USB device, and find a few files in that UDI or POLISY folder. An "ip.txt" file, for example, might have the IP address and networking information (to help a user find a Polisy that's been lost on the network). Perhaps a "logs" folder might contain a copy of the boot log (dmesg), the logs in /var/logs/*, and the polyglot logs. Going even further, one might envision that one could create a simple text file with network information that the Polisy could read from that USB device -- I'd imagine this would be used by a non-technical user who might be unable to get the Polisy configured with DHCP on their router, for example. For ease of use and security, it might make sense to have a simple page hosted on udi.com that would allow the user to enter their Polisy's serial number, the desired network information, and the site would create a downloadable "config.udi" file for the user to put in the correct place on the aforementioned USB stick. It wouldn't be hard to obfuscate the config.udi file, if desired, to make it less likely that someone other than the owner would play with the USB ports and change the networking config by accident (or maliciously)... although frankly, I think that being able to disable the config.udi feature via the web UI would be a better solution for those who don't need that feature. Now, this is a terrible hack, I'll be first to admit! But, when a device has no console, and the user is unable to talk to it on the network, you need to look around to find what that user might have that matches a port in the device, and it seems to me that the ubiquitous USB stick is probably the most likely thing lying about...

@Michel Kohanim - as an expert in breaking things (and generally pretty good with recovering them), I'll happily volunteer to be an early tester for that recovery mechanism. Let me know how I can help.

Yep, that pretty much matches mine as well. Most of the filesystems are pulled out of a single pool, and it looks like that pool is 5.2 GB in size, total. The partition table on the SSD suggests it's sized to the full 32GB. I've poked around with the zfs command, and it doesn't look like the various filesystems are using the multiple-copies approach, and it makes no sense to have RAID running on a single SSD, so there's clearly something else going on.

FYI, only the first slot supports msata cards -- the other two only have the PCI signals it would appear.

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?