Building Dynamic Orbiters with JSON/AJAX/HTML5

[totallymaxed]

Here at Dianemo we're in the early phases of exploring the notion of building 'Next Gen' Orbiters in HTML5/JSON/AJAX. The idea being to enable anyone with some modern Web technology skills to be able to design & implement new Orbiter UI's in a Web browser. These Orbiters will not be restricted by the current Web Orbiter implementation or be based in anyway on those ie they will not be based around a series of big whole Orbiter screen bitmaps generated at the Core and displayed in the browser. They will be built & designed like any other HTML5 page.

At present we're in the embryonic stages of implementing some prototype devices at the Core that will expose JSON objects representing some simple devices eg On/Off Lights & Dimmable Lights etc. We're several months, at best, from having enough working to have anyone play around with this outside our team. However it would be useful to be able to gage how many of you with the right Web Development skills would be interested in being involved in testing this capability when we are ready.

So please drop a post into this thread if your interested in getting involved when we are ready and have the right skills (you will need to be familiar with building Web services/sites using JavaScript/JSON/AJAX/HTML5).

Also If you have questions about what we're doing in this area then by all means post them here too... I may not be able to answer every question as we're still figuring this out but I will do my best to answer as fully as I can.

All the best


Andrew

[buckle]

Will it be fully compatible with LinuxMCE?

Can you describe the server-side architecture you are using?

What limitations, if any, should we expect to see in the finished version (relative to the current native orbiter feature set)?

[totallymaxed]

Will it be fully compatible with LinuxMCE?

Can you describe the server-side architecture you are using?

What limitations, if any, should we expect to see in the finished version (relative to the current native orbiter feature set)?

Yes we intend to make this available to LinuxMCE and it will be GPL. There will definitely be a stage where it exists only in Dianemo...but that will short and will be before we open it up to a broader audience here. The idea is to get this broadly deployed and get as many people with UI Design/Web Developer skills using it as possible.

Other than what I have said already I can't say much more yet other than to say that the architecture will use JSON and will require client side Javascript code as you'd expect. As and when we have more specific details I will post them here and or on the wiki.

Re your question on limitations v 'Native' Orbiters; We don't expect or anticipate any limitations compared to existing Orbiters... in fact we expect the opposite of that in that you will be able to design new Orbiters on 'the fly' by just editing HTML/Javascript... the design/run/test loop should be very fast and dynamic. No regens will be required. Make a change in your Javascript code and test it. See the result. Adjust if needed and test again. Performance will be driven by the performance of your browsers Javascript engine and we really dont expect that to be an issue even on lightweight in wall panel style devices for example (we're testing one now with a full WebKit browser and in general terms it performs like an iOS device would.

Each Orbiter can have a different UI design deployed on it if that was a requirement... develop a small UI suitable for an Android mobile Phone or iPhone...its just a design problem not an engineering issue... it will be about defining how a tiny UI should be presented on such a device and performance will be like any other HTML5 based UI on that type of device. More efficient Javascript code will improve performance as you'd expect and it would be possible to write inneficient Javascript code and make your Orbiter perform badly of course... but then its just an issue of better coding to fix that.

Hope the above is helpful.

All the best

Andrew

[hari]

maybe we can join efforts with ago control and come up with an abstraction layer that hides the innards of DCE/ago control and talk the same JSON-RPC protocol. I've added JSON-RPC to ago control recently, this page describes the current protocol: http://wiki.agocontrol.com/index.php/RPC

It should be straightforward to add similar methods to the DCE RPC plugin. I'd volunteer to implement this.

[uplink]

It appears I need to take a look at this Ago Control thing to see what it can do Bolting new features onto Pluto is getting a bit old.

Can it play media? If not, does it have the infrastructure in place? If not, I have a few ideas of my own - just not the time, or I'd jump right in.

The JSON-RPC interface can be designed in such a way that it's the same for both LinuxMCE and Ago Control. The way I see it, it should present high-level objects, and avoid providing access to the low level infrastructure as much as possible.

I'm still to invent what the data exchange protocol should look like, but I'm sure it has to NOT look like what's in the Ago Control wiki.

Here's a quick example I'm inventing as I'm writing it:

Request:

Code: [Select]

GET /lights/list

or:

Code: [Select]

GET /lights/list/+room/<id>

Reply:

Code: [Select]

{
  "lights": [
    {"id": "<id1>", "type": "<simple|dimming>", "power": "<on|off>", "level": "<0..100>"},
    {"id": "<id2>", "type": "<simple|dimming>", "power": "<on|off>", "level": "<0..100>"},
    {"id": "<id3>", "type": "<simple|dimming>", "power": "<on|off>", "level": "<0..100>"}
  ]
}
Request:

Code: [Select]

POST /lights/<id1>

{
  "power": <on|off>,
  "level": <0..100>
}

Reply:

Code: [Select]

HTTP/1.1 200 OK
Request:

Code: [Select]

GET /lights/<id1>

Reply:

Code: [Select]

{
  "power": "<on|off>",
  "level": "<0..100>"
}

That doesn't look like JSON-RPC. It's plain new RESTful. That's what I'd like to have. Essentially, the HTML5 Orbiter I have in mind won't be very different from a Web 2.0 web service.

