mwester

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

I have a similar situation with a mud-room light. It needs to be on in the evening for a few hours, and stay on (so the dogs can see their dog food bowls). It needs to turn on when the outside door is open, and turn off when the door is closed. It needs to be turn on automatically if someone enters from hallway, and stay on while the room is occupied (laundry, perhaps). The solution for me is a door sensor and a motion sensor, and a switchlinc dimmer for the light. A series of programs are triggered by time-of-day, by the motion sensor, and by the door sensor. Each program sets the light to a specific brightness (very close together so the human eye can't tell the levels apart) -- this allows any program to determine if the light is already on, which other program set it to on by the specific brightness level. Thus, when the program goes to turn it off again, it knows if it should do so or not. As a specific example, consider the motion sensor tripping at 9:05PM -- it will find that the light is already on at 99%, and will leave it that level because that's the level for the dog's evening timer. Thus the motion sensor won't end up plunging the dogs into darkness. However, at 11PM, if I walk into the mudroom to let one of the dogs out, the motion sensor will turn the lights on at 98%. Opening the external door will run a program that will note that the lights are at 98%, and won't turn the lights off on me when I close the door. Turning on the light from the switchlinc results in it being set to 100% on -- and none of the programs will turn it off if they find it set to that value (because you turned it on manually). You get the general idea I'm sure -- use the brightness level to record who and why it was turned on, so you know when what program is allowed to turn it off.

Love the sail switch -- that's an excellent example of a simple "hack" to effectively create a new insteon device type!

Updating a single value or variable in the ISY every 2.5 seconds is a bit much -- it would work, but in my experimentation, the updates were often delayed a bit, and sometimes the ISY would simply not be ready and the update message would be dropped (this would happen all the time during the 3AM query, and often when the system was busy with other intense updates). My point being that something like a full update of the entire screen for a weather station is probably far too much for the ISY to handle -- perhaps once per minute might be a better way to do it (I'm not at all sure that the 30-second long-poll time in Polyglot would be long enough).

You'll get lots of opinions on this. There seems to be a school of thought that says your home automation system should keep track of absolutely everything about your schedule and movements and preferences and should adjust and tweak the HVAC to suite you. There's another that says your HVAC system should be isolated from your home automation system, either because it's not necessary, and/or because the risk that a failure in the programming or the hardware of the home automation system may result in damage to the house due to the HVAC failure or mis-control. I'm in the latter camp -- where I live, a failure of the heating system could do massive damage to the house in below-freezing weather, so I prefer to have no direct control of the HVAC by the ISY. However, the house is also new, with radiant heat in the floors, and lots of stone and tile -- the point being that it's actually more efficient to have a single set-back per day, and that being just a minor couple-degrees tweak. So, put all together, there's just no compelling reason to connect the HA and the HVAC systems, and there's actually a very good reason to NOT connect the two together. I can envision, however, a more southerly-located house with less thermal mass -- and such a house might be different. If it were practical to cool the house by 6 - 10 degrees in an hour, then perhaps being able to have a geo-fence at your work location trigger when you leave work, and start the A/C might be useful if don't have a predictable work schedule (if it is predictable, well, then a set-back thermostat would work equally well). Perhaps if the HVAC is not well-tuned, or perhaps undersized for a house, or perhaps if there were add-ons to the house, then automating duct boost fans might be useful. Perhaps if the windows were not solar-reflective glass, and lacked an awning, then a light/lux sensor might be useful to compensate in advance for the heat gain through the glass -- or perhaps it could automatically draw the curtains. So my personal thought -- if your house is newer, well-constructed, and has a well-tuned and properly-sized HVAC system, then you're only going to screw it up by automating it... on the other hand, if it's not all of the above, then there may well be things you do better with some "smarts".

I'd also make a point to swap the power supply and see if it might be a marginal power supply -- they've been known to cause all sorts of mayhem as they go bad. The ISY can take a wide range of input voltage, so you should easily be able to find one you can "borrow" from something else in the house for a test.

There are many ways to attack a system, and username/password is only one means of doing so. I am sure I am about to enrage some of the forum members here, but I mean no disrespect to UDI -- merely stating the truth, and that is that it is not known how the ISY's protocol stack will stand up to attacks compared to (for example) the Windows or Linux stacks. The latter two have been heavily tested by many researchers, with numerous tools ranging from static code analysis through protocol fuzzing. And, we're *STILL* finding bugs and issues in those stacks. My point is that it seem probable that there are unknown issues in whatever code is running in the ISY, and for that reason, fronting the ISY with something like the UDI Portal makes a lot of sense - far, far more sense than opening up whatever that protocol stack is to the internet. So, while we're on the topic, one of the other reasons I'm looking forward to the Polisy (gah, that spelling makes me crazy!) is that it'll be running a codebase that while not as common as Windows or Linux, is still known to be one of the best and most robust network stacks out there. I'd be willing to expose a Polisy port to the internet - but given the lack of knowledge out there about the code running on the ISY, I'd never expose an ISY port to the internet. Again, it's not about password or user ids... there are MANY other ways to attack a remote system.

A USB-to-Serial adapter won't do the job -- USB requires a connection to a host, and the PLM is an endpoint, not a host. I explored the use of a Raspberry Pi as a communications relay back when I had need to view the data-stream and timing between the PLM and the ISY. It works, but it's really quite the wrong way to do it. Given that PLMs self-destruct after two years, it's not a bad idea to buy a new one, especially if you've had that USB one plugged in for a year or so already.

Having the Polisy side-by-side to an ISY is pretty much like an RPI - that is true. I'm eager for when the Polisy will subsume the ISY functionality -- for me that will mark the point where node server will really start to live up to their potential. (The show-stopping issue for me is that the very limited TCP/IP stack in the current ISY is not carefully enough handled in Polglot, so under load messages and updates are dropped).

Important things like home automation controllers should NEVER rely on wifi -- so mine will be wired in. That leaves the WiFi (and bluetooth) free for me to do all manner of interesting things -- like listen for specific WiFi hot-spots or devices (in a pure "monitor" mode), for proximity detection. I've a few ESP8266 devices that do interesting things, and when they blow their little firmware brains out and reset themselves to their default empty firmware, they start broadcasting on Wifi as a hot-spot -- listening for that will quickly alert me that one or the other of those devices has gone all wonky again (hey, what do you expect when you pay $5 for a microcontroller with WiFi built in???) Another though is that right now when the home network goes kerplunk, the ISY can't be reached -- so turning the WiFi into a WiFi hotspot for the sole purpose of letting a browser connect to manage the Polisy is also on the list. Depending on the chipset used for the WiFi, I think I can do both monitor and hotspot at the same time, but if not, it'd be easy to "mechanically switch" that on, for example by plugging in a USB stick with a special code on it to signal that it should enter hotspot mode. What can't you do with an open device like this?? Node Servers are great, but they're just the start.

Donate it to your local school.

Scene-capable z-wave devices can do this as well. (Cue argument about how z-wave doesn't do it as well as insteon, and insteon feels better than z-wave, and single-source doesn't matter, etc, etc... Let's not do that this time ok?)

There's a thread here on repairing the PLMs, in case that might help. I have a spare PLM on-hand at all times, and a set of replacement capacitors (because it's actually easier to re-solder a set of caps than it is to fix all the links if I change out the PLM). It's infuriating that Smarthome won't acknowledge the problem still exists -- it implies that they don't understand the problem (which is dreadful, since they designed the blasted thing), or that they don't care (which is perhaps even worse -- apathy is harder to fix than ignorance). But to be fair, there are some on this forum who insist that the issue isn't the PLM, but that we (those who experience these all-to-frequent failures) have "bad power" or we have temperature or humidity issues that are causing premature failure of these units.

Because for many devices that use solid-state relays or semiconductors to control the power, off is really "mostly off" -- there's always some leakage, and LEDs require so little power that some of them may glow on just the leakage current. For some relay-based units where "off" really should be "off", the manufacturer has put in a "sense" circuit to detect when the user turns on the plugged-in device using it's on/off switch -- these "sense" circuits put a small current on the line to do this, and that current is enough to make some low-power devices like LEDs glow as well.

It would be a hardware concern primarily - does the Polisy have a USB port? (One would hope so.) The Insteon USB PLM has a USB-to-serial chip inside, so when you plug it into a Linux (or BSD) system it automagically appears as a serial device - so effectively, if the Polisy has an open USB port, the software change to make it work amounts to telling the UDI software to use a different serial port #.

While the flavor of Unix that the Polisy will run is different from Linux, a well-written high-level code such as that used to implement node servers won't be able to tell the difference -- so unless a developer has a specific and unusual requirement which they should document (and should be trying to avoid), if it works on you RPi, you should expect it to work on the Polisy too. Things might be different for really interesting node servers that are very low-level -- for example, there's a node server that specifically interacts with the I/O pins on the Raspberry Pi -- that one obviously won't work on the Polisy. It might also be too much to expect node servers written to interact with low-level blue-tooth functions on the Polisy (e.g. presence detection) to run on an RPi, althought that could probably be addressed by a well-written node server if the developer wished to do so* * Or if the developer were incentivized to do so -- making a polyglot node server work on as many hosts as possible would increase the developer's income once the monetization aspect of all this is taken care of...

Like all marketing department schlock, it doesn't really say a d*** thing! I'm still waiting to see a proper, working PLM.

https://www.lightdims.com/index.php I use these on a LOT of my devices, although not so much on the insteon ones (the while LEDs are not so "eye-piercing" as the blue ones... the blue one on the ISY is blinding.)

I'd agree that there's huge confusion about what things are triggers and what are not. I'd second this idea -- some sort of markup or annotation or perhaps just auto-adding comments to the program that would indicate with certainty what the ISY considers to be triggers would save a lot of trouble. (If one were to start all over, I would strongly suggest a program structure other than "if (events and conditions) then (something) else (another thing)" -- perhaps something like "when (events) do if (conditions) then (something) else (another thing) -- which would allow one to simplify most real-world programs to the very clear and very obvious "when (events) do (something)", which even the most basic beginner would find obvious. JMO)

Basically, the device functions as a normal occupancy switch -- it turns on the load if it senses motion in the field of view. There's a paddle switch for manual on/off, if desired. If you add it to a z-wave controller, like the ISY, it will respond to on/off (or dim, if you get the dimmer version) commands -- and it'll send events upon detecting motion (in addition to turning on the local load). (I could do without the blasted blue LED, though - why do manufacturers insist on using those horrible eye-blinding-blue leds on everything??? I'll give Insteon credit for having avoided the temptation to "blue" everything, and instead going with a softer white led...)

I've been quite enjoying my z-wave occupancy sensors -- they're wired in (replacing the light switch), but actually give very good coverage of the areas I need covered in the basement. And while I just use the occupancy mode, they DO work as motion sensors (signaling motion to the ISY when detected).

Alas, that's not how Insteon scenes work. When you linked the two devices manually, one was the controller and the other the responder -- the PLM was not involved. When you added the device to the PLM, another scene was created, involving the PLM as the controller and the device as the responder -- note that the other device was not involved in that link (it exists solely so that the PLM (ISY) can control and monitor that device). So, given those two scenes, when you turn on the device from the ISY, according to the Insteon protocol, the device that you tapped on the shoulder is specifically, per protocol, to turn itself on (or off) -- it is NOT to run off to do "something" because that activity is a DIFFERENT scene (which you defined manually, and thus it isn't even possible for the ISY to add itself to that other scene). So, while it might be logical, or "out of the box", none of that matters because that's not how the Insteon designers built the devices. I'm afraid you're going to have to delete that manually-created scene and re-create it from the ISY in order to have it work they way you wish.

The parameters are determined by Fibaro, not Universal Devices. So check the Fibaro documentation... near the bottom of this page (https://manuals.fibaro.com/door-window-sensor/) they list various parameters.