upstatemike

If you enroll it on a battery and then apply AC after won't it still behave as a battery device? (ie not act as a repeater etc.)

This of course is one of the problems that Matter will solve once and for all.

I think I am going to give up on Z-Wave and return my small test area (about 20 devices) to Insteon. Z-Wave just consumes too much effort every time I want to change something and I still can't get groups and associations (direct or programmatic) to work the way I want them to.

I wonder what happens if an end point device supports Matter plus a legacy protocol? Will the Matter path always take priority? Will the device be clever enough to determine which path is more efficient (least latency)? Will this be yet another thing that is left up to the manufacturer so there is no way to predict what will happen?

Eve just released a new thread enabled motion sensor that is supposed to operate lights in a scene instantly. Waiting for somebody here to get one and confirm that.

Who for all their market research still seem unable to grasp what users actually want from these products. I'll quit bashing Matter for now and wait until there are some actual products available to evaluate. I still might change my username to "antiMatter" though.

So if you buy a device it might follow the current Matter standard or it might work using legacy proprietary messages (buyer beware). Don't we already have that with Z-Wave and Zigbee so called standards? What was the point of Matter again?

Which itself is a concern. We are into double overtime now for the published standard and we still only have vague marketing descriptions about what it will and will not include. There should be a Matter spokesman who can get down into the weeds about this stuff by this time but all we get are smoke and mirrors.

Happy to go back to talking about the latest communication from Inseon instead... If only there was one.

So a couple of things here: 1 I don't care if there is only 1 way to control light as long as "control" includes ramp rate, color or color temperature, behaviour in a scene, status reporting that the command was recieved and executed, etc. Who is deciding what "control" means and what needs to be included as part of the universal standard? 2 As many folks have noted on other threads, automation is not just about remote control but also about triggering things from current state, state change, manual vs programatic changes, multiple button presses and long vs short button presses. etc. Where is my assurance that all of that is part of the universal standard? 3 If manufacturers implement proprietry features without following a framework or standard then what prevents another manufacturer from implementing the same feature in a different proprietary way? At what point does Matter declare that function to be common enough that it should be part of the universal standard and how will thay walk back all that proprietary junk and force it to conform to the newly updated universal standard?

Only works if the manufacturers implement it. If Z-Wave used it I could probably live with that platform; but they don't and nobody else has stepped up to say "yes we know that this is important so we will make sure multicast control of groups is part of the most basic command set that will be required to be supported across all Matter products and manufacturers"... unless they did and I just missed it somehow.

So my take away from the above is: 1 I probably misused the term protocol when I should just say platform to identify a particular technology. 2 While it is possible for a routed technology to avoid the popcorn effect it would take some attention from the manufacturer to prioritize that and none have published any intent of addressing it. Insteon being a broadcast technology avoids the issue automatically. 3 Popcorn effect really really really sucks and we need better channels to communicate to manufacturers that fixing this is important. I suggest any device sold on Amazon deserves a question about smooth group actions to deliberately emabarrass any product manufacturer who did not make an effort to provide this in their offering. 4 Most of the benefits of Matter will only be realized when end point devices speak Matter natively (so plan to replace everything you have). The kluge of having a hub do translation is just a way to get by in the near term. 5 Products like Lutron, Insteon, Hue, Broadlink Fastcon. and Yolink LoRa, will do a bare minimum Matter integration to get the logo but will otherwise ignore it as it provides less advantages to consumers than the native versions of those products.

So my take away from this conversation is: 1. Matter will provide a common protocol where everything works together so the only differentiator from one product to the next will be price. So Amazon will simply provide cheaper matter devices than anyone else and will soon be the only source for IoT products. 2. The Matter protocol will emphasize security over performance so any group of lights will s l o w l y respond one by one like Z-Wave instead of simultaneously like Hue or Insteon or Lutron. 3. Matter will borrow heavily from Wi-Fi and Zigbee and therefore add congestion to the already overloaded 2.4GHz frequency range while sacrificing the longer range and better material penetration you get from 900MHz or 300MHz based products. I can't wait!

You are completely missing the point! Matter is going to be great because you don't need so many apps on your phone. You just add a new Matter device using any Matter compatible app and you will be able to configure all of the basic features (like really braindead basic). Of course if you want to adjust any of the advanced features (ie most of the features) you will still need to use the actual manufacturer app for that product... so skip over that one. But with Matter you won't need a hardware hub for each technology. You just need a Matter "Edge Router" (another name for a hub) to talk to all of your Matter devices. Of course some manufacturers won't put Matter in endpoint devices but will instead put Edge Router functionality into their own hub and let that translate to their native protocol which means you still need all your existing hubs in addition to the official Edge Router hub... so let's skip that one as well. But Matter will let you control things from multiple platforms at the same time! Imagine if you could control your Hue lights either from the Hue app OR by talking to Alexa... which is pretty much how it works now so skip that too. What was the point of Matter again?

