Honeywell and Nest all have nice Wi-Fi connected thermostats, but the problem with their products is the price point. They cost around $300, which is out of reach for many consumers. The goal of the T701i was to create a $50 thermostat that had the capabilities of the Nest, but at a much lower price point. Using light weight processors and Wi-Fi chips, we were able to create a thermostat, firmware, and iOS and Android apps, and achieve our price goal. Utility companies have even been able to give these thermostats away for free. By writing low level firmware, simulators, and efficient apps, our company was able to help them keep the thermostat’s price low.
When we started the project, the hardware had been designed, but a finished PCB circuit board didn’t exist, nor had any code been written. Our first step was to create an iOS simulator that would allow us to start writing firmware for the thermostat. The simulator also allowed us to use state of the art debugging tools from Apple, which greatly reduced development time. We saved so much time using the simulator that we were able to more than recoup the cost of building the simulator. Once the simulator was done, we created a simple web-based (REST) interface on the thermostat that would allow us to provision the Wi-Fi chip. After that was done, we started work on the consumer facing apps that allowed customers to setup the thermostat to work on their Wi-Fi networks. We also created an installer app that allowed the installer to customize the app and the firmware so that they contained the installer's information, and looked like they were manufactured by the installer himself. The thermostat could even message the installer when things went wrong or service was required. Installers could thus have a continual revenue stream after initial sale of the product.
These apps allow the customer to connect the thermostat to their WiFi network, and control the thermostat remotely via their cell phone.
The installer can configure settings for the thermostat and customize the thermostat to show their contact information.They can also configure the thermostat to notify them if a problem occurs or service is needed.
A virtual platform that exactly replicated the thermostat’s hardware in software, and allowed use to start development before the hardware had been completed. We could also use advanced debugging tools from Apple to speed up testing.
We travelled to Shenzhen, China to create a firmware burning tool for the factory that manufactured the hardware. This tool was written in Chinese, and allowed factory workers to upload firmware to the thermostats without any technical training.
The most difficult aspect of this project was the hardware. In order to keep prices low we needed to use hardware that was inexpensive and not very user friendly. The debugging tools that came with the hardware would often return incorrect information, which made development harder. Also, the multitasking of the hardware didn’t function well at first. We worked hard, and were able to overcome these challenges, ultimately saving the client millions of dollars in hardware costs down the line.
The project took one year in duration with a total of 2 software engineers working full time. Approximately 1/4 of the man hours were dedicated to the apps, with 1/8th of the total cost for the Android app, and 1/8th of the total cost for the iOS app.
Our work on the simulator and the firmware blew the customer away. After the initial demonstration, the client’s main engineer said “This is why we should hire software engineers to do this work!” Their office personnel even asked if they could have a version of the iOS simulator to show their clients.
Although the app is stable, there are a few important lessons that should be learned from this project. First, this app is a hybrid application (native and web apps together), but this should be avoided at all costs! Web apps can be very costly to troubleshoot, run slowly, and have a significant impact on revenue as the result of a negative customer experience. We strongly recommend that our clients pursue 100% native applications as they run faster, are more stable, and lead to greater customer satisfaction.
The second lesson is that it is important to have a thorough testing cycle before releasing hardware. Allocating enough time for testing while trying to meeting an aggressive release schedule is inherently difficult, but testing is a necessity. You don't want your customers to be your beta testers. A professional test team can find many bugs before your customers have to suffer, and you earn a bad reputation for buggy software.
The third lesson is that cost savings on low level hardware can lead to significant profits as production volume goes up. Development costs associated with this economical hardware can be high, but with volume, it is almost always worth doing. It is important, however, to have accurate sales forecasts to help decide on an architecture that will save the company the most money overall.
This was a full featured banking app that allowed one to check their balance, send money to a friend, send money via PayPal, do a remote check deposit, transfer funds, and find a branch. It had to interface with existing banking servers, and we developed a server API to connectwith the app.
When we started working on this project, it was at version 2.0. One of the first new features that we worked on was the ability to do remote check deposit. This included adding image processing libraries and API’s that connected to the processing center. We also added the ability to send money to friends and family via PayPal from within the app, and experimented with other features like instant car loans and new member signup. These last two features never made it into the final app, but they gave the banks interesting ideas for ways they could bring in new customers.
This particular company liked to experiment with new ideas all the time. We were always creating new versions of this app to see what customers liked. Although these features did not always end up in the final product, it was a great way to advertise to the outside world that we were an innovative company that was pushing the bounds of banking.
This project took 6 developers 2 years to complete.
The OCR processing engine was very math and memory intensive. It required so much memory that much of the rest of the app had to be rewritten in order to bring the memory foot print down so that the app would not be shut down by the OS.
Another issue we faced was that we were required to interface with Microsoft’s proprietary XML format. This eventually led us to write our own XML parser that would properly parse the XML we got back from the server. We were able to parse the data in as little as 20 milliseconds.
Our client ultimately became the largest banking app manufacturer in the world.
It is important to note that the banking sector is one of the strictest and most security focused industries in existence. We have worked on code that is used in over 30 different banking applications by a number of different banks throughout the world. Earning their trust was a long process, but paid off in the end. If they can trust us to develop secure apps that control their finances, you should rest assured that you too are in good hands when you work with us.
Immersion owns many patents associated with haptic technology. Their goal for this app was to produce something that would highlight how haptic technology improves our lives. Conference attendees would make a selection on a large screen to experience one of the many ways in which haptic technology can be used. The screen would then walk the user through putting on a haptic watch before showing them a movie. The watch’s haptic feedback would then bring the user into the movie in a dramatic way, and encourage other vendors to include haptic feedback in their projects.
We had a haptic player that had been used in a previous project, and Immersion gave us many files containing haptic data streams that had to be synced with the movies. The client also provided us with detailed Photoshop design files, as well as movies of exactly what the app should look like and how it should function.The documentation was extensive, which greatly helped speed up development.
The project had to be done in one month, which for most apps would be impossible, but given the level of documentation that the client provided, and the fact that none of the requirements changed after day one, we were able to finish in time.
This was very different from most of our other projects in that the client knew EXACTLY what they wanted, and what every image should look like. Many companies spend lots of money going back and forth on what they want, making changes, and having us redo things. Having everything decided before starting development is a great way to reduce costs.
This was an android app designed specifically to run on the Samsung Note 3, and included:
We had three challenges with this project. The first was time. We only had four weeks to complete this project, which is a very tight deadline for even a simple app, and meant we had to work through Christmas. The second issue had to do with the 2.4 Ghz noise from all the electronic devices on the conference room floor, which would prevent us from streaming real time haptic feedback. We pre-buffered much of the haptic feedback to the watch early in the demonstration, which fixed the real time streaming issues, but led to our third challenge. Because the data was being pre streamed, we had to do lots of extra work to make sure the video buffer and the haptic feedback buffer where staying in sync throughout the demonstration.
This project took 2 developers (each working 70 hours / week) a total of 5 weeks to complete. The project only supported one mobile device (the Samsung Note 3) which helped reduced development time. The entire budget went towards this one device. About half of the money was spent on Bluetooth data transfer and synchronization.
The client was very happy that we were able to get the project done with a week of their goal (4 weeks). The extra week was spent polishing up the app.
This is an app that that helps people study the bible. It is theequivalent of carrying a Study Bible, a Strong's concordance, a couple interlinears, a notebook to write your thoughts, and a study guide. Unlike most Greek texts, this app will allow the user to simply touch a Greek word to get the definition, grammar, and cross references. Some of the features of this app:
When we began working on this app, it was nothing more than an idea. At the time, the original iPad had just come out, and this type of app didn’t exist. We had to design the app from scratch, find the databases, transform / optimize the databases, cross reference everything, add features, and port the app so that it ran on iPhone / iPad / Android.
This application is stuffed to the gills with data, tons and tons of data. Many months were spent transforming the databases to optimize size and performance. The first iPad was not very fast, and disk access was especially slow. In the first version of the app, displaying a single page of Greek and English text took 91 seconds. After a month of optimizing the database and disk access routines, we were able to drop the time down to less than 0.1 seconds. Here are all of the databases that are in the system:
We had to design special programs that ran on the PC to optimize the data. These programs took over a month of processing to finish optimizing the data. In all, the databases add up to 500 megabytes of data.
We can’t believe how many end users have written us letters thanking us for such an amazing app. One magazine article was written about the app, and one class in England used the software to teach a course on biblical studies in the modern world.