gduprey Posted February 26, 2016 Posted February 26, 2016 Howdy, Wasn't sure where to put this as it's not strictly an ISY question, but figured someone here might have thoughts/insight on the question. In particular, as I understand it, Insteon device addresses are 6 digit hex addresses. That suggests that there can be about 16 million devices before the device addresses "wrap around". Granted, that is a big number, but not so big it made me wonder what would happen in that case? Would you just have you double check to make sure you don't have an existing Insteon device with that address and return/replace it with another? Is it something the Insteon/SmartLabs people have ever commented on? It may be a hypothetical question, but not so far out of the realm of possibility that someone must have thought about it some. Gerry
Teken Posted February 26, 2016 Posted February 26, 2016 Howdy, Wasn't sure where to put this as it's not strictly an ISY question, but figured someone here might have thoughts/insight on the question. In particular, as I understand it, Insteon device addresses are 6 digit hex addresses. That suggests that there can be about 16 million devices before the device addresses "wrap around". Granted, that is a big number, but not so big it made me wonder what would happen in that case? Would you just have you double check to make sure you don't have an existing Insteon device with that address and return/replace it with another? Is it something the Insteon/SmartLabs people have ever commented on? It may be a hypothetical question, but not so far out of the realm of possibility that someone must have thought about it some. Gerry I've thought about this issue way back in the day when I thought Insteon would take over the entire Home Automation (HA) space. That was back in 2007 - 2009 period when HA was still very much a hobby. Now, given the massive adoption of Z-Wave / ZigBee, BLE, WiFi, the odds of the 16 million codes being used up is less of a concern. As you noted (IF) that was to be an issue a return of the product would be the only solution moving forward. But its safe to say if you ever received a duplicate MAC address for a Insteon device you better consider buying a lottery ticket!
gduprey Posted February 26, 2016 Author Posted February 26, 2016 Where it's been making me think lately has been for a lot of the RF stuff. Granted, someone has to have an investment in Insteon to really make those worth deploying, but in addition to nearly 90 Insteon light switches/dimmers, I've been adding a lot of motion, door and leak sensors lately. They work well and collectively (in two homes) I have about 135 Insteon addresses in-use around now. ZWave has a lot going for it, but for lighting in particular, I feel Insteon still has an edge for whole home installs (between the fact that Insteon switches have direct/status reporting, directly supported scenes and seem to be, on average, noticeably less expensive than similarly equipped ZWave devices). For thermostats, locks and (to a lesser extent) motion and door sensors, ZWave has much better offerings. I have noticed that there are a lot of "WiFi" automation products in use by folks looking to automate one or two things (a few key light bulbs, a thermostat, etc). But everything has it's own app and/or is bound to some cloud service. It doesn't scale very well for "whole house" automation. I do think there is a place, especially for larger, more complete automation installs, for Insteon and someday, this issue will likely come up. It'll be interesting to see how it's handled (my guess/hope is a new generation of device that adds 8 or 16 more bits and is backward compatible with existing protocols/devices with an implied '00' or '00.00' prefix -- ideally "just" needing a new PLM and ISY firmware upgrade). Gerry
Teken Posted February 26, 2016 Posted February 26, 2016 Random (unsubstantiated) talk in various forums indicates Smartlabs i3CS is supposed to offer more features. Whether or not they even consider increasing the prefix has already been seen by some newer devices. I think you may be more familiar with this than I in this regard as many new devices generate new values when a level 3 error log is invoked. Features already seen in the wild are send clean up messages, smart hops, blink on error, and the ability to turn RF / Power Line on-off. They have also increased their RF output on at least four products now shipping: HUB II 250 feet, HUB Pro 250 feet, Dual Outlet 250 feet, Range Extender 200 feet from the standard line of sight 150 feet. The three items I believe they need to focus upon is better security whether it comes in the form of encryption. Better error correction, and moving the antenna for all hardwired devices to the front of the device. If we assume they continue to increase the power output while staying with in the FCC guidelines it will give Z-Wave a shot to the body. Besides the most obvious con's about Insteon is zero support from third party hardware makers. No 3rd party lock support that offers real time feed back of lock / unlock. Zero support and feed back to the community and other vendors offering Insteon as a product line . . . All of these items supersede a what (IF) scenario of getting a Insteon device having the same MAC address. You have a higher likely hood of getting struck by a drunk driver than receiving a duplicate hardware.
paulbates Posted February 26, 2016 Posted February 26, 2016 As a related topic, I've wanted to see market penetration and trajectory for Insteon / Zwave / Zigbee / Wifi iot devices. How many are out there, and how much is it growing? I've asked next market if that was something they would look at but no response
Brian H Posted February 26, 2016 Posted February 26, 2016 (edited) I have seen duplicate six digit Insteon ID's for the special Developers Group Hardware Kits. All the PLM's where AA.AA.AA All the Lamplincs where 11.11.11 A few of the developers with more than one kit being used by a few employees. At the same time. Caused all kinds of strange happenings when one developer caused another developers kit to go on, off brighten or dim. Probably would also get strange answers if the LampLinc was asked its status. Edited February 26, 2016 by Brian H
KeviNH Posted February 27, 2016 Posted February 27, 2016 For certain specialized network equipment, I've had a vendor ask me to provide them with a list of existing similar gear specifically to avoid shipping a device with a duplicate address. I suppose a similar check could be implemented by a really savvy HA retailer, if such a firm exists... Granted, that is a big number, but not so big it made me wonder what would happen in that case? Would you just have you double check to make sure you don't have an existing Insteon device with that address and return/replace it with another? Some Ethernet cards store the MAC on an EEPROM, so it can be permanently rewritten, same approach could be used for Insteon. Hypothetically, I'd expect that if the address space were exhausted and they were forced to start re-using addresses to preserve backwards compatibility, they'd move the address to a rewritable area and provide a mechanism to change the address in the field in the rare case of a conflict. Speaking of Ethernet their 6-byte MAC allows for 281,474,976,710,656 possibilities, but IEEE allocates blocks to manufacturers in blocks of 3 bytes or so. Additionally, many devices (e.g. Cisco routers, VMware, etc) generate virtual MACs, and these are prone to duplication -- I've had some rather annoying bugs in Cisco networks due to routers assigning the same virtual MAC to multiple interfaces. While the total address space for Ethernet isn't exhausted, individual chipset makers have intentionally and accidentally produced network cards with duplicate MACs, causing no end of headaches.
paulbates Posted February 27, 2016 Posted February 27, 2016 Some Ethernet cards store the MAC on an EEPROM, so it can be permanently rewritten, same approach could be used for Insteon. Hypothetically, I'd expect that if the address space were exhausted and they were forced to start re-using addresses to preserve backwards compatibility, they'd move the address to a rewritable area and provide a mechanism to change the address in the field in the rare case of a conflict. Smarthome actually did this to replace the first defective generation of hub 1s in early 2013. One of the services SH offered was to burn the current hub's insteon ID into the the replacement hub. The replacement hub with the old ID was shipped, restore link table to the hub, and go on your way. I would gladly pay $10 more today for a replacement PLM to have that same feature; burn in my current defective PLMs address to a new PLM. Its possible, I've seen it done, but only in that one case. Paul
Recommended Posts