Teken

Randy, Could you provide the rest of the program code for review?

To be clear this remote lync bridge connects to the Kidd smoke / CO alarms via RF. This device in turns connects to the network via WiFi. It then connects to a cloud hosted service for sms / email correct? What happens when there isn't any Internet connectivity in the home?

io_guy, For the benefit of others can you explain what are some of the use case and benefits of having a node server in place. I am trying to envision what kind of features and abilities that can be seen by this. As always the membership thanks you for sharing these link programs!

A few other issues I have noted using the DB -> ISY method is slow to long variable reaction. Meaning if a device comes on it can take 20-90 seconds for the variable to change state. You also have the case where variables continue to run long after that energy state has ended. I have tracked this strange behavior for a year now and have never found a solution or explanation as to why this happens. Initially I considered and tried changing the send interval to much shorter bursts. But, as many of us know if there are many network devices doing the same this can impact the ISY Series Controller in performing other aspects. For me I've determined a 25 second send interval is the best balance of network traffic, response, and operation. For those who have nothing else that is banging away at the ISY Series Controller a send interval of 10 seconds is OK. Lastly, given the small amount of users who actually have a GEM / ECM unit in place and couple that with actually using a ISY Series Controller the odds of more development for the Energy Module are not very likely in the next few years. You can do your part and spread the word in what ever forums you're a member of and this in the long run will drive adoption and increased sales. I know personally that my *Install Thread* has brought lots of attention, awareness, and sales for Autelis, Brultech, and UDI. Letting people know there is some little box(s) available that can help aggregate, track, and manage a persons electrical energy in the home is the next big push for the HA space. Sadly, the reality is HA took more than 25 years to see mass adoption and penetration in the market place. Energy Management and tracking is just now getting that same exposure. My belief is it will take another 5 years until the *general consumer* sees value, benefit, and use from such wares. On the plus side Brultech and UDI are well positioned to help those who wish to adopt such measures. My hopes is by the time these people see the light and want to use the Energy Module it will be more mature and feature rich. Let the games begin . . . Ha . . .

As you noted the ISY Series Controller does not currently support the ZigBee HA 1.2 protocol and only the energy management aspect. It was stated this was on UDI's road map at some point in time after various mile stones were completed such as Z-Wave, 5.XX, etc. I don't for see ZigBee HA 1.2 being supported for several years at its current pace of development. With respect to which brand to go with over all the Insteon products look and feel much better when compared to Z-Wave. The one device which I have to give the nod to is the Z-Wave Aeotec 6-1 multi sensor: http://www.smarthome.com/aeotec-zw100-a-z-wave-multisensor-6.html Insteon does not offer such a small, flexible sensor at the moment. Another aspect which I have to give the nod to is many of the newer Z-Wave products offer *Energy Monitoring* in their hardware profile. This is from outlets, switches, micro modules etc. In that respect it provides the end user more value and insight along with the same control Insteon does. I believe if you purchase the Z-Wave upgrade kit you will have the very best of both worlds. As you will have native support for X-10, Insteon, and Z-Wave . . . There are also more TSTAT's, Locks for Z-Wave than there are for the ZigBee protocol. Lastly, you will find pricing for Z-Wave products often times cheaper when compared to ZigBee. The ZigBee protocol has huge potential and flexibility unfortunately UDI and many others do not provide full support to take advantage of such. Perhaps once all of this Z-Wave / 5.XX settles down there will be development time set aside to increase ZigBee support.

As I understand it if you obtain the energy data via Ethernet / WiFi only 7 channels will be made available and there will be 7 nodes in the device tree. It should also be noted that response time and accuracy using the Dash Box method to obtain energy, temperature, voltage, pulse, etc is delayed and not as accurate when compared to the native energy module via ZigBee. There are a few people who have deployed the method you have described above. To date I have never read of one person indicating they are happy or unhappy with that specific solution. Lastly, it should be clarified that the purpose and intent of the Dash Box (DB) in having the ability to push state variables to the ISY was to provide more access and data not currently supported by the current energy module platform. The only limitation to using this method is what I stated above which is slower response time and (sometimes) missed readings which either are peak, low, or instantaneous readings. These three attributes are extremely important if mission critical monitoring is expected and wanted as I do. As many who follow my *Install Thread* know the benefit of using the DB to relay the 32 channels, 8 temperature, 4 pulse, is having the flexibility of installing and using Z-Wave. Some would consider the above a great balance and trade off . . . While others who are more focused and concerned about mission critical energy monitoring use the ZigBee method.

