6 ms·

There is Zigbee, Z-Wave and Matter. These are all smart home standards that are fully local and devices will be able to be set up and used even when the company

There is Zigbee, Z-Wave and Matter. These are all smart home standards that are fully local and devices will be able to be set up and used even when the company goes out of business. You are however limited to the things that are standardized. If you want to go a step further, look for devices made for ESPHome or devices made by Shelly. Both have local APIs and are very hackable. (disclosure: I am the president of the Open Home Foundation and ESPHome is one of our projects and I am also a board member of the Z-Wave alliance)

hardwaresofton 1y ago
> There is Zigbee, Z-Wave and Matter. I am not a practitioner, but instead someone that looks at the ecosystem from time to time and has been waiting for a while, because I dont see the stack + DX/UX that I want yet. Zigbee never reached critical mass and requires a hub. Z-wave seems to be the same. Thread over wifi (IIRC different protocols/transports are just fine) is what I think will be the future. IMO Thread wins out, support gets put into routers, and I can just have a thread enabled router which MAY have other I don’t want to buy an IoT hub. Many IoT devices I want to control are powerful enough to run Wifi, and I want to control them with a standard networking stack with high adoption and familiar tooling. Thread seems to fit this use case the best. Please feel free to rip apart the above opinions, they’re loosely held. I’d love to learn how wrong I am today! > If you want to go a step further, look for devices made for ESPHome or devices made by Shelly. Both have local APIs and are very hackable. Thanks for the recommendation! Appreciate the disclosure and apologize for the blast of relatively uninformed opinions. One more side question — why is it so hard to get a simple IoT button that runs local Wifi (really hoping for no base station) only and is battery chargable? Buildable with an ESP32 clearly but I just want to buy this.
- balloob 1y ago
  Maybe not exactly what you are looking for, but check out the Shelly BLU Button1. It's a BLE button with a long battery life. It sends out BLE packets when pressed, which can be picked up by Home Assistant via a Bluetooth adapter or using a Bluetooth Proxy. You can make the latter with any ESP32 and https://esphome.io/projects/?type=bluetooth https://esphome.io/projects/?type=bluetooth
  - hardwaresofton 1y ago
    Thanks for the recommendation! This definitely makes it easier. IIRC BLE power mode + wake on BLE + wifi would probably work for easy use! Sounds like a far off weekend project
  - hardwaresofton 1y ago
    BTW, just bought a bunch of Shelly stuff. Looks like that project might happen sooner than I thought! The Shelly 1 also looked like a good option :) Thanks again for the rec.
- yjftsjthsd-h 1y ago
  With Thread+WiFi, can devices talk to the internet? Because denying them that ability is a lot of why I like Zigbee/Z-Wave.
  - balloob 1y ago
    Wifi yes. Thread depends on the settings on the Thread Border Router. Ours defaults to no internet access.
  - deleted 1y ago
    [deleted]
  - hardwaresofton 1y ago
    I’m sure I’m speaking to the choir here but access to Wifi != access to the internet! Why I’m excited about thread over wifi is that I don’t need any extra specialized gear and possibility one device could run by itself
    - mook 1y ago
      While true, it's really hard to shop for devices that have access to WiFi without internet. It's too easy for the manufacturer to slip in the internet requirement and not put it on the box. Using other protocols makes the expectation disappear.
      - hardwaresofton 1y ago
        This is a good point I haven't considered until now. Inability for the ad-supported model to ever sneak in. Now I'm really wondering why over wifi didn't take off.
