Juha Lindfors wrote on Sep 03, 2008 19:44:
I think we are very much in agreement. X10 is in focus because of the DIY popularity, the protocol design has some real deficiencies so we must carry it around mostly to support existing device investments people have made.

Just to be clear - I'm not knocking X10 - it can be very useful and there are many people using it. From a community perspective there would clearly be many people who would benefit from and hopefully extend the functionality OR could offer. I am merely looking from the perspective from an established integrator who is only likely to use X10 at the margins of their work, if at all.

Jeremy Aston wrote: Crestron is an interesting one. If you have any of the others we've mentioned, a control processing engine such as OR provides you with a gateway to trigger actions, respond to events and incorporate logic. Of course, Crestron and AMX already have this so I am guessing that the proposition is to use OR as a gateway/middleware for non proprietary control interfaces to talk to a Crestron processor.

Juha Lindfors wrote: Yes, that's the point. Integrate with existing control protocols to open up the home for developer/user driven innovation. We will see if Crestron/AMX have built wide enough moats yet.

Interestingly enough, I see evidence that even high end customers are increasingly not quite so quick to agree to Crestron/AMX prices especially when it comes to touch-panels. It should be noted however that Crestron and AMX provide a wide range of free training, support, software and services to dealers, all of which has to be paid for somewhere. This also causes a problem for those who simply say that that hardware is much cheaper than the Crestron/AMX price but then have to charge for software. Stardraw, for example, can only really make money through software sales. This is where an OS approach has massive benefits. Reference hardware can be low priced yet well tested and community supported. The software is similar - it too has the benefit of a wide range of users proving it constantly.

Juha Lindfors wrote: Other than TCPUDP, the current plan is to have OS native code handle the IR/RS communication, and we interface from middleware via sockets to this. This effort is lead by Neil Cherry.

Yup - I have seen this and also noted the resultant discussions about hardware dependency. I am sure these issues can be overcome however I would be a strong advocate of also supporting the use of IR/RS232/IO over IP solutions such as Global Cache. Why?

Firstly, in practical terms you often need lots of RS232/IR etc. If you have an amp, DAB tuner, projector, screen, matrix switch etc. to control you need lots of RS232. In a solution with 4 sat boxes you need four discrete IR outputs. A control processor with one or two IR and RS232 ports is not going to cut it.

It can be also be a massive benefit to distribute RS232/IR control. For example, you may not have everything sitting in a rack, you may have equipment through a home. How do you get RS232/IR around? Of course, you can send it directly down a CAT5 cable or via baluns but it is sometimes easier to put a local control processor behind a screen for example. In Crestron/AMX terms this is a entry level processor acting as a room control box but OR could use a Global Cache. Something like GC also allows local IR to trigger events so you can use a very simple or low end remote to trigger multiple events.

I clearly need to look at and understand Neil's work in more depth but a GC interface is something I think would make a useful feature.

I guess the ideal is that OR is platform agnostic. The issue for integrators is that they want an end to end solution that offers stable hardware and software. This is the RI I suspect. For OR however the issue there is how to ensure a RI supply chain that offers low cost but good support in a global space. I don't think it is possible to encourage a wide enough range of users, especially in the commercial and professional integration space, if only software is on offer. For example Stardraw is a great bit of software and has grown. I don't get the feeling however that it is really hitting the likes of Crestron as it is software only. They don't package hardware (although some distributors do) but then the issue is that the software has to be charged fo to generate the revenue for development, support and other overheads.

Juha Lindfors wrote: What do you mean by open/close contacts, make/break I/O? Hardware connection status?

Not sure exactly at what level I am not being clear so please don't take offence if I am teaching my granny to suck eggs!

Contacts and digital I/O are the same thing really - just the ability to either open/close a contact closure to make/break a circuit (output) and then the ability to sense if a circuit is made or broken (input). Many projection screens have 12V triggers, for example, that will allow the screen to drop when a contact is closed.

Many, many things in the integration world work via contacts. You may have a contact from an alarm panel, for example, which means you could turn all the lights on when it is triggered.

