OpenRemote Blog Atom Feed

KNX Video Contest

2012-02-01T19:40:28Z

News Item added by Juha Lindfors

KNX Video Contest

Mathieu Gallissot and team have submitted their "KNX social bar" video to KNX contest.

This is not your usual KNX demo but shows KNX used in some new and imaginative scenarios. They've also got a nice OpenRemote user interface included in the demo.

If you like KNX and like the video, please help and submit your vote.

http://contest.knx.org/en/videos/view/theonlylimitisyourimagination

View Online

Russound and KNX with Rule Integration

2012-01-31T07:32:41Z

News Item edited by Juha Lindfors

Russound and KNX with Rule Integration

In the previous month's video (if you missed it watch it here), Marcus Redeker showed an integration of OpenRemote, iPhone/Android UI, Russound and KNX. He created an iPhone interface to control audio output from Russound controller and integrated it with a touch interface on iPhone and also with physical KNX switches with OpenRemote controller rules.

This second part of the video shows how the iPhone UI panel was constructed with OpenRemote Designer. It also demonstrates the new Russound Import Wizard which automatically creates commands, sensors, sliders and audio zones. Finally the new rules feature is demonstrated with a rule editor in the OpenRemote Designer.

See the 'OpenRemote Russound Integration' video for Part 1 with live system in action. In this Part 2 you will learn how to use OpenRemote tools to create a similar system yourself.

The new features in this video will be available in the next update of the OpenRemote Designer online, scheduled for February 2012. Enjoy!

Lower Knowledge Acquisition Costs in Home Automation

Today, building a home automation system is riddled with barriers-to-entry by proprietary vendors. The software and protocols are closed, training and information is shared only with authorized dealers and integrator network.

This leaves market control to those willing to invest in the knowledge acquisition – and investment that usually requires a dedicated dealership and client-base development with which to earn back the initial investment. This results in higher prices that makes automated homes too expensive for too many households.

OpenRemote Inc's philosophy to automation is to approach it with open standards and open systems. Not only is the software free (and you're free to install it on any off-the-shelf hardware that meets the system requirements) but it also enables a lower knowledge acquisition costs to those who are interested in automating their homes themselves. The investment required is your time. The knowledge is free for you to use as you see fit.

To help realize this vision of an open standard to automation, we will attempt to develop further videos, tutorials, how-to documents and other documentation to enable anyone – whether a professional installer or DIY user – to invest their time to learn how to create automation installations with OpenRemote. You may only be interested in automating your own home, or you may be interested in becoming a professional installer, the choice is yours.

This work is just a beginning. Watch this space for more to come.

And for those interested in some help with the learning process, OpenRemote Inc. can offer you training services. Please contact sales@openremote.org for more information.

Enjoy!

View Online

OpenRemote at FOSDEM, February 4-5 2012

2012-01-25T17:48:46Z

News Item added by Juha Lindfors

OpenRemote at FOSDEM

February 4-5, 2012
Brussels Belgium

Eric Bariaux will be presenting OpenRemote at the upcoming Free and Open Source Software Developer's European Meeting (FOSDEM) this coming February, the weekend of 4th and 5th, held in Brussels, Belgium.

If you're planning to attend, do come by and say hello!

Talk description:

"After a quick business introduction, covering the business model, the raison d'etre for a standards based, open source platform in the crowded field of home automation, this presentation will address: - the global architecture of the OpenRemote ecosystem and its components - a detail presentation of each components, their role and the technologies used - a short video of the great applications the community has used OpenRemote for - a technical walk-through of the how to implement a new protocol - the OpenRemote community"

More information about the FOSDEM conference: http://www.fosdem.org/2012/schedule/event/openremote

View Online

OpenRemote Russound Integration

2011-12-03T08:33:04Z

News Item edited by Juha Lindfors

OpenRemote Russound Integration

Marcus Redeker is back with another video that demonstrates OpenRemote integration with Russound multi-room audio system.

The iPhone touch interface shows multi-room zone control with volume, source, bass and treble controls. Similar user interfaces can be used with iPhone and iPad tablets, Android phones and tablets and from within your PC's web browser. This enables you to use your existing touch devices to control your audio setup without necessarily adding separate keypads for Russound control.

As an added bonus, the video shows integration of Russound touch interface with physical KNX switches. The audio can be controlled both from touch interfaces or physical switches with state synchronization across separate systems.