- cyberax 1y ago
  ZWave is the most stable radio-based standard right now. It's not great, and it's not very extensible, but it's OK-ish. There's one hackable device: https://z-uno.z-wave.me/technical/ https://z-uno.z-wave.me/technical/ but its SDK is not that great. Pure ZigBee is... spotty because there are no certification requirements. Matter is stuck in development hell, but is slowly getting better. And the problem with WiFi is energy efficiency (or a lack thereof) compared to ZWave/ZigBee/Thread. So far, I've tried probably most of the home radio standards. Lutron was the most reliable, but it's also super-proprietary. My next house will just have conduits with low-voltage cables running to all the light switches, so I can use something like KNX instead of the radio-based stuff.
  - hardwaresofton 1y ago
    > And the problem with WiFi is energy efficiency (or a lack thereof) compared to ZWave/ZigBee/Thread. This is a problem I'd really like to solve the old fashioned way/I think it prevents too much building. Energy density, rechargability, etc are like CPU speed to me -- it will eventually be solved, and I can deal with replacing a device every month or swapping a rechargable battery (especially if the device can tell me it's low). I really do think it will be Thread+Wifi routers that eventually get a built-in Thread antenna that win (at least wining me over). If either ZWave or ZigBee had managed to get into the home router space, they would have won already IMO. There are probably annoying reasons they couldn't until now. > So far, I've tried probably most of the home radio standards. Lutron was the most reliable, but it's also super-proprietary. My next house will just have conduits with low-voltage cables running to all the light switches, so I can use something like KNX instead of the radio-based stuff. Thanks for sharing this and your other experience! Also TIL KNX.
    - cyberax 1y ago
      > I really do think it will be Thread+Wifi routers that eventually get a built-in Thread antenna that win (at least wining me over). That actually had been the case for a while. A lot of WiFi routers had a built-in Thread (ZigBee) radio, but then nobody actually used them and the manufacturers stopped bothering with them. So now pretty much only Eero access points still have it. > Also TIL KNX. My dream is to have _actuated_ switches, that have full tactile feedback. So that the paddle will physically flip when switched remotely. I commissioned an engineering company to look into that, but apparently this is not feasible at all with the NEC and UL requirements in the US. The only way is to use low voltage wiring to the switches and then use them to control line-voltage relays. This kind of system is popular in Europe, so you might as well just go with something like KNX.
- baq 1y ago
  > why is it so hard to get a simple IoT button that runs local Wifi (really hoping for no base station) only and is battery chargable? Battery life is atrocious and latency from deep sleep will be very bad. I’ve got Zigbee buttons from ikea that run on nimh batteries for a couple years now and only used like half of the charge. The hub is an usb dongle attached to the home assistant server, no issues.
  - hardwaresofton 1y ago
    > Battery life is atrocious and latency from deep sleep will be very bad. I’ve got Zigbee buttons from ikea that run on nimh batteries for a couple years now and only used like half of the charge. The hub is an usb dongle attached to the home assistant server, no issues. So what do you consider to be "bad" battery life? I've got quite the tolerance, but the problem is that they don't even exist. Everyone seems to stop out on this at "it would never be worth it". > Zigbee buttons from ikea that run on nimh batteries for a couple years now and only used like half of the charge. This is intense for me, I'm happy with replacing batteries every 6 months if I could simplify deployment by 10x. > The hub is an usb dongle attached to the home assistant server, no issues. Maybe deployment isn't as hard as I'm making it out to be! That said, nothing easier than sending some packets to an IP address. I assume Zigbee APKs are easy... But for example if I search on crates.io (https://crates.io/search?q=zigbee https://crates.io/search?q=zigbee) I don't see any obvious choices. To restate what I want (and hopefully is sounds a bit more reasonable) I want to be able to buy one smart light bulb, configure it over BLE to connect to Wifi and for the rest of it's live configure it/change it via Wifi. I want that for basically every device, and I'm fine with swapping batteries every 1 to 6months if I could have that!
    - baq 1y ago
      BLE should also work but you also want a dongle, so hardware wise it’s the same; ideally you also want a couple gateways (Shelly devices can do that out of the box btw, and new Shellies will be supporting Zigbee.) You should look into zigbee2mqtt IMHO.
      - 1y ago
