mwester

Most common reason for the "not loaded", "out of memory", and "not saved" messages is that the UI version doesn't match the firmware version -- check that first.

The only times I've rebooted my ISY is the last time DST changed, and I think I moved it sometime last fall that required I unplug it. But that might have been last summer, actually. If you have to reboot your ISY periodically, there's something wrong with one (or more) of your programs. Fix those, don't hack it with a reboot -- this isn't a windows box!

Perhaps you can clarify the wires to the fan -- sounds like three wires going to the fan from your switches, right? And what colors are those wires?

Yep, I'd give it a shot! As long as the plug fits, it should work... (although 300ma is right at the limit, so it's probably not a good long-term solution -- those little wall-warts do not like running near capacity...)

In the meantime, perhaps you can "borrow" one from some other device -- the ISY is very tolerant of input voltage, and will easily accept a 12v wall wart if you don't have one that matches the factory-provided one. As for the current draw, anything rated at or above the amperage of the original one will suffice - but if your replacement candidate is only slightly lower, I'd give it a try rather than living without the ISY for a while! (Amazon would have been my go-to for a replacement, 2 days at most -- but now tech purchases are showing huge shipping delays, so I'd scrounge around for something I could "borrow"... might be a long wait from any online supplier...)

The wall-wart that plugs into the wall -- those things are far more likely to fail than the ISY itself.

Replace power supply.

I agree with those above regarding ergonomics, expectations, etc. And double that for bathrooms. Bathrooms are private places, people are nervous about sensors and the like to begin with. Consider also that people are often motionless in bathrooms for considerable periods of time -- especially if they ate something that didn't agree with them the night before, for example. Something simple like an occupancy sensor would be as far as I'd go for automation in a bathroom. I've chosen to avoid even that -- the only "automation" is a manual timer on the fan itself (so it doesn't run all day). If you turn on the lights in the bathroom here, you have every expectation that they will stay on until you turn them off. No arm waving, no commotion, no odd-looking sensors on the wall, no privacy issues. "Oh my goodness mwester, your electric bill must be sky high from all the lights left on unnecessarily!' No, LED bulbs really don't take much energy, especially in a small room like a bathroom where you don't need (or want) a 100-watt-equivalent even! (Illustrative story: Some years back, I finished the bathroom in the basement -- because I was cheap, I bought a distressed mirror, and then stupidly drilled too far when I re-affixed the back to it, leaving a small round-ish chip out of the front of the frame. It's a basement bath, what do I care -- a little black paint to match the frame, and it's all good... So, my daughter came by for a visit... her comment on my handiwork (paraphrasing): Nice, Dad -- except it looks a lot like someone put a spy camera into the mirror frame. Lesson learned: bathrooms are sensitive places, and even careless workmanship can freak people out, much less big Insteon motion sensors!) Conclusion: Install LED lights and a timer for the fan, and leave the room off-limits for home automation.

There have been numerous bugs around DST (both times of year). Some of them are (were) in the ISY firmware, and should be fixed if you're on the latest release. Many bugs are in user programs that don't know how to deal with the time change... you're on your own for those. And some of the bugs are in the various devices and computers all over the rest of the world. I've adopted the brute force but reliable strategy of rebooting EVERYTHING that has an clock, internal or external. Sounds horrible, but we get power fails rather regularly so things reboot here pretty often, and I've got the startup sequence for the ISY programs pretty much working. There's certainly value in going through your logs and seeing if you can track it down to a bug in your or UDI's code -- but frankly, DST is one of the world's worst ideas and I personally wish to waste as little of my time and energy on it as I can.

Actually, I rather hope that's a designed feature of the UDI portal -- it's bad enough thinking that a breach might expose my ISY's contents to a hacker, but at least said hacker can't change the firmware on my ISY...