Hardware connection - what I meant here was current sensing - e.g. is the TV on?

Juha Lindfors wrote: DnD is planned for the GWT based interface in the online manager. Scripting as well, Groovy is interesting there. Java we can deploy at runtime. IR drivers are coming from Beehive. Learning IR we've discussed in the past as well. Prebuilt hardware is something we are also looking at. Logic definitions can be easily externalized for non-programmers via rule engine like Drools.

Sounds great.

Juha Lindfors wrote: You should look at the current XML at the middleware as an export of properties that can be manipulated. I don't expect anybody except programmer types to be exposed to it. Deploying protocols is done from online/offline manager GUI and downloaded to the controller based on the profile that the user creates on the website. We can dynamically add/remove packages from controllers depending on user needs. The XML is the interface for the middleware to deal with but not the user.

OK - I think I am probably lacking in understanding of where things sit. What you are saying makes sense. My thinking was about how to easily enable less technical integrators to create things like IR drivers, RS232 drivers, simple logic modules etc. I suspect this is more related to the end user programming, DnD interface, Drools integration etc.

Click HELP for text formatting instructions. Then edit this text and check the preview.

Jeremy Aston wrote on Sep 03, 2008 23:37:

Jeremy Aston wrote: Crestron is an interesting one. If you have any of the others we've mentioned, a control processing engine such as OR provides you with a gateway to trigger actions, respond to events and incorporate logic. Of course, Crestron and AMX already have this so I am guessing that the proposition is to use OR as a gateway/middleware for non proprietary control interfaces to talk to a Crestron processor.

Juha Lindfors wrote: Yes, that's the point. Integrate with existing control protocols to open up the home for developer/user driven innovation. We will see if Crestron/AMX have built wide enough moats yet.

Interestingly enough, I see evidence that even high end customers are increasingly not quite so quick to agree to Crestron/AMX prices especially when it comes to touch-panels. It should be noted however that Crestron and AMX provide a wide range of free training, support, software and services to dealers, all of which has to be paid for somewhere. This also causes a problem for those who simply say that that hardware is much cheaper than the Crestron/AMX price but then have to charge for software. Stardraw, for example, can only really make money through software sales. This is where an OS approach has massive benefits. Reference hardware can be low priced yet well tested and community supported. The software is similar - it too has the benefit of a wide range of users proving it constantly.

Yes that is an interesting way to position OR with respect to Crestron integrators. Do you want to use those slick Low voltage KNX in-wall euro panels from Jurgen and German with your Crestron install? we need to map an KNX input to a Crestron output. I think a lot of folks understand this notion intuitively with the iPhone but really it applies to all proprietary panels out there. The limitations of end to end HW market is one thing we can address here. To Juha's point, I do not see a way for Crestron to stop this from happening (from us or others). But maybe I am underestimating the closed nature of the business relationships.

The point about the training is interesting. I will investigate Stardraw. The current vendors are the equivalent of mainframe vendors with everything integrated end-to-end. The software and the service are really embedded in the hardware price and feed off of it, including installers cut.

For IBM in the early 80's software and services were really support functions (cost centers) to enable the sale of hardware. It is my impression that the current prevailing business model is that of mainframes.

A PC model where hardware can be assembled and still have some quality attached to it is what is an interesting parallel and alternative. It is not entirely clear how to pull it off and it is clear that existing installers have it good with the status quo, no? I did note your point about the customer wanting to move, hence the importance of DIY crowd for PR, tech, knowledge and future services.

Juha Lindfors wrote: Other than TCPUDP, the current plan is to have OS native code handle the IR/RS communication, and we interface from middleware via sockets to this. This effort is lead by Neil Cherry.

