mwester

Not that I can tell. But then, I've no sense of style in the first place, so I'd be unlikely to tell!

A couple minutes with an abrasive-based cleaner (I use what I found under the kitchen sink -- something called "Soft-Scrub") takes off the lettering very nicely.

No, neither the polyglot framework nor individual node servers are aware of everything the ISY does (i.e. the websocket thing) -- in fact, it's quite the opposite -- the ONLY thing that Polyglot-the-framework knows about are the events about the nodes (administrative activities) and the specific commands that are sent to the node servers by the ISY. These commands are explicit requests for data or explicit commands to the node server -- with no information outside of that node server's set of commands or values. (In fact, for this node server, since there's no means in the Node Server API, I suspect that the author has had to use the general ISY REST API to "go around" Polyglot-the-framework in order to access variables. The Node Server API is, by design, extremely limited -- it's designed so that a node server could work as a "device driver" for some other HA system, not just the ISY...)

Yes.

I'm not Brian H, but I can tell you what sort of delays I see from the ISY994i and various devices... generally the ISY is notified of an event almost immediately - one can see the delay, but it's far less than a second. The big problem is that it isn't always so. Sometimes, it's a full second until the ISY appears to notice the event. The worst case is when one has Insteon traffic underway -- it's slow, and I've seen multi-second delays when (for example) I'm syncing the link table on an older Insteon device. So, it might work if you had a one-second delay, or perhaps seconds. But it won't be completely reliable.

I'd second that -- don't do port forwarding, not for anything anymore. VPNs are becoming easier and easier to set up, and often are built-in to better-grade router/firewall devices.

As others have noted, rebooting the ISY is not a good idea -- it's rather akin to solving an occasional stall by having your local dealer remove and re-install your car's engine every night. And querying the devices more often -- that's just a hack, rather like "if the light switch doesn't click when you turn it on, jiggle it and turn it on and off until it does" -- it solves the symptom, but the light switch is bad, and until you fix it, it's just going to get worse. In the case of the ISY, if it's missing status updates, something is causing that -- and it's not going to get better with time. See the numerous threads here on dealing with "noise" and "signal suckers" -- you probably will need one or a dozen of the Insteon FilterLinc devices to clean up your power-line signal. Welcome to Insteon's special little version of hell!

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.