This page last changed on Apr 25, 2009 by crosen.

Building on a thread launched by Dan C, I thought many might enjoy hearing directly from the current OR team on how their vision and roadmap are shaping up across various dimensions:

  1. Fnctional scope: what is the extent of the features and functions you wish to address?  how much of the target is DIY vs. Pro?
  2. Fxonomy/schema: to what extent is there or will there be published OR' notions of the entitites within the problem space?
  3. Achitechture: how do you see the core components being organized and with what responsibililtes (i.e. separation of concerns) to realize the functional scope?
  4. What is foreseen as the major opportunities and issues that need to be addressed for this project to gain broad adoption
  5. Are there any elements of a current control protocol (i.e. zigbee, z-wave, insteon, upb, radioRA) that you like and would like to  embrace/mimic/absorb with OR - or that you find to be particularly off the mark?  Thoughts on Zigbee's public application profiles for HC, for example?

Well, I'll leave it at for now - hopefully other smart people will jump on and we'll get a nice mixed set of perspectives coming at this.

Thanks,

Cliff











First, understand that I'm not the chief architect of the project. I'm going from a general understanding of what's going on. So basically this is my opinion.

> 1. Fnctional scope: what is the extent of the features and functions you wish to address? how much of the target is DIY vs. Pro?

Both! This is where life in general gets complicated but the project doesn't. Once everything gets established we'll have a general set of APIs that will allow anyone to add their favorite protocol (KNX, X10, Insteon, Twitter, Facebook, <your favorite protocol here>). The nature of open source lends itself towards the DIY crowd but if the tools are correct the Pro crowd will have no trouble using it also. You see this in things Apache and JBoss.

One thing I'd like to make clear is that there will be no limit on the project on what you can do. The limits will be that of your imagination and your programming abilities.  My goals have nothing to do with KNX because I can't get it in the US. But I am looking at adding a module to support the things I have such as the Elk M1, X10, Insteon ZWave, my weather stations, my IP cameras and few other things I intend to build (custom hardware). Another gentleman is interested in the HAI Omni system and UPB. I'm also interested in a scripting language in Groovy, interfaces to the US National Weather Service, Twitter, Facebook and a bunch of Google stuff. Oh and I might try out some of this IR stuff.

> 2. Fxonomy/schema: to what extent is there or will there be published OR' notions of the entitites within the problem space?

Fxonomy?

One of the positive points in this project is that it is open source. Once we start getting software to use, such as the modules, the community will get involved. Then the discussion will begin. My opinion is that documentation will be generated from there.

> 3. Achitechture: how do you see the core components being organized and with what responsibililtes (i.e. separation of concerns) to realize the functional scope?

My understanding is that JBoss will be at the core. It has many features that we need and it's well supported. Yes I've been influenced by some of it's founders but I accept their recommendations readily.

Here's the overview of OpenRemote- I'd really like to ammend the picture to add an 'Information' bubble on the left and '<your favorite protocol>' bubble on the right. Then I would think that would cover all the bases (Lighting and HVAC falls under Comfort in my definition).

> 4. What is foreseen as the major opportunities and issues that need to be addressed for this project to gain broad adoption

The largest major oppertunity/issue we will address with this project is that OpenRemote will be the glue between competing protocols. If a user has X10 and wants to jump to Lutron. We want to be in the middle of that. This way the customer doesn't have to dump one for the other or have two seperate systems. It allows them a safer upgrade path. In some cases it keeps them from throwing away perfectly acceptable solutions while still moving forward with more modern solutions. It also allows newer software technology and techniques to be used without disposing of older technology.

At first I was puzzled by the iPhone/iTouch stuff as it's only a small part of my view of home automation (comfort, security, entertainment, communications, and information processing). Once a 'standard' module is established (I think Marcus Redeker just made a little progress on that front today) adding more modules will follow. I think the scripting language and it's tools will be a pretty important module too but that's not the limit of the issues.