An Open Integration Platform

With OpenRemote, it is possible to integrate existing automation installations and equipment into a single integrated solution. You can combine your KNX light control with your Russound audio controls into a single touch interface on your smart phone or tablet – or even to existing physical switches as is demonstrated in this video.

OpenRemote establishes a de-facto integration platform for home control and automation in Open Source. We adopt Open Source to create an open, free-to-access, unencumbered platform for vendors to integrate their protocols and smart- home devices to existing automation systems at lower cost. We enable installers to create solutions where all parts of the system are integrated, controlled and automated from a single panel interface. End-users benefit from having a unified control panels which cover all their integrated devices instead of a chaos of unintegrated controls and applications that do not interoperate.

OpenRemote puts you in control – choose the most cost-effective components rather than paying over-inflated prices for a closed, proprietary solution. You can use off-the-shelf hardware and drastically reduce the cost of your installation.

View Online

OpenRemote Z-Wave Demo

2011-11-25T18:31:23Z

News Item edited by Juha Lindfors

OpenRemote Z-Wave Demo

Marcus Redeker put together a video that shows OpenRemote controller with an iPhone user interface controlling Z-Wave enabled hardware – door sensor, light, dimmer and a motion sensor.

The Z-Wave hardware is controlled via an IP-to-ZWave gateway from HomeScenario.

We will be working on more support for Z-Wave USB sticks to add to our existing protocol integrations (KNX, Lutron, ISY-99 Insteon, X10, Z-Wave, GlobalCache, IRTrans, 1-Wire, etc).

The second part of the video shows how the UI was created with OpenRemote Designer.

View Online

OpenRemote at Devoxx -- Nov 17th, Antwerp

2011-10-30T20:27:53Z

News Item edited by Administrator

OpenRemote at Devoxx Conference

Eric Bariaux will be presenting OpenRemote at Devoxx Conference on November 17th in Antwerp, Belgium. If you're planning to attend Devoxx, come by and say hi!

The presentation slot is currently reserved at 16:40 - 17:40 in Room 3.

BIO

Eric is a Java and iOS developer as well as Home Automation and Home Theater specialist, always looking to push the boundaries. As part of the OpenRemote project, he draws on its practical experience in the automation field and knowledge of enterprise technologies to help design a truly open and modern platform that will unite a currently fragmented market and bring it into the "cloud and internet of things" age. In a previous life he has acted as senior developer, architect or project manager for enterprise J2EE projects in the financial, banking and telecommunication sector.

Presenting: Having fun with Java and Home Automation

Devoxx Conf Day 4 Schedule

View Online

Videos from Community

2011-10-30T20:28:36Z

News Item edited by Administrator

Videos from Community

The best thing about working in Open Source is when you get to see what users are able to accomplish with your software. Here Mario Neugaertner demonstrates the OpenRemote user interface he has created for his office space.

It includes control of lights and blinds and open window detection, controllable from iPad. We especially like what Mario did with the customized sliders to represent blinds in the UI. The photo work is also impressive and the UI in general looks fantastic.

Great work Mario and thanks for showing everyone where OpenRemote can go! Looking forward to the updates too

View Online

Google Enters the HA Market -- Android At Home

2011-05-14T22:40:54Z

News Item edited by Juha Lindfors

Google Enters the HA Market – Android@Home

Since writing this entry, little more information has trickled out:

The LED lighting OEM appears to be company called 'Lighting Science' who plan to offer LED light units at around $30 price by end of 2011.
The wireless sensor network protocol appears to be based on 802.15.4 and 6LoWPAN, another piece of good news

Google made an announcement this week at Google I/O conference where at the keynote they demonstrated an Android device controlling the lights of the showroom. This created quite a bit of buzz in the HA field, and we've since received quite a few questions what exactly does Google's move mean?

We've tried to figure it out but things are quite fuzzy still, and lots of detail is missing.

First up was the intent : the big announcements were around media streaming service (Amazon very recently announced the same) and the Android Accessory API (based on Arduino, yay!). That makes sense to Google from strategic point of view and both are directly aimed at Apple.

In that context the whole HA announcement seemed a little bit of a side-show. So we were trying to figure out if Google the advertising company is getting into HA with a real push (serious partnership money required from their part) or whether the demo was more of a "party-trick" to show what could be done with the Android Accessories vs. what Google will put serious weight behind in terms of creating a new market opportunity for them - and for the record, getting a standardized USB API from Android side to dedicated HA extensions would have tons of potential.