I have to gather this is on the newer units because up to a certain manufactured year the fancy remote controller worked perfectly fine and it never cut the power to my unit. With the advent of the Internet *My Q* module it seems the reliance on the data bus is more stringent than years past. To be honest I don't know of many people who rely on the clock, temperature, at all. So if the OP can live with the LCD going blank and flashing 12:00 and it allows the I/O to operate. Than, I say have at it its free and it works! Ha . . .

I think some of the fault lies with the general public to be honest and not all of the blame can land on Smartlabs. In this day and age all of us want our cake and eat it too. This often times leads to a compromise in security or to the basic elements of the system. Any person can walk into a office building and find best practices with respect to security not being followed. Whether it be using strong passwords, not allowing recycling of similar ones, to expiring them on a known interval. Many places still do not use any kind of two form authentication or challenge phrase passwords. Many of the places I supported used all of the above and much more such as biometrics, random number generators used as a 3rd (in person) authentication etc. Some of the other military and bio medical facilities use face recognition, palm print, and retina detection for level 4 areas and beyond. At the end of the day if we all could accept the fact the device had to be physically pressed to send out its MAC address while encrypted enroute there would be very little to worry about. But the reality is *we the people* have asked to make the enrollment easier and faster so this is what we are left with. Again, I see what EVIL Pete as doing ,is for the benefit of the product, people, and the hardware. For ever and a day those using Mac computers have believed they were impervious to exploits, virus's, and trojans, etc. Fast forward the last five years there are more each day that exploit the Mac OS. The reality is the Mac had a market share of less than 2% globally and nobody who was hacking at the time wanted to waste resources in something that had zero impact to the global market place. Now, given the mass adoption rate and growth of the Apple product line in all manner of business, government, and public use. That 2% target has outpaced the PC industry by 300% YOY. To a hacker there is now a reason, and ROI for spending time to find and exploit known holes in the Unix / Linux kernal. For me if EVIL Pete finds something that truly exploits the Insteon hardware that is a good thing. As this will make future hardware that much better in the long run. The biggest concern people should have is the slow aszz response time Smartlabs will have. Let alone the wall of silence and the lack of time line to correct said issue(s).

True, but I saw it as informational data that he wanted to offer the general public. I don't pretend to know his underlying intent or purpose. But, its safe to say given his past history its a combination of tinkering and finding exploits to help people and companies be aware and ultimately improve their products and security attributes. I am more curious as to what hardware / software is being used to cause this exploit to be seen. As I have often seen people use things that the *Average Person* really had no capability to mimic or copy to do the same. Case in point ELA has made his ELAM which assists him in monitoring every aspect of the Insteon protocol and line traffic along with signal strength. Given the fact his skills are very high and is a EE this does not come as a surprise to me in the least. What does surprise me is Smartlabs in ability to offer the same? You're talking about people who are intimately aware and have all the technical know how of the Insteon protocol and more. Yet you have some random person like ELA & EVIL Pete who have summarily been able to obtain more and provide more data than any single Smartlabs engineer in the history of the product? What is wrong with this picture???

I have one of the first generation jack shaft 3800 series GDO's. It too came with a fancy wall mounted controller. Unlike others I never went down the road to soldering any remotes. I simply installed the I/O linc wires in parallel at the GDO unit itself. This has been working perfectly fine for six plus years. You might want to give that method a try and could save you some cash! [emoji4][emoji6] Ideals are peaceful - History is violent

Well for perspective I don't think anyone had the same skill set as EVIL Pete. Considering this is what he does as a hobby and related work. Keeping in mind not one soul has ever been a presenter at DEFCON so this lends credence to what has been stated. At the end of the day I don't believe he's just blowing smoke up your dress! [emoji5]️[emoji4] Ideals are peaceful - History is violent

Yes, EVIL Pete indicated this in the Smarthome forum several weeks ago. I am eager to see what has been found and what methods are used to exploit the Insteon protocol. Not too sure how Smartlabs will respond to this news . . . But, if history is any measure or indicator they (Smartlabs) will sit and wait for a year or so before they provide any kind of resolution. This was seen in the HUB v1 a few years ago and was documented in the Cisco site as to the threat level etc. For me I am not worried at all about a hacker trying to control and access my Insteon network. Given the extremely short distances of RF / Power line signalling. The odds of someone outside in a vehicle lying in wait to capture the Insteon signal is highly remote. Bolster this with the shear fact I am surrounded by red necks and low tech fools that simply decreases the odds anyone is interested in hacking my lighting system. Don't get me wrong, if EVIL Pete provides methods and techniques that compromise the Insteon architecture Smartlabs needs to plug those holes etc. For me I won't lose any sleep over this because there is a higher possibility of me getting struck by a meteor in this hick town than some random person coming down my street waiting to capture and turn on/off my lights.

