mwester

There's already a node server for that board. Edited to add: http://forum.universal-devices.com/topic/20239-proof-of-concept-micro-node-server-running-on-an-esp8266/

I'll pop in with a few comments here: - I agree with Teken, actually -- I removed the original fuse, and used the printed numbers on it to find an identical replacement (on Amazon; not easy to find). I didn't want to take any chances of starting a fire in the Syncrolinc by over-fusing it -- the 15amp fuse is there to protect the *sycrolinc* from melting internally, not the load or the cord to the load! - Regarding querying the Syncrolinc (question from the original poster): Yes, that's a good idea. But be prepared for lots of false alarms. When I did that, I found that the device wouldn't respond to queries during the motor startup period. I put a wired-in 20A X10 filter on the load side - that helped, so I got the signal that the load had turned on. But the device still had trouble responding from time to time, for no good reason. - I can't find that thread where I described my final solution, perhaps someone with better "search fu" can... but in a nutshell, I replaced the whole setup with an IOLinc that was triggered by a current-operated switch. The current-operated switch is what the syncrolinc should have been, had it been properly designed -- it's a current transformer, that encircles the hot wire. Thus it does not sit in-circuit, and therefore it has no fuses to blow and no other parts that can cause the circuit to be disrupted. That setup has been working perfectly for a long, long time now. - Finally, regarding the knowledge one might gain from monitoring a pump like this: it's huge. For me, it's far more than just "is my pump running" -- I have a filter screen involved, and by monitoring the run times for a couple of years now, I can pretty much gauge exactly when it's time to clean that screen. So my ISY monitors that for me, and when it detects several pump cycles that all have crossed the threshold, and all are trending upwards in time, it lights up a KPL button (labelled, appropriately enough, "ALARM", with red plastic behind the button). I also have a heavy-duty relay connected to the IOLinc so that if the pump cycle goes waaaay to long, the ISY can shut off the pump to avoid burning it out. Another program runs hourly, and turns it back on after an hour (when it's cooled down), and lets it try to pump some more -- this will continue ad-infinitum, in the hopes that enough water is getting through the clogged filter that cycling like that will prevent an overflow. And since it's actually a septic tank, an overflow is a messy business that we want no part of!

What larrylix says. I've blown that fuse, when I tried the syncrolinc on a 3/4HP sump pump. It lasted for a while, then eventually failed -- the startup surge for a pump can be significant, especially when under significant load (a dry-run test will not only damage the pump, it'll be utterly meaningless for measuring startup surge!). We were saved from an ugly mess by a high-water alarm -- always, always engineer a solution with failure in mind! I cannot recommend a syncrolinc for pumps of 1/2HP or greater.

More likely that the RF from the 2477 is leaking into the humidity sense circuitry on the humidity-controlled switch. Not much you can do about that, except remove the 2477 and replace it with a standard switch. Or replace the humidity-controlled switch. It's NOT a good idea to try to block the RF inside the junction box -- wrapping things with aluminum foil, for example, is a recipe for a short-circuit, or a fire, but even if you get lucky and don't short anything, it may very well end up causing overheating of the devices. Perhaps you can find an ancient power-line-only insteon switch to try?

Aaaaaaagh! I just KNEW we would end up here -- which is what my response to Teken was all about (NO NEW SCRIPTING LANGUAGES)! We don't need any custom scripting languages for this, but even if we did, re-purposing an existing, known, standard language is a wiser choice, lest we all go further down the path to the coding equivalent of the Tower of Babel. NO NEW SCRIPTING LANGUAGES! NO NO NO! STOP THE MADNESS!!!! (Ok, I'm calm now.)

Yes, I have a number of applications for such a thing. I have one box where I've managed to fit two Insteon switchlincs and a micro on/off -- but only by shortening the wires in the box to make the necessary room. Turns out that other people do as well, enough to justify someone making such a product -- since there are multi-relay z-wave devices (but no such thing in the Insteon world).

Teken, I think the answer is a definite "maybe"... With some effort, one could create a "fill-in-the-blanks" framework -- mostly. At a high-level, the problem isn't so much the "what" that you would fill into the blanks, it's the "how". The "what" would be things like "I need a value, integer ranging from 10 to 30, units are in degrees Celcius, and the value is sent FROM the device TO the ISY, and the name of the value is Heating Setpoint". That's just data, and it's pretty easy to do. The problem comes in the "how": "Well, you fetch this value by reading the API key from the secure keystore locally, then open a network connection to an internet cloud service, and if it responds with a "OK" value when you connect and present the API key, then send another message, then parse the XML data block you get back, find the element named "Basement Thermostat", and in that element find the sub-element named "HSetPt", then read that value, and finally, use a formula to translate that from F to C, and if all that worked, then send that to the ISY". It's that last part that makes a "fill in the blanks" node server pretty danged hard to do, 'cause that's coding -- not filling in blanks. Not sure how you'll ever get around that. And don't say "we need a custom node server scripting language" 'cause the very last thing the world needs right now is Yet Another D*** Scripting Language!