One issue that the HA industry has right now is the high price of some of these systems. I think we can have an effect on that pricing and help bring in more consumer products. Lets face the world is looking to go green. A home automaton system is the central point of managing your resources. By having flexible, managable, expandable software at the center of the home automation is reall what makes the hardware work.

> 5. Are there any elements of a current control protocol (i.e. zigbee, z-wave, insteon, upb, radioRA) that you like and would like to embrace/mimic/absorb with OR - or that you find to be particularly off the mark? Thoughts on Zigbee's public application profiles for HC, for example?

I want them all!

I have a bit of a wait and see attitude. Unfortunately I'm not well versed as a software developer but I'm making efforts to fix that. I have ideas in my head and I'm not sure how to implement them. The one thing I do know is that I can't do them alone and this is the team I've decided I want to work with. I have quite a few quick hacks to solve various problems and I've gone the bubble gum and baling wire route for too long. I need something a bit more professional and I intend to help make this that project (of course I'm not the only one).

I'm going to have to sit down and put all my ideas into a notebook (I need to draw) then organize them then maybe this rabling post will make sense.

Posted by linuxha at Apr 27, 2009 04:28

Thanks for the detailed reply.  I'm sure I join a growing list of those who are eager and optimistic about this project.

Concerning items 1, 2 and 3 (and, btw, 2 should have been "Taxonomy" and not "Fxonomy" - sorry about that) I greatly look forward to gaining more insight as sample code and documentation become available.  Like I'm sure many you've heard from, there are a number of functional and technical elements that I'm frustrated with in current solutions that I'm hopeful to see addressed in this project.  Here are a few things I'm keen to see in various areas:

Front-end Features and Architecture

1. Clean separation between front end/UI device logic and central control logic.

2. Native and fully customizable iPhone/iPod Touch front end support (yes - I know you're on this!)

3. Elegant mechanism for implementing asynchronous callbacks from the control server (i.e. ORB) to a front end device (i.e. panel software.)  Example use case: alert message pops up on panel in response to a device changing state.

Device Management

1. Declarative configuration of devices that decouples a logical device from the physical path to reach it.  Example: if I move my A/V receiver from IR blaster box X to IR blaster box Y, I should need to update the system only once as a configuration matter, and not anywhere as a programming matter.

2. Declarative configuration of devices that decouples a logical device from the protocol used to reach it.  Example: a dimmer is a dimmer is a dimmer, whether controlled by Insteon, Z-wave, UPB, Z-wave, etc.  (I know this introduces a least common denominator issue - good luck with that!)

3. A well organized device driver ecosystem including device discovery and driver management.  (Go Beehive!)

Rules and Logic

1. Better global visibility and management of system rules/events/triggers/logic.  Current solutions require looking in too many places to fully round up system behavior, which is not only a time waster but makes it more difficult to maintain a clean, reliable set of logic that behaves as intended.

2. Elegant and natural scripting framework that avoids these kludgy proprietary language constructs (seems you're on this one, too!)

Operational Considerations

1. Low latency event handling.  The use of polling rather than true interrupt driven event handling adds small delays at various points in the execution chain, and these small delays add up.

2. Elegant and robust process command and control, monitoring, logging, etc.  (I expect OR will have no trouble with this given the founder backgrounds.)

I see from the content you referenced that a number of these items are well on their way.  I also recognize that all this takes time, and that my specific wants and wishes may not all be consistent with what best serves the industry.

Again, I look forward to seeing where things go as well as what I can learn from the project and where I can contribute.

Cliff

Posted by crosen at Apr 28, 2009 04:51

Hi Cliff,

Thanks for taking the time to write down your notes. It's an excellent list of considerations. I think we are in agreement with a lot of them. But as you also recognize, it will take some time to get there. We will get there.

Feel free to add more details to your list if so inclined. Also, it is such a good start of a document I really think ought to go in as a full wiki page on the site.

Best regards,

– Juha

Posted by juha at Apr 28, 2009 11:09

First pardon the 'diarrhea of the keyboard', I've been thinking about Home Automation for at least 31 years and I'm finally seeing a project that will fulfill many of those ideas! Second, these are my opinions and do not necessarily reflect reality (reallity, what a concept! ).

Front-end Features and Architecture

I think others have this pretty well covered. My GUI skills are weak so I'm going to try and stay out of this, otherwise we'll end up with a command line solution.

Juha, someone gave me the good news that I can get to the CLI on the iTouch (yeah!).

Device Management

Device configuration will be interesting but I think that's up to the module to handle the addressing issues. If I move my blaster from x to y the module will need to know where it is. OR can remove itself from the details as it's just an object or a group of objecst to communicate with. That's an issue we'll tackle as we further develop the technology.

As for declarative config, I'm thinking we're going to need a layered model for this. You are correct a dimmer is a dimmer ... but there are unique features that the end user may wish to use. Such as the ramp rate (Insteon has it, X10 doesn't, I suspect ZWave and UPB have this too). There needs to be a way for the user to tune this. But in scripting the code could look like this:

 LRLamp.dim(10) // dim to 10% 

At this point, as a user, I could care less if it's X10, Insteon, ZigBee or a kerosene lamp controlled by a squirrel. I just want it to dim to 10% of the light level (or there abouts).

Rules and Logic

This is a very difficult area to tackle. It's the glue that binds everything else together (other than the JBoss core). This will be attached in stages just like everything else. Since it's a module it'll make development a little easier. You'll probably be able to run more than one at the same time.

My background on this comes from Misterhouse and Perl. One nice thing about Perl is CPAN. This makes creating scripts easier. Take the Elk M1 HA interface module used with Misterhouse, someone wrote a module that uses the ethernet interface to communicate with the Elk. I didn't have the ethernet but just the serial interface. Both used the same protocol to communicate. So I took the Perl ELK module and overloaded the open to take to the serial port instead of a socket. I think that was 25 lines (and a couple of other modules). I want this kind of library support for OR.

One thing I don't like about Perl is it's syntax. Teaching someone Perl to accomplish some macros is not easy. Yet a few developers did write object oriented Perl code which made using the modules much easier. Hence you see code like above. I'm hoping that Groovy's overload abilities (like overloading '+') will simplify some of that for most of the users. At least that's the general idea.

Operational Considerations

I didn't know about JBoss before this project but I like what I'm reading. I'm just hoping I can translate this into producible code. Like I've said before, my wife hates when things don't work. They get junked if they don't work. And shutting things down to reboot is a big no-no. She doesn't care that it'll be back up in 5 minutes. Right now the X10 modules in my home are causing me fits! I'll replace them with Insteon this summer. The one standard she has is it had better work and now. I'm beginning to think I have to schedule change control calls and schedule outages weeks in advance and I'm really tired of that. What I want (beside plain old World Domination) is a system (hardware and software) that runs 7x24 and you can swap out any part and it keeps running. The technology isn't there yet but I think we will see it in the next few decades. We're starting to see it in Cicso routers (IOS and hardware).

And yes, I think that far in advance. I know what I want, I just wish I had the patience to wait for it ... but I do't so there!

Posted by linuxha at Apr 28, 2009 15:50

Juha - thanks for the note.  A wiki page with design goals and considerations and the like sounds like a great idea and I would surely enjoy helping contribute to it.  It would be great to track which considerations are specific goals of the project, which are specifically NOT goals of the project, and which remain open for evaluation.

Neil - thanks again for the reply.  A few follow-up notes:

Device Management

> Device configuration will be interesting but I think that's up to the module to handle the addressing issues.

Suppose you have an Scientific Atlanta HD3250 cable box wired up via IR through a GC-100.  Several current HA software controllers would have you send a command to this device using a syntax that includes the GC-100 in the path:

  GC-100-Upstairs.HD3250-Bedroom.sendIR('Channel Up')

This is what I object to.  Now, if you move the HD3250 to something other than the GC-100 upstairs unit, you just broke your code.  Instead, the association of the HD3250 to the upstairs GC-100 should be done once, and only once, in a configuration file, and not appear in the code.  (I guess this is just typical dependency injection or IOC.)

So, yes, the module need to ultimately implement the addressing scheme, but I think interface and configuration design guidelines need to be in place for developing these modules to ensure adequate and consistent abstraction and isolation in the device interfaces.

>You are correct a dimmer is a dimmer ... but there are unique features that the end user may wish to use.

Yes, that's what I meant by the "least common denominator" issue.  Perhaps one way to address this is to allow devices to implement multiple interfaces.  So, a dimmer can implement the "ORStandardDimmer" interface as well as the "InsteonDimmer" interface.

 > At this point, as a user, I could care less if it's X10, Insteon, ZigBee or a kerosene lamp controlled by a squirrel. I just want it to dim to 10% of the light level (or there abouts).

Exactly.

Rules & Logic

> Since it's a module it'll make development a little easier. You'll probably be able to run more than one at the same time.

That sounds very powerful.  At the same time, this makes global management of rules that behave as desired and don't step on each other or result in endless loops more challenging.  Perhaps whatever level of flexibility is provided with the rules system needs to be accompanied by a corresping level of visibility/traceability through an overarching management plane.

> I know what I want, I just wish I had the patience to wait for it ... but I do't so there!

Patience is only a virtue, but only when you don't have the option to move things along yourself!

Cliff


Posted by crosen at Apr 28, 2009 18:19

I've got to make this quick as I have to run to work but ...

Device Management

Suppose you have an Scientific Atlanta HD3250 cable box wired up via IR through a GC-100. Several current HA software controllers would have you send a command to this device using a syntax that includes the GC-100 in the path:

GC-100-Upstairs.HD3250-Bedroom.sendIR('Channel Up')

Wow that's just incredibly irritating!

// It's on Port 2000 of IP 192.168.24.1
HD3250-Bedroom = new GC100(192.168.24.1, 2000); //
// Setters can go here and other things need to be set 
// before use
    :
// Now this is where is gets used
HD3250-Bedroom.sendIR('Channel Up');

If you move the device to another GC100 then you just change the IP address in your new statement. We'll have to address that change in some way but I'm not sure how yet. It should be dynamic such as you make the change in some web interface and bang it's changed in your code and OR didn't need to restart (I hate having to restart for a simple change!).

Some of the many other things to consider is having a sequential section of code which is where most user code gets added. It runs continuously in a loop. Another section is code that runs in it's own thread, the parallel section. I'm not sure how to approach this yet. This was something I learned from using the HCS-II (Z180 based hardware HA controller) which had these features. Of course someone may come along and show me that zzz is a better way and I'll listen. The sequential method is used in Misterhouse. To do parallel they use a fork which causes problems. Just things to ponder.

Posted by linuxha at Apr 29, 2009 11:42

// It's on Port 2000 of IP 192.168.24.1
HD3250-Bedroom = new GC100(192.168.24.1, 2000); //
// Setters can go here and other things need to be set
// before use
:
// Now this is where is gets used
HD3250-Bedroom.sendIR('Channel Up');

Yes, that moves us in the right direction.  Going further:

DeviceConfigFile.cfg

DeviceClass DeviceInstanceName DeviceFactory Attributes
HD3250 HD3250-Bedroom GC100.IRPortFactory 192.168.23.1,2000
SONY123 SONY123-Bedroom ... ...

Now, when the config file is processed, the system environment knows to create a global object called HD320-Bedroom of type HD3250 using the GlobalCache100.IRPortFactory along with the contructor attibutes.  (Voila - dependency injection.)

Later, when you want to change the GC-100 address or even move the HD3250 to another IR capable device, you just have to change the one line in the configuration file.  The actual code never has to change.  Dependency injection takes care of the dynamic coupling of the HD3250 to the appropriate device factory.

The discussion about threading and sequential vs. parallel operations seems very interesting.  If you'd like to pick it up later. I'd love to hear some specific thoughts perhaps building on a concrete example.

Posted by crosen at Apr 29, 2009 12:18

Very interesting discussion indeed!

I'm pondering these concepts at a bit higher level and notice that in the current implementation we do not have the concept of an 'instance' of a certain object. That is obviously being planned with the addition of the 'room modeller' as an addition to the 'remote / UI' modeller we have now.

It's in the room modeller that the physical objects live and when that comes to live the UI modeller will only reference this objects. Now the challenge I think is not so much the 'moving'. The object is still derived from the same class with some attributes (config) different and so that should be seamless.

It would be a challenge when you switch adressing the box in a different way, say switching from using CommandIR(IR) to GC100(ip or rs232) (assuming this box supports that of course).

Most likely this would result in the instance of the object being instantiated from a different 'class' with (slightly) different attributes. For example the hd325 IR implementation might have the command 'power' whereas the GC implementation would have the power_on and power_off command. So obviously the commands that where mapped with the IR implementation would not be valid on the new instance. And so in that case you would have to change the UI model as well and remap commands.

Good thought experiments to practice with, especially now in this phase when we're still designing.

Thanks for adding very valuable feedback to the discussion.

JL

Posted by jlvh at Apr 30, 2009 01:49

Yes, this has been an interesting and enjoyable discussion.  Many special cases emerge from the variety of ways in which a given device can be logically abstracted and physically connected.

I would say ideally that the logical interface should be preserved even when the physical interface type changes whenever possible.  For this reason, I think it is advantageous to avoid:

 myCableSettopBox.sendIR("Power On')

in favor of:

 myCableSettopBox.PowerOn()

This level of consistency, I believe, is without much precedent in HA, but then what a great opportunity for OR.

We have in this thread considered various implications of attempting this consistency, such as dealing with interface methods that work with one physical interface but not another:
- example 1: discrete power commands may be available only via serial but not IR for a given device
- example 2: some lighting dimmers support variable ramp rates while others do not

There is a distinction in these two examples that may be worth highlighting.  The first example was raised in the context of one specific target device that happened to have two physical interfaces.  The design goal here is having a single logical interface that can endure a configuration change from one physical interface to another.

The second example concerns control of different target devices each with one physical interface, but the physical interface differs between devices.  The design goal here is providing a single logical interface to control devices that are functionally homogeneous but physically heterogeneous - and, doing so without losing the functional benefits that are unique to a given physical variety.

Generally speaking, we all seem to be concerned about the same design goals:
- Programmatic code should be isolated from and resilient to configuration changes and shielded from physical/topological nuances whenever possible
- Logical interfaces should be reusable across different physical interfaces whenever possible
- Logical interface convenience and simplicity must be balanced with preservation of functionality

There is so much more to discuss here, but it seems difficult to do so without first establishing a set of terms and assumptions in the problem space.  I will spend some time later to pen out a draft of these and see if there is any interest for discussion and elaboration.

Thanks,

Cliff

Posted by crosen at Apr 30, 2009 18:42

Hi Cliff,

While I totally agree that .PowerOn() is the preferred way, it's probably not going to happen because of the legacy databases and the simple fact that for example most IR implementations don't even have a distint ON. So in the beehive (or any IR) database there are only lists of codes without any knowledge which code would have the same meaning in another (IR) device listed in the database.

Posted by jlvh at May 01, 2009 01:14

Hi Jean-Luc - ok, I think my example was unfortunate as I was not intending to address the issue of discrete power codes, but rather how instruction syntax is formed.  So, let me rephrase this point as I think it advantageous to avoid:

myCableSettopBox.sendIR("Channel Up')

in favor of:

 myCableSettopBox.ChannelUp()

Cliff

Posted by crosen at May 01, 2009 02:28

Hello everybody,

A quick word of introduction as this is my first post here.

I'm a custom installer and independant programmer in Belgium, working mainly with AMX as a control system. I've looked and been lightly involved in other more "DIY" systems also. I'm also a software engineer and I've worked on some "enterprise" projects with tools like JBoss, Hibernate, Spring, ... I'm also developping software for the iPhone.

I just wanted to comment on some of the things that have been said here. I believe it's a really interesting discussion and an important one, mainly at this stage in the project. I think decoupling between logical device and physical device is extremely important and having a uniform interface to talk to devices of the same category also.

The "smallest common denominator" is always an issue but there are ways around it (see below for AMX way). As we're in java, I like the idea of having a general interface and additional specific ones. Anyway, the goal is that code that uses "common" behaviour will not need to be changed if you change a component e.g. dvd.play(). If on the other hand you need to access a device specific feature, just cast to the particular interface e.g. (MyDvd)dvd.enableUniqueFeature(). If you change you're DVD player, there is a big chance that feature will not exist anymore or be different, so you'll have to change the code any way.

I read somewhere in this thread or forum that this has not been tackled yet very well in the industry. Well if you look at what AMX is doing, they have some nice ideas. (All I'm talking about here should be publicly available on www.amx.com -> techcenter).

Let's first talk about the "old/current" way of doing things. One way to make components do something in AMX is with channels. It is just numbered slots that will carry out an action and provide feedback. But this has been standardized. So you know that channel 1 is play. Turning channel 1 on will start playing on any device that have transport (DVD, VCR, ...). If the communication is through IR, the IR command for play is stored in slot 1. If the communication is through serial, the module ("driver") will intercept that and send the correct command on the serial port. This is a simplified view but I hope you get the idea.

But this means that all AMX IR files for instance are standardize and this follows up on Jean-Luc's comment above. I think it must happen in Beehive. It is a gigantic work to ensure that the Beehive DB is fully standard and that all power on commands are either referenced as number 123 or tagged as ON or whatever but adding this kind of semantic information is key to many things. I've wanted to do this kind of DB for a long time but I think there are 2 ways to go there: having gazillions of $ to just hire enough people to do it or go the open source way and have enough people participate. Let's hope solution 2 will work.

Going back to AMX. They have been introducting some new tools / ways of working / ... for the last few years: duet, DDDP and VisualArchitect. They're moving to Java to implement some of the modules, and Duet is the technology that allows they're native language (NetLinx) to interoperate with Java in the same control processor. VisualArchitect is their visual tool that allows you to draw the components in your system and generate the control code behind it. For instance, I take an AMX processor, connect a DVD player on IR port 1, a Projector on serial port 1, ... and the tool does the rest. To make this possible, they're using Java and having standard interfaces for classes of devices (BTW this is available at http://www.amx.com/techdocs/NDT-CAFEDUET.SNAPI.Components.Listeners.pdf). So they now all DVD players you drag into your system will implement the DVDPlayer interface. DDDP (Dynamic Device Discovery Protocol) goes even a step further. I design my system knowing that I have a DVD player and a projector. I desgin my control program based on those interfaces. At runtime, the processor will query all its ports or broadcast on IP and discover the device connected. It will then go download the driver (jar file) that implements the communication procotol. So now my system has download my JVC RS20 module and all is find. I swap that projector for a Panasonic AE3000, the JVC module is unloaded, the Pana module is loaded and the system continues to work with 0 intervention.

That is the theory, they're not there yet but they're moving in the right direction.

Another comment on "least common denominator" issue. Another way to work around that in AMX is the concept of a passthrough. So all DVD modules know what play, pause, stop mean but also have a passthrough method were you can pass some kind of generic "blob" message to be interpreted by the module itself.

Well that's kind of a brain dump on this. I'll try to articulate some more thoughts and come back here.

Eric

Posted by ebariaux at May 04, 2009 14:20

Interesting stuff indeed on the AMX 'way' of doing things.

Getting things right vs how to get it in database (IR) and so on are the real challenges.

auto-Discovery is fortunately part of some protocols at least. So they should be easy .

Stuff to think about and work on ....

Posted by jlvh at May 04, 2009 16:42

For devices that look up stuff through DHCP even a configuration file for dependency injection sounds like a headache.  If your house resets then you lose all the IP addresses and "shit don't work no'more".

GC for example has a beacon that exports presence and a dedicated listener that knows what to look for can find the GC instances that way.  For KNX it is a slightly different thing,  a UDP packet that gets responded to, Juha was saying yesterday on the chat that he was hacking a quick java library to lookup a KNX gateway on a sub-net.

The central idea however that there is no device "lookup" but rather dependency injection is right on imo.  A device factory indeed.

Juha is the one working through those moves as we speak.

Posted by marcf at May 05, 2009 21:47

Right, it seems there are two separate issues:

1. What you refer to as the "central idea" pertaining to dependency injection, about which there seems to be much agreement.

2. The method of providing configuration information that informs the system what to inject.

On this second issue, it seems likely that one user may prefer one or another dynamic discovery  method while another prefers a fixed XML configuration file and yet another prefers XYZ method.  In other words, it seems the choice of configuration mechanism itself should be configurable such that users may declare whichever "configuration service" best suits them.

Then the bootstraping of this configuration matter would be enabled through a Java System property, or what have you, that points to the root config file.

Posted by crosen at May 05, 2009 22:31

Thanks Eric,

The "AMX-way" sounds rather close to how I'd see things working for OR as well. There are some specific details which may not be an exact match but overall at high level it makes sense (the behavior you describe is very middleware-ish).

The point about type-casting to a specific interface is also good, and is used a lot in "enterprise" Java projects you mention via proxy pattern (keeping the middleware generic).

And you are right this needs to tie to Beehive which then extends from a collection of distinct commands into shared interface-to-command mappings across a device class.

– Juha

Posted by juha at May 10, 2009 03:04

Since this is my first post, let me introduce myself a little bit. I works with embedded software/hardward companies in US and taiwan for more than 12 years. Develops products from embedded software development tool, IP/wireless roter gateways and some network media players, such as D-link DSM320/320RD/520/750. Recently, I join a company which provides home automation gateways. This is why I am insteresting in recent development of openremote. The question mentions here are exactly what we are discussing one years ago.

There are two issues.

1. How the device is identified.

2. How is the actions of the device is identified.

For the first question, it is realted to what the 'users' or 'programmers' identify a device. In the logic view, our intention is to "have the DVD in the living room to play". The object in this statement is "DVD in the living room". However, how do we describe it in the rules/programmer?

A possible is

     IRTrans1.send(1, 14)

This will send the IR code 14 of port 1 of IRTrans. The IRTrans need to lookup for the key 14 at the database the assoicated with port 1. We know the 14 is for play key of the Sony DVD. However, if we change to Toshiba DVD, it breaks. The resolution is to write the rule as

    IRTrans1.send(1, "play")

In this way, we ask the IRTrans module to look at its database to get the "play" in its database. However, this creates issues to standalize the database to define a set of standard keysyms and change the database to match it. In AMX's way, they define 1 as standard keycode for 'play' in this case, but the symbolic name might be better.

The other issue is how to find the port 1 is Sony DVD. In the above case, we know the port 1 is Sony DVD. However, its better we rewrite the rule as

    IRTrans.send(getDevice("MyDVD"),"play")

In this way, we define a label "MYDVD", which can be either Sony DVD or Toshiba DVD. If the SONYDVD is out of order, we can purchase a new one and use it to replace the MYDVD association. All the rules does not need to be changed.

In addition, we may define even more abstraction.

    getDevice("MyDVD").action("play")

in this way, the device can define how it can be controlled. Each device can defines a lot of actions which can use their own way to control themselves. The beauty of this format is that we can seperate the logic and the physical device. We can provide a device panel which allow us to assign the MYDVD to be the port 1 of the IRTrans and then select the IR code database as SonyDVD. If we get a ne DVD which can be controlled by RS232, we can go to the device manager to change it to use RS232 protocol and then select the new RS232 control signal database for it. We don't need to touch the rules database or the programs at all.

Posted by wycc at May 10, 2009 03:05

Reminded me of the famous quote:

"Any problem in computer science can be solved with another layer of indirection."

Your solution is good and it makes sense.

Posted by juha at May 10, 2009 21:56
Document generated by Confluence on Jun 05, 2016 09:32