I would love to read over a in depth review and possible You Tube video of all of this in action.

I was mistaken as you can see the One Link sensors all have the following designations: http://www.firstalertstore.com/store/category/wireless-interconnect-alarms.htm They also have the markings so what ever they sold you is incorrect.

Just to be clear you're saying the face of the smoke detector has no markings indicating One Link? As you can see all of mine do and they come from various sources from North America. The SA-501CN is the correct model . . .

LOL I did not even consider you purchased the wrong units! [emoji5]️ Yes all one link units are so marked and all of them work with the smoke bridge. Well besides the Z-Wave version of one link! [emoji4] Here are three kinds I have deployed in my home. 120 VAC hard wired, battery smoke, and battery smoke / CO. Ideals are peaceful - History is violent

Once you confirm bridging / coupling if that is good. The most likely cause is noise in the home. As painful as it is the only recourse is to unplug everything in your home and turn off breakers to items you simply can't reach. If afterwards you see status on the smoke bridge it's time to replace / filter the offending device(s). [emoji53] Ideals are peaceful - History is violent

Have you confirmed you have proper coupling / bridging in your Insteon network as outlined in the users manual for the 2413 PLM? It sounds to me based on your reply you have either noise on the line or poor coupling. I would suggest you complete the coupling / bridging test and get that out of the way first. Next, move the smoke bridge to another outlet using a long extension cord. If you find one that shows proper status identify what devices are on the offending outlet and either remove / filter them. If nothing is on that circuit at all it tends to point to poor coupling but could be still noise makers / signal suckers in the home.

The fan must be set to the highest speed and left there. The fanlinc moving forward will control all aspects of the fan speed and light. I would not remove the chains but simply secure them in place and out of the way. Because one day you're going to need them for some testing / maintenance.

Took a quick glance at this site and most if not all of the information is none informative and provides little reference(s). The site actually comes off as horse sh^t material. Clicking on their Smarthome link goes no where but talks about Apple / BMW?? Really, fail . . . EDIT: It should be noted one of the HUB's they are speaking about has to do with the HUB v1 / v2. Which I am told was finally patched after two years of being well known. This was first issued by Cisco and some 3rd party white hats who perform security threat assessments on products / services. This is one of the reference materials I saw two years ago: http://tools.cisco.com/security/center/viewAlert.x?alertId=33393 This is the other famous one which is the Vera Lite: http://www.computerworld.com/article/2484542/application-security/home-automation-systems-rife-with-holes--security-experts-say.html

I use a combination of dedicated hardware, software, and cloud solutions. Which assist me to see real time, historic, and aggregated trends. The ISY Series Controller provides me from small to large tracking abilities which are integrated into several other cloud solutions. In the screen capture you will see state / integer variables which track current, low, high values for specific areas, rooms, zones, floors, devices, appliances in my home. Using the power of the ISY Series Controller I forward the same data sets to the free hosted service of Smart Energy Groups (SEG). As this allows me to use multiple graphs, charts, dials, to be used to track those sensors and energy readings for later review. While on the other extreme I use my Brultech Dash Box to capture all of the electrical energy, temperature, water, gas, weather data which is stored locally in my home. I have the benefit of local storage, control, and security / privacy. While also having redundancy of the same data set held off site freely hosted in the cloud for later retrieval and sharing with the community should I so desire. Ultimately all of the above takes some time, effort, and financial resources.

Pressing the set button should also send a heart beat update about 1-2 minutes afterwards. This is unless the latest firmware has interrupted this behavior. For the benefit of others please state the hardware, production date which is on the device (inside) and the ISY firmware.

The only sure why is to look on the back to see what model it is whether its a older single band 2412S vs the dual band 2413S. As I recall hardware v.92 was present for the 2412S. For some reference if you had a 2412S and compared it to the 2413S in terms of shear weight the 2412S weighs about twice the same weight as a 2413S. Lastly, you can keep the older unit and follow the capacitor replacement guide and have a back up. This assumes only the capacitors have failed. As a very small percentage of users had other components fail besides the caps.

Just to clarify in your program 100 equates to 100'F correct? Because in the Autelis Bridge 100 is actually only 10, 100;F would be 1000 no? I use metric so 20'C comes in the Autelis Bridge as a value of 200.

That's good to hear. Regardless, great job on getting it all connected and working as you hoped. I enjoyed this little project develop and its final completion. Well done . . . [emoji1] Ideals are peaceful - History is violent