What Xathros said. To clarify, a port number is like an apartment number, and a IP is like a street address. You can have as many apartment #80s as you like, as long as each is in a different building with a unique street address.

Alas, the ISY console is not that type of Java app. You're thinking of the server-side Java program -- the so-called "web application" -- the one that runs so very much of the internet and intranets of our world. The far-less-common type of Java application is not a web application at all, but an ordinary program with it's own non-web-based GUI. Kinda like how "notepad.exe" runs on your Windows desktop. The former Java application runs (among other ways) on Tomcat, and is something that one might reasonably host on a Synology server. The latter, however, runs on your desktop, requires a monitor and keyboard on the local host, and has nothing to do with Tomcat or any other web app container -- exactly like "notepad.exe" and other native Windows applications. So, you'll need either a Windows system, a Mac, or a Linux system to run the ISY console. Sorry.

As a hint, two of the worst interference-creators that I've found over the past few years were physically very small, and both were apparently working just fine. One was a 25-watt-equivalent LED bulb (Feit) -- when illuminated, it looked exactly like it's neighbor on the other side of the garage door, but it created so much electrical racket that the 2477 SwitchLinc that controlled it went deaf on both powerline and RF. Replacing that single bulb solved the problem entirely (to be safe, I hunted down all the bulbs of that same type I'd installed, tossed them, and replaced with Philips equivalents). The other was a no-name cell-phone charger from eBay -- physically looked exactly like the Samsung chargers for their cell phones. It created so much racket on the powerline in the kitchen that not only did the nearby KeypadLinc stop working, the KeypadLinc locked up and started emitting a long, never-ending beeeeeeeeeeeeeeeeep! I replaced the KeypadLinc, thinking it had failed - the replacement was also deaf as a post (despite working on my workbench 10 minutes earlier). That led to a massive hunt in the kitchen and adjacent living areas, annoying the entire family as I unplugged every bit of entertainment gear, floor and table lamps, etc, etc, ending when in desperation I finally unplugged the "too-little-to-possibly-cause-trouble" things including the cell phone charger. Now i have nothing but name-brand chargers, and everything - and I mean everything - in that area is plugged into those oh-so-attractive Insteon Filterlincs. Best of luck. Some on this forum maintain that the powerline comms with Insteon is great, and works fine -- others of us have experienced similar things to that you've just dealt with. Welcome to the club. Investigate z-wave, save your sanity. And money.

I approached this problem a bit differently. In a nutshell, my need was similar, but I wanted the ability to have different time delays at different times of the day. So, I structured this as a set of programs, with a variable as the "master control" for it all. 1) There's a set of programs that check the status of the door, each one based on a different schedule. So, the condition for one is something like: if the door has just been opened and it's night time, and the action is to then set the master control variable to 300 (number of seconds I'll permit the door to remain open at that time). There's a bunch of those. 2) There's a timer program. It runs from 12:03AM to 11:59PM, every 20 seconds (sufficient granularity for me) -- and it's job is to subtract 20 from the value of each master control variable (I have lots of them - two garage doors, ice melters in the winter, block heaters for the tractor, etc). It checks to make sure that the variable is >0 before it does that, just to avoid silliness (not sure that matters, though). 3) Finally, there are action programs for each "master control" variable, these set to trigger on the variable reach zero or less than zero (IIRC). When that happens, the program sends me emails, or for the ice melters and block heaters it just turns off the scene. By decoupling the bits and pieces into three programs controlled by a state variable, I find I have much more flexibility in determining what and when timers start, what happens when the timer expires, testing the alerts, testing the timers, etc. It also avoids the oddness associated with "wait" statements inside UDI's programs.

One must note that lumped into the entire "security" discussion is the concept of ensuring that data is not tampered with in transit -- which is exactly what's happening, according to the prevailing theories, to cause the dreaded "ALL-ON" problem. Data corruption is a security issue. I'll also note that security relates to a lot more than door locks and garage doors with Insteon -- those with Insteon thermostats in the northern climates should be taking steps to protect their homes from freezing, and those with sump-pumps controlled by Insteon devices should ensure they have a battery-backup, etc. And again, it's not just about someone being malicious; security means protection from accidental or any other unintended operation, regardless of the source. And yes, the ISY clearly has the most exposed attack surface for any of us - that's the high-value target for any "criminal" or "mischief-maker". But from accidental/unintentional issues, probably the most severe vulnerability is the PLM's "ALL-ON" issue - and UDI is certain that's got nothing to do with your ISY.

