This is basically update # 36
Negotiations with our tooler/injection molder facilities have wound down and we have selected and visited the facility we will be using. We feel confident in the quality of their work and we have been working with each others engineering teams to minimize errors in moving from our CAD designs to cutting our first physical tools that will be used in our injection molding. Our last step is verifying all the materials, colors and textures will be used in each tool. Our relay design, for example, requires 6 tools, 3 materials, 3 textures, and 4 colors. We are also taking one more spin on the mechanical system that holds our relay together to improve its overall fit and are expecting the prototype to arrive late next week for verification before we can pull the trigger to start cutting some steel. We of course will post pictures of this process once it begins.
DeviceJS Documentation & Support
As we prepare for the public release of DeviceJS, we are internally debating whether we take the time to document deviceJS or just put it out there, undocumented. The challenge is the more time we publish documentation the less time we are spending on finalizing our software and bracing for production. If we do publish DeviceJS without documentation, we will most likely be hit by a plethora of questions from our backers, partners, and future customers, which may be more time consuming than creating and posting documentation. (By documentation, we don’t mean “in line comments” as those exist. We mean web pages, tutorials, how-to’s, and definitions for how to use deviceJS.) We welcome your comments and feedback on this as we decide the best action to take for this critical piece to our platform.
DeviceJS has been worked on to support Philips Hue, TCP bulbs, Belkin, Insteon, LIFX and Z-Wave. Users of these products will be happy to know that those products are supported and, for the most part, have few kinks to work out. Note, Z-Wave and Insteon are protocol drivers. We have added one device for each protocol and will ask the community to fill in the blanks with further device drivers. ZigBee is on our list as well but Ed has a ways to go before it is implemented. Jon (embedded software) has ways to go on the ZigBee dongle as well. Additionally, our onboarding process for devices now include UPnP, MDNS, and QR code scanning, which will help our developers as they add products to the WigWag platform. Particularly with UPnP, developers will not have to write code for initial discovery of a smart device. Instead, deviceJS will recognize it exists and begin communicating with it. The dev team is sprinting for a full test run before mid August.
This week, Ben has been cranking on several goals for the iOS and Android apps. Not only does this ensure that, beginning next week, the app will be extensively stress-tested, it means he can help test and debug other parts of the code while the rest of the product is being completed, accelerating overall development time. Backers will find this version of the iOS app more robust, extensible, and clean-looking than the app we had originally created for Kickstarter.
Rule Builder Testing
To have our accompanying services in line for launch, we have decided to stick with the current design of the rule builder and move forward with cross-browser support. Currently Chrome and iPad versions look great. Firefox and IE11 will need some work before launch. What does the backer community think about skipping testing of IE11? Who out there uses that?