I started out running more than 20 x 5m RGBW strips to facilitate lighting in two pinwheel formats for a wedding in a tent. I got carried away and wrote many animations to make dancing and special events a little more fancy. Then I discovered that there were many brands of RGBW and now RGBCW bulbs that use the same protocol. After moving from my larger home to a sky apartment I now only run about 5 RGBW strips and more RGBCW bulbs. My latest venture was two gooseneck MagicHome Pro app compatible variable white temperature lamps. I had to sniff out the protocol as they were protocol compatible, except for the two white levels. It turned out to be completely different packet structure but I just patched it into the bridging software when it finds one in the interrogation of type..
-
You've been granted Beta access to this site, allowing you to explore some of the new features while they're still under construction. More information can be found in the Beta forum.
Future of Z-Wave and Zigbee
- Thread starter BraveSirRobbin
- Start date
pete_c
Guru
Here never went much beyond modification of the MagicHome controller hardware and software. It all works fine for me and is high on the WAF.
To make this work it was mostly related to modification of the ESP firmware using the right "speak" and save to the device.
The automation technology is moving so fast these days that it is hard to keep up. Keep it much simpler these days while I tinker to keep busy I always leave in place what continues to work for me.
To make this work it was mostly related to modification of the ESP firmware using the right "speak" and save to the device.
The automation technology is moving so fast these days that it is hard to keep up. Keep it much simpler these days while I tinker to keep busy I always leave in place what continues to work for me.
Yeah, you certainly have to pick your poison or you get nowhere. I find it hard reading forums and walking away from threads thinking "that isn't for me".
The same thing that happens when a Z-Wave controller goes down.
Every system has its critical controller that is vulnerable to loss of connection/signal/power/crash. I've tried many systems over the years, and every one has had it's occasional problems that cause it to be flakey or just stop working. But there are always ways to improve robustness and limit failures - just part of the burden in DIY systems.
That said, my Unifi wifi has been very solid using overlapping radios, and is powered via UPS - so I am becoming more comfortable with wifi lighting - slowly adding more Shelly devices. My X-10 stuff is getting old and starting to suffer from powerline interference. I am seeing Z-wave devices randomly stop working a few times per year, and the Homeseer implementation is flakey in my experience. I have yet to see any Shelly wifi device not work. No internet required.
Same thing with any other home automation protocol. If your devices are Internet dependent, then they cannot be controlled. Mine are not.
If your devices are WiFi dependent then they cannot be controlled, same as when any other home automation system modem goes down or becomes deprecated. WiFi is a very strong and well supported protocol and I could get a new modem (or another from my junkbox) within an hour. I could also use a local switch to operate my home automation system that controls my WiFi lights, and if that wasn't enough, my bulbs can also be operated from BT directly from the mobile phone app. None of this involves any Internet or Internet connections.
The problem with any "automation protocol" is that someone is going to create the "next best thing" and no protocol is going to stand out and become "the standard". Zigbee and Z-Wave are just two of these in a long list of automation protocols. CHIP and Matter are just two more......... I think the list of defunct automation protocols is longer than the list of dropped Google projects, and that is saying something!
I didn't "buy into" any lighting system for a long time due to this splintering of protocols. I could never bring myself to spend serious money on a bunch of switches/plugs that used a protocol that I knew wouldn't stand up to the test of time (because no automation protocol so far has).
When I discovered Tasmota (which uses Wi-Fi as it's communication protocol), I changed my mind. Wi-Fi is obviously not going anywhere. I don't think it is unrealistic to believe it will still be the standard local wireless communication protocol for the next 20-30 years and beyond. (It's already been the standard for the last 25 years and it is stronger than ever). You can't honestly say that about any automation protocol that has been produced to date.
I like Tasmota because it does remove the cloud dependency that so many consumer "smart home" Wi-Fi devices have. My devices are on a VLAN dedicated to these IOT type devices which does not provide access to the internet or even any other part of my network. In other words, they are completely isolated from any other devices. If my internet fails, nothing changes with regard to the functionality of the devices. They will still perform all the expected functionality I have programmed into them.
The worst case scenario would be if my local Wi-Fi network failed. That would stop the individual devices from communicating with each other, but the individual device do not require wi-fi connection to work as a local "dumb" device. This means the interconnectivity/automation that I have programmed into my system would stop working, but the actual devices/switches will continue to work as expected. For example, I have it programmed that if anyone turns on the outside light over the garage, the system will also automatically turn on the outside light at the front door or vice-versa. Those two lights are on different circuits and switches. If my Wi-Fi goes down, they won't automatically turn each other on (which Tasmota handles), or automatically turn on at dusk and off when our house is armed "night mode" (which CQC tells them to do via MQTT), but they will still function normally themselves. You would just have to walk over to the individual switches to turn them on/off. Basically they would just turn into regular "dumb" switches which is exactly what I had before and no critical functionality would be lost. Besides, a loss of local wi-fi would create a lot more havoc than just some lighting system functionality and would be quickly corrected. Not because of the loss of lighting functionality (which probably wouldn't even be noticed), but the loss of connectivity for everything else.
As I hinted in the example above, some of this interconnectivity is programmed at the Tasmota level and some is programmed through my home automation software. Things programmed at the Tasmota level are more reliable (because they only rely on a local wi-fi connection and not wi-fi AND my home automation system), but programming some things in the home automation system is just easier. The way I handle it is if I want a Tasmota device to interact with another Tasmota device, I program that at the Tasmota level. For example, the wall switches in my Den turn the ceiling lights on (which physically wired into the switch leg of the wall switch), but also have an additional button on them that I've programmed to turn on/off the pair of lamps on our sofa tables (which are plugged into a separate Tasmota wall plug behind the couch). These types of commands are handled at the Tasmota level so even if my home automation system fails, this type of functionality will still work. Most of my "timed" or "triggered" events occur through the home automation system however because it was easier to program this way. Events like turning the garage interior light on when the garage door opens and it's dark outside (because the light on the actual garage door opener doesn't work) or turning exterior lights on at dusk, or turning them off when the house is armed "night" mode, etc, etc, etc are all done in the automation system software. These functions would fail to execute if my home automation system went down for some reason.
I didn't "buy into" any lighting system for a long time due to this splintering of protocols. I could never bring myself to spend serious money on a bunch of switches/plugs that used a protocol that I knew wouldn't stand up to the test of time (because no automation protocol so far has).
When I discovered Tasmota (which uses Wi-Fi as it's communication protocol), I changed my mind. Wi-Fi is obviously not going anywhere. I don't think it is unrealistic to believe it will still be the standard local wireless communication protocol for the next 20-30 years and beyond. (It's already been the standard for the last 25 years and it is stronger than ever). You can't honestly say that about any automation protocol that has been produced to date.
I like Tasmota because it does remove the cloud dependency that so many consumer "smart home" Wi-Fi devices have. My devices are on a VLAN dedicated to these IOT type devices which does not provide access to the internet or even any other part of my network. In other words, they are completely isolated from any other devices. If my internet fails, nothing changes with regard to the functionality of the devices. They will still perform all the expected functionality I have programmed into them.
The worst case scenario would be if my local Wi-Fi network failed. That would stop the individual devices from communicating with each other, but the individual device do not require wi-fi connection to work as a local "dumb" device. This means the interconnectivity/automation that I have programmed into my system would stop working, but the actual devices/switches will continue to work as expected. For example, I have it programmed that if anyone turns on the outside light over the garage, the system will also automatically turn on the outside light at the front door or vice-versa. Those two lights are on different circuits and switches. If my Wi-Fi goes down, they won't automatically turn each other on (which Tasmota handles), or automatically turn on at dusk and off when our house is armed "night mode" (which CQC tells them to do via MQTT), but they will still function normally themselves. You would just have to walk over to the individual switches to turn them on/off. Basically they would just turn into regular "dumb" switches which is exactly what I had before and no critical functionality would be lost. Besides, a loss of local wi-fi would create a lot more havoc than just some lighting system functionality and would be quickly corrected. Not because of the loss of lighting functionality (which probably wouldn't even be noticed), but the loss of connectivity for everything else.
As I hinted in the example above, some of this interconnectivity is programmed at the Tasmota level and some is programmed through my home automation software. Things programmed at the Tasmota level are more reliable (because they only rely on a local wi-fi connection and not wi-fi AND my home automation system), but programming some things in the home automation system is just easier. The way I handle it is if I want a Tasmota device to interact with another Tasmota device, I program that at the Tasmota level. For example, the wall switches in my Den turn the ceiling lights on (which physically wired into the switch leg of the wall switch), but also have an additional button on them that I've programmed to turn on/off the pair of lamps on our sofa tables (which are plugged into a separate Tasmota wall plug behind the couch). These types of commands are handled at the Tasmota level so even if my home automation system fails, this type of functionality will still work. Most of my "timed" or "triggered" events occur through the home automation system however because it was easier to program this way. Events like turning the garage interior light on when the garage door opens and it's dark outside (because the light on the actual garage door opener doesn't work) or turning exterior lights on at dusk, or turning them off when the house is armed "night" mode, etc, etc, etc are all done in the automation system software. These functions would fail to execute if my home automation system went down for some reason.
Last edited:
NormandyHA
Member
Since this thread appears to cover Z-Wave, Zigbee and even Matter, thought I'd post this recent news announcement. https://z-wavealliance.org/news_p/z...ete-now-open-and-widely-available-to-members/
The top part of the article also has this "Additionally, Exegin Technologies has demoed how Z-Wave Source Code can be ported to third-party silicon, opening members to develop on any chip provider of their choice."
Interesting advancements for Z-Wave when some may have thought it just doesn't Matter (pun intended). If you already are full Zigbee/Thread setup, no need to switch, but I'm feeling more confident that I won't need to do a rip/replace of Z-Wave for the foreseeable future.
The top part of the article also has this "Additionally, Exegin Technologies has demoed how Z-Wave Source Code can be ported to third-party silicon, opening members to develop on any chip provider of their choice."
Interesting advancements for Z-Wave when some may have thought it just doesn't Matter (pun intended). If you already are full Zigbee/Thread setup, no need to switch, but I'm feeling more confident that I won't need to do a rip/replace of Z-Wave for the foreseeable future.
Well that's newsworthy for sure, I posted that one on the front page 
upstatemike
Senior Member
Interesting development but when is Z-Wave going to address the persistent problems that really turn users away such as the popcorn effect (can't control groups of devices in perfect unison), no way to back up a controller from one manufacturer and restore to a different brand controller, or provide a wired keypad where buttons act as virtual switches in 3 or 4 way configurations instead of having buttons that can only trigger scenes?
Similar threads
- Article
