What is HotForestGreen?
HotForestGreen is an “internet of things” developer framework.
It can be used to create things like Automated Homes, Smart spaces and Real Time Collaboration Software.
It is created with several purposes in mind, including:
- To reduce the threshold to build Smart Spaces, Distributed Applications and “Internet of Things” things – By making and keeping it as simple as possible.
- To run on low budget, low power machines – Like 150 euro Android phones, 100 euro Android Tablets and 200 euro Netbooks (prices based on price levels of August 1, 2011)
- To serve both tinkerers and professionals – By offering a system that offers you all the things for your basic needs and that can be scaled up to multiple Servers on multiple systems over multiple networks, using load balancing and automated processes to re-wire communication when Servers drop out.
Frozen since 2010 by lack of funding.
What is the main idea?
Read this blogpost for a more elaborate description.
Hardware is becoming a commodity. More and more devices and systems are becoming “smart” and connected. To operate these devices from any and all device (laptops, tablets, phones) is only the next logical step.
From single devices, interaction will expand to “smart spaces” and “smart cities”.
There are two main challenges in this new field:
- Distribution, connection, communication and unification – How do you connect all these elements that should form one single system (like a smart house)? How do you make them work together, communicate, interact?
- User Access and User Interaction – How do you make access to these systems simple, safe, protected? How do you avoid specialized applications? Instead: how can you make one app that provide access to all and everything?
To keep it simple:
- Open and open source protocols – To keep things simple, the protocols itself are open source: from the server to the messages sent to clients, to the way you connect to services.
- Standard technologies– HotForestGreen uses standard technologies: Sockets, HTTP. You can build servers and clients in Java, C# and any other possible language using standard libraries.
- Proxies and mediators – When you connect a device to the “internet of things” it probably offers a hardware specific interface, which requires hardware specific addressing. Instead HotForestGreen counts on a software based “man in the middle” in the shape of a Proxy or Mediator. This Proxy or Mediator standardizes the communication between the (hardware)device and the rest of the world. The idea is that it should not matter HOW something is build or what specific (hardware)solutions are used. The only thing that matters is what you can do with that end-device.
How does it work client side?
- Discovery – You run one app: to discover services. This can be based on any wireless protocol or visual marker. Services can also be advertised (“connect to OurServiceWiFi and find all the riches!”)
- Listing/overview – One specific location can contain many services. (See also “service-spam”, to be written later). Listing can be based on provider (WiFi, Bluetooth and other nodes) and services per provider.
- Connection – You connect to the service, which is ideally run and hosted by the provider itself.
- Use – Once connected, you use the service, which can run from selecting and ordering a meal in a restaurant, to manipulating lighting and temperature in a room.
Within the prototypes I wrote, HTTP based services are the starting point. Here is how they work:
- Connect – You connect to a Service (after discovery and selection)
- URL – The service-provider sends a hyperlink to the client
- Loading the interface – The interface can be anything, from an HTML page to Flash (unfortunately not a good strategy anymore due to dropping support on mobile devices) to a HTML-like page rendered by the app itself
- Interaction – You interact with the services.
How does it work server side?
- Provide the hardware – You provide the hardware, which can be simple sensors or complex “smart” devices
- Provide a proxy or mediator – The proxy/mediator is a piece of hardware “standardizing” and abstracting the communication with and from the device. For instance, a RGB color lamp can be addressed with a simple instruction: “color=#FFFF00;brightness=50%”.
- Connect the proxy/mediator as Client – To a (HotForestGreen) Server. The proxy/mediator will be registered as a device: listening to specific events, which can be very specific and 1 to 1. Like: “eventname=Door231” where only the event “Door231” will lead to a response by door 231.
- Run the server – The server works mainly as a distribution point of events between Clients. “Door 231” can send events to specific devices and listeners, for instance: “Light 55”.
- Send messages – Each Client is capable of sending messages. These messages use the “publish/subscribe” model which is a specific variation of the Observer Pattern. Each Client subscribes to specific events which can be generic and specifically bound to that one Client. When a message with a specific tag is sent/published, the Server will distribute it to all subscribers. Each subscriber than can “read” the message and do whatever it wants with it.
What can be connected?
- Objects and devices – Think of lights, doors, locks, heating, machines. Whatever the use case might be and require.
- Databases and data sources – Messages can contain pure data. For logging, but also from real-time Distributed Applications. Think here of any system where multiple people with different roles are working on the same data source, at the same time.
- Applications, sub-systems and (data) objects – One of the simplest examples of real-time/distributed systems are chat-clients. But what if this real-time “chat” concerns (data) objects? From name/address/phone number objects to more complex things like characters in a game.
Setup of the client
The client has the following parts:
- Discovery module – This scans the environment for services and service providers. This can be based on a WiFi network you are connected to, bluetooth services or visual markers.
- Selection module – Out of all possible services, you are presented a list, as offered and organized by the provider
- Web browser – Once you select a service, the application simply launches the URL connected to that service. This URL might lead to a local server or a Server somewhere online. From that point on, the app simply displays whatever the remote service wants to offer.
This way, localized services do not need service-specific apps installed on the user’s machine. Instead they can be created using open, generic and transparent technologies allowing for effortless access. In short: you enter a space, select a service, start working with it.
When did the project start?
Why am I developing this?
There are three reasons:
- Simplest, best, kick ass – I want to be able to use the simplest possible and the best, lightweight, high performance, kick-ass framework to build small, large and scalable distributed systems.
- Dead simple to build complex, scalable stuff – I want to make it dead simple to build those complex, small, large and scalable distributed systems.
- What I need is not there yet – And that is why I started building HotForestGreen.
How does it help you?
- Off the shelf solutions for you basic needs – HotForestGreen makes things easier by providing a set of “off the shelf” solutions to:
- Distributed Systems – Create small- and large scale Distributed Systems using local networks and the internet
- Data – Retrieve and store data (on remote locations)
- Remote Objects – Send and update Remote Objects within Application Clusters
- WebSockets – Use HTML 5 or just the WebSocket Protocol to communicate to devices
- Simple Webserver – Allow you to serve web pages and Flash Content – for instance to offer a Web Based Remote Control to your users – via a built in Simple WebServer.
- Multiple Servers/Load Balancing/Redundancy – Support an “unlimited” number of Servers to balance the workload (especially handy when using less powerful Servers) and add redundancy to backup and deal with drop outs when a Server crashes
- Multiple devices – Work on and with multiple devices, including Netbooks, Android phones and Android tablets
- Multiple layers of security – Protect the data and the system from hijacking by Trusted Relationships via Shared Keys and the use of encrypted data streams via Secured Socket Layers.
- Open source and free for non-commercial use – So you can use the code base, add your own stuff if you are not happy with my work, and expand on it and use it to play and freely experiment with to your hearts delight.
- Multiple platforms– So you can build it in the language you choose. Currently I am developing the framework in:
- C# – For Windows based solutions
- Java – To run on Android, Linux and Mac OS
- Flash – For Web Based user interfaces and that extra bit of eye candy
What is it for?
- Distributed systems– Are systems with two or more “smart parts” working together. Think of:
- Automated homes – Where rooms are governed by individual systems like a Netbook or an ARM-based device or
- Distributed applications – Where people work together on the same things or the same data from different locations and different machines, updating and adding to each others work
- Smart Spaces – Which are houses, rooms and locations able to interact with the people and events happening within the range of their sensors.
- “Internet of things”– Based on smart objects which communicate to each other and respond to specific signals including:
- Sensors – Including RFID, heat, movement, pressure and states of doors and windows (open/ closed)
- Devices – Including stuff that opens and closes doors, changes lighting and temperature, display information and wakes you up in the morning
- Storage – To retain information.
- RAD / Agile software development – To build stuff quickly, when you need real time (distributed) systems, data from databases and send data from one place to another
- Tinkering – You can build small projects and play with Real Time systems with very little effort,
- Heavy duty stuff – Utilizing the full spectrum of Clustering, Load Balancing, SSL/encrypted connections and fall back scenarios when Servers drop out or crash.
What will it run on?
- Wintel, Linux and Mac – The three main Operating Systems
- Android – For phones, tablets and low budget ARM based computers
How much does it need?
- Light weight/low cost ARM devices – HotForestGreen is developed to run as a full Server on low cost, low memory ARM bases devices like the Archos/Arnova 100 euro tablets and the 25 USD Raspberry Pi computer.
- Netbooks – For more heavy work while still keeping budgets limited, you can use 200 euro Netbooks
- Limited to no additional installs needed – HotForestGreen is developed to run completely out of the box. While it will need the Java Virtual Machine and .NET 3.0 or higher, you do not need to install extra software to make the Client or Server run.
What is the current status?
Why am I not working on this awesomeness now!?
Several reasons. First is: I have a sabattical until end of 2012.
I am writing and finishing a series of near-future SF stories you can find documented here.
I also lack the kind of feedback that stimulates me to make it a top-priority.
When will it be released as Open Source?
What will be released?
- Unknown date– First release, demos
- A C# based Libary for you to use and build on– containing:
- A HotForestGreen Socket Server – Supporting Sockets, WebSockets, and HTTP requests
- A HotForestGreen Client – Using Sockets and working with Remote Objects
- A Transparent Data Access Layer solution – Allowing you to access and alter data in one or more databases without the need of writing any additional code
- A basic user authentication system – To support solutions requiring user logins
- Several security layers – Including SSL connections, implementation of several Trust Levels and Secured and Hidden SandBoxes
- Base classes to connect to SandBoxes and create Remote Objects – Allowing you to build Real Time HotForestGreen applications with a minimum of coding required
- Precooked event models – To deal with updates in Remote Objects
- Several demos– including:
- Synchronized Screen Color Demo – Simultaneously changing the color of screens on all machines to the color selected on any of each.
- Synchronized Browsers Demo – Browsing and scrolling on any and all browsers on any and all connected computers, leading to all others to follow
- A C# based Libary for you to use and build on– containing:
- October 1, 2011– Java and Flash release, Remote Proxies for Arduino and XBee, more demos
- A Java Based library– mirroring the exact same parts as the C# library, for:
- Android – Using the Android SDK
- Windows, Mac OSX and Linux – Allowing for a broader implementation, including ARM based machines
- A Flash based library – Containing only the HotForestGreen Client
- Remote Proxies for Arduino and XBee – To make DIY electronics and sensoring easier, we will provide Remote Proxies and local Drivers for Arduino and XBee that will allow you to get started immediately and read and set data simultaniously from any place, application and device you choose – as if you are directly speaking with the devices itself.
- More demos– including:
- The Smart Home – Using electronics and sensors to register open and closed doors and windows, switch lights on and off and to register temperature, light and movement.
- A Java Based library– mirroring the exact same parts as the C# library, for:
Who is HotForestGreen?
HotForestGreen is currently Peter Kaptein.
Hopefully this team will grow as the project evolves.
Will it remain to be called HotForestGreen?
I do not know yet. For now it is the working title.
What can you contribute?
Once the libraries are Open Sourced in Public Domain you can create your own variations on the Client / Server technology in the language and/or platform of your choice: Python, PhP, C++, Objective C, Cocoa, iPhone, iPad, Windows Phones and whatever else there is.
The more choice there is in the what, how and by whom, the better.