mwester

My current network uses a single flat subnet -- so everything on the LAN can talk directly to each other, without involving any firewall or anything that can monitor that traffic. I was only interested in monitoring and controlling what various devices did with inbound/outbound internet traffic. That was 2017 -- my resolution for 2018, based on the increasing volume of IoT-based security vulnerabilities, is to actually segment my LAN into different spaces that cannot communicate except through firewall rules (as suggested by Scottmichaelj, above). This will certainly complicate my experimentation, but I too am worried that someone may gain access to more critical and valuable data on my LAN by using a compromised IoT device. (And I guess, as I think about this, that I should lump all my audio/video devices into that same controlled/restricted category -- I suspect that the FireTV stick, the Sonos units, etc, are also likely to be hacked...) (Thinking about this even more, it almost seems as if I need to do the opposite: segment the few devices that hold truly valuable data into a secured subnet, rather than try to lock out the IoT, Audio/Video, and guest access... but with Windows 10 calling back to Microsoft every few hours with all your personal information, is there really a device in your own home that you can trust???)

I have all my IoT devices on specific IP address ranges, and have my pfsense firewall configured very carefully. To oversimplify, basically the ISY is the ONLY IoT device that is allowed to make unlimited outbound connections. The Amazon Echo isn't in that address range -- I considered it an "audio/video" device when I installed it originally, so it's in that address range instead. I should probably reconsider that, and start watching/logging exactly what it's sending to whom... Thanks for the heads-up on this.

Insteon is just as "fractured"... I1 -- and I2 -- and I2CS -- and no good way to determine which protocol is used by which device, and sometimes it even changed with the version of the firmware in the device. And then there's the RF -- some devices have it, others don't, and again, no good way to know which ones are RF, and which are not other than the advertising glossies (or tearing the device apart). Some devices support peek and poke commands, others don't - and sometimes the version of the firmware matters when determining if peek and poke work. The difference is that (recent history aside), UDI and the ISY *know* about all the quirks and capabilities and even bugs in each device. We'll need to develop that for the fractured Z-Wave space, that's all (other controllers are already doing that, so it's something that's possible -- which doesn't seem to be the case with recent Insteon devices, alas.)

I've found that recording the state of the light in a variable, state or otherwise, is unreliable (old programming maxim: if you have multiple copies of something, it's correct in at MOST one place...). So, my solution is to dim the light to slightly different levels based on how it was turned on, and then it's easy to have a program determine if it should turn it off or not. As a simplified example, every evening my mudroom light turns on at 41% for a few hours (so the dogs can see their dinner while they eat...). There's a door sensor as well -- and it triggers a program. If the "door-opening" program observes that the light is at 41%, then it sets the light to 91%. If it observes the light being "off", it sets it to 99%. If the light was at 100%, then it leaves it at 100%. Then it arranges for a "light off" program to run after a short delay. The "lights off" program checks the light's level: if 91%, it sets it back to 41%. If 99%, it turns it off. If 100%, it was originally turned on manually, and it leaves it as-is. It's actually a bit more complicated, since there's also a motion sensor, and the dog's lighting is dependent on sunset, etc. But you probably get the idea - use programs, and set the light level itself to record the state it should be returned to.

No, with a common ordinary UPS used for computer sorts of devices, you will NOT get the PLM to communicate through it. And in fact, at least on the line-side of the UPS, it will put enough noise on the electrical lines that attempting to use it without a FilterLinc will result in degraded or no comms on the line side of the UPS as well. So, in summary, it is a true statement that common UPS devices are incompatible with the PLM's power-line communications.

yes, because 5.x is not yet released, you'll have to do a manual upgrade.