- Asmod4n 1y ago
  thread and matter will, in my opinion, never matter for consumers. Why? It’s basically a walled garden. Think HomeKit but a tiny bit more open, the open bit is, that a vendor can allow it to communicate with devices of other vendors. But they don’t have to. Thread also needs more expensive SOCs, with Zigbee you only need a tiny micro controller with a few MHz of clock speed and a few KB of RAM. Thread and matter on the other hand can require megabytes of RAM. Vendors which nowadays sell HomeKit devices can reuse their SOCs for thread matter, keeping their 3-4 times higher prices compared to devices with the same functionality from Zigbee vendors.
  - hardwaresofton 1y ago
    > thread and matter will, in my opinion, never matter for consumers. Why? It’s basically a walled garden. I'd counter with the fact that walled gardens are incredibly popular, and in particular to consumers. Consumers don't care if the gate is locked or not, they care if the flowers are pretty and the tea at the garden party is nice. > Thread also needs more expensive SOCs, with Zigbee you only need a tiny micro controller with a few MHz of clock speed and a few KB of RAM. Thread and matter on the other hand can require megabytes of RAM. IMO prices of SOCs are going to zero. ESP32s are a great example of this. Once RISCV is more widely used and capable things will accelerate even faster. > Vendors which nowadays sell HomeKit devices can reuse their SOCs for thread matter, keeping their 3-4 times higher prices compared to devices with the same functionality from Zigbee vendors. I think we agree here...? I think that HomeKit device that is just a bit more open is going to win. But I think that HomeKit device gets adopted faster if it's just a router -- I can understand updating a router to get a smart home. What I don't want is confusion around whether I need a hub or not, or whether devices work together or not. Buying a single router that acts as a hub + Wifi "repeaters" (IIRC that's what they're called) that can "extend" the signal (and along the way give other devices a point to connect to) makes perfect sense to me as a consumer. I already know what WiFi is, and I want better coverage, not worse. The smart home stuff just falls out of tech I am already familiar with, efficiency by damned.
    - Asmod4n 1y ago
      Thread is a WiFi replacement, the devices talk IP over thread. And it has an encrypted pairing process to your vendor controlled hub. Said vendor can allow or disallow it which other vendors may speak with said hub. Here is the landscape we have: HomeKit: fully closed, requires certification from Apple. Very expensive and limited functionality. Zigbee: fully open, anyone can make Zigbee devices and sell them without any restriction. Operates on the same frequency all over the world. Devices are super cheap. You can expand the protocol however you like as a vendor. Z-wave: fully closed, several incompatible frequencies, requires certification to sell devices. Thread and matter: semi closed, same ieee standard as Zigbee for data transfer. Vendors can allow it to talk to devices of other vendors. Requires certification. Same price tag as HomeKit, aka 3-4 more expensive than Zigbee. All of them require hubs. And only with Zigbee you are guaranteed to have interop between all vendors and all devices sold across the globe. Thanks to Home Assistant. With thread the vendor can simply disallow you to use your devices with HomeAssistant, which is unacceptable by me.
