akss

Yep, I run proxmox on a Gigabyte Brix (like a Nuc) with a 6th-gen i7 and 16GB of RAM. Runs like a top, ultra reliable. The restoration story of a ProxMox VM is pretty good - gives me a lot of options to bring it up on any spare local compute resource if need be. It's starting to feel like a Snapcast server may be my next project, which I see runs on FreeBSD. May be interesting to try that. I'd typically just use Ubuntu server as my go-to.

When you say slow, I gather you're talking specifically about hardware access (how the pass-through is adding latency)? Or just noticeable impacts to execution times? It seems to be a thing on ProxMox: FreeBSD Guest Notes - Proxmox VE I think pfSense is FreeBSD and that seems to be a not uncommon client of proxmox in the home server space. But I've certainly not done it personally and can't attest to performance. EDIT: reading through a few posts on the proxmox forums, it looks like a headache. I think in the enterprise space, hyper-v runs FreeBSD and has some direct hardware driver work done for it to address performance, but that's a whole different thing, obviously.. unless one is running windows server at home, which.. I mean, people do. I used to.

@Michel Kohanim speaking for myself, I hope you don’t think I’m trying to tell you or the community how things “should” be done, I don’t know jack beyond what I’ve found useful personally, and my questions are only coming from a place of raw curiosity. I appreciate your patience in explaining why decisions were made, I find it all fascinating for its own sake and feel I can empathize a bit with the demands to make product decisions in a timely and committed manner. re: the Linux recompile, couldn’t the FreeBSD image as-is just be run as a VM on any x86? I mean, no recompile necessary, no conversion to Linux, etc? Isn’t that the big advantage of such deep abstraction? A container is probably never an option but a VM? Again, not saying this should be done or that UD “should” support this, just curious if it would work. But yeah, maybe there are other non-hardware ancillary product ideas for UD down that path.

Not specific to me, just responding to post saying they had a gaggle of systems to load up on one host. If they can’t load them all up on the eisy hardware, what about running the eisy VM on a different host? I can imagine some issues there, but if I had one I’d have a hard time not trying it just to satisfy curiosity. What’s your position on doing so, acknowledging such a person would floating out into deep space alone without a tether (no support, no sympathy)? Known issues with boot process (like tied to the tpm)? Prefer people don’t do that (which is entirely fair)?

@ndfan77 What about (for science!) coming at it from the other side - running EISY in a VM or container on other hardware? Secure boot might screw with this if it’s in use (?) for the EISY stack, and be entirely unsupported, but you might be able to P2V the bhyve instance or maybe something like qemu-img would help convert the disk image to mount with another HV. Then you’d be off to the races with a beefier host. Not sure what M would think of this - the EULA For your EISY may demand only their hardware kinda like MacOS does.

I hereby nominate you to write the "HA guide for Dummies" book that the world needs desperately! Lord knows I can't write a thing unless it's verbose, pedantic, and full of jargon. We can include a chapter on running HA on EISY hardware! Sold! 😉

Slight correction to your diagram - VMs are the individual instances that run upon a hypervisor. Not sure what EISY is using, but yeah the HV can be packaged as THE operating system (a Type 1 hypervisor) like ESX or ProxMox, or function as a more loosely-coupled application over an existing OS installation (a Type 2 hypervisor), like DosBox or VirtualBox.

@DualBandAid, it's helpful to think of it as two discrete machines, just run virtually as isolated instances on one physical piece of hardware. So from a logical design perspective, it would be the same as running HA on your green, and EISY on the EISY, but now they're just separate VMs on the same piece of hardware. Like an apartment building instead of two houses. Almost certainly, UD's scripts would be passing the USB ports through to the EISY virtual machine and not giving HA direct access to hardware. In that way, the EISY VM would be the controller for any hardware accessories connected to the box (like radio dongles), and then via a network connection HA would use the EISY integration to see all the devices that EISY can see. The HA would, however, see and establish direct connections to other elements exposed just on your IP network (Wifi, etc). One of those elements exposed on your IP network will be the EISY VM itself, so you'd use the ISY integration in HA to communicate with it, NOT the direct Insteon integration - because your HA VM is not seeing the USB port the PLM is connected to. Zigbee and ZWave would work the same - EISY sees them, and HA sees the EISY over the IP network. Again, just think of them as logically being two separate machines, but physically the hypervisor, a low-level manager of hardware abstraction, lets you run both of these machines on one piece of hardware. Is that about right @Michel Kohanim?

