mwester

Connecting to the Polisy Serial Console Port - Hardware When things go all wrong... or when you think something you're about to do has a chance to go all wrong... then you might need access to the Polisy serial console port in order to recover. This post and thread is all about connecting the hardware in order to gain access to that port. (Note: PLEASE start a NEW THREAD for your questions and issues, this thread is reserved for HOW-TO information, not debugging, troubleshooting, or questions!) (1) Acquire the USB to TTL Serial Cable First things first -- you'll need a USB to TTL Serial Cable to connect your PC or Mac to the Polisy serial console port. You want THIS ONE. While there's nothing special about the Polisy's internal serial console port (it uses the pretty-much standard 3.3 volt TTL RX and TX signals), a potential pitfall is the lack of standardization of the USB-to-TTL serial cables themselves -- they often use different chipsets internally, and different color coding, and different device drivers. (The end result being that if you can't get a prompt, it's fiendishly difficult to determine if the problem is the terminal program you're using, the driver for the cable you've got, the pin connections you've guessed at, or perhaps the Polisy hardware is in a state where it's not talking to you...) So, once again, you want the Adafruit USB to TTL Serial Cable, product #954: https://www.adafruit.com/product/954 (Note: If you choose NOT to use that product - start a NEW THREAD for your questions and problems -- this thread is reserved for HOW-TO information using that, and only that cable!) Next, install the software you'll need. Follow the instructions on the Adafruit product page (use the links above) to install the device driver, and other software, as appropriate for your computer. Note that the Adafruit pages will take you to a topic that is all about connecting to a Raspberry Pi's serial port -- that's fine, since the Polisy's serial port is electrically identical. So just follow the guide to configure your Windows, Mac, or Linux host, and you'll be all set. The details of what to do, and how to use the serial console are NOT the subject of this thread -- this thread is about connecting the hardware, and nothing else! So please, please, start another thread to discuss your issues, questions, concerns, or anything else about the terminal software and everything else associated with using the serial console once it's connected! (2) Gain Access to the Polisy Serial Console Connector The console connector is a white 5-pin connector inside the Polisy, right up front on the circuit board. Start by opening up your Polisy -- power off your Polisy, remove the screws holding the top cover on, and gently lift the cover off. Identify the connector -- it's the one circled in red in the photo: (3) Tape or Tie Back the USB to TTL Serial Cable's Power Pin Play it safe -- tie the extra, unused power pin (the one on the red wire) on the Adafruit USB to TTL Serial Cable back, out of the way, so that there's NO chance it'll touch anything it shouldn't! That pin is live whenever the USB connector is plugged in, and it is most assuredly not a good thing should it touch anything in the Polisy! So, get it out of the way. I had a twist tie handy, but electrical tape is also perfectly useful for this purpose. (You could cut it off, as well, but that seems excessive to me...) (4) Move the Jumper You'll note there's a jumper connecting two pins on the serial port -- that jumpers the RX (received data) line to the ground pin, and it's there because if the RX line is just left floating (connected to nothing) it picks up electrical noise, which can look like random keystrokes to the Polisy. While mostly the random keystrokes won't do anything, they'll certainly suck CPU cycles as the Polisy tries to figure out what commands it's getting. Moreover, since the port is operating at over 10,000 characters per second, the laws of statistics say that it won't be too terribly long before those random keystrokes actually end up being a valid sequence that'll instruct the Polisy to do something you won't like it to do! We're going to need to remove that jumper (you did remember to power off the Polisy, right? If not, do so now). Murphy's Law states that since you need that jumper, it's almost certain that you'll lose it. So, instead of putting it on your bench, or in your coffee cup, or goodness-knows-where, just shift it over a couple slots to that it's plugged into the single pin on the end of the connector (with half of it hanging over the edge). Not only does this ensure we don't lose that jumper, it also makes sure we don't accidentally use that end-most pin -- it's live and connected to the Polisy internal power bus, and we DO NOT want to connect ANYTHING to that pin -- or the pin on the extreme other end of that connector (both of the end pins are power pins -- we're going to be using ONLY the middle three pins!) (5) Connect the Serial Ground As with every electrical connection, one ALWAYS connects the ground first. That's the black wire on your Adafruit USB to TTL Serial Cable -- connect it to the pin shown in the photo below. Check carefully which pin is which -- in the photo below, the jumper (with the red arrow) is on the extreme right-most pin with half of it hanging over the edge, and the ground connector is on the adjacent pin (black arrow). If you get it wrong, you'll either short one of the data lines to ground, or worse yet, you'll short the Polisy's 5-volt power-supply or it's 3.3-volt power-supply to ground. Neither is good. Double check after you've plugged it in. Seriously. (6) Connect the Transmit and Receive Data Wires You've tied back the red wire on the Adafruit USB to TTL Serial Cable, and you've connected the black one. That leaves only the RX and TX data lines to connect -- these connect as shown in the photo below, on the other two middle pins of the connector. When you're done, double-check -- you should have the jumper on one of the end pins of the Polisy internal serial console port, and the pin at the other end of the connector should be empty! (These are power pins from the Polisy - we have no need for those. And whatever you do, do NOT connect the red wire from the cable to either of those end pins!). (7) Using the Serial Console Now what? Well, you've done all the hard stuff - now all you have to do is start the terminal software (the last part of section (1) above, which you've already done, right?), and power up your Polisy. The output from the Polisy's boot sequence will appear, and you'll end up with a prompt to login. Login just as you would with an SSH connection. The details of what to do, and how to use the serial console are NOT the subject of this thread -- this thread is about connecting the hardware, and nothing else! So please, please, start another thread to discuss your issues, questions, concerns, or anything else about the terminal software and everything else associated with using the serial console! (8) Preparing for the Future Make life easier -- mark the connector with the wire colors so it's easier next time. In the photo below, I had some green painter's tape that I marked up... in retrospect, blue tape would have been easier! But if you look closely at the connector itself, beneath the black cable pins, you'll see the markings... (9) Putting Everything Back When you've done what you need to do, you can simply remove the cable -- but it's best to do this with the Polisy powered off, of course. And don't forget to put that jumper back into the correct place -- it jumpers the RX line to the ground line -- refer to the photo above to make sure it goes back into the correct place. (Note that if you get it across the wrong pins, you'll be very unhappy: shift it one place in one direction and you'll jumper the Polisy's transmit data line to it's receive data line... shift it one place in the other direction and you'll short out the Polisy's power supply to ground. Use caution. Double check. Seriously. Conclusion When all else fails -- your network connections are dead, the reset button isn't fixing it, and not even UDI's excellent support has been able to recover it -- the serial console is that "last resort" that'll regain access to enable debugging and recovery. Or, if you're a geek who lives on the edge, access to the serial console is a requirement for those experiments that go wrong ("Gee... I wonder what happens if I delete this file named kernel?"). Access to the serial console port is pretty easy, and by using a well-supported standard cable and by following this guide, the typical trial-and-error process to figure out which wires go where can be eliminated.

Check if your UI is the same version as the firmware in the ISY.

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.

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.