I'm not sure we actually want Leviton to "eliminate their Hail" -- it's the only thing possible to trigger on and without it, there's absolutely no hope that we can detect a switch on/off/dim event without polling! The problem, just to be clear, is that the concept of proactively sending a status update when a person turns the switch on/off is patented. That patent expired very recently, so the majority of the Z-Wave switches and dimmers out there still do not support a proactive status update message -- instead, many of them send a "Hail" message, which can be used by the controller as a signal that it should poll the switch/dimmer to find out what changed. If Leviton just turns off "Hail" because it's "obsolete", then we have nothing - nada - zip - zero! Regarding the last sentence, again, just to be clear and avoid mistaken assumptions for future readers -- one cannot get Hail added back, because it was never supported by the ISY in the first place. We need UDI to do what many (if not all) other z-wave hubs do when they get a Hail message (obsolete or not): it should simply poll the device that sent the Hail message. Should be very easy to do. And if that's not possible for some odd reason, then a next-best thing would be to expose a Hail message as a trigger (that's undesirable because it would then restrict most existing Z-Wave switches and dimmers to being useful only by programs -- which in the ISY add a 1 to 3 second delay (usually the latter)). Just to provide a data point: Running a Home Assistant software on an old Dell PC, with an Aeon z-wave stick, the total response time from depressing the paddle to turn on my office light to the time my desk lamp turns on is a fraction of a second -- the desk lamp is on before the main light has ramped to full-on. That's a z-wave paddle switch on the wall sending a Hail message, the Home Assistant software getting that message from the Aeon z-wave stick, polling the switch, running the "automation" (their equivalent of an ISY program), sending a "turn on light" message to the Philips Hue hub, which sends a zigbee message to the bulb in my desk lamp. Yes, that's a silly long sequence of events, but it was set up that way to test things -- and it works flawlessly andfincredibly fast with some open-source software on a surplus PC... that's the expectation users have, and if the ISY (IMO) is going to be taken seriously in the Z-Wave HA space, it needs to be in that same ballpark in terms of performance. High bar, indeed.

Short answer: yes, you can make events on the ISY result in actions on HA. I try to avoid that, however. My strategy is to try to make everything work with the ISY, first. If doing that is not practical or possible, or if it's too expensive, then I'll consider using another automation controller. I also try to avoid crossing automation protocol boundaries in the same part of the house -- what I mean by that is best illustrated by example: the kitchen and dining rooms are all Insteon, and all controlled by scenes, so everything in that part of the house will work regardless of the state of the ISY or any other controllers. Most of the z-wave devices are also on that same ISY -- all the door sensors, the multi-sensors, and the garage door controller, as well as half a dozen plug-in appliance controllers and dimmers. Those devices are all managed by ISY programs, and none are automating things where the delay is objectionable (and in many cases, what they automate is not critical so a malfunction is not objectionable). That leaves a small handful of problematic z-wave devices -- and these all ended up on the second floor. As a result, these z-wave devices don't interact with the ISY-controlled things in any significant way. My current integration strategy between Home Assistant and the ISY is simplicity itself -- even if somewhat crude. I have a python web app running that creates files in a folder based on incoming REST calls. The ISY uses network resources to do this, and Home Assistant watches for these files -- in this way, a program (which might be triggered by a keypad button push) can cause an automation to run on Home Assistant. The other way around is done via ISY variables -- an automation event on Home Assistant can use a REST call to set a state variable on the ISY, which can trigger a program to run. Again, this is a bit "Rube Goldberg" in design, but it works for now. And I'm reluctant to spend a lot more time making a better integration, because it's my hope that some day, one day, perhaps, the ISY may be able to handle those z-wave devices as well... I'm not a fan of multiple automation controllers.

AFAIK, the HAIL functionality is not supported by the ISY -- based on this thread: https://forum.universal-devices.com/topic/22224-leviton-dz6hd-02a-dimmer I hope UDI will rethink their position on this functionality. It's supported by other platforms, and I've found it very useful for my z-wave switches/dimmers.

There is no schedule. Per conversations in many other threads, UDI have not committed to any dates, nor to any specific functionality in any specific timeframe. Based on the past -- >2.5 years since 5.0 began development -- it seems wise to find another solution rather than just wait. My solution is to leverage one of the great strengths of the ISY -- it's open and easily integrated into other solutions. So, I've moved my difficult and contrary z-wave devices to an alternate z-wave controller, and integrated that with the ISY using network resources and the ISY REST interface. I've adopted Home Assistant (https://home-assistant.io/ ) along with an Aeon z-wave USB stick. I needed the stick anyway to update the firmware on some of my other Aeon z-wave devices, and home-assistant runs on one of my always-on Raspberry Pi systems that used to be used for node server development -- so it was pretty much a zero-out-of-pocket investment; your situation may be different. It's rather challenging to get the z-wave stuff working on home assistant; I kept getting distracted by "shiny features" One of the great things I discovered was that HA seems to understand the "HAIL" z-wave feature, which effectively provides "Instant Status" for a lot of devices that couldn't do that feature due to the patent issues... so I actually ended up moving more z-wave devices off the ISY than I had planned. Responsiveness of the HA device is nearly instant (unlike programs on the ISY, not sure about the new in-the-ISY-scene-magic performance, since I've not used that). And where it's necessary, it's easy to have the HA stuff run a script to update a variable on the ISY (which is how I choose to make the two interact).