The one tidbit that was revealed there was that they are working with some LED lights OEMs to demo light switches by end of 2011. That is the interesting bit to watch. If they do plan on building a serious HA ecosystem around Android, establishing similar relationships they've done with Samsung, HTC, Motorola, Sony Ericsson in the cell phone world would be necessary. Google should be looking for partners in the area of HVAC, Security, multi-media (they've got Google TV, that's a good start), even healthcare to get to a complete residential automation solution. It's a large, extremely fragmented field and a big name like Google pushing for some unification would be very welcome.

So watching whether there's a desire, will (investment) and understanding of the need to build the partnership network is one way of measuring whether this effort will take off or if it will fizzle like a Google Wave.

The second part is the wireless protocol itself that was mentioned. Sounded like could be a new proprietary entrant to the wireless sensor network field because little detail was given. Whether it builds upon 802.15.4, 6LowPAN or anything in that direction would be interesting to know. It can potentially make things more complicated in terms of technology choices if it is a new entry, or it can put some serious weight behind one of the existing WSN options if one has been chosen. Will be very interesting to see what emerges there too.

Getting one clear direction on wireless sensor transport would be very welcome (we like 6LowPAN here).

Whatever the case, and especially if its a new wireless protocol, the approach Google seems to be taking there is to get a vendor buy-in (the previous point about a LED light OEM) - and for a company with the money and brand recognition of Google that does make sense. It does not however remove the reality of how slowly consumer space updates hardware in general (do you want to buy a new TV again?) and residential buildings in particular (your boiler is from what year again?). So in those terms if we think about the HA market as a whole where a fully automated solutions are possible, integration will still be key for long time to come. No details yet on how legacy integrates with the all-new Google HA with from-scratch approach. Yet another key point to watch as the year progresses.

And having said that, if the Google effort will be successful and there's a serious push on this, getting something to emerge long-term as potentially ubiquitous HA stack would be a very big deal.

The other great long-term side-effect of ubiquitous runtime (Android) and protocol (currently unknown) is that it would completely commoditize the controller and transport protocols which would benefit everyone and grow the market place immensely. Focus would then move to building tools for professionals and pro-sumers.

What Does It Mean For OpenRemote

So we were thinking what would an announcement like the above mean for OpenRemote. Mind you there are big caveats here, first with if Google is really serious about HA or if they just wanted to build a party-trick to make Accessory API look cool and second if they've analyzed what it would really mean for them to enter a HA market (they are an advertizing company after all).

Anyway, let's assume Google is serious about it because that is the most exciting scenario

In terms of controller, the runtime would clearly shift towards Android. We've been going back and forth about this a for long time, not really getting to a decision whether go with a full Java SE or go with Android (great for embedded which is where the controller will eventually live).

On a tangent, I'm gonna take a dig at Google here for messing up the Java compatibility issue with Android. They dropped the ball there. Had they stuck with WORA the above would be a non-decision. Now Android is an extra effort. Boo to Google for not living up to Java's WORA promise. Double-boo.

Ok, that out of the way, controller running on Android would become a clear target. The big extra effort there is to port all the cool Java libraries (rule engines, scripting languages, and the such) that we want to use to Android. But once done, an Android controller is easily embedded into very small devices, merged with your panel hardware, hidden away, whatever. One less piece of hardware and one less install to deal with. Goodness.

In terms of the wireless protocol that we know nothing about, it would be an obvious candidate for a back-bone transport protocol that is much, much needed. We've got the IP Ethernet for wired installations but we do need a clear back-bone for the wireless sensors (and WiFi isn't it). At OpenRemote we don't care if that ends up being Z-Wave, Zigbee, 6LoWPan, or something from Google (but we like 6LoWPAN, did I say?) because we are agnostic but having some clarity in the industry of how frames are transported between controllers, sensors and devices would certainly be a big deal. For everyone. More time spent on building what matters and less time spent on twiddling bits trying to map signed and unsigned, big-endian and little-endian, whatever.

Finally, the Android Accessory DevKit will be very very interesting - and the only part that looks more or less concrete right now. Whether its an IR extender to your Android Hardware device, or a wall-mount frame (maybe with some key physical buttons) for your Android tablet it will create a standard eco-system of hardware extensions. This wasn't targeted by Google to HA specifically but it will make a difference in HA and will be a big boon for anybody wanting to build Android-based and Android-integrated HA extensions.

