RPerrault

homeseer

flat out wrong - ud was the first (or among the first) to closely integrate - meaning no 'tell insteon to...' formulaic crap - allowed a synonym so when echo heard damn lights it meant den lights - i control z-wave via ud integration - between echo and ud, 'turn off the lights' mean the den lights on the den echo - bedroom lights on the bedroom echo there might be better integrations but i doubt it if you have to yell at your echo, you need one closer if you think grabbing your phone to adjust your a/c at 3 am is good - go for it - i'll just say 'alexa, set the bedroom thermostat to 72 degrees'

ud cannot deliver one packet ud can present devices using insteon and z-wave to a user and allow our interaction to be something close to single pane for packet delivery, ud needs a z-wave radio and a plm for insteon what ud does is remarkable - and if you want to buy z-wave repeaters and more insteon to 'build out the network', go for it - it takes a ton of work to do what ud has done - but ud saw it could not expand the isy to include lutron (if lutron allowed it) and all the others - ud built a device with insteon (plm), z-wave (z-wave radio board) and elk - ud has those deliver the packets - node servers do not deliver a packet - they construct the packet and pass it to ud - ud passes it to whatever network interface it has that can deliver it i got nervous when ud discussed the decision to move to the polisy modularity of just get out of the game - focus on energy - ud - if nothing else - could allow a graceful, gradual migration path for us and nothing says ud would not add matter as just another node if they have a network interface - its not mutually exclusive

i understand - change is scary you do not know what matter will support - their market research skipped you so they did none? matter might clean your toilet - or have overcome popcorn - or have the magenta command the argument that is completely inane is 'who needs just another standard' - why would anyone object to yet another standard since matter is so crappy - ignore matter - no one has to adopt it - keep guessing what insteon will do - and hoping it sounds like a good concept - a huge part of the battle is the network component - people saying it can't be done - well it HAS been done not attacking - i enjoy the thought exercise and thanks for challenging me - i like speculating on how challenges might be overcome - the ones we can envision

do you care which it uses? no - z-wave cannot deliver a packet to anything but z-wave devices in theory, i suppose insteon could wrap its existing commands in a ''matter compliant' packet and never use any matter commands

they may not have it all defined - i have not looked, but seen little info on the commands that will be in matter i think they chose a good path allowing proprietary commands - ge matter devices probably won't need to be concerned with setting a status light to magenta - if lutron is, they can still do it without violating the matter standard - the larger the command set, the more resources needed we do now see there is a chip for the networking - people here were claiming the impossibility of that working matter is speaking to the people that 'matter' - companies that can build and adopt the technology - matter is not selling to end users - they have to sell manufacturers

doesn't have to be - they allow for that "...manufacturers are free to define proprietary messages because IP networks do not restrict message content. So, functions common to many products such as transmitting well-known commands and data types and setting up new devices on a network work predictably across all Matter devices without restricting manufacturers from using non-interoperable product-differentiating messages where appropriate." it IS in the 'framework' if the capability is later adopted by matter - it would not remove the ability to adopt the new command or keep doing it the way they always were before the adoption

my guess is that if it were in 'matter', we would not know yet i am not saying its the only way to do it - i am saying that it might be one way it could be implemented - instead of declaring it impossible we do know wifi supports it - don't know about the matter application - both would be necessary to implement it

the standard - i suppose - could let a lutron device still speak lutron "An old argument for using proprietary messaging is that products need differentiating capabilities that are not necessarily part of a universal standard. But how many different ways do we need to set a temperature or turn on a light? The correct answer is “one.” However, some products have unique features that Matter does not define. In these cases, manufacturers are free to define proprietary messages because IP networks do not restrict message content. So, functions common to many products such as transmitting well-known commands and data types and setting up new devices on a network work predictably across all Matter devices without restricting manufacturers from using non-interoperable product-differentiating messages where appropriate."

multicasting?

