On 24th April, we gave our group presentation along with the other groups. We spent a long time the day before preparing and ensuring that our demo would work. The light sensor we were using in our demo decided it didn’t want to work but luckily we got it working on the morning of the presentation. We went through a few quick PowerPoint slides before moving onto our live demo.
We were able to load up the UI and show some switching between states. We then showed that the UI was accessible across multiple devices by turning on a radio (controlled by WeMo) from one of the mobile apps and demonstrating that the status of the radio updated on the main screen. Finally, we set up a simple rule with the ECA and made our bulb turn on when we turned o…Read more >
Slightly delayed post for the last new feature I added to the project due to exams and writing up the final report.
I wanted to give users the option to upload a number of plugins that could access the various items in the house and provide new functionality. Users can upload a plugin as a zip file and it will appear in a list of plugins to load. The system loads any classes that extend the Plugin class which provides methods such as setup() and teardown().
For now, a few sample plugins are provided; one that shows the weather and another that acts as an interactive whiteboard between users in the same house. They both simply load other websites in iframes to demonstrate the concept but if they wanted, they would be able to interact with the…Read more >
Over the last 2 weeks I have been working on interacting with the LightwaveRF hardware and creating a middle layer for our system.
Initially I used what I could gather from the internet for the API since it is not open. This allowed me to interact with the hardware well enough but I came across the problem of not being able to get the state of the hardware which is a problem when a user changes the state manually (e.g. turning a light off at the wall). Because of this I applied for API access but unfortunately when the official documentation came through it turned out there was nothing new and there is no way to get the state like this.
My next thought was to “force” the state to be correct by sending a command for that state each time the s…Read more >
Continuing on from last week I started this week with trying to get the WiFi working with Gadgeteer. A shout out to the Occupancy OS group (http://occupancy2013.wordpress.com/) who gave me a hand with getting this working. It turns out that the code is slightly different from the code over at http://wiki.tinyclr.com/index.php?title=WiFi_RS21_Module which I was previously trying to use.
So with Gadgeteer now on the WiFi I worked on getting together some modules to interact with our system. Now I’m aware that I’ve moaned a fair bit in the past about Gadgeteer on this blog but today’s blog is going to be a welcome change and I’ve had a good week with it.
After working with the Arduino for the previous week I can really see the appeal of the Gad…Read more >
This week I revisited parts of the ECA backend since Li was designing the UI for it. There were several small changes that needed to be done to make for better interaction between the two which mostly concerned what data the API provided. I also made methods for changing events, conditions and actions.
There was continued discussion about how clear the ECA system is. Currently it is not that clear to some people who have looked at the code what the difference is between an event and a condition. In addition to this we are all in agreement that our current way of handling the scope of a rule (eg. Is it per item/room/house?) is not good. Unfortunately, we can’t think of a better way to do it so it will have to stay as it is for now. It’s defi…Read more >