
RPerrault
Members-
Posts
275 -
Joined
-
Last visited
Everything posted by RPerrault
-
as i understand it - the plm probably has a new address - there is a post abot replacing a plm that involves a plm restore
-
well thank goodness all us rubes have someone smart like you to explain to us (who does not know the difference between a network switch and a light switch) look up the word integration https://assets.lutron.com/a/documents/040249.pdf roomba is not udi - nor any number of node servers - go troll people posting about them you can believe me or not - i don't care about your opinion - i talked to two lutron homeworks dealers about wood blinds - they offered because unlike you, they thought i was capable of doing it explain this 'api' to us without using the word integration how many apis have you written code for? does lutron have one of these apis? fish in a barrel
-
for those interested in homeworks (and not being argumentative) components https://www.lutron.com/en-US/Products/Pages/WholeHomeSystems/Homeworks/Components.aspx architecture (qsx processor) https://assets.lutron.com/a/documents/homeworks_system_architecture.pdf published protocol (for the node code types) https://assets.lutron.com/a/documents/040249.pdf
-
both dealers i spoke with were willing to sell it to me
-
lutron dealers will sell you homeworks and hardware - and its not $50,000
-
How to use Alexa AV to control receiver volume?
RPerrault replied to landolfi's topic in Amazon Echo
my comment was to say this homeseer has had some form of voice control for a long time in response to the comment on local based voice control and what hardware might be necessary to drive it -
lutron homeworks
-
How to use Alexa AV to control receiver volume?
RPerrault replied to landolfi's topic in Amazon Echo
homeseer -
vm haterz love their blackberry
-
https://www.home-assistant.io/blog/2016/01/19/perfect-home-automation/ evidently the founder of ha - good advice but seldom heeded
-
omg don't tell that i posted - i was told not to until i use topic sentences and have grammarly parse my posts not sure if anything else does this - but the 'replace device with...' function is invaluable for me - i have well over 100 insteon devices and at least as many scenes - lots of keypad among the insteon devices - craplincs being craplincs, ud makes replacing devices easy and - the setup - once you grasp the bizarre controler/responder lingo, ud makes the setup easy ud has saved my life many times - but the 'nodes' are not supported by ud - hope the beer truck does not take out the support for the node you rely on - i am not saying its a bad approach (allowing 3rd party developers) but its not like you are able to call a company for support odd that people think ud devices are simple - there is a learning curve and its a unix based os - not that unix is bad - its good for some applications - but its not an apple pc - people keep wanting graphical interfaces and sound and hdmi and crap to make it into an apple os - which completely eliminates the advantage unix has - its not a 'just buy a box' - ud devices are not about apple graphical interfaces - ud devices are about the setup and execution - ud devices belong in an equipment closet, no matter how pretty they make it - functionality adds complexity and points of failure and security risk - and size - i think ud is doing that right - its a workhorse that does not need attention - not an apple minimizing points of failure is good but until you have a hot standby system...ud does not do this bmercer's (at least that is who i credit) worked on the echo integration was fantastic - voice control is great - with the echo routines, i finally got my wish - 'turn the lights on' is device dependent - i also learned that i don't need ecobee thermostats interfaced to the isy - as i said, i am not 'a real home automation' nerd because i don't try to control others with motion sensors and guessing what others need - i call that parlor tricks but evidently its 'true home automation' ud devices are a bargain if you replace a craplinc
-
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