more conceptual see the link i posted to nxp - wifi is part of their chip - buy that chip to put in your light switch and you can choose how you want to communicate - or i suppose, all 3 from the forbes post "Thread devices can plug and play on existing home networks, provided that there is at least one Thread border router to act as a bridge between Thread and Wi-Fi (Figure 2). But consumers don’t want to buy and manage another router or hub specifically to enable Thread. Like I said above, we’re trying to get rid of hubs. That’s why Amazon, Apple, Google, and other consumer electronics ecosystems are busy incorporating Thread border router capabilities into new products such as smart speakers, Wi-Fi routers, and TV streaming boxes. With one or more of these devices installed in a home, Thread devices “just work” when first plugged in without special hubs or routers." one hub is needed - buy another single function device if you want - as above - to act as a bridge between Thread and Wi-Fi how does insteon prevent eternal rebroadcasts? (hop counts) - how does any network prevent it? not a wheel that has to be reinvented insteon lost - it is not part of 'matter' - a matter border hub will not talk to insteon - if you want that, build a hub that can ride both the insteon network and the existing network options matter embraced - insteon might make one - but unless they license out something, it won't be - bridging the network is just one part of that hub - still have to address the application layer (something ud has brilliantly done for us with z-wave) here is one - i have a wifi network - i can spend money on other things as opposed to 'building out' insteon and z-wave and zigbig - i have a matter border router already - added 3 cents to the cost of something i was already buying as i understand it, matter won't have a phone app - so the pretty and function of whatever matter compatible phone app you choose is up to you - at least there will be competition insteon lost - not in matter - i doubt insteon will have the time and resources to be matter compatible - best hope is ud for that - their new z-wave device (not matter either) also has zigbig (which i am unsure if it is formally part of thread) - but their new devices have wifi (i think) and ethernet - if they can use those interfaces to matter, they can be in the game (with a TON of work to get there) yes, you will be able to control a ge and lutron (when they make one) with one button if you want the how, that has been speculated about - but at the matter level, brand won't be concerned with the brand - if they are dimmers, command 41a will be sent to both devices - those devices will either know that 41a means dim or convert 41a to ge or lutron dim command - or have matter send the command to your ge hub or lutron hub to convert 41a to lutron or ge and deliver the packet i think its interesting to speculate on how matter will overcome the obstacles but i know this - no obstacle presented here is something matter has not thought of and overcome

see block diagram above i think we all have different definitions of the word protocol here - and the word matter matter uses existing network technology to deliver packets to the application - technically, matter is the application layer - people use the term to refer to all the layers insteon is the same

for those interested in the architecture https://www.nxp.com/products/wireless/wi-fi-plus-bluetooth/2-4-5-ghz-dual-band-1x1-wi-fi-6-802-11ax-plus-bluetooth-5-2-plus-802-15-4-tri-radio-solution:IW612 no subscription needed