Certain types of noise on the powerline can cause an Insteon device to go deaf on the RF - but it's never been totally quantified, and anecdotal evidence suggests many cases where the RF gets through fine while the powerline doesn't. But regardless, if the noise source is only affecting the outlet or circuit on which the PLM is located, then you'd have exactly the symptoms you describe -- and it wouldn't be unexpected for the devices themselves to continue to work just fine without the PLM.

I'm now wondering if we've all been chasing the wrong "fix" here. Perhaps the real issue is that there is (suddenly, for as-yet-unknown reasons) a massive noise-creator and/or signal-sucker on the powerline. How about we pull back, and establish if we can get that ISY/PLM combination talking to a single selected insteon device, with all the other breakers in the house turned off? I've had a case where a normal-appearing LED bulb would cause a switchlinc to go completely deaf -- perhaps the O.P. has had a similar switching-power-supply failure in something on or near the same electrical circuit on which the PLM is located.

Alligators, Teken. They call devices like that "alligators" because they're all mouth and no ears. Based on the sad front-end on the Insteon devices, they could do just as well, probably far, far better by adding higher-Q filters on the receivers. But, that requires RF engineers. And engineers, no matter what country they work in, require money. And that requires a business decision: "Will investing $X thousands of dollars to improve the performance of the Insteon XYZLinc offer me $>X thousands in return?" And the answer, alas, is: not likely -- especially if that businessman factors in that improving the performance will actually REDUCE the sale of FilterLincs, Insteon repeaters, Insteon phase bridges, last-second-desperate-attempt-to-make-it-work PLM and Hub replacements, etc. I fear that right now the Smarties business model is actually benefiting in a very measurable way from all the replacement and add-on devices users buy in an attempt to make their networks operate. Speaking for myself, I wish I had invested elsewhere all that money I spent on Insteon repeaters (5 of them), filterLincs (many, far more than 5, I've lost track since they litter my walls all over my house and garage), phase bridge, and spare PLM.

Experiences differ -- I doubt very much that I'm the only one on this forum with exactly ONE z-wave repeater -- but 9999999999999999 freakin' Insteon Filterlincs all over my home. Frankly, reliability is the number one factor constraining growth in this market. But that wasn't the question posed by the O.P. -- he asked if a next-gen Insteon protocol could be backward compatible. And the answer to that question is that it's technically possible, but impractical from a business point-of-view.