@Kentinada I know you're probably trying to avoid replacing the thermostats if you can find a way to integrate what you have. If you're looking for a thermostat with a local-only and well documented API, you might want to look at Venstar thermostats. They have a decent reputation; I don't own one; I'm not affiliated in any way. But something to consider since most have never heard of them. @Michel Kohanim Good points. Out of curiosity, have you thought of using your already sourced hardware (or arguably a cheaper variant with no HDMI ports) to just build a straight HA Yellow alternative? I realize it might represent a distraction from core business, but it also seems like a market opportunity - off-the-shelf, pre-built solution for HA, with no dependencies on RPi's. Anyway, congrats on the record sales!

Yep, true. It's complicated by the fact that the field of options is so broad, any guide may contain things that are entirely irrelevant to your needs, which can send one down roads of fruitless complexity. Such a guide, I imagine, would need to be structured like a choose your own adventure novel, while also previewing the impacts of choosing one path over another (like how do I know what path I should take??). Also complicating it is the pace of iterative development: a guide from 2021 is probably unnecessarily complex compared to the 2023 (sorry 2024) product. More and more functionality is being smoothed over, the automation workflow in particular just within the last month (https://www.youtube.com/watch?v=OV_bSXwh3-g) I'm more of a "plunge in and thrash wildly about" kinda guy, where RTFM is just a contingency plan, but the docs are pretty good, the glossary is a helpful link to keep handy, and of course google with the filter of "site:community.home-assistant.io" to search the forums (my most used resource). And reddit. But as with all things, a bit of RTFM up front would have saved me a lot of thrashing, but what fun is that? Getting Started - Home Assistant (home-assistant.io) Glossary - Home Assistant (home-assistant.io)

@xlurkr yep, that all makes sense to me, I think. And like @RPerrault said, the ability to "replace" an Insteon device is probably smoothest on an (E)ISY. Home Assistant, AFAIK, will not swap a device like that (relevant discussion: https://community.home-assistant.io/t/wth-there-is-no-easy-and-automated-way-to-replace-devices/468863/18). And while I'll likely replace my Insteon devices with something else if/when they each fail, this feature limitation for impact analysis and device/entity replacement affects all integrations in HA, not just Insteon/UD. @asbril, my nearly-bricked gen 1 Sonos speakers are feeling triggered by your comment. This video from EEVblog on turning these into "Fronos" speakers is ever on my mind: https://www.youtube.com/watch?v=IeIk-4ItQ70 @Kentinada, I noticed you didn't mention linux pain in particular. It's been my experience that HA does a good job of keeping that away from users - that everything is happening in the app, but unless you intentionally go looking for trouble, HA keeps Linux pretty well concealed, and in fact discourages users from shelling into it directly. Has that been your experience as you started working with the Green? I may underestimate how much of a learning curve exists with Home Assistant - sometimes - but I feel like the ISY ecosystem was no different when I first got that guy going. I remember reading forums a lot to climb the learning curve for setting up jobs and logic in ISY's particular idiom, dealing with finicky devices, understanding the PLM's expectations. I'm not sure I can articulate this well, but I feel that the maturity of home automation in last 5 years particularly has been moving locus of control to be more heavily focused on software integration (APIs) and less on bare metal electronics - more the domain of software developers and less so of electricians. There's still the maker community building new stuff with ESP32 and other RTOS or SBC platforms (e.g. WLED and QuinLED), but there is an expectation that all of that work ultimately gets abstracted by an MQTT interface or REST API, allowing standards-based integration. And there is increasing pressure on OEMS to follow suit, I think - build what you want, but give us a standard interface. And in a way, that realignment reminds me of similar shifts in industries like telecom where the importance of low-level knowledge serving all the analog infrastructure started rapidly being displaced by a need to understand the digital protocols and the software stacks built on top of them (fiber, software switches, orchestrated soft provisioning, etc.). And I propose that you see this reflected in Home Assistant: the whiff of software development is all over that product - YAML, Python, MQTT, git repos, etc. - so the learning curve to get into it is of a really different nature than prior generations of home automation equipment. I'm not sure it's "harder" than it ever was, but it's a different focus, maybe? I'm not going to die on that hill, just thinking out loud about it. Re: beer trucks and all (assuming that's the same as "greyhound syndrome" - getting hit by a bus), at least with OSS a developer leaves behind their source code and schematics, which can be forked and picked up by others. There is a network effect though, where the deeper and broader the user base, the more likely a piece of OSS is going to have a geographically diverse community supporting it. A niche plug-in for a niche platform has more risk from the beer truck than one which is more broadly used. That idea gives me more confidence in a platform like HA having pretty good longevity in the face of renegade beer trucks.

@DualBandAid - yeah that's correct. When I plugged my USB PLM into to the HA machine (and reloaded HA, which isn't a reboot), it recognized the PLM and prompted me to install the Insteon add-in. I'm pretty sure that when I had the ISY on the network, HA saw it and prompted me to install the integration for that, but I can't recall precisely. For my situation, since the use of HA prompted me to upgrade my PLM to a USB device, I re-paired all my Insteon devices with the new PLM. With HA that process will be a very familiar two-step - in GUI tell it to add new device(s), then on device hold the set button for three seconds and it gets picked up and added to list of devices. So I'm no Insteon expert, but I think that if you were to use the same PLM, each device would already have links to the PLM in it's local ALDB and everything may just come over. The primary advantage of the UD/ISY integration (it seems to me) would be not having to rebuild all our automation logic in HA (you can kick the can down the road). And that process is very similar to adding new Zigbee devices. When I plugged the Zigbee dongle in, HA recognized it and prompted me to install ZHA, I think, which is its native Zigbee integration. That's a straight play and pretty easy to get Zigbee working. If you like making life more difficult like I do, you install the Silabs multi-protocol add-in to get Thread support on your Dongle-E, the Mosquito MQTT broker add-in, then the Zigbee2MQTT add-in, then the MQTT and Thread integrations in HA. This basically converts the Zigbee signals to use MQTT, which is a barebones message queue. But anyway - pairing a new device is similar to the above - in HA you tell it to allow pairing either from the core dongle, any device, or a specific gateway you installed out in the field. The latter is helpful when you want to make sure a device pairs with nothing except the particular gateway it's in close proximity to. Then press and hold button on device for a time (varies by device) and it pairs up. @xlurkr - heard, but it sounds like OP is keeping his Insteon devices and may start the tests with the UD integration. But to your point, this conversation is HA-heavy and weedy. The HA forum is a very useful place that will have more and better info than I'm handing out: Home Assistant Community (home-assistant.io). You mentioned you're using your Polisy with HA. Are you keeping your devices and programs on the Polisy and using a separate machine for HA, or are you literally running HA on the Polisy? What's the advantage of using the Polisy/EISY in a home environment rather than doing a direct Insteon integration with HA? Genuinely curious. Like what would cause me to recommend that someone go this route rather than building their own HA or buying a green/yellow? Is the market more for people that need off the shelf openadr certification? Is it just easier to get going (i.e. "it just works") and less fiddling required by people? If you're in the boat of running HA anyway on the polisy or on a separate machine, I guess you've already got that trouble in your life, so then what's the advantage of keeping the Polisy device in service? I can certainly empathize with not wanting to migrate and name scores of insteon devices and redo automation logic if I could avoid it for some number of years.

Oh I see, no, that was my misunderstanding. Z-wave is definitely not my wheelhouse but I see people say good things about the Aeotec brand sticks (with 700 series support), and of course Silicone Labs has made a good impression on me. If I had to buy one today, I'd likely go with one of those I guess. BTW, you've got me kind of energized to hear how your tests go..

Re: new ecosystem - I hear ya, and in my experience with linux variants, "there's always something" that requires fiddling with. I will simply say this, however - HAOS boots and it expects you to use the web interface / mobile app exclusively. In fact, I feel like they actively discourage one from SSH'ing in and fiddling with things. But I know what you mean. Re: zwave - that's a whole thing. For example: this discussion on reddit; There's a lot of bias (and BS) on both sides about why the other sucks. I'm not an expert but personally I viewed it as trying to do one or the other, and I settled on zigbee for a variety of reasons and it works fine for me. But regardless, both Z protocols will require some planning on deployment for repeaters, interference, picking parts for quality, etc. But more broadly, I feel like home automation wireless technology is in a pretty huge transitional and shake-up phase right now, specifically as different wireless protocols are explored for HA devices in new, creative, and efficient implementations: LoRa, Thread, Wi-Fi, BTLE. For this reason, I'd be cautious about investing too much money and labor in either zwave or zigbee. Some people a year ago were like, "shit, quick, replace all the Insteon with a Z protocol". That can represent a sizable investment, the product of which may start to feel a bit stodgy and dated sooner than we think.

@DualBandAid - 1. I concur with @xlurkr in that the pre-built Yellows seem dang hard to find owing to the CM4 shortage. RPi still hasn't caught up to demand. But if you have a green on the way, I say run with it. The specs will get you pretty far, I think. It is ethernet only (no wifi) but that's not a bad attribute for the role it will play - a hardwire is advisable for reliablity. I have my Brix hardwired to the network even though it has a wifi radio. 2. I think the transfer/restoration would be relatively easy. HA has built-in backup functionality, and there are add-ins that you can configure to automatically upload these backups to Google Drive or OneDrive from within the HA gui. If you have a NAS like QNAP or Synology or some sort of disk storage that supports SMB file shares, you can backup to those as well (local only). So if you got a new machine, you can just restore from those. This link has some deets: Home Assistant: Ultimate Backup Guide - Derek Seaman's Tech Blog If you've done app development, you may be familiar with Git/GitHub. If you want to get really nerdy you can keep all your config information in a git repo, which is what I do. This augments a full backup to some degree, but where it's really helpful is the ability to diff the changes over time and keep a record of what changed and when. It's a more technical rabbit hole, but pretty cool that the platform plays nice with this kind of thing and I think reflects the sophistication of the ecosystem. 3. If you have 4th gen Hue, they do Bluetooth or Zigbee, and just Zigbee for earlier gen stuff. With the Green, as @xlurkr said, you'd need to be adding your own radios for this, like the Sonoff Zigbee Dongle-E (v2) adapter and/or a Bluetooth adapter. Zigbee is a solid bet though. I use the Zigbee2Mqtt (Z2M) and Mosquito Broker (installed as add-ins through HA) for a lot of things and am very pleased with it. The latest Zigbee adapters often will be multi-protocol, in that they'll support Thread. So I wouldn't worry too much about the lack of on-board radios on the Green, as you'd probably want after-market devices anyway that are more capable than any onboard radio and have the flexibility to move the antenna away from the computer (e.g. via extension cord). It makes sense to me why they didn't put radios aboard the Green. 4. Yes, HA does integrate with Alexa. I don't use any voice reco in my house, but I know it's a thing that HA supports. Amazon Alexa - Home Assistant (home-assistant.io) Much of this makes more sense when you can actually get into the HA interface and see the context. 5. HA will frequently auto-detect things that show up on your network and prompt you to install integrations for them. But sometimes you need to use a manufacturer's app to get a device on the network (particularly if it's wifi). But this really depends on the device in question. I try to eschew any devices that make proprietary apps or cloud connectivity a critical part of the operation, favoring pure local control. It plays a big role in my purchasing decisions. In some cases, you'll have devices that natively just show up in HA (like Insteon, for example, once you've activated the native Insteon integration). A device like the Shelly T&H sensor will come with instructions telling you to download their app, etc., but this can be safely ignored and the device paired over Zigbee or wifi directly with HA (using the native Shelly integration). From reading forums and reddit you can pretty quickly get an idea of which manufacturers play best with HA vs ones that seem more closed by design. Some devices like a Sonoff smart plug which is based on ESP32 can be flashed with Tasmota firmware to make them local only devices - this is more advanced stuff but cool AF since it lets you co-opt a manufacturer's hardware (Getting Started - Tasmota). These are ways of getting around the whole "install my app" nonsense. That said, sometimes there is value in using the manufacturer's app if you can get more control over the device than is exposed through the direct HA integration. Some devices are going to want to lock you in to having a cloud account with them (e.g. Google Nest and Roomba are going to push this hard, though I believe the devices can survive pretty well being blocked from the Internet, but Google and Roomba won't tell you that - HA community forums will, however). Sometimes the app is just for initial activation (e.g. Ecowitt might still do this to get the device on your wireless network, but from then on you can block its access and it will continue working fine locally), but sometimes it's for ongoing use (e.g. Schlage Encode Plus exposes more functionality in the app like access code schedules, etc). But it does really make you start to be a bit more selective about privacy and all. If you outgrow the Green, I guess your migration path would be to purchase a Yellow and restore your HA setup to that new device, or purchase a micro PC or similar from Ebay (often less than $200) and install HAOS directly on it ("bare metal" install). It's not too hard to pull this off, and micro PCs from years ago are still more powerful than the latest RPi's. If you have an old Mac in the closet you could probably install on that if it has x86 chipset. You can run HAOS in a VM on your current Mac, but I'm not sure you want to be using your daily driver as your home automation server tethered to a PLM. Nonetheless, here's a link that may give you some ideas: MacOS - Home Assistant (home-assistant.io) But I'd really recommend considering an old Dell Optiplex or HP Mini Computer from Ebay if you're comfortable with buying from randos online. HAOS is just linux, so the process is similar to building any machine - make a boot disk out of a USB thumb drive using something like the Balena Etcher app (works on MacOS) and then boot the spare PC off that thumb drive. Plenty of online guides walk you through this, but just pointing out that it's nothing to be too intimidated about. Since HA just exposes a web app when it boots, you'd connect to that and restore the backup from your Green. Should work pretty spiffy, but I'm talking theoretically here. I think this agrees with everything xlurkr was saying, but I'd not try too hard to find an RPi CM4 when you can save a workable droid from the landfill using EBay and get more capacity for doing so. I mean, look at all these little guys who just want a new home: micro pc i7 16gb for sale | eBay