This Will Be Good

Bottom-line: exciting announcement from Google!

Hope they're serious about HA beyond producing a cute party-trick at keynote.
Moving towards a less-fragmented ecosystem with Android as runtime, Android Accessory API and wireless transport would be a huge deal for everybody
Watching and waiting for some serious partner network push here
Using Arduino is awesome!
Getting some installers pulled into this because of Google brand and weight would sure help
OpenRemote will for sure want to participate
At the very minimum the Android Accessory API and using Arduino will help.

What do you think? Please share your thoughts on this forum thread that was started.

Juha

View Online

UIComposer Design for 2.0

2011-05-15T07:22:21Z

News Item edited by Juha Lindfors

We've started the work on designing the next version of the user interface composer. From user functionality and user interface point of view this is going to bring some notable changes to the current 1.x release branch.

Marc described some of the logic driving the changes in his earlier UI composer, next generation post in June. The upcoming changes are mainly driven by the discussions we had last month at our Amsterdam meeting.

Building Modeler vs. UI Designer

To summarize, the user interface of the application is going to change to cater two separate user roles – one for an installer who models the building automation setup and another for a user interface designer who uses this model to create different types of panel and console applications. At times these two roles may be assigned to the same person but it does allow some of the technical details of the installation to be hidden from purely panel UI related work (and vice versa if necessary). A technical end-user for example could be allowed to modify the user interface layout to better suit his or her needs without necessarily exposing them to the technical details of KNX or UPnP protocol configuration used at the building.

Sharing Model Information

In order for the installer, UI designer and end-user to collaborate, we are introducing an account where data can be shared between these users. This account is intended to be used as a private storage of all protocol configuration and device data plus all the user interface layout configuration. Since it is a private account between the collaborating parties, installation specific data such as non-unique KNX addressing may be stored on this account. This ensures all parties involved are in sync with changes to the model and that all parties have equal access to all the model, data, code and UI layouts that belongs into a full home or building automation installation.

Devices and Ease-of-Use

Since the application is logically split between Building Modeler and UI Designer, some additional context is required to pass information that so far was implicit in using the 1.x release UI Composer. We are planning to address this by introducing a "Device" abstraction to the user interface, where both Building Modeler and UI Designer begin from creating/using a device type.

Device naturally associates with the available protocols and commands (available buttons on the UI Designer side). This should help with scaling the user interface to accommodate more protocol implementations – we've already doubled from the expected 3 supported protocols to 6 supported protocols in 1.0 release (thanks to contributions from our community) and are looking to add at least two or three more either in 1.1 or next 2.0 releases. Further, it is the hope to increase the ease-of-use of the user interface by exposing only the available modeled commands in the UI designer interface as opposed to showing all possible protocols and commands that could be modeled for a panel or console.

Easier Integration

Additional goal of the redesign is to allow contributors more easily add their own implementations to the online tool UIs by exposing some UI elements as XML configuration files that can be modified without having to familiarize yourself with the codebase. This should increase the ease-of-use for integration scenarios.

UI Mockups

The following UI mockups illustrate some of the changes mentioned above.

Figure 1: Create a new device in Building Modeler

The application view is logically split to Building Modeler and UI Designer. The views made available are based on user permissions on the account. For example, an end-user logging in with a UI Designer permission would only see how to arrange the UI elements on the preconfigured devices and protocols (created in the Building Modeler).

An installer modeling the house or building configuration would start the work by creating a new device. Device has a logical name, vendor and model. Additional attributes can also be supported for devices (such as device type shown in Figure 1).

Figure 2: Create a new command by inputting the configuration manually or importing from Beehive.

One of the challenges with the existing UI Composer design is the quickly increasing number of protocols and the complexity it adds to the user interface. With the device modeling abstraction shown in the Figure 1, it is natural to add commands and protocols to these specific devices.

Commands can be added in two ways. Either by inputting them directly for cases where there is no shareable data available or looking them up from Beehive database which contains data about devices that can be shared.

For example, creating a KNX command is at the moment a manual process since the addressing is non-unique and specific to each installation. This is also true for many other IP-based protocols that require local IP address or port information, and where discovery is not available. Choosing the protocol type (KNX, X10, etc.) for a command allows these properties to be typed in the dialog.

