jec6613

I don't have children, I have labrador retreivers, and multiple sensors on the opener that will bounce the door back, plus a camera. Since there's no way we can see the garage door from inside the house, and no way without walking outside (even though it's a short distance) to close said door otherwise, I use an IOLinc and some keypad buttons. That said, when the existing IOLinc goes, I'll be upgrading to something with even more logic and sensors. As far as running, it sounds like it would run just fine, but it's a bit kludgy. I have my goodnight program set a variable, then use that variable to trigger other programs. Ditto home, away, etc. By doing this, it also lets me change out how the house responds in the middle of the night vs after sundown, including ramp rates and on levels for lights.

"Sincere apologies. This is an aberrant email from our staging server and not the production. Your account is alive and well and you can access it using your email address."

First hard reset the keypad, then restore its settings from the ISY's admin console. If it's still broken, then replace it - a reset and restore only takes a few minutes.

I was filtering on anything with a tilde character not making a device, but HASS still subscribes to the firehose XML internally, and it's quite chatty, as you say. The things is though, I only have 300-ish Insteon and Z-Wave devices combined, the bulk of the devices are from nodeservers. One Harmony remote, for instance, can show up as dozens of devices in HASS, as I discovered. The thing is though, the firehose honestly isn't *THAT* chatty. At most I get 5-10 state changes per second normally, unless something like an alarm goes off and it'll change 50 or so at once. But even 200 state changes per second should not be an issue for an RPI even with JIT code or even most scripting languages. Essentially: there's no excuse for having code that borks like this, it's just poorly coded.

Yeah, I've noticed that it's quite heavy. Also that, regardless of me filtering them, it loads them into memory. I don't care per se about everything being in the UI, just things without the tilde in front of them which is maybe 200 or so items, but it was loading all of them just not displaying them, then crashing out of memory a few hours later. The really funny thing about how HASS scales up is that it doesn't seem to become CPU or memory or I/O bound, just cruddy coding. It was running on four cores of a Xeon E5, 8 GB of RAM, and SAS SSD, and never had anywhere near that amount of memory demand. And this is the problem of open source... really cool features, generally low QC on the code and efficiency.

I was using the version through HACS.

I think it's just a straight up size issue. Nodeservers eat up a lot of memory on HA, and if I had to guess a single add-on is just chewing up too to load well over 1,000 items. The thing is though, I'm not moving anything out of the ISY because every nodeserver and everything else does do stuff. I've run into HA performance problems before though, when I tried to see if it could run my Insteon setup. It had no chance then, either. It could also be that HA is primarily designed for ARM and the x64 code is a bit of an afterthought.

Well I was able to patch it and get it to pull in info to the ISY, but it appears that HASS itself is bugged and main processes crash with out of memory errors. Which I didn't think was really possible running any sort of supervised code like Python, and the VM's memory load isn't nearly high enough to trigger a physical out of memory. Worse: when it comes back up, it turns tons of things on. Not an Insteon All On event, but every LampLinc comes on, which isn't good.

I'm not sure about the portal interface, but when using the Polyglot/Hue Emulator combination to expose them, the spoken name is tagged in the Spoken note of the ISY itself, which gets backed using ordinary methods.

Exactly, HASS for the UI only. It works well for that, it's the automation and sorting through and issuing dozens of commands in quick succession that was the problem for me, it could take 10+ minutes to execute what an ISY can do in about 5-10 seconds. I'm going to sort out the update issue the simple way ... it's a VM so I can just checkpoint it. I've looked at CQC in the past, but it's spendy for what it does and doesn't offer the flexibility of new interfaces spun up so quickly or the sort of management flexibility of a web app. As a Windows guy I use very different tools, and the learning curve to development is much steeper. On the other hand, I have lots of fun OS-level things to do what I need, Windows Server really includes a ton of extra stuff for free with it, from RADIUS and PKI, to proxies and VPN, and it's all well documented and works very well and doesn't require hacking things together. The downside, of course, is I'm expected to be an expert on about 1,000 different ways to use a Windows server.

Right, using a web application. I can mangle ports and protocols and authentication all I want after that, but I have the spousal requirement (fortunately with no deadline) to have a variety of interfaces available. And put it simply, I'm not a developer, I'm a sysadmin, so I can configure a working app to be a whistling teapot but can't build or debug the app very well. We use Agave HA for a phone app, which is fantastic as such, but she wants it on everything from a 7" touch screen up to a 32" wall panel on Windows, to an 80" TV, or directly from her Mac, and have it be reasonably usable and look good. The only thing we'd be missing then is a wearable UI, which I'm fine with given the current state of wearables. I can get Lovelace or any other HASS web frontend, bring up multiple configurations on multiple ports if I want, and send it through a simple Windows RRAS WAP that can handle auth in a variety of ways (I already have the Windows servers and PKI for other reasons) including just having unauthenticated sessions from an 802.1x secured VLAN for wall panels, or my VPN VLAN, and then lock out functionality as required, and so on. So, for instance, an RPI touch screen in the guest bedroom could access a subset of controls. This sort of thing is also why I'd like an SNMP nodeserver, as it would greatly simplify life for me, but I do have other mechanisms to fire remote commands as required, and in the worst case I can do it in PowerShell, or just use HASS just to manage panels directly. For me at least, all of the automation and home control functions will remain on the ISY. I've tried HASS before and tried to have it manage things some years ago, but so much compute horsepower is required that it becomes at best problematic. Even running on a Xeon E5 based system couldn't make the Python stack a performant option.

At this point, mine are primarily coffee.

Their interfaces they have already are fine, but for me being over Http is important.

I can see where you're coming from with this. Personally, the ISY handles everything just fine already, so I'm looking to use HASS for its pre-built web interfaces for a few projects - basically a frontend. So I have patience for this to get sorted if it'll take a while, and meanwhile a HASS VM doesn't cost me anything.

I'm having similar issues but at different points. In my case, the IOLinc seems to be the point where it bombs out from the debug log. The trouble seems to be that PyISY hasn't been fully updated to handle firmware v5 fully, more than the add-on not working. PyISY should be handling an IOLinc using a different mechanism on v5 firmware, but instead it's being passed to a legacy 4.x device handler and that's where the error is occurring. Without getting more into debugging everything it's hard to tell more, and I'm not that good at debugging.

I did this with Polyglot and harmony. Motion normally works, but once the theater is in theater mode, motion sensing is disabled.

It should work just fine on a switched network. Routed over the internet and tunneling through IPSec, on the other hand, may not be an acceptable situation.

Side note: I've done fiber before, run either 6 or 12 strands of singlemode (it'll come as a single cable) and terminate properly to a fiber patch panel, then run to whatever you want. Don't even try and bother with individual pairs, and singlemode can run 100 Gbit later if you ever have the need. Run it properly once and you'll never regret it. Singlemode SFPs aren't much more expensive than multimode, but re-pulling that cable in 10 years is. If you want some multimode to run things other than Ethernet, might as well run 6 or 12 of that as well, and be sure it's OM4. RS232 over fiber, audio over fiber, and so on frequently will only work with multimode due to cost considerations. But the way things are going, you'll probably be better off with just singlemode and dump everything down an Ethernet pipe. And if you want to try linking the two PLMs via RS232, you can get RS232 over Ethernet adapters and just send it over TCP/IP with everything else. Even a reasonably cheap Netgear switch will be more than enough to handle all of that going over it, their cheap evergreen GS716/724T switches will handle AV over Ethernet no problem, and if you need more bandwidth the M4300 series is designed for AV over Ethernet from the ground up with 10/40Gb support. The tiny control signals will be no problem for any of them to handle.