I'm currently evaluating a software solution (I fear a hub will be too limiting, not to mention that many of them are cloud-dependent). I'm looking at Home Assistant (https://home-assistant.io/) -- I've got it running on a Linux server right now, with the Aeon Labs USB z-wave stick, but if this works out it'll end up on a Raspberry Pi. I can't make heads nor tails, so to speak, of the z-wave Primary/Secondary thing -- perhaps the ISY doesn't play nice with this, but it just doesn't seem to do anything useful for me. So I moved a few devices off to the Aeon Labs stick, so that Home Assistant "owns" those; the ISY no longer sees them. (And I agree - the UDI team are fabulous! Of late, their responsiveness in terms of the new Google Home and the V3 Alexa skill are just awesome -- what other company can go from forum discussion to deployed fix in a week or less?!? But let's be honest - the Z-Wave support seems to be a very steep mountain for UDI to climb (based on the amount of time its taking). And another concern I have is that the two ISY Z-Wave dongles I have are already obsolete, and are completely proprietary to UDI -- we've been down that road with the PLM, and I'm feeling very uncomfortable right now.)

I tend to agree with Gary on this. I'm running a mix of both right now. I feel I've waited long enough for a stable 5.x release -- it's been months since 5.0.10 alpha came out, and there's just been no sign that we'll have anything any time soon on that front (frankly, I don't fault UDI -- they seem to be putting their effort into the Google and Amazon portal stuff, which is where the sex and sizzle is at). The point is that I've just stood up an alternate open-source HA package, and I'm exploring that to see if that's a better route for z-wave support. I'll be keeping at least some Insteon, although as more of those devices die I'll be replacing them with z-wave equivalents. And there's nothing better to handle the Insteon stuff, so my ISY will be staying for the long run. It's really a question of which controller I consider to be the "master" -- and for me, integration with Amazon and Google is not what makes or breaks that, alas. Others will have different priorities, of course - to each their own.

Doesn't have to be a major appliance -- even something as small as one of those cheap knock-off Chinese phone chargers is enough to wack out the Insteon power-line comms. And since the Insteon RF can be adversely impacted by the power-line noise (odd, but true), that's enough to cause all sorts of problems for your devices.

That's like having two steering wheels in a car -- just don't do it, nothing good will come of it. Guaranteed.

Since my pump control is based on the principle of redundancy, the backup controller (a raspberry pi) keeps track of the details (it actually tracks the precise current draw of the pump, taking measurements once-per-second during the full run time). I have it post the exact elapsed time to a variable on my ISY.

My experience: On the device side, - Insteon as a protocol is stagnant -- there have been no enhancements to add or implement security, for example. - Insteon's dual-band technology is flawed (i.e. the RF side becomes non-functional when the power-line side is suffering significant interference). - Smarthome has ceased to be responsive to third-parties (unwilling or unable -- it's all the same in the end). - Smarthome was recently sold and there's been no official statements on new direction yet. From the technology point-of-view, it's pretty clear that switching power-supplies have replaced the transformer supplies almost completely. Further, it's clear that the consumer is not willing to pay for devices that keep the power-line signal "clean" -- and neither UL nor the FCC care whether the power-line in your house is a sine-wave or is distorted by your LED lights, TV, phone chargers, etc. The point is that communications over a power-line in the home is a technology that's simply no longer practical. Oh, it might work -- technically a spark-gap transmitter can still be used to send Morse code signal. But power-line technology as used by Insteon is just too slow, and too sensitive to noise. Finally from the consumer's point-of-view, the Insteon technology is single-source, and doesn't play well with others. The PLM is the only interface, and Smarthome is quite happy to leave that ancient bit of technology as-is (and it doesn't hurt their bottom line that we all replace ours every two years due to the built-in obsolescence). Conclusion: Start looking at the technologies out there, and consider switching to something else. (And yes, that's what I've done: I shall purchase no more Insteon devices, new or used, for any purpose -- as they fail, I'll pull existing ones out of the wall and shuffle them about so that I can keep the technologies working sort of in "room" boundaries.)

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.