- raffraffraff 1y ago
  Does the hub requirement matter that much though? I mean if you want truly peer to peer, then yeah, but if you're already using Home Assistant you can plug a cheap ZigBee usb dongle into that. So the bit I'm missing: how do you control them purely over WiFi? Do you run software on your phone that can control the target? Eg: app talks directly to the device over your network, instead of via a browser + Home Assistant running on a Pi. I can't think of any examples of a product that works this way without being cloud enabled (IE: there is a hub but you don't own it)
  - hardwaresofton 1y ago
    > Does the hub requirement matter that much though? I mean if you want truly peer to peer, then yeah, but if you're already using Home Assistant you can plug a cheap ZigBee usb dongle into that. Maybe not, but I don't really want to actually run Home Assistant, I want the basics to hack on, really. Trying to pick the most open thing that will be easy to program without relying on using something like Home Assistant (not that its bad or anything). > So the bit I'm missing: how do you control them purely over WiFi? Do you run software on your phone that can control the target? Eg: app talks directly to the device over your network, instead of via a browser + Home Assistant running on a Pi. I can't think of any examples of a product that works this way without being cloud enabled (IE: there is a hub but you don't own it) Yeah that's my goal -- basically I want to be able to control the devices from anything web connected (and ideally, the same program running in multiple places). My thinking is that I can build this without being cloud enabled if I "just" (famous last words) had Thread/Wifi. With all the excellent feedback in this thread (thanks HN!), it's looking like a small SBC + a Thread/Zigbee/BLE dongle[0] is the way forward, and hooking that up to my router via USB so it's always powered and follows the router around (maybe velcro it on). SBC (or something smaller maybe, but probably the SBC) so I can program it myself. [0]: https://sonoff.tech/product/gateway-and-sensors/sonoff-zigbee-3-0-usb-dongle-plus-e/ https://sonoff.tech/product/gateway-and-sensors/sonoff-zigbe...
    - lawn 1y ago
      The basics of Zigbee isn't Home Assistant, it's something like zigbee2mqtt with a USB dongle and then you interface directly to an mqtt broker. For my automations I do just that and I bypass home assistant and control my devices directly over mqtt. It works very well.
- viraptor 1y ago
  > I don’t want to buy an IoT hub. Different expectations. I don't want my things to know that wifi exists. It stops vendor lock-in, it ensures local communication, it means things work even if network goes down. It also makes sure they will never autoupdate or join Mirai botnet. I've got a mix of zwave (fibaro), ZigBee (Ikea) and ble at home and I'm ok with that.
  - hardwaresofton 1y ago
    Yeah I think so -- I like to think I can control my router at least, so I don't have to worry about it. That said, probably not protected from the botnet case. Also, unfortunately up until now I've been saying the wrong thing -- I mean Matter over Thread versus Matter over Wifi. Matter over Wifi seemed like a winner to me because I could just use it. It looks like going forward I'll be plugging a small SBC into my Router's USB (+ ethernet) and connecting a Zigbee + Thread dongle. That should cover me for most communication options, then from there it's "just" a software problem :)
  - wlesieutre 1y ago
    Same boat here, I like knowing that none of of my devices can get network access, all they can do is communicate with HomeAssistant. And with Zigbee bindings most of my inputs are set up in a way that they still work even if HomeAssistant goes down. Not that HomeAssistant has ever down, but I can imagine its SSD or something failing and not bothering moving it to a different computer for a few days while I get a replacement in.
- Aurornis 1y ago
  > I don’t want to buy an IoT hub. Many IoT devices I want to control are powerful enough to run Wifi, Having a lot of career experience in this area, I greatly prefer to keep my IoT devices off of my WiFi. You don’t need a separate hub device for Zigbee or Z-Wave, just a simple USB adapter that you plug directly into your device controlling everything. Keeping the low bandwidth IoT devices off of the main WiFi had a lot of advantages. It’s also much easier to rotate your WiFi password when you can do it all without reconnecting every light switch in your house, for example.
  - hardwaresofton 1y ago
    Thanks for sharing your experience here -- agreed that it's better to avoid the chatter and also rotating your WiFi passwords is indeed an issue to consider, that would be quite a pain.
- cbull 1y ago
  The "Hub" device can be as simple as a USB stick that's attached to the machine running Home Assistant. That's what I have been running for years, a Z-Wave USB stick that passes through to a ZwaveJS docker container (which also communicates with HA). So it's not like you need a big stand alone device that has to have it's own Wifi or ethernet or anything like that, it's just a USB stick.
  - hardwaresofton 1y ago
    Thanks! This is what I eventually got to. That said, I'm leaning towards putting the USB stick in a Pi or something like that, which is attached to and powered by the router! Just want to have the one device and I think that's maybe the simplest way to get it without trying to run stuff on the router. Basically, it is a hub, but it's more of an attachment to the router than anything else.

hardwaresofton 1y ago

> There is Zigbee, Z-Wave and Matter. I am not a practitioner, but instead someone that looks at the ecosystem from time to time and has been waiting for a while, because I dont see the stack + DX/UX that I want yet. Zigbee never reached critical mass and requires a hub. Z-wave seems to be the same. Thread over wifi (IIRC different protocols/transports are just fine) is what I think will be the future. IMO Thread wins out, support gets put into routers, and I can just have a thread enabled router which MAY have other I don’t want to buy an IoT hub. Many IoT devices I want to control are powerful enough to run Wifi, and I want to control them with a standard networking stack with high adoption and familiar tooling. Thread seems to fit this use case the best. Please feel free to rip apart the above opinions, they’re loosely held. I’d love to learn how wrong I am today! > If you want to go a step further, look for devices made for ESPHome or devices made by Shelly. Both have local APIs and are very hackable. Thanks for the recommendation! Appreciate the disclosure and apologize for the blast of relatively uninformed opinions. One more side question — why is it so hard to get a simple IoT button that runs local Wifi (really hoping for no base station) only and is battery chargable? Buildable with an ESP32 clearly but I just want to buy this.

balloob 1y ago
Maybe not exactly what you are looking for, but check out the Shelly BLU Button1. It's a BLE button with a long battery life. It sends out BLE packets when pressed, which can be picked up by Home Assistant via a Bluetooth adapter or using a Bluetooth Proxy. You can make the latter with any ESP32 and https://esphome.io/projects/?type=bluetooth https://esphome.io/projects/?type=bluetooth
- hardwaresofton 1y ago
  Thanks for the recommendation! This definitely makes it easier. IIRC BLE power mode + wake on BLE + wifi would probably work for easy use! Sounds like a far off weekend project
- hardwaresofton 1y ago
  BTW, just bought a bunch of Shelly stuff. Looks like that project might happen sooner than I thought! The Shelly 1 also looked like a good option :) Thanks again for the rec.