Assuming the second building is smaller than the first by a substantial amount, I'd just use network resources to pass commands so that every single device is effectively controlled from one ISY.

But if Insteon went away tomorrow, I'd also use Lutron for lighting. Z-Wave to replace the Insteon sensors … and neither of them immediately, I'm 95% built out so there's no rush to move to another platform until things stop working. And I have a spare PLM, and a spare USB PLM for when the Polisy eventually takes it all over. The fit and finish on Lutron are even better than Insteon, and Z-Wave aren't there yet. It'd have to be RA2Select though, since Caseta can't handle as many devices as I have. And hopefully if this ever happens, there will be a Lutron NodeServer.

I'm not sure about a thread, but if you install the Hue Emulator it will expose any device with a Spoken from the ISY via a Hue emulation. You can then add that to the Harmony, I've been very successful using it.

Is this an AFI/GFI breaker? It could be going bad if it's giving you nuisance trips. I'd also re-terminate the wires into the breakers themselves if it's AFI/GFI, to ensure you have good connection there. This is the cause of your red light. The simple way to make sure it's not a programming issue is to hard reset the switch, then restore its configuration from the ISY.

The second node is an Off node. Very much like how there's a wet and a dry node on leak sensors, it's just inverted.

I mean, given all of your requirements are just monitoring, why not use somebody like Sensaphone? The ISY is designed for a lot more stuff, but Sensaphone meets all your requirements and has support in a commercial environment with BMS tie-ins. (heck, even an ISY can talk to a Sensaphone).

Of course it has more than just DIY use cases, but though I likely have the requisite skills, I also have a day job, and have been in IT long enough to know that this sort of gig wouldn't pay enough to make it worth the aggravation of dealing with it as a side job.