As usual, I lack the time. While Andy made it sound like an HTML5 Orbiter is my main priority right now, that's not the case. I have some ideas, and I was hoping somebody else around here had enough knowledge to work on it, but I found out, after a few trials, that the person in question has a very steep mountain to climb first in terms of knowledge.

The concept is very promising. It just needs resources.

[hari]

The reason why I chose JSON-RPC is that you can talk to it from a lot of languages in a standardised way. Media is on the list. We already have a lot of drivers in that area. What lacks is the logic that glues the things together and provides the user with a media browser.

[polly]

totallymaxed, please use jquery as JS library, i'm sick of all the other JS libraries ....

;-) ...

[Marie.O]

polly, isn't jquery the browser side of things? Choose your weapon. I am sure the backend doesn't care.

[uplink]

totallymaxed, please use jquery as JS library, i'm sick of all the other JS libraries ....

;-) ...

No argument here: jQuery is what will be used.

[polly]

jQuery is pretty much the only JS Framework i use ....

[hari]

it is fairly simple to do JSON-RPC via jquery, e.g. setting a dimmer level does look like this in ago control:

Code: [Select]

function setlevel(uuid, level) {
  var request = {};
  request.method = "message";
  request.params = {};
  request.params.command = "setlevel";
  request.params.uuid = uuid;
  request.params.level = level;
  request.id = 1;
  request.jsonrpc = "2.0";

  $.post(url, JSON.stringify(request), myCallback, "json");
}

So JSON-RPC barely adds overhad/code but provides a standardised way to talk to it. And that snippet isn't much more complex than concatenating specific URI strings. Coming up with dozens of /what/ever/it/might/be RESTful URLs ain't gonna make it easier in the long run. Specific URIs to fetch e.g. a list of lights are too specialised. A simple inventory request that delivers structured data with all rooms, scenarios, devices and states provides all that data in a single request. Plus it provides the schema. So the GUI knows what kind of actions the devices support. That allows for a generic widget approach (on, off, level, …). My two cents.

br Hari

[polly]

hari thats the point! ....
even i understand jQuery without reading tons of documentation ..

[uplink]

Inventory command is OK. RESTful /what/ever/path/to/object doesn't interfere with it, it can just provide reduced sets when needed, rather than transferring a full schema all the time (reload Orbiter? ). Both can co-exist on top of the same data layer.

I don't like the JSON-RPC structures because you have to wrap the useful data with extra crud that stays fixed. Are you planning to set request.method to anything else but "message"? Because only request.params contains useful information, and that's pretty much what I've exemplified. Any reason not to pass just the contents of request.params around?

I assume that you have libs that do json_rpc_call($method, $params), that's why you say it's "standard". So is ad-hoc JSON then The params are that ad-hoc JSON anyway. The method can go in the URL. I'd say that would be a lot more readable and properly separated. But that's just me. Hell, you could tail the web server log and see what commands are coming in (without their parameters), just to make sure you're sending the right commands or that the commands get to the server - helpful if your server isn't sitting there idle just for you and you need to grep the tail.

So, what I'm suggesting would look like this with jQuery for the example you gave:

Code: [Select]

$.ajax({
  url: '/message',
  method: 'POST',
  data: {
    command: 'setlevel',
    uuid: uuid,
    level: level
  },
  onSuccess: function() { do_my_thing(); },
  onError: function() { moan_loudly(); }
});

RESTfully, it would look like this I guess:

Code: [Select]

$.ajax({
  url: '/' + uuid + '/setlevel',
  method: 'POST',
  data: {
    level: level
  },
  onSuccess: function() { do_my_thing(); },
  onError: function() { moan_loudly(); }
});

Now that I wrote the second one, it does look a tiny bit uglier, because I have to compose that URL Hmm... But neither is uglier than JSON-RPC so far.

[hari]

yes, there are other methods besides "message". Regarding the inventory, that is only fetched at the first load. You'll get notifications for changes when you subscribe to them on ago control. When listening to the proper events you can keep it up to date without needing a "reload". With standard I mean this: http://www.jsonrpc.org/specification
Adhering to it allows clients from multiple languages to talk to the service without much hassle. You can e.g. batch requests and have a defined set of result codes. Anyway..

[mkbrown69]

Good day folks!

I just thought I'd point out a home automation controller with a well developed REST and SOAP/WSDL implementation that might provide some food for thought.  It also has an AJAX library specific to it that leverages it's REST/SOAP interfaces, that's used as an embedded controller Web UI (it's main Admin/configuration app is Java based, but will likely be ported to something more HTML5 based in the future)

http://www.universal-devices.com/isy-developers/   look under the Official SDK section.

I'm pointing it out because it exposes lighting control, climate control and weather, energy measurement, etc via those REST/SOAP interfaces using XML.  It exposes enough information that various GUI's can determine it's configuration and that of all the child devices, and present a GUI based on that information.  It might give you folks some ideas...

HTH!

/Mike

P.S.  that's the device I'm struggling to write a GSD driver for, so if Hari feels like whipping one up for Ago Control, I'd be happy to test.  I can't 'C' my way out of a wet paper bag ;-). I've been playing with Ago a bit on my Pi.  Want to have some free time for hardware hacking so I can play with your Blink-M stuff (once I build a few clones). /M