or those without a subscription https://www.forbes.com/sites/moorinsights/2022/01/11/ces-2022-matter-and-thread-win-the-iot-connectivity-wars/?sh=1dba658d19b1 CES 2022: Matter And Thread Win The IoT Connectivity Wars Bill Curtis Contributor Moor Insights and Strategy Contributor Group Jan 11, 2022,05:18pm EST CES 2022 product announcements signal the end of the consumer IoT “connectivity wars” that began over 20 years ago. Two complementary industry standards are transforming the Internet of Things from a hodge-podge of incompatible gadgets into a scalable industry with interoperable, plug-and-play products from multiple suppliers: Matter – “Lingua franca” for the Internet of Things Thread – IP-based mesh network for low power devices Gold Rush With Matter and Thread, consumers can buy connected products such as door locks, window shades, light switches, thermostats, and cameras that plug-and-play with existing Wi-Fi networks and home ecosystems such as Alexa, Google Assistant, HomeKit, and SmartThings. There’s no vendor lock-in, nothing extra to buy, no complicated hub to configure, and setup is a few clicks on a smartphone app. Although this vision sounds too good to be true, the open specifications that make it possible have been in the works for years and are now widely adopted. At CES, big consumer brands and chip companies demonstrated Matter running in real-world devices, dozens of companies announced new products supporting Matter and Thread, and hundreds more are on the way. The trend towards Matter and Thread is rapidly becoming a gold rush as influential companies stake claims. Thread and Matter are eliminating IoT scaling barriers by making multivendor interoperability practical over industry-standard networks using off-the-shelf silicon. Here’s how it all works. Thread After eight years of development, Thread is now a first-class wireless device network alongside Wi-Fi. Thread and Wi-Fi carry the same kinds of Internet Protocol messages, but Thread is suitable for low-power devices that run on batteries, even coin cells. Also, Thread is a mesh network. Some Thread devices (typically mains-powered ones) act as routing nodes, automatically extending the network by relaying messages from one device to another. Consequently, a Thread mesh typically has better residential coverage and reliability than Wi-Fi, especially for low-power devices. Although Thread has been around for years, it has been slow to catch on, partly because it does not specify an “application layer” – a standard set of commands and data formats that enable device communication. Like Wi-Fi, Thread defines the network protocols but not the message content. That’s intentional – it’s a feature, not a bug. Thread is an IP-based network by design, so it is inherently message-agnostic. Your home Wi-Fi router doesn’t care about the content of the messages that flow through it. Those messages can be web pages, audio, video, photos, or documents. Likewise, Thread doesn’t care if you’re sending messages to unlock a door, turn on a light, set the temperature, or raise a window shade. But without a standard that defines the content of those messages, devices from different manufacturers don’t interoperate. That’s where Matter comes in. Matter is an application layer that runs over Thread and other IP-based networks. Matter Matter, founded two years ago within the Connectivity Standards Alliance, normalizes the messages that flow to and from IoT devices, enabling Matter products from various manufacturers to communicate with one other over Thread, Wi-Fi, and Ethernet. In other words, Matter defines a common language for IoT networking, making multivendor IoT product interoperability practical. Although creating a lingua franca for residential IoT is a very ambitious project, Matter is likely to succeed because its sponsors include some of the biggest brands in consumer electronics – Amazon, Apple, and Google. These companies, plus over 200 others, agree that removing undifferentiated friction from the IoT marketplace is more important than any perceived competitive advantage from using proprietary networks or messages. So, industry-leading companies have assigned senior-level talent to the project and are already incorporating Matter into consumer product portfolios. This year, the first wave of plug-and-play Matter products hits the market, creating an inflection point in IoT industry growth. Matter is likely to rapidly displace the non-interoperable “walled gardens” that dominate consumer IoT today. Here’s a slightly more technical view of Matter from an IoT device perspective (Figure 1). At the top of the stack, IoT devices and ecosystems send and receive Matter network messages via standard Internet protocols – TCP/IP and UDP, with IPv6 addressing. Wi-Fi and Thread networks deliver these messages to Matter-enabled products. Matter also uses Bluetooth LE to simplify adding nodes to a Matter network via smartphones. With three types of radios and a Matter API, IoT products from any manufacturer can plug and play with other products and ecosystems. An old argument for using proprietary messaging is that products need differentiating capabilities that are not necessarily part of a universal standard. But how many different ways do we need to set a temperature or turn on a light? The correct answer is “one.” However, some products have unique features that Matter does not define. In these cases, manufacturers are free to define proprietary messages because IP networks do not restrict message content. So, functions common to many products such as transmitting well-known commands and data types and setting up new devices on a network work predictably across all Matter devices without restricting manufacturers from using non-interoperable product-differentiating messages where appropriate. Thread border router Thread is an integral part of the Matter vision. Although Wi-Fi is great for cameras, thermostats, and other plug-in devices, Thread is better for small, battery-powered things. Low power mesh networks such as Zigbee, Z-Wave, Insteon, and others have been around for 20 years, so why do we need another one? The legacy networks do not use IP protocols, so each requires “protocol translation” by a hub or gateway to communicate with the IP-connected world. In contrast, Thread doesn’t need protocol translation because it uses the same IP protocols as Ethernet and Wi-Fi. Therefore, Thread does not need a hub or gateway device. Matter messages are routed directly to any device connected by Wi-Fi, Ethernet, or Thread. Thread devices can plug and play on existing home networks, provided that there is at least one Thread border router to act as a bridge between Thread and Wi-Fi (Figure 2). But consumers don’t want to buy and manage another router or hub specifically to enable Thread. Like I said above, we’re trying to get rid of hubs. That’s why Amazon, Apple, Google, and other consumer electronics ecosystems are busy incorporating Thread border router capabilities into new products such as smart speakers, Wi-Fi routers, and TV streaming boxes. With one or more of these devices installed in a home, Thread devices “just work” when first plugged in without special hubs or routers. Border router silicon Matter’s success largely depends on the universal availability of popular networked consumer products (such as smart speakers) with built-in Thread border router capabilities. In homes with one or more of these products, Matter-enabled Thread devices plug and play without buying additional hardware. Market leaders Amazon, Apple, Google, and others are already shipping a few products with integrated Thread border routers, and many more are on the way for this year. One way to accelerate the growth of Thread and Matter is to reduce the cost and development time for adding Thread border router capabilities to smart-home products. Manufacturers need complete Thread border router subsystems that easily integrate into cost-sensitive consumer products. Border routers need three radios – Thread (802.15.4, the same radio used by Zigbee), Wi-Fi (for connecting with the home network), and Bluetooth LE (for adding new Thread devices). Although chips and modules for all three of these radios are readily available from many silicon suppliers, integration is surprisingly complicated. For instance, all three radios share the same 2.4GHz ISM band, creating gnarly coexistence problems. Also, developers need software stacks that work together across all three radios, and regulatory certification must be straightforward. A single chip with converged, ready-to-use software stacks would certainly decrease product cost and time-to-market. That brings us to the NXP IW612. NXP IW612 tri-radio SoC At CES, NXP announced the IW612 with complete subsystems for Thread (802.15.4), Wi-Fi 6, and Bluetooth LE on a single chip (Figure 3), including RF power amplifiers. Integrating all three radios in a single monolithic SoC addresses the three-radio coexistence challenges while unifying the software stack, reducing the cost and development time for adding Thread border router capabilities to connected products. The chip runs Matter over both Thread and Wi-Fi while using Bluetooth LE for connecting new devices. NXP demonstrated an IW612 based border router at CES 2022. The chip has been sampling since early 2021, with consumer products targeted for 2022. NXP IW612 Tri-Radio SoC NXP The IW612 paves the way for universal availability of Thread border routers in every smart home, and we expect similar SoCs from other suppliers in 2022. Summary After 20 years of incompatible radios, proprietary protocols, vertical product silos, annoying hub (gateway) devices, bafflingly confusing device onboarding procedures, bewildering shopping experiences, and unnecessarily high device costs, the consumer electronics industry is rapidly adopting two new practical, scalable, and open connectivity standards – Matter and Thread. The vision of buying a smart home device from any manufacturer with confidence that it’ll work with your existing Wi-Fi network and chosen ecosystem(s) is finally becoming a reality. Rapid adoption is likely because Amazon, Apple, Google, and over 200 companies are on board and announcing products. Let the gold rush begin!