As the phrase goes: "Hope springs eternal" I guess there's a possibility that there may be a next-generation of Insteon products. Certainly technically there's a niche for a combination RF/Powerline protocol for HA. So let's go with that: - Firstly, I'd observe that the existing Insteon devices are extremely dated in terms of the technology contained therein -- the protocol, and thus the devices, were designed assuming extraordinarily resource-constrained hardware, by today's standards. So, it seems reasonable that any new technology could have considerably more firmware, memory, computational power, and I/O capacity. The point being that the extra complexity of adding support for two entirely different protocols wouldn't be a problem from a hardware resource point-of-view. - Secondly, I'd note that something like this has been done before. Early Insteon devices lived in a world dominated by X10, and while support for X10 has diminished in Insteon devices over the years, many of them not only co-existed with X10 devices, but also actively participated in the X10 network (such as it was, limited by the X10 protocol itself). Again, technically there's a precedent. - Finally, I'd note that Insteon is a closed proprietary ecosystem. There are no third-parties, no integrators, no outside developers to support or worry about (heck, they even have UDI *reverse engineering* things to get Insteon devices to work with the ISY!). So, from a technical perspective, this makes it far easier to build a "dual-protocol" solution, since the only devices that need to be tested are those manufactured by Smarthome/Smartlabs -- and probably only the currently-shipping ones out of that set. That's a considerably easier task than if there were third-party Insteon devices out there (and note that while it might *look* like there are Insteon-compatible devices on the market, if you look closely you'll find they are built onto a standard PLM, as far as I've ever seen -- so they're not really third-party devices after all). So, considering the technical issues, my conclusion is that a next-generation protocol with backward compatibility is very, very do-able, with no significant *technical* issues or risks. But, don't start the party yet. Let's consider the business side of things. From a business point-of-view, we need to take a look at the conduct and behavior of the Smarthome/Smartlabs (aka "smarties" from here on in) folks recently -- specifically the products and marketing of the past several years. That's more likely to be indicative of the future than their conduct when the first Insteon devices were created. - I note that their business model is "cloud-based" - there's been no new PLM, just hubs. And those hubs don't even feature the ability that previous network-based central controllers had (the TCP/IP version of the PLM, specifically). This matters, because it tends to indicate where their mindset is -- in the "cloud". From the cloud perspective, there's one and only one thing that matters, and that's the hub. The hub controls the devices. My concern here is that from such a perspective, the idea of making the hub the "protocol translator" rather than making the devices natively upwards-compatible seems logical, and much much cheaper. What that means for us, since the ISY can't talk to a hub, is that it's likely there won't be a "new" PLM, and likely no way for the ISY to talk to the new-protocol devices. - That last sentence might be met with the objection "Hey mwester - I'm sure that the Smarties understand that UDI customers are a significant base, and they wouldn't leave us behind!" To which I'd respond: read the forum, specifically the PLM issues, the siren, the new motion sensor, etc, etc, etc. You'll quickly see that the recent Smarties' business model doesn't include or care about UDI's customer base, except to continue to extract 75USD every two years as we all replace our burnt-out PLMs. - Moving to a broader business perspective, one has to ask the question: "Why?" A savvy investor would ask that of the Smarties -- why does the world need Yet Another HA Protocol? Why not just add z-wave, or zigbee, support to the Insteon Hub, and solve all the problems that way? Hardly any engineers required, and given the Smarties' current cloud-based model, end users wouldn't notice nor care. I just can't see any value to be generated (in terms of dollars) by creating a next-gen version of a failed, obsolete protocol with little market share, in a market space dominated by stock standard WiFi and BLE on one end, and ZWave and zigbee on the other, with custom-wired protocols still required or the norm for commercial work. It makes no business sense. - Finally, one might make an argument about a next-generation Insteon protocol, opened up to developers, that might fit well with the current "makers" push (arduinos, esp8266's, 3d-printers, companies like Sparkfun and Adafruit, etc). True enough. ZWave suffers from being non-open (Sigma owns it). Wifi is too power-hungry. Zigbee - I've not looked into that, but it too doesn't have a huge hobbyist following. Nevertheless, I'd have to look at the business model and wonder where the cash is going to come from? How much is a hobbyist willing to pay for devices? And once we establish that, one has to ask the follow-on question: given how little money (relatively-speaking) one can make in that field, does it really make sense to have backward compatibility? Do the hackers and makers really care that much? Enough so that they would pay a few dollars more for each device? It's a weak argument, assuming that anyone is willing to gamble on making money off of makers and hackers, vs making money from folks who "just want HA to work". In conclusion: It's my opinion that Insteon, as a protocol, is dying, and that while it's technically possible there's no business rationalization that would make it practical for a "protocol refresh" to see light-of-day. The recent buy-out was a purchase of the Hub-based business, for that customer base, and certainly wasn't a purchase of a top-tier engineering team to build a new protocol! So: No, there's no hope for a next-generation Insteon protocol, compatible or not. Make the switch to z-wave, starting now.

Oh wow! 30+ years ago, my college electronics lab instructor (an ex-military engineer who loved to tell stories of his life among the electrical and electronics aboard Navy vessels) made a comment about User-testing and QA-testing that's stuck with me all my life. To paraphrase: "It's impossible to account for every use-case and mis-use-case, because the users are so d*** ingenious!" Ingenious, simply ingenious. It can't work -- it's WAY outside any design parameters, let alone the safety issues involved in putting a 120V plug on a low-voltage cable and bulb system. And it would never, in a million years, have occurred to me as a possible misuse-case were I the QA engineer in charge of the LampLinc! Nevertheless, it has a certain amount of logic to it... Please undo whatever you've done, for safety's sake.