It seems like a good case could be made that letting UD build a PLM would not significantly cut into Insteon's own PLM sales and could enhance the speed (and therefor the profitability) of Insteon's recovery while also alleviating customer concerns about investing in single source technologies.

I wonder if all the prototype items were shipped or if there is still a stash of them someplace?

Another mitigation is to shut off auto channel select and lock each AP onto a non-overlapping channel. I definitely don't allow auto channel select in the 2.4GHz range.

Several Homeseer dimmers and fan switches plus a Zooz wireless switch, 4 Zooz scene controllers, and some Zooz plug-in modules plus 1 Inovelli dimmer. All current generation 700 series. Currently testing with Homeseer/Z-Net but will also test using Polisy, Home Assistant, and Hubitat at some point. (I have all of the controllers, I just need to find the time)

It is interesting that Control4 uses a routed protocol (Zigbee) and yet have no popcorn issues. I wonder if it is because of their proprietary implementation of Zigbe or if Zigbee has some non-routed broadcaast capability that most manufacturers just don't take advantage of?

When I press the wireless Z-Wave switch at the entrance to the room there is enough delay that each switch clearly is operating in sequence. Takes about 5 seconds far all the lighst to respond to an on or off, not counting ramp rates. My point is that companies claiming to solve the "problems" with current HA protocols seem to ignore the things that consumers actually care about and instead invent imaginary problems that match the strengths of their new technology to solve. How can Z-Wave claim to be designed from the ground up for HA and not understand why popcorn effect or a lack of good wall keypads or better implementation of direct association to reduce dependency on a controller for basic operations might be important? How could broadlink just release a new Bluetooth protocol that has excellent smooth group control with no popcorn effect not realize that after a power failure their bulbs need to return to the previous state instead of snapping on in the middle of the night or while you are away at work? The folks coming up with this stuff are NOT as clever as everyone is assuming and I admit I am extremely cynical that Matter or any Wi-Fi based standard is somehow going to get it right this time.

So I'm shutting off the lights in my one room (about 12 devices) where I have deployed Z-Wave (a protocol designed from the ground up for home automation) and I'm reflecting on the annoying popcorn effect as each switch responds to the off command individually. I wonder how Thread/Matter will fix this and other problems we see in the current platforms they are meant to replace? Z-Wave has detailed conceptual overviews and the promise of expanding device types (when will the device class for a regular keypad that can do something useful by direct association get released?) but that didn't result in a solid consumer friendly solution so why should I think Thread/Matter will do better? At the end of the day I will ignore all the industry hype and just install Thread/Matter into a room (maybe redo my Z-Wave room) and see if it solves any of the things that currently bother me. We'll see how it goes.

But isn't that the point? A purpose built network is optimized for the mission and does not have excess overhead to add manufacturing cost or kill batteries. A purpose built network can reduce interference by using different frequencies from Wi-Fi and can improve distance and penetration by using lower frequencies carrying smaller payloads. A purpose built network does not consume limited IP address space, DHCP table space, or router CPU cycles and reduces the number of concurrent connections on each access point. A purpose built network is resilient against netork storms and other problems that can be caused by IP devices that have nothing to do with the critical IoT mission. (Critical if you are depending on it for core IoT functions like turning on a light or alerting you to an emergency situation) The idea that an existing Wi-Fi environement is "already there" to support a massive increase in client load is unrealistic. There might be a corner case where somebody buys a small number of IoT items and then never expands from there but that is not the trend. You can build up your network with semi-pro gear but that will not end up being cheaper or easier than just using a dedicated protocol and hub so... why would you want to go that route?

Maybe I missed it in the article but I still don't understand what Thread can do. Sure Thread devices can speak a common protocol like IPv6 but what baseline command set will they share? On/Off, Dim/Bright doesn't get you very far... how about color or color temperatur? Fan Speed? Energy usage? Will all Thread devices recognize scene commands? In what common syntax? Can a Thread Keypad button start a Thread enabled music player to start a specific playlist without the need for controller intervention? Just generalizations and verbal fluff at this point. I would like to see an example of a complex action as it will be set up and executed using Thread.

Interesting. The Leviton switch must use a different strategy for speed control from the internal switch. Maybe PWM?

So I am trying to picture a typical 2.4GHz WiFi installation. There are 3 non-overlapping channels. Chances are somebody with a large Home Automation system might also have a Sonos system which uses one of those channels. So you have two channels and a bunch of Access Points. Each Access Point should be on a different channel than its nearest neighbors for clean roaming and minimal interferance but after AP1 and AP2 you find you can't put AP3 where you need coverage without it being close enough to interfere with either AP1, AP2, or Sonos and there is no 4th channel you can go to. It doesn't seem like you have to be in NYC or LA to run into interferance issues.