mystery solved

email is an interesting beast - i recently moved a municipality from an exchange server to microsoft 365 - learned some things but i am in no way an expert microsoft 365 has some rudimentary filtering but i chose to add barracuda for extra protection - and its good - has fended off attacks successfully - so far internal email is not parsed - only incoming and outgoing external email of course it does not deliver viruses - but that is not all that is not delivered if a sender's dkim or spf key has a problem, not delivered - this is not uncommon even among technology companies (check your dns entry) - some will overlook those errors (microsoft 365 will), barracuda (by default) does not ignore those errors 'intent' is another reason email is not delivered this one was interesting - 'reputation' - caused me some grief if barracuda (not a small player) deems you to have a bad reputation (spammer, for example), your emails are not delivered - you can check if a company is on barracuda's naughty list here https://www.barracudacentral.org/lookups interesting to know, if someone is on the naughty list, it will be blocked from delivery if that company is referenced in the email content - if someone forwards an email to me that refers to that company, not delivered - this can even be in a signature block for example, if barracuda considers instagram to be naughty, an email to me with an icon linking to their instagram account - even in their signature block - no delivery it will not pass if i send that email with the signature block, remove the signature, its delivered as best i can tell, those notifications you get are from the email provider - if barracuda rejects delivery, i am unsure if you get a notification so email is not absolute - if it sends to one account successfully, that gives you some information but is not proof that it should send to all computers suck not back to my first sd-wan conversion - wish me luck

not a good omen

i do it as a service for those that only comment on my gutter posts - not on the substance of the post - just my adolescence never participate in conceptual discussions of networks and protocols so i do it as a service - so everyone can participate

i had a house full of farthome's switchlinc plus x10 devices - had scene capability - worked as well as any of the stuff they put out - when they quit selling them and introduced insteon, i tried a few with the x10 setup - the coexistence stuff was what you'd expect from them - bought into the 'add more and it will work' too scenes were like insteon in response without that response, z-wave is not an option for me

the good news is that you are in a position to migrate to another technology slowly should insteon fail