yjftsjthsd-h 1y ago
With Thread+WiFi, can devices talk to the internet? Because denying them that ability is a lot of why I like Zigbee/Z-Wave.
- balloob 1y ago
  Wifi yes. Thread depends on the settings on the Thread Border Router. Ours defaults to no internet access.
- deleted 1y ago
  [deleted]
- hardwaresofton 1y ago
  I’m sure I’m speaking to the choir here but access to Wifi != access to the internet! Why I’m excited about thread over wifi is that I don’t need any extra specialized gear and possibility one device could run by itself
  - mook 1y ago
    While true, it's really hard to shop for devices that have access to WiFi without internet. It's too easy for the manufacturer to slip in the internet requirement and not put it on the box. Using other protocols makes the expectation disappear.
    - hardwaresofton 1y ago
      This is a good point I haven't considered until now. Inability for the ad-supported model to ever sneak in. Now I'm really wondering why over wifi didn't take off.
cyberax 1y ago
ZWave is the most stable radio-based standard right now. It's not great, and it's not very extensible, but it's OK-ish. There's one hackable device: https://z-uno.z-wave.me/technical/ https://z-uno.z-wave.me/technical/ but its SDK is not that great. Pure ZigBee is... spotty because there are no certification requirements. Matter is stuck in development hell, but is slowly getting better. And the problem with WiFi is energy efficiency (or a lack thereof) compared to ZWave/ZigBee/Thread. So far, I've tried probably most of the home radio standards. Lutron was the most reliable, but it's also super-proprietary. My next house will just have conduits with low-voltage cables running to all the light switches, so I can use something like KNX instead of the radio-based stuff.
- hardwaresofton 1y ago
  > And the problem with WiFi is energy efficiency (or a lack thereof) compared to ZWave/ZigBee/Thread. This is a problem I'd really like to solve the old fashioned way/I think it prevents too much building. Energy density, rechargability, etc are like CPU speed to me -- it will eventually be solved, and I can deal with replacing a device every month or swapping a rechargable battery (especially if the device can tell me it's low). I really do think it will be Thread+Wifi routers that eventually get a built-in Thread antenna that win (at least wining me over). If either ZWave or ZigBee had managed to get into the home router space, they would have won already IMO. There are probably annoying reasons they couldn't until now. > So far, I've tried probably most of the home radio standards. Lutron was the most reliable, but it's also super-proprietary. My next house will just have conduits with low-voltage cables running to all the light switches, so I can use something like KNX instead of the radio-based stuff. Thanks for sharing this and your other experience! Also TIL KNX.
  - cyberax 1y ago
    > I really do think it will be Thread+Wifi routers that eventually get a built-in Thread antenna that win (at least wining me over). That actually had been the case for a while. A lot of WiFi routers had a built-in Thread (ZigBee) radio, but then nobody actually used them and the manufacturers stopped bothering with them. So now pretty much only Eero access points still have it. > Also TIL KNX. My dream is to have _actuated_ switches, that have full tactile feedback. So that the paddle will physically flip when switched remotely. I commissioned an engineering company to look into that, but apparently this is not feasible at all with the NEC and UL requirements in the US. The only way is to use low voltage wiring to the switches and then use them to control line-voltage relays. This kind of system is popular in Europe, so you might as well just go with something like KNX.
baq 1y ago
> why is it so hard to get a simple IoT button that runs local Wifi (really hoping for no base station) only and is battery chargable? Battery life is atrocious and latency from deep sleep will be very bad. I’ve got Zigbee buttons from ikea that run on nimh batteries for a couple years now and only used like half of the charge. The hub is an usb dongle attached to the home assistant server, no issues.
- hardwaresofton 1y ago
  > Battery life is atrocious and latency from deep sleep will be very bad. I’ve got Zigbee buttons from ikea that run on nimh batteries for a couple years now and only used like half of the charge. The hub is an usb dongle attached to the home assistant server, no issues. So what do you consider to be "bad" battery life? I've got quite the tolerance, but the problem is that they don't even exist. Everyone seems to stop out on this at "it would never be worth it". > Zigbee buttons from ikea that run on nimh batteries for a couple years now and only used like half of the charge. This is intense for me, I'm happy with replacing batteries every 6 months if I could simplify deployment by 10x. > The hub is an usb dongle attached to the home assistant server, no issues. Maybe deployment isn't as hard as I'm making it out to be! That said, nothing easier than sending some packets to an IP address. I assume Zigbee APKs are easy... But for example if I search on crates.io (https://crates.io/search?q=zigbee https://crates.io/search?q=zigbee) I don't see any obvious choices. To restate what I want (and hopefully is sounds a bit more reasonable) I want to be able to buy one smart light bulb, configure it over BLE to connect to Wifi and for the rest of it's live configure it/change it via Wifi. I want that for basically every device, and I'm fine with swapping batteries every 1 to 6months if I could have that!
  - baq 1y ago
    BLE should also work but you also want a dongle, so hardware wise it’s the same; ideally you also want a couple gateways (Shelly devices can do that out of the box btw, and new Shellies will be supporting Zigbee.) You should look into zigbee2mqtt IMHO.
    - 1y ago
