Soap Box - "WiFi" vs Z-Wave / Zigbee + Compatible Devices List

Not necessarily, I think. I believe Shelly devices, for example, have a web server that can be used to configure them directly.

3 Likes

And it is feasible with Kasa devices. Just more code to write an I like the second path for user troubleshooting (e.g, I can't control my switch. Resp: Check it works in the Kasa Phone App.) Hubitat (Smart Things, everything) has problems identifying device failures. The Phone App provides a second path that verifies operational status independently.

PS - I have had Kasa devices for 5 years. Never a failure. Several lamp switches turned off by cleaning lady.

3 Likes

Not for Kasa.

1 Like

Just jumping in here. But I think the hate for WiFi devices is due to a lot of headaches over the years from them more power users that have proper zigbee/zwave networks setup (this are great when it works right).

Wifi devices are the wild west. Just some of the things I have observed over the years (especially when writing drivers):

  • each one implements its own api. They don't follow a standard.
  • The popular ones try to lock you into their ecosystem. Most of the time a community driver can be created by reverse engineering the calls but you won't get access to all of the features.
  • you will require a solid wifi network. Especially with devices that are mounted inside a metal box. Edge devices may have issues.
  • integrate a few wifi devices and you may be fine, but start overloading a home grade router with a bunch of wifi devices on the same network you are streaming cameras and videos on and you may start to see issues/slowness. I personally try to hardwire all my heavy devices.
  • I try to avoid anything that requires a lot of polling for status. If you have a switch and need to poll it to get its on/off status you will put unessary load on the hub. And the more you have the more polling. Ecobee/MyQ(if you knew how)/Ring were two that I need to poll and I eventually just got rid of the last two. In all fairness there were older non zwave plus devices that had this same issue that would overload the zwave network. I really hated wemo because (from what I can remember) you had to subscribe to their updates and would then send the status to the hub. But if that subscription expired and the hub did refresh it, updates would stop. This happened to me a number of times.
  • Wifi devices (if your lucky) get updates, that break things (MyQ/Wemo for example) (if your unlucky). A lot will get no updates at all that will leave some big security holes in your network (I'm hearing rumblings of Hikvision cams recently). You can do a bunch of stuff to work around it but most basic users won't know how to create vlan's or even have the tech to do it.

Saying all that, you can't avoid them. I still have wifi devices (Ecobee, Bond, Racchio, Alexa, Sonos, Foscam Cameras for example) but I am much more aware of their effects on the hub when it comes to polling etc. The only one I have to poll right now is the sonos and ecobee for updates. But they are also not very frequent.

NOTE 1: This is just some of the stuff I have seen/experienced over the years. It is my opinion and doesn't represent the community.

NOTE 2: All spelling mistakes were done on purpose.

9 Likes

:rofl:

1 Like

Things like lifx you can use just ihome to add, no lifx needed (but yes an app) Shelley is similar for just ip purposes but still local

I think if you embrace WiFi devices approaching qty 50 you must understand and implement good quality AP’s or divide the devices between AP’s based on SSID. If you don’t it will fail.

No - but sometimes, maybe often you will do this.

WiFi is suited for hundreds+ of devices and more reliable with good AP’s than ZWave or Zigbee (IMHO). Not ideally suited to battery devices usually though, and some other scenarios if you wish to exclude cloud. I consider that but I don’t worry overly about it.

WiFi in huge networks works solidly if properly architected. After all the whole Internet is built around that at the IP layer. ZWave and ZigBee are not so predictable, in some homes they are problem free and in others not so. Zigbee and ZWave mesh issues are intermittent and hard to troubleshoot. That is typically going to be problematic in all radio networks. Matter will be much better as probably will be ZWave LR for single nodes.

2 Likes

Poll sonos?, I have 10 of them going, no polling here, please explain...

I could be wrong with Sonos, it may actually just be just recieving updates from the device. I think it was a subscription model with the Sonos devices. I wrote the code a while back so would really need to dig thorugh it to see what I may be doing differently. But it was one of the integrations I was planning to revisit and probably clean up as I see it is one of the top in the list of "total ms" on my hub.

Same. So much so that I moved all 9 rooms of SONOS to my secondary hub. I wasn't experiencing issues but there were a few integrations that seemed heavy and I wanted to branch them off to provide as much relief to my primary hub as I could.

It must be a subscription because I have automations running nanoleaf controllers depending on whether playback is stopped or playing and it's an instant response every single time.

It is indeed

So, now we get into a discussion of Cloud vs LAN based WiFi plus the protocols to implement these. In my experience, the sendHubCommand (used for LAN) indicates more efficient than the raw protocols and the HTTP protocols. Rationale. I use the same code for all protocols on my Kasa devices (LAN or CLOUD)..

  • LAN. Use sendLanCommand (and encrypts the message before sending). It returns to a parse method, is decrypted, and then sent to the common methods.
  • CLOUD. Use HTTPPost (no encryption). Sends and recieves the message from the same method and then passes to the common methods (does not have to decrypt).
  • RawSocket. Uses the rawSocket protocol (encrypts message) and returns the response to the parse method. Parse decrypts and sends the message to the common methods.

Generally, for the Kasa devices, LAN is significantly better than Cloud and rawSocket. rawSocket is slightly better than cloud.d

Results for KASA sendHubCommand indicate aboout a 0.05% of total processor time for each device for a one minute poll frequency. Results appear to be linear (i.e., 30 sec would be 2X the time). Cloud takes two to three times what the sendHubCommand takes.

Final: The Kasa devices use a Linki protocol in their code. This is DESIGNED for LAN control of a significant number of devices.

1 Like

Have you tried the asyncHttpPost? I would expect that to give you similar performance to the sendHubCommand as it sends the command and does not wait around for it. The results are returned later to another method. If you haven't give that a shot.

I use the async methods pretty much everywhere. There are some times when I use the sync method though as well.

Good Idea. Since I am set up for testing, should be a simple test.

Dave

asynchttpPost uses less processor time than httpPost and only more slower than the LAN protocol. I will implement in my next release as the backup comms.

1 Like

You know lately I am getting so sick of complications caused by connections between the various different dialects of zigbee that I am actually looking for wifi/lan (cloud-free) devices that have Hubitat drivers to use! Is there such a list? I already have Dave's Kasa drivers

1 Like

I don't know if there is a list but as far as the zigbee stuff, if you stick to the compatibility list you should be ok.

1 Like

Ah but that's too boring. I like experimenting with new stuff. But with wifi stuff at least it's not going to mess up the connection of other items to the system.

There are also some local integrations for some of bleBox devices (Polish company, kind of pricey) and a Samsung TV Remote that does not require cloud (but can use, if necessary. Both sets developed by me.

1 Like

You can also run HPM and do a install, search by keyword, "LAN". This may list some more integrations.

1 Like