Yup - I have seen this and also noted the resultant discussions about hardware dependency. I am sure these issues can be overcome however I would be a strong advocate of also supporting the use of IR/RS232/IO over IP solutions such as Global Cache. Why? Firstly, in practical terms you often need lots of RS232/IR etc. If you have an amp, DAB tuner, projector, screen, matrix switch etc. to control you need lots of RS232. In a solution with 4 sat boxes you need four discrete IR outputs. A control processor with one or two IR and RS232 ports is not going to cut it. It can be also be a massive benefit to distribute RS232/IR control. For example, you may not have everything sitting in a rack, you may have equipment through a home. How do you get RS232/IR around? Of course, you can send it directly down a CAT5 cable or via baluns but it is sometimes easier to put a local control processor behind a screen for example. In Crestron/AMX terms this is a entry level processor acting as a room control box but OR could use a Global Cache. Something like GC also allows local IR to trigger events so you can use a very simple or low end remote to trigger multiple events. I clearly need to look at and understand Neil's work in more depth but a GC interface is something I think would make a useful feature.

GC gets mentioned a lot. It is a very interesting product and one I believe we will end up competing with.

1. I have seen the iPhone to Crestron integration done this way (see at CEDIA UK). This hardware really is the embryo of the new OS we talk about that interfaces a iPhone panel to a Crestron processor. All the software is in the iPhone and it sends commands to a GC instant with IP connectivity to Crestron.
2. The number of IR outputs needed is not an issue. GC offers (3/6/12) and the form factor of the box changes upon those needs. See the current BOM for the ORC RI, it includes USB based IR emit and receive.
3. The multi-room thing is good. Neil has been pushing the idea of pods for multi room so that we have a really low end environment to relay the commands
4. We had missed contact closure, it is something we need to add to the ORC RI in short order. I do take note of that as well.
5. We need to run software somewhere. Either we strike a partnership with these people and run our software on their hardware or we actually build and ship the ORC RI. At $300 it is not cheap but not expensive.
6. I am still fuzzy as to how the IR codes get to the box and where the repository is. Is it all learning based? Is there an equivalent of Beehive?

I guess the ideal is that OR is platform agnostic. The issue for integrators is that they want an end to end solution that offers stable hardware and software. This is the RI I suspect.

No, The ORC RI is there like GC is there. To provide a IR/RS output and as per your point we should add a IO to that. The point of end to end quality is well taken. Where is the DELL of HA hardware? If there is a integration layer (OS) if there is a wealth of hardware vendors then a assembler is really someone supplying installers with hw made of commodity pieces. Some of the philosophy behind KNX plays into this BTW: to enable a multi vendor market, like the PC was a multi vendor market.

For OR however the issue there is how to ensure a RI supply chain that offers low cost but good support in a global space. I don't think it is possible to encourage a wide enough range of users, especially in the commercial and professional integration space, if only software is on offer. For example Stardraw is a great bit of software and has grown. I don't get the feeling however that it is really hitting the likes of Crestron as it is software only. They don't package hardware (although some distributors do) but then the issue is that the software has to be charged fo to generate the revenue for development, support and other overheads.

Thanks for the tip. I will check out Stardraw.

My thinking was about how to easily enable less technical integrators to create things like IR drivers, RS232 drivers, simple logic modules etc. I suspect this is more related to the end user programming, DnD interface, Drools integration etc.

I don't know what you mean by create JEZ but the idea is that those drivers are installed on a ORC by default the codes for it come from Beehive via a configuration tool. That is how we think about it. It should simplify the installers life.

Jeremy Aston wrote on Sep 03, 2008 23:37:
Yup - I have seen this and also noted the resultant discussions about hardware dependency. I am sure these issues can be overcome however I would be a strong advocate of also supporting the use of IR/RS232/IO over IP solutions such as Global Cache. Why? Firstly, in practical terms you often need lots of RS232/IR etc. If you have an amp, DAB tuner, projector, screen, matrix switch etc. to control you need lots of RS232. In a solution with 4 sat boxes you need four discrete IR outputs. A control processor with one or two IR and RS232 ports is not going to cut it. It can be also be a massive benefit to distribute RS232/IR control. For example, you may not have everything sitting in a rack, you may have equipment through a home. How do you get RS232/IR around? Of course, you can send it directly down a CAT5 cable or via baluns but it is sometimes easier to put a local control processor behind a screen for example. In Crestron/AMX terms this is a entry level processor acting as a room control box but OR could use a Global Cache. Something like GC also allows local IR to trigger events so you can use a very simple or low end remote to trigger multiple events.

