RPerrault

which is a big plus when an existing open standard is used and not being held hostage to proprietary protocols - one reason i think matter would be a good thing for ha

how?

the controller can report what it sees and made available by the protocol with network problems - for problem isolation - a tool for powerline and rf communications that captures traffic would solve lots of problems without the guessing and theories - like a sniffer or wireshark that is not the responsibility of ud to make one - i am npt bashing ud or insteon someone posted a thread on how to make your own rf antenna that can capture the rf signals - i think it can provide some formatting too - and i suppose an oscilloscope could capture powerline signals it would be interesting to see the traffic

my point was - there is no way of knowing if those devices ever get or respond to rf signals insteon - like many of these ha devices - do not have tools to monitor communications my theory is the 'buy more - robust - build the mesh' routine is profitable for them problem resolution by guessing is how i fix problems on a car engine - try this sensor - now this part - with enough guessing i generally stumble onto something that works

farthome/fartlabs is not selling off their assets lienholders and bankruptcy court would be interested if the liquidator breached their fiduciary responsibility by doing that

so - how do you know - with the deep fryer not in use - that those devices get the rf signals?

gmail strengthened its authorization for access - i don't know the details but it caused technicians for multifunction printer manufacturers mayhem (scanning to email) might want to check on that

i don't use programs but do use keypads - and a scene for each setting - on, off, low, medium, high i would - off the top of my head - set up a variable for each setting and pass them to alexa - then program for each - when variable on, set scene on - then reset the variable value not super graceful but i do it with blinds

this will set off the safety lectures - i have the insteon on/off switch controlling the food waste disposal to match the dimmer in the same 2 gang box - made sense at the time but having confessed, i'm pathetic - sigh

what kinda freak controls their attic lights? actually - i do too - sigh but ima try to trump you - my attic lights are on a dimmer with frosted light pipe and a lutron screwless plate omg i need an intervention

as i understand it, the structure of the packets is not the mystery - nor are the commands - i think fartlabs published that for their development program someone posted on a rf device they used to see the packets - a sniffer or wireshark type tool that could be used to break all that down - packet structure and commands should not be a problem (if its legal to construct and send them commercially is out of my league) michel has always said insteon needs security but it was not in the specs - as i understand it, insteon traffic is sent through all houses serviced by a transformer - an all off command would be interesting... these packets are tiny - they isy constructs them and passes them to a plm/c/s/u/whatever (fartlabs device) to deliver - that is where the gotcha is - getting the packets sent - inserting data on a powerline seems impossible to me - but its done - sling made devices to send video over powerlines - not sure how good it was broadcasting on a frequency seems easier to me either way - has to have a driver or whatever unix calls it - an interface for a program to pass the data to the operating system - for the operating system to dispatch the packet on the hardware which is why i asked the question - if an insteon device (say dimmer) gets a packet from an rf delivery, does it repeat that packet on both rf and powerline? and powerline delivery repeated on rf? if so, you only need one to work (rf or powerline) to one device to get the hoppin started - until the hoppin count is exhausted

of course i win you might try reading the random links i post - might learn what a protocol is - or how to see a 'router' constraint

and that is important enough to me to drop zwave from consideration - for lighting scenes

i have installed 600 billion - if that matters i don't do this for a livelihood - i'm a nerd your experience might work for you - understanding the concepts works for me - might work for others if you'd stop bashing us i understand the concepts of the internal combustion engine - can work on them a bit too - don't need to understand the concept to drive a car though you can drive - that is all - which is ok for setting up devices like you do - but you do NOT understand communication basics - if something is causing a communication problem, you can only guess why you have no idea of if wifi is constrained - and certainly never prove what the problem is - but you would probably drop jargon and sell a customer more devices - 'read it on a forum' like others, i am looking for a replacement for insteon - to make that decision, i need to understand the concepts and market direction and capabilities of each solution - limitations - cost - migration path - cost i read - not just copy and paste - others might read too - i doubt that is you (your analogies are even lame - trumped you there too - only needed one lane)

and - have something like a receptacle... sigh

and would never use ra2 - or ra3 until it can support more than 200 devices

what i posted above do that and many other scenes with zwave - insteon did - lutron does i don't dislike zwave - or married to lutron - scenes are important to me - as far as i know, zwave can't do what i want

you might snipe at others from behind your keyboard on this forum and get by without a response - i will respond so you can vomit up how many people you have helped yet again i know i am not the big fish in this pond and i understand that this pond is important to you i also understand that most here do not want to discuss concepts - especially you because you do not understand them - you can't ignore a thread i created to discuss wifi and its use for home automation - you could not ignore that thread - but felt compelled to bring in your snark you are not as smart as you think you are - as revealed by what you post - and your language is off-putting if not offensive this will run you off - what is the constraint in using wifi for home automation - post the resource utilization for us

2.4 is NOT a protocol

zwave do this instantly and simultaneously?

its not bad 2.4 reaches farther than higher frequencies - higher frequencies are faster transferring data generally, lower frequencies penetrate better

2.4 is the rf frequency - nothing says it has to be wifi protocol while lutron can use that frequency, that does not mean its wifi protocol - i suspect its not - its their 'clear channel' generally, wifi repeaters are not the correct answer - unless its to extend the signal wifi access points are the answer to most problems a repeater STILL sends traffic through the access point it is connected to home access points are not some huge technical feat only a nerd can set up - most homes need good wifi coverage for devices other than homeautomation - just be aware that if you want to 'roam' between access points in your home, you will need a controller of some type to accommodate the handoffs between access points probably need good home wifi already - its a no brainer to use it for home automation (though dealers can't make more money saying 'robust' and 'add more') i agree that reducing single points of failure is always a good thing - as i understand insteon, the traffic does not have a path the packet must traverse - if one device dies, most likely another device will pass along the packet - with zwave (way outta my league here), the route is set at setup or until some kinda 'heal' process is initiated - the new 700 standard might have addressed that

Autelis - bummer that it went away The Lutron integration protocol will allow third-party equipment, such as touch-screens, universal remote controls, and software applications, to control and monitor devices in a Lutron lighting control system. The protocol supports three basic types of integration operations: • Execute an action in the Lutron system • Query the status of the Lutron system and Lutron devices • Monitor responses from the Lutron system Integration Access Points communicate with external systems using RS232, Ethernet or both. The Lutron integration protocol will allow third-party equipment, such as touch-screens, keypads, and software applications, to control and monitor devices in the Lutron lighting control system through an Integration Access Point. For more information, check the page specific to the Integration Access Point being used. An example of an Integration Access Point is the QS Network Interface (QSE-CI-NWK-E). For a listing of all the available Integration Access Points supported by a particular system, see the Integration Access Points section for that system in the table of contents. start coding

um - dealer only - sealer - jeez