more of a developer discussion - installers use the technology and implement it for customers - they don't necessarily have to understand that the communication method and application (commands) are not the same thing - insteon combined both into the name insteon - matter will not - it will use existing, open communication methods to deliver the traffic to the device 0f course - discussion is welcome - we are learning from each other no one is wishing failure on the new owners - at least MY anger is directed toward farthome/fartlabs - for the reasons posted all over - glad your experience was better with insteon, you have to hope for those door locks - IF insteon wants to make them - with an open standard, any number of companies can make them - competition - and hopefully - a better looking lockset (snicker - actually - baldwin brass had a zwave product at one time) insteon is interested in locking customers into insteon - has you waiting for a door lock - might have been a good or bad market strategy - i don't know - zwave allowed ge to make a zwave dimmer - and others (zwave gets a fee) - and schlage - different strategy from insteon insteon took forever to make a working hub - ud made an excellent one - but you think insteon was first to integrate to alexa? ud blazed that trail and closely integrated before others - the 'tell insteon to...' is a no go for me - i need the lights to respond to 'turn the kitchen lights off' ud saw the writing on the wall - and a business opportunity - a market need to allow me to use insteon AND have those door locks - ud added z-wave support AND presented the zwave devices to me in a common interface - just a list of resources that - though unrelated in technology - allow me to relate to each other and act upon - i could (if i had one of those ugly things) have an insteon keypad button unlock a zwave lock - while others are hoping insteon makes a lock - and accepting whatever they decide to make ud expanded to elk security, allowing elk and insteon devices control each other - michel is a brainiac and business savant - he saw that matter or no matter, he did not wait - he did the work for ud customers - doing what insteon would not do - make different technologies work together and give me options - and do it in a common interface - i do not have to know that the insteon command for dim is 14 - or that zwave is 63b2 - i just tell the device to dim - ud does the real work - that is huge - ud pioneered interfacing resources like a zwave blind motor with alexa - even if the manufacturer does not michel saw us wanting to turn the thermostat up from an insteon keypad - i have ecobee while another has nest - multiply that by tons of ha equipment - so he created hardware and announced to all the developer nerds 'you build a 'node' and sell it - polisy will run it' - i don't want nest - i do want ecobee - i choose what i want - he introduced choice and modularity but isy and polisy are dependent on insteon in that it takes a insteon plm to communicate insteon - with zwave, more than one manufacturer makes a rf transmitter - matter chose to adopt existing communications methods i wish them well also - however - if they fail, you have thousands invested in a technology with no door locks or replacement dimmer - i am done basing all this money on hope - no one cares of ge goes belly up - lots of others make zwave dimmers - insteon chose a different path and i was suckered into it insteon has lots of advantages - their unwillingness to open insteon to others - in hindsight for its customers - was a bad idea (not saying it was a bad business decision - it was bad for its customers)

in hospitals, they have an annual inspection of biomed equipment - and iv pumps are expensive and constantly disappear while listening to the cfo whine about it - i told him i could put a $50 tag on each pump and find them for him IF they were in the building - he tried to kiss me the proximity tags are battery operated wifi - when used with lots of other cisco components they already had, you can locate each tag now granted, the batteries were changed annually - but they did last a year - and tons of them granted, lots of aps too - but telemetry equipment, vital sign devices, guests on wifi streaming who knows what, 150 wifi phones, ekg carts - who knows what all is on wifi had 2 wifi problems while at that hospital one clinic was dropping and recovering aps - rogue detection is a regulation in that hospital and the clinic next door triggering it - they got 'free wifi' from those companies that give them free wifi in exchange for those huge tablets in the waiting and exam rooms selling you drugs you never knew you needed - and prompting you to beg the doctor for them the second problem was when the director doubled the number of aps on one floor to expand coverage - which caused the hospital aps to thrash changing channels and decrease their power - giving less coverage the proof was visible to the kissing cfo on the cisco prime heatmap - because the director refused to believe less can be more with aps the thing that amazed me was that even with all the thrashing, the wifi network handled it remarkably well - the diminished coverage was what brought attention to the problem

jump on in - we all are i am victimizing the routed network guys to help me clarify concepts i am foggy about i was talking to an anesthetist - she was from india - asking about why some nerve blocks last longer than others and why that is different from an epidural - she said 'you ask too many questions' - but she did answer sigh but one of the constraints of using wifi in ha was the limited channels - i pointed out that each ap uses 3 channels - not the SAME 3 channels - wondering is mesh uses the same 3 channels too many aps too close cause problems - because they have to change channels because another ap in range is using that channel - too many can cause constant thrashing of all the aps constantly changing channels - one mitigation strategy is to power back the ap so its range is less can the traffic be tcp? only applications that come to mind are udp applications well when we are putting our nail clippers online... something like a keepalive? or a time to live interval? i did not think wifi had to solicit data from every device now THERE is overhead - bandwidth used for relaying is bandwidth not available to end devices

oh - sorry - i saw another reply to you that was wrong - that the zwave associations were direct device-to-device - not if the associated devices are out of direct range of each other

unless there are some aps i don't know about - roaming requires a wifi controller of some sort - people don't realize that when buying something like those ubiqutit or unifi or whatever - but they do offer both a cloud controller (um - really?) or a hardware controller that can be installed locally i don't know enough about mesh wifi (not the frequencies - the topology) but they seem to be fancy range extenders if they all use the same channels and have to route the traffic back via the same wifi frequencies