Ok I'm trying to make sure I understand you correctly but what you are talking about is multi-controller/multi-room setup? Over IP where one controller can receive IR command that invokes a device that is ultimately connected to a different controller box somewhere else?

If that's correct then yes we can easily support this over IP with JGroups that gives us a reliable UDP broadcast protocol to get messaging and state replicated across controllers. That was essentially the reference earlier in email I made to you about JBoss Cache (which is a tree-based API on top of JGroups).

Now if we need to get this messaging over device control network then it's a bit more challenging. But could be a fun challenge.

Jeremy Aston wrote on Sep 03, 2008 23:37:
I guess the ideal is that OR is platform agnostic. The issue for integrators is that they want an end to end solution that offers stable hardware and software. This is the RI I suspect. For OR however the issue there is how to ensure a RI supply chain that offers low cost but good support in a global space. I don't think it is possible to encourage a wide enough range of users, especially in the commercial and professional integration space, if only software is on offer. For example Stardraw is a great bit of software and has grown. I don't get the feeling however that it is really hitting the likes of Crestron as it is software only. They don't package hardware (although some distributors do) but then the issue is that the software has to be charged fo to generate the revenue for development, support and other overheads.

Yes, we've discussed prebuilt hardware quite a bit. That's where Digium's experience would be useful.

Jeremy Aston wrote on Sep 03, 2008 23:37:

Juha Lindfors wrote: What do you mean by open/close contacts, make/break I/O? Hardware connection status?

Not sure exactly at what level I am not being clear so please don't take offence if I am teaching my granny to suck eggs!

Assume I know nothing about hardware ;-)

Jeremy Aston wrote on Sep 03, 2008 23:37:
OK - I think I am probably lacking in understanding of where things sit. What you are saying makes sense. My thinking was about how to easily enable less technical integrators to create things like IR drivers, RS232 drivers, simple logic modules etc. I suspect this is more related to the end user programming, DnD interface, Drools integration etc.

For logic modules, certainly.

I'm a bit uncertain on the need for integrators to go and build IR/RS drivers, not that often anyway. If that's the case then sure something needs to be built in terms of API and that should essentially be on top of Socket API for controlling the daemon(s) that interact with hardware.

Juha Lindfors wrote on Sep 06, 2008 11:16:
Ok I'm trying to make sure I understand you correctly but what you are talking about is multi-controller/multi-room setup? Over IP where one controller can receive IR command that invokes a device that is ultimately connected to a different controller box somewhere else? If that's correct then yes we can easily support this over IP with JGroups that gives us a reliable UDP broadcast protocol to get messaging and state replicated across controllers. That was essentially the reference earlier in email I made to you about JBoss Cache (which is a tree-based API on top of JGroups). Now if we need to get this messaging over device control network then it's a bit more challenging. But could be a fun challenge.

In practical terms there are two scenarios. Firstly you may simply want to have control of a device(s) that are not local to the processor. If you have some CATx going to the remote location then you can make use of that by (1) directly sending a signal down one or more pairs, e.g. IR, (2) using baluns/transcievers to send a signal further than would normally be possible (e.g. RS232 more than say 15m) or (3) have an IP aware device in the remote location then treat that as a slave device which you talk to from the processor over IP (e.g. Global Cache).

In this final case you simply do not need to replicate logic etc. remotely and therefore the network messaging issue does not arise. All you need to do is pass a signal. Now, if the controller hardware is cheap enough then you could use another instance of the OR remote controller. You do need to consider the form factor of the controller hardware however since you may want to put it behind a screen or similar.