Usually that means that the links in the devices do not refer to the PLM. Normally, one would restore each device to re-write this data -- when you replace the PLM, one of the steps that's supposed to happen involves the ISY computing the new link database entries, based on the new PLM's address, and updating each and every device. As I understand your last post, you have: - factory-reset your devices (switchlincs and appliancelincs, etc) - defined scenes in the ISY - ensured those scenes were written to the devices - tested that operating the switchlincs, etc, result in the other devices responding correctly Is that correct? Then, you are observing that: - a program triggered by turning on a switchlinc (or similar controller) does NOT trigger. Can you check to see if the ISY knows the correct status for the scene controlled by that switchlinc (or similar controller)? In other words, does the admin console's view of the controlled devices (responders) change when you manually operate the switchlinc (or similar controller)? If yes, then you have a problem with the program logic, folder conditions, or a runaway program, or something like that... but if no, then your symptoms are all compatible with missing a very important step when replacing a PLM -- one that could explain all the issues described above. Basically, when the ISY writes scenes (links) to devices, it always add a link to it's PLM by address -- this is how it knows when a device has done something (i.e. when a switchlinc has turned on). In order to do this, the ISY needs to know the PLM's address -- it gets this when the ISY boots up. So, if PLM was swapped while the ISY was running, then the ISY never obtained the PLM's address, and is continuing to use the old (failed) PLM's address. And that includes writing that old PLM's address into all the link tables instead of the new one. Hopefully that latter scenario isn't what happened, because if so, it's just plain easier to factory reset everything -- including ISY -- and start over.

Dunno what makes you say there's been no progress -- Chris' comment was a year ago, and lot has happened. What hasn't happened is a formal release -- so if you want to see if/how this device functions, you'll need to install the 5.0.10 alpha firmware. It's alpha - so things may not be perfect. But a lot of us are running it, and quite enjoying the new functionality. Again, I don't know if this device in this thread will work, but if you need to know, just load up the alpha version, and provide some feedback.

The locks are very sensitive to range issues -- part of the problem being that they are often mounted on steel doors, and sometimes are surrounded by masonry, but always are on the outside wall of a house (far from the ISY usually). Combine that with the fact that some of the most important events for them to transmit/receive happen when another huge signal blocker (a human) is right in front of the device, and said human may even have a hand on a keypad mere fractions of an inch from the antenna... The result is that a door lock is usually in one of the most difficult environments to get a reliable signal in and out of -- so you'll almost certainly need some sort of z-wave device that can repeat the signal, ideally directly opposite the door itself (even if that might be through a wall, it may be a better location than off to the side of the door where the signal has to go through your steel doorframe and the masonry around the door, for example). Note that the z-wave device you choose needs to support *secure* connections, and it needs to be always powered-on (battery-powered devices don't repeat the z-wave signal). Many here have selected the Aeon Siren module as a low-cost device for this purpose; it's reputed to perform far better than the actual Aeon repeater itself (!), and has the benefit of actually being useful for something other than just repeating the signal.

Well there's at least part of your problems -- you MUST have the GUI and the firmware at the EXACT SAME version level. You'll want to fix that before you go a step further in trying to fix the issues.

Reading this topic, a couple things jump out at me: First, I don't think the behavior of the device is as big a problem as the original poster does - but to each his own; it clearly is a big deal for some. Given that, it would be nice if each switchlinc device had a setting to disable the fade up/down, since *THAT'S* the real problem. Second, anything to do with the scene being "on/off" is wrong -- the root issue is that the device sending the command is sending a command that isn't wanted. The challenge here is the same one that comes up every few months in one context or another, and that is that there's no such concept as a scene having a value. You can't say a scene is "on" or "off" or 38% bright -- that's just not how Insteon works. Now, one can consider that design to be a mis-feature - but it's not going to change. The issue is that each device in the scene determines how it responds to the command that was just sent. So sending an "on" to a scene usually turns on everything associated with the scene - but that's not necessarily the case. Turning on the switchlinc on the wall in my family room sends an "ON" to everything in the room - but the cans that wash the wall turn on to only 50%. So what's the value of that scene? It's not off, that's for sure. But is it on? Some of the lights are 100% on. Some of them aren't dimmable, so they're just ON (with no percent). And three of them are on at 50%. And it gets worse - with the new scene support inside the ISY, one can add node servers for totally custom devices. So I can add my newest invention to the afore-mentioned scene - the mwesterLinc. When it gets and ON signal, it blinks green, red, and purple, plays the opening bars to "take me out to the ballgame", and spins a propellor round and round a dozen times, then goes back to sleep. Is it "ON"? Or what? (Yes, it's stupid -- and with a node server, we can even add that as it's value: "Off" and "Stupid" could be completely valid values! So what's an on/off scene, then??) Anyway, the above is just to illustrate that the concept of "On/Off", while it seem simple and obvious, like so many other things that are obvious to humans is very difficult for simple devices. This is a case where a program running on the ISY is the right place to sort out what "On" and "Off" means for a given scene -- and that make's Larry's suggestions far from a hack. That makes those suggestions absolutely the right way to go, and the very reason you have an ISY in the first place! Now, about that mwesterLinc -- I'm taking orders. Wanna buy a few?

Both have to be Insteon.

Which, in retrospect, is probably what we all should have recommended in the first place... would have been hours easier!