Ah, now THAT might be the real issue. If you're more wondering about the WHY of variables rather than the HOW, well, then you probably haven't yet encountered a need for variables. And if your automation doesn't need variables, then don't use them - and don't worry about them! You're not missing anything! (By analogy -- variables are kinda like a spark-plug wrench -- if you're not sure when you'd ever need to use one, then clearly you don't need one in your toolbox! Conversely, when you encounter a situation where you need a spark-plug wrench, you'll know it, and you'll know that nothing except a spark-plug wrench will do the job.)

That's the problem with pseudo-code -- it exists to make things simpler, but then folks try it literally and get confused when it doesn't work. Yes, you can't type in ANY of my examples and expect them to work as typed into the forum. You'll have to update them so they are valid ISY code, that's on the user to do.

In the admin console, go to the variables page, and define new variable. I used the name $variable1 -- that's dreadful, so use a better more-descriptive name everywhere it's used and defined. When you define that variable name, you can optionally set the initial value. The programs I sketched out above are fine if the variable starts out with the value "0", so I'd just leave it at the defaults. It's that simple.

Consider a program that runs every day at 10 minutes past sunrise. There's a value there that the ISY must compute, no? Somewhere in the logic, each day it computes the time that the sun will rise, so that it can run that program at the correct time. In that example, "sunrise" is a variable -- its value changes (although in this case, the ISY changes it for you, you can't change that value). I can also run a program at 10:21AM every day -- in that case, we'd commonly say that the value "10:21AM" is a constant. So, when we speak of variables in the context of ISY programming, we're usually referring to variables that YOU can change, rather than the ones that the ISY changes for you (such as sunrise, sunset, last time a program ran, the brightness of a light, etc, etc). As for using variables -- you note that there are ways to write programs that eliminate the need for variables. This is true -- the programming language for the ISY makes it pretty easy to write programs that eliminate the need for variables. You can do this with other programming languages as well, where (for example) the state of the program determines some intermediate value -- sometimes this is a good thing, but often overuse of this technique results in obfuscated and inscrutable logic that's impossible to debug and fix, not to mention impractical to re-use. (Sound like some of the programs posted on this forum from time to time? Yeah, I am sometimes both impressed and horrified at the incredible over-complexity some folks go to in order to, apparently, avoid the use of multiple programs and/or variables...) So, here's a simple example. I want to train the dog not to wake me up at 5AM in the morning, so I've rigged up a gizmo that unlocks the dog's crate door automatically. The approach I'm taking is to unlock the door at 5:05AM, then shift that 5 minutes later each day, up to 7AM. Because I don't like complicated programs, I'm keeping it simple -- one program runs at 5AM, waits for a variable amount of time, then unlocks the door. Another program runs at midnight, and adds 5 minutes to that amount of wait time, saves that away in case of an ISY reboot, and of course I want to make sure that I never let that value get longer than 120 minutes (poor dog needs to go outside at SOME point in the morning!). Main program: runs at 5:00 AM every day wait $variable1 minutes turn Dog-Crate-Door-Lock on Support program: runs at midnight every day and if ($variable1 < 120) $variable1 = $variable1 + 5 init $variable to $variable (save the value over powerfails and reboots) Can you do that with just a program? Possibly. But I'm not sure it'd be simpler to do so, or more obvious to maintain. Plus, you'd still be using variables, they'd just be ones that the ISY itself manages for you.

There's a lot of cases where full-featured nodeservers are overkill... and it seems we've all sort of forgotten that it's dead simple to set a variable in the ISY via a simple REST API call. So you can also consider a process on a Raspberry Pi or some other always-on device that requests the status from the device and updates a variable in the ISY with the results. If that's something you're interested in doing, I can post an example REST call.

Network resources are one-way -- they can only send an outbound message, there is absolutely no way to do anything with a response. You'll need something outboard that can send the request, read the response, and update the ISY with that information. There's a bunch of ways to do this, although these days it seems like the only answer is to write a node server for polyglot... Perhaps there's something already out there that will work, or perhaps you're completely comfortable writing something an outboard system (like a raspberry pi or such) to do this.

Was the change to upgrade the z-wave dongle to the 500 series? If so, please be aware that many on this forum have observed that the new dongle's range (no matter how you compare it) is very different than the 300 series dongle. I originally had a 300 series with external antenna centrally located in my basement -- and according to the diagnostics, it could reach every z-wave device in the house directly. The upgraded 500 series dongle in the same location required that I have a z-wave repeater within about 10 feet of the ISY. The topology of the mesh changed every time I ran a "heal", but at most the three closest devices could be directly reached, all others repeated through one of those three devices. Alas, only one of those three was a z-wave plus device, and the ISY has NO control over the topology, so the resulting mesh often ended up with unnecessary hops, and often unreliable hops. I finally ended up shifting a bunch of devices to my Home Assistant install, so that the ISY can ONLY see the z-wave plus device, so my mesh is now stable. The 500 series dongle is a major disappointment to me (in fact, I'd go back to the 300 series if I could easily do so).

My ISY has two long-lived connections open (outbound): IP 52.54.245.47, port 443 and IP 52.54.245.47, port 8000. Both IPs are in Amazon's cloud, according to a DNS lookup. I block outbound connections to a site named "flexyourpower.s3.amazonws.com" since that's not pertinent to me, and I'd rather not have the ISY connecting there if there's no reason for it to do so. Your request makes perfect sense, and as you can clearly tell, the community doesn't really know what the minimum required ports really are. I'd suggest just opening a support case with UDI and asking.

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.