The second scenario is that you need a slave processor, perhaps running it's own program, but with a connecton to the main controller. Crestron and AMX both allow this. A use case might be where you have a main processor running the key logic for control of a house but have a local slave processor in the cinema, controlling the kit there. Both processors have idependent programs running but understand what is going on with each other so they can interact. This is much more closely matched to what the solution you are discussing above.

The truth is you need to support both scenarios. The question is if you decide that the only way to do signal extension is via another OR instance. IMHO I think this is too narrow a view and one that could have a negative impact on potential takeup by the professional installer community. I would, for example, much rather have the option of putting a GC behind a TV or use a Neets RS232 Relay unit to control a projector/screen lift combo than be forced to use another OR RI box. Surely the point of OR is to be able to give the option that such devices can be supported, assuming that someone is prepared to make the effort to write the appropriate interfaces.

Jeremy Aston wrote on Sep 06, 2008 22:55:
The question is if you decide that the only way to do signal extension is via another OR instance. IMHO I think this is too narrow a view and one that could have a negative impact on potential takeup by the professional installer community. I would, for example, much rather have the option of putting a GC behind a TV or use a Neets RS232 Relay unit to control a projector/screen lift combo than be forced to use another OR RI box. Surely the point of OR is to be able to give the option that such devices can be supported, assuming that someone is prepared to make the effort to write the appropriate interfaces.

Ok I understand. This is the slightly more challenging scenario where we need to integrate with other's stuff.

Yes you are correct in that supporting a community with tools and interfaces is where the Open Source approach gets its strength to accomplish this. Having a choice of hardware platforms for OR software should also be a benefit here.

Juha Lindfors wrote on Sep 06, 2008 11:16:
For logic modules, certainly. I'm a bit uncertain on the need for integrators to go and build IR/RS drivers, not that often anyway. If that's the case then sure something needs to be built in terms of API and that should essentially be on top of Socket API for controlling the daemon(s) that interact with hardware.

Erm... it's critical but in the context that we may be confusing the scope of driver. Let's take Pronto or RTI as an example. Both these products have nice GUI interfaces to build configure the remote. They also offer nice big libraries of IR codes. I would bet however that on pretty much every install the integrator has to learn at least a few codes and definately has to create macros etc. Fair enough, not all integrators will create an RS232 module for a device but Pronto allows you to just enter some strings and blat them to a port just through the GUI - great for one way control. This level of functionality has to be as accessible and as simple to use as possible.

If you take it up a level then Pronto gives you ProntoScript (EMCAScript based so therefore as simple as JS). This gives you logic, program flow etc. On the Pronto it sits on the remote but in the Crestron/AMX world the equivilent sits on the processor as it would in the OR world. Basic modules would be DnD, PLC type programming in the OR world (analgous to Crestron Simpl Windows). It's not enough to leave it there however (IMHO), you need to offer the ability to do things at a lower level (potentially via Groovy and then Java). RS232 return string processing is a good example. Whilst not every integrator needs or can do this level of capability (hence why you contract a Crestron programmer), it is needed.

The ease of importing (via Beehive) IR, learning IR as needed and firing it off is a major requirement. The easier you make it to fire off RS232 is also really important. An easy way to send off a request and simply process a response via IP is also an increasingly important feature (see Gira Homeserver). Being able to wrap this up in macros and a scripting language then becomes important.

I hope I don't sound preachy however this aspect of the project is the bit that is important for the professional integration market and if it does not measure up to the established products then all credibility and confidence disappears. I also know that this is being addressed through various parts of the project - it's just a case of me dumping some additional context.

Jeremy Aston wrote on Sep 06, 2008 23:26:
I hope I don't sound preachy however this aspect of the project is the bit that is important for the professional integration market and if it does not measure up to the established products then all credibility and confidence disappears. I also know that this is being addressed through various parts of the project - it's just a case of me dumping some additional context.

No, it's just me trying to understand the requirements. Obviously we don't want to make things more difficult for integrators but trying to understand what they would be looking for in a product. Use cases would be very helpful here too.

On second reading of this I think I understand where you're coming from and it makes sense.

Thanks for posting this Jeremy, it's invaluable.