Where shareable database of device commands are possible, existing command information can be imported from Beehive. Currently this is the case for LIRC infrared data. In that case, all the available commands for a device can be imported directly into the device model.

Figure 3: Working with commands associated to devices.

As the device modeling proceeds, working with macros or creating UI layouts is based on the list of available devices and commands configured for them. On the UI Designer side, a macro will be another command available as a UI widget for the layout. The details of protocols, addresses and protocol commands are hidden when creating or modifying existing panel layouts.

Integration and Contributions

To ease the integration of new protocols into the UI tools, we are externalizing some of the basic UI configuration. For example, a dialog to enter protocol properties could be defined in XML in the following way:

<?xml version="1.0" encoding="UTF-8"?>
<protocol name="KNX">
       <attr name="groupAddress" label="Group Address">
        <validations>
           <allowBlank>false</allowBlank>
            <!-- message is option -->
           <regexp message="group address should be 1.4.1.4">(\d\.){3}\d</regexp>
        </validations>
    </attr>
     <attr name="command" label="KNX Command">
        <validations>
           <<allowBlank>false</allowBlank>
           <maxLength>10</maxLength>
           <regexp>\w*</regexp>
        </validations>
    </attr>
</protocol>



<?xml version="1.0" encoding="UTF-8"?>
<protocol name="X10">
       <attr name="address" label="Address">
        <validations>
           <allowBlank>false</allowBlank>
        </validations>
    </attr>
     <attr name="command" label="Command">
        <validations>
           <allowBlank>false</allowBlank>
           <maxLength>10</maxLength>
           <regexp>\w*</regexp>
        </validations>
    </attr>
</protocol>

There's a large number of details not covered in this quick overview. The most suitable place for further discussion is the Design Forum.

View Online

OpenRemote iKNX Presentation Online

2011-05-15T07:22:21Z

News Item edited by Juha Lindfors

Jörg Falkenberg gave an OpenRemote iKNX presentation last week in Amsterdam. We've made the slides available online.

One of the more frequent questions we get about iKNX is how does it fit with the rest of the OpenRemote product strategy? OpenRemote RI is based around a controller whereas iKNX is a product connecting directly to a KNX gateway. To some this seems like a conflict of product architectures but we don't see it that way.

KNX through iKNX and the OpenRemote Box (ORB) can and do co-exist. OpenRemote iKNX is a client application to an existing KNX installation. It is an easy adoption for users who want to control their existing KNX installation through an iPhone interface. No additional installation is required: no extra boxes, no extra wiring. Assuming you do have an KNX IP gateway set up, you can download the iKNX application from the App Store and you are ready to go! OpenRemote iKNX contains a KNX protocol stack written in Objective-C so it can run "natively" on the iPhone.

The ORB on the other hand is more of a server-side box. It can also act as a client to a KNX IP gateway but due to its nature can easily host functionality that may not make as much sense or is difficult to implement for a pure client device. One example of a KNX-related service that makes sense on the ORB is KNX connection multiplexing. For installations that use a KNX IP gateway, rather than a KNX IP router, the number of available connections tends to be very limited. When you start adding KNX IP client devices (multiple iKNX iPhone clients for example) to such an installation this can quickly become an issue. The ORB can alleviate this by implementing a KNX connection multiplexing or limiting the lifetime of persistent KNX connections. This will make larger installations more manageable.

Another example of a KNX-related service on the ORB is the ability to integrate other protocols to KNX events. For example, an event from KNX bus could trigger an infrared signal to A/V setup or translate the incoming event to a device-specific serial port communication protocol. Or perhaps you also have devices that are managed using a different protocol, 802.15.4 wirelessly, X10 devices or something using Insteon. These devices can be integrated with ORB to act and coordinate with a KNX installation, something that would be much harder to create directly through a pure client device.

So there's a natural synergy between iKNX and KNX services in the ORB, depending on what type of functionality you are looking for and whether that functionality fits more naturally to client or server-side layers of an application. OpenRemote iKNX makes it very easy to adopt an existing OpenRemote product (and ultimately the ability to adopt an open OpenRemote platform is what we offer, regardless of the form or type of installation you have) whereas KNX on the ORB will serve as a server-side host for integration, connection management and other tasks that benefit from data centralization.

(click for a PDF of the presentation)

View Online