Asmod4n 1y ago
thread and matter will, in my opinion, never matter for consumers. Why? It’s basically a walled garden. Think HomeKit but a tiny bit more open, the open bit is, that a vendor can allow it to communicate with devices of other vendors. But they don’t have to. Thread also needs more expensive SOCs, with Zigbee you only need a tiny micro controller with a few MHz of clock speed and a few KB of RAM. Thread and matter on the other hand can require megabytes of RAM. Vendors which nowadays sell HomeKit devices can reuse their SOCs for thread matter, keeping their 3-4 times higher prices compared to devices with the same functionality from Zigbee vendors.
- hardwaresofton 1y ago
  > thread and matter will, in my opinion, never matter for consumers. Why? It’s basically a walled garden. I'd counter with the fact that walled gardens are incredibly popular, and in particular to consumers. Consumers don't care if the gate is locked or not, they care if the flowers are pretty and the tea at the garden party is nice. > Thread also needs more expensive SOCs, with Zigbee you only need a tiny micro controller with a few MHz of clock speed and a few KB of RAM. Thread and matter on the other hand can require megabytes of RAM. IMO prices of SOCs are going to zero. ESP32s are a great example of this. Once RISCV is more widely used and capable things will accelerate even faster. > Vendors which nowadays sell HomeKit devices can reuse their SOCs for thread matter, keeping their 3-4 times higher prices compared to devices with the same functionality from Zigbee vendors. I think we agree here...? I think that HomeKit device that is just a bit more open is going to win. But I think that HomeKit device gets adopted faster if it's just a router -- I can understand updating a router to get a smart home. What I don't want is confusion around whether I need a hub or not, or whether devices work together or not. Buying a single router that acts as a hub + Wifi "repeaters" (IIRC that's what they're called) that can "extend" the signal (and along the way give other devices a point to connect to) makes perfect sense to me as a consumer. I already know what WiFi is, and I want better coverage, not worse. The smart home stuff just falls out of tech I am already familiar with, efficiency by damned.
  - Asmod4n 1y ago
    Thread is a WiFi replacement, the devices talk IP over thread. And it has an encrypted pairing process to your vendor controlled hub. Said vendor can allow or disallow it which other vendors may speak with said hub. Here is the landscape we have: HomeKit: fully closed, requires certification from Apple. Very expensive and limited functionality. Zigbee: fully open, anyone can make Zigbee devices and sell them without any restriction. Operates on the same frequency all over the world. Devices are super cheap. You can expand the protocol however you like as a vendor. Z-wave: fully closed, several incompatible frequencies, requires certification to sell devices. Thread and matter: semi closed, same ieee standard as Zigbee for data transfer. Vendors can allow it to talk to devices of other vendors. Requires certification. Same price tag as HomeKit, aka 3-4 more expensive than Zigbee. All of them require hubs. And only with Zigbee you are guaranteed to have interop between all vendors and all devices sold across the globe. Thanks to Home Assistant. With thread the vendor can simply disallow you to use your devices with HomeAssistant, which is unacceptable by me.
raffraffraff 1y ago
Does the hub requirement matter that much though? I mean if you want truly peer to peer, then yeah, but if you're already using Home Assistant you can plug a cheap ZigBee usb dongle into that. So the bit I'm missing: how do you control them purely over WiFi? Do you run software on your phone that can control the target? Eg: app talks directly to the device over your network, instead of via a browser + Home Assistant running on a Pi. I can't think of any examples of a product that works this way without being cloud enabled (IE: there is a hub but you don't own it)
- hardwaresofton 1y ago
  > Does the hub requirement matter that much though? I mean if you want truly peer to peer, then yeah, but if you're already using Home Assistant you can plug a cheap ZigBee usb dongle into that. Maybe not, but I don't really want to actually run Home Assistant, I want the basics to hack on, really. Trying to pick the most open thing that will be easy to program without relying on using something like Home Assistant (not that its bad or anything). > So the bit I'm missing: how do you control them purely over WiFi? Do you run software on your phone that can control the target? Eg: app talks directly to the device over your network, instead of via a browser + Home Assistant running on a Pi. I can't think of any examples of a product that works this way without being cloud enabled (IE: there is a hub but you don't own it) Yeah that's my goal -- basically I want to be able to control the devices from anything web connected (and ideally, the same program running in multiple places). My thinking is that I can build this without being cloud enabled if I "just" (famous last words) had Thread/Wifi. With all the excellent feedback in this thread (thanks HN!), it's looking like a small SBC + a Thread/Zigbee/BLE dongle[0] is the way forward, and hooking that up to my router via USB so it's always powered and follows the router around (maybe velcro it on). SBC (or something smaller maybe, but probably the SBC) so I can program it myself. [0]: https://sonoff.tech/product/gateway-and-sensors/sonoff-zigbee-3-0-usb-dongle-plus-e/ https://sonoff.tech/product/gateway-and-sensors/sonoff-zigbe...
  - lawn 1y ago
    The basics of Zigbee isn't Home Assistant, it's something like zigbee2mqtt with a USB dongle and then you interface directly to an mqtt broker. For my automations I do just that and I bypass home assistant and control my devices directly over mqtt. It works very well.
viraptor 1y ago
> I don’t want to buy an IoT hub. Different expectations. I don't want my things to know that wifi exists. It stops vendor lock-in, it ensures local communication, it means things work even if network goes down. It also makes sure they will never autoupdate or join Mirai botnet. I've got a mix of zwave (fibaro), ZigBee (Ikea) and ble at home and I'm ok with that.
- hardwaresofton 1y ago
  Yeah I think so -- I like to think I can control my router at least, so I don't have to worry about it. That said, probably not protected from the botnet case. Also, unfortunately up until now I've been saying the wrong thing -- I mean Matter over Thread versus Matter over Wifi. Matter over Wifi seemed like a winner to me because I could just use it. It looks like going forward I'll be plugging a small SBC into my Router's USB (+ ethernet) and connecting a Zigbee + Thread dongle. That should cover me for most communication options, then from there it's "just" a software problem :)
- wlesieutre 1y ago
  Same boat here, I like knowing that none of of my devices can get network access, all they can do is communicate with HomeAssistant. And with Zigbee bindings most of my inputs are set up in a way that they still work even if HomeAssistant goes down. Not that HomeAssistant has ever down, but I can imagine its SSD or something failing and not bothering moving it to a different computer for a few days while I get a replacement in.
Aurornis 1y ago
> I don’t want to buy an IoT hub. Many IoT devices I want to control are powerful enough to run Wifi, Having a lot of career experience in this area, I greatly prefer to keep my IoT devices off of my WiFi. You don’t need a separate hub device for Zigbee or Z-Wave, just a simple USB adapter that you plug directly into your device controlling everything. Keeping the low bandwidth IoT devices off of the main WiFi had a lot of advantages. It’s also much easier to rotate your WiFi password when you can do it all without reconnecting every light switch in your house, for example.
- hardwaresofton 1y ago
  Thanks for sharing your experience here -- agreed that it's better to avoid the chatter and also rotating your WiFi passwords is indeed an issue to consider, that would be quite a pain.
cbull 1y ago
The "Hub" device can be as simple as a USB stick that's attached to the machine running Home Assistant. That's what I have been running for years, a Z-Wave USB stick that passes through to a ZwaveJS docker container (which also communicates with HA). So it's not like you need a big stand alone device that has to have it's own Wifi or ethernet or anything like that, it's just a USB stick.
- hardwaresofton 1y ago
  Thanks! This is what I eventually got to. That said, I'm leaning towards putting the USB stick in a Pi or something like that, which is attached to and powered by the router! Just want to have the one device and I think that's maybe the simplest way to get it without trying to run stuff on the router. Basically, it is a hub, but it's more of an attachment to the router than anything else.