That’s what we call “brand synergy”.
That’s what we call “brand synergy”.
Is that anything like transpiling?
Not enough to be a problem. I think things can get unstable around 100-150 devices.
I’m curious how many devices are on your Zigbee network.
I bought an N100 mini PC (not POE) as my new server a couple months ago. I really like it. That processor is great for power efficiency.
people will shit on me about replacing Proxmox with LXD
From reading your comments I understand why. It’s in your delivery. You’re abrasive and you don’t explain why. You’re also telling people not to use something they know, to use something they don’t know, and not explaining how that would be beneficial. As far as I can see, you’ve only explained how LXD, when setup correctly, can do what Proxmox does.
You’re essentially telling people to use something that is at best a side grade for reasons, and being salty about it.
My x86 Proxmox consumes about 0.3 kwh a day at around 15% average load. I’ve only had the Kill A Watt on it for a day, so I don’t know how accurate that is, but it shouldn’t be too far off.
I don’t know personally. But I’d assume it would be from ease of use and reliability.
You could probably get something close to a networked zigbee dongle by running zigbee2mqtt on a pi with a USB dongle and run nothing else on it. It would potentially make restoring it in a failure easier.
From everything I’ve seen, the networked ones are never recommended over USB dongles.
I definitely recommend zigbee2mqtt over ZHA. I originally went with ZHA and just recently went through the hassle of converting over. It was worth it. IMO, it’s best to just start with zigbee2mqtt, and to convert before you have a lot of devices and automations.
Edit: before I posted this comment, I couldn’t see any comments other than the one I was responding to.
To your point, I clicked on this post hoping to see what OP was going to use and why because I would like to build my own NAS some day. But like you said, this post is a waste of everyone’s time.
Learning how to use other Docker images to run Docker containers is an important first step in that process.
I’m a programmer. My foray into learning how to containerize applications started by learning how to run containerized applications. Honestly, running them is the more complicated part (for many cases, some are dead simple).
Turning an app into an image is sometimes just a simple two line Dockerfile.
I started learning with Home Assistant and the branched out to pi hole, Frigate, Mosquito, and other home automation tools. I used that knowledge to containerize a home automation tool I wrote myself.
And now I’m working on containerizing dozens of applications at work.
I like Nabu Casa because it’s easy, it works, and it supports the HA devs.
Auto detection for MQTT devices is a bit tricky. I struggled with that myself when I was trying to incorporate data from a web scraper I wrote. This config file here shows what I ended up with to create auto detecting sensors in HA https://github.com/chunkystyles/reservationsScraper/blob/main/mqttConfig.json
Each one of the devices gets registered at start up of the app.
If I were doing this all over again, I probably wouldn’t use auto detect sensors. I’d manually configure them. Here’s some examples of that kind of configuration I used for some HVAC remote devices I built:
mqtt: sensor: - name: "makerfabs_remote_1" state_topic: "makerfabs/hvacremote/1/status_out" force_update: true expire_after: 125 - name: "makerfabs_remote_2" state_topic: "makerfabs/hvacremote/2/status_out" force_update: true expire_after: 125 - name: "makerfabs_remote_3" state_topic: "makerfabs/hvacremote/3/status_out" force_update: true expire_after: 125 - name: "makerfabs_remote_4" state_topic: "makerfabs/hvacremote/4/status_out" force_update: true expire_after: 125
For these to work, you just put them in your “configuration.yaml” file in HA.