Premise MiniBrowser - The Next Generation

[123]

I thought I'd give everyone a head's up about my current project, namely a revised version of Minibrowser able to present different user-interfaces.

A little background ...
Premise has two Modules that can present a browser-based user-interface (UI):

1. AutomationBrowser
   AutomationBrowser is designed for Windows PCs with Internet Explorer (IE). It uses an ActiveX plugin and IE-specific HTML commands. Although its user-interface is no longer state-of-the-art, it does use sophisticated techniques and is able to render almost any Premise Home object.
2. MiniBrowser
   Minibrowser is designed to run on any browser-based device. It uses very simple HTML commands to ensure compliance with all devices. Its user-interface is simple and (probably) intended for Pocket PCs since it is invoked with http://PremiseServer/ppc. It can render basic Premise Home objects such as rooms, lights, MediaZones, thermostats, etc for a small screen (i.e. about 275 pixels wide).

At some point in time, Rob Brun created xBrowser. It had a UI designed for Internet Appliances (i.e. screen-width of 640 pixels like the 3COM Audrey) and included support for additional objects like Appliances. In addition, Rob showed how other Modules could be made 'xBrowser-compliant' and capable of presenting their UI via xBrowser.

When Premise was still a commercial product, it wasn't a good idea to mess with MiniBrowser's code because all modifications would be overwritten by the next software release. That's probably why Rob chose to leave MiniBrowser untouched and make xBrowser a completely separate Module. However, xBrowser's code comes directly from MiniBrowser; xBrowser is an (enhanced) duplicate of Minibrowser.

There's another version of xBrowser (author unknown) called xBrowser_DSL and it provides enhanced support for MediaZones.

Recently, Chuck Lyons developed a Module to support the iPhone and it is based on xBrowser_DSL. So MiniBrowser has at least three offspring, all based on its core code with only slight variations to the UI.

My thoughts ...
It's safe to say that there'll never be a new release of Premise. That means MiniBrowser's code can be modified in whatever manner one sees fit. What I envision is a single MiniBrowser able to present different user-interfaces. Depending on how you invoke it, it will present a different UI. Here's what I mean:

• For a Pocket PC: http://PremiseServer/ppc
• For an Internet Appliance: http://PremiseServer/xb
• For an iPhone: http://PremiseServer/iphone
• For a Nokia N800: http://PremiseServer/n800
• etc

In effect, MiniBrowser supports multiple WebRedirects (i.e. virtual paths). For each WebRedirect, it knows how to present the appropriate UI. Adding support for new devices (N800, Apple Tablet, etc) would mean defining its basic characteristics (i.e. screen width) and, optionally, a new toolbar and a fresh set of icons.

My progress ...
I've revised MiniBrowser's source code from top to bottom. I've changed the design of several functions and started cleaning up the HTML code it produces. I'll described the major changes in a future post. I should have something ready to share, for beta-testing, in the near future.

 

[chucklyons]

hmmm....I like the idea! I am wondering how that will affect changes made to iPhone, Xbrowser, and the like? So count me in on the beta....

 

[samgreco]

Count me in too. Sounds like a great way to go.

It still amazes me how open and ahead of it's time Premise was/is.

 

[etc6849]

It would be awesome to have automation browser functionality for my tv, rx and etc through minibrowser! Count me in too

 

[chucklyons]

123, when you say you are doing a complete rewrite, does that include zones and AV_Component functionality? If so, I can stop driving myself nutz on the zone stuff (although, I'm close..it works automatically, but not user selectable)

I'd be thrilled if you are/did!

 

[123]

I'm not including any new features beyond what I descibed in the first post. Sorry Chuck and etc6849 but the new MiniBrowser won't contain enhanced MediaZone functionality (it is currently limited to playing music).

By "rewrite" I meant that I was streamlining MiniBrowser's existing functionality. MiniBrowser contains some coding techniques that make its source code unnecessarily difficult to understand. I have re-written parts of it (i.e. how it creates new WebRedirects and large portions of several RenderPage methods) in order to get the new 'chamaeleon' functionality.

FWIW
There's one bug in MiniBrowser's MediaZone that I haven't been able to resolve. Increasing the Volume can cause the whole thing to hang ... you have to delete the Session object (WebServer > Default Web Sites > Sessions > Session) in order to recover. I'm able to reproduce this bug in xBrowser and MiniBrowser. I've examined the Volume control code and there's nothing obviously wrong. This is all low-tech HTML so clicking the Volume Up button causes the entire page to refresh and that means retrieving the entire list of music ... each and every time you click the button! I feel this may have something to do with it ... it only happens with lots of music content.

 

[123]

After studying MiniBrowser, it dawned on me that I could add an interesting feature: The ability to control a Premise object via an URL.

In all fairness, the existing MiniBrowser offers this capability as a by-product of its design. However, this feature is now an integral part of the new MiniBrowser's design. Here's how it works (it may change in the final release):

Assume you have a light called WallSconce whose location is: /home/apartment/foyer.

1. To turn it ON, use:
   http://PremiseServer/sys/home/apartment/foyer/wallsconce?d??mbOn(1)
2. To turn it OFF, use:
   http://PremiseServer/sys/home/apartment/foyer/wallsconce?d??mbOff(1)
3. To toggle it, use:
   http://PremiseServer/sys/home/apartment/foyer/wallsconce?d??mbToggle(1)
4. To brighten it by 10% use:
   http://PremiseServer/sys/home/apartment/foyer/wallsconce?d??mbUp(1)
5. To dim it by 10% use:
   http://PremiseServer/sys/home/apartment/foyer/wallsconce?d??mbDown(1)
6. To determine its current operating state use:
   http://PremiseServer/sys/home/apartment/foyer/wallsconce?d??mbState(1)
7. To increase the setpoint temperature of a thermostat by 1 degree (Fahrenheit), you'd use:
   http://PremiseServer/sys/home/apartment/hallway/thermostat?d??mbUp(1)

You're probably asking, what's with the "(1)" at the end of the command? The number indicates the reply format.

• 0 = User-Interface mode
  This is reserved for use by MiniBrowser to display a user-interface.
• 1 = HTML mode
  HTML mode simply returns the object's name in order to provide a basic visual confirmation that the message was received.
• 2 = XML mode
  XML looks like this:
  <premise version="1.0">
  <Object ID="{3536D217-DF2F-476E-91DF-A3B9E8D627B5}" Name="WallSconce" Class="sys://Schema/Device/Lighting/Sconce" PowerState="-1" Brightness="0.33" PresetDim="0.31" />
  </premise>
  The XML response is useful for a remote application because it provides greater detail and can be easily parsed. Browsers will not normally display this response.
• 3 = Quiet mode
  This mode simply returns an empty string and nothing will be seen in the browser.

NOTE: The mbState method returns the object's current state and isn't useful unless you use it in XML mode.

 

[samgreco]

Ooooh.. That opens up all kinds of possibilities. Including using other "front-ends" like SageTV or xLobby, etc. for a 10-foot UI.

Lots of things could be done, I would think.

 

[123]

Status update:

The new MiniBrowser module can now render three different user-interfaces using a single code-base:

1. PocketPC
2. xBrowser
3. iPhone

Other UIs can be easily added because Appearance properties (height, width, columns, fonts, etc) are exposed for each UI Style and not buried in the code (see the attached screenscrape). Plus you can indicate if a UI Style relies on a specific Cascading Style Sheet (CSS) and an images folder if the UI Style uses a specific set of images (like iPhone).

• V2 supports TemperatureSensors and LightSensors (rendered by a common method called "mbRenderSensor").
• The MediaZone displays the current Album, Artist, Track, and Duration.
• V2 also lets external applications control Premise objects via URLs (a quasi RESTful interface). Objects now have common methods like:

1. mbOn (for PowerState or State)
2. mbOff (for PowerState or State)
3. mbToggle(for PowerState or State)
4. mbUp (for Volume or Speed)
5. mbDown (for Volume or Speed)
6. mbState

• Unify
  MiniBrowser V1 contained lots of redundant code. For example, Lights, Fans, and Appliances share a common appearance yet each class had its own code for rendering the object. V2 has a single "mbRenderController" method that can render Lights, Fans, Appliances, Relays, etc. Much easier to maintain a common appearance.
• Simplify
  V1 used a deeply nested 'if then elseif' contruct to test if an object could be rendered (i.e if it was supported). V2 uses an Enumeration that lists all the valid classes. An "IsValidClass" method simple loops through the Enumeration. Much easier to extend MiniBrowser's support to other classes.
• Accelerate
  V1 used a lot of string concatenation that looked like this:
  Output = Output & whatever & whatnot & widget & foo
  Output = Output & something & thatthing
  "Output" gets larger with each appended string and there's a whole lotta memory allocation goin' on. V2 uses parentheses to group the small strings into one string before they are appended to the big string (i.e. Output). Just a little bit faster.
  Output = Output & (whatever & whatnot & widget & foo & something & thatthing)
  V2 uses the Scripting.Dictionary object to concatenate all of the strings used in the ColorPicker. Just a little bit faster.
• Extend
  V2 retains the use of the TABLE tag to organize most of the onscreen widgets and tends to use lots of FONT, CENTER, and other deprecated HTML tags in order to maintain compatibility with ancient browsers (like a 3COM Audrey's browser that cannot digest any form of style information). However, it has a "UIAdvanced" property that, if true, allows MiniBrowser to render objects using current techniques like AJAX (an exercise for someone else, thank you very much).

 

[chucklyons]

AWESOME!! This is what the mini/x/browser always needed! Of course, now I'll have to redo a couple of the mod's I made to support the old version. A small price to pay!

So when can I get my hands on this? (Don't be a Damon and only tease us!)

First Damon's UI and now this. Christmas IS a magical time of year!

 

[ckindel]

After studying MiniBrowser, it dawned on me that I could add an interesting feature: The ability to control a Premise object via an URL.

In all fairness, the existing MiniBrowser offers this capability as a by-product of its design. However, this feature is now an integral part of the new MiniBrowser's design. Here's how it works (it may change in the final release):

Assume you have a light called WallSconce whose location is: /home/apartment/foyer.

Premise already includes a SOAP interface that does this. It looks like this.

    /* SYS URL format.
     * a - SubscribeToProperty
     * 	    http ://localhost/sys/Home?a?targetelementid??Brightness?subid?subname
     * b - SubscribeToClass
     * 	    http ://localhost/sys/object?b?targetelementid?action?class?subscription_id?subscription_name
     * 	    Class subscriptions don't get prop change events, just add/delete
     * c - Unsubscribe
     * d - InvokeMethod
     * e - SetValue (e.g. url = http ://localhost/sys/Home/Kitchen/Overheadlight?e?PowerState, message contains
     *                  "0" or "1"), no response message-body
     * f - GetValue (e.g. url = http ://localhost/sys/Home/Kitchen/Overheadlight?f??PowerState (Note double ??)
     *                  no message body in request
     *                  You *can* put a targetelement between the double ??, but not really necessary here.
     *                  response message body contains value
     * g - RunCommand
    */

I've been building a Windows Phone 7 front end for my house using the SOAP interface and have found it 'lacking'. First of all the subscriptions don't work, and second REST would work better for my solution.

What you've demonstrated here gives me the idea that the SOAP interface is actually built in minibrowser and I could fix it THERE. Is this correct?

 

[Waynedb]

Great a new member who knows a lot about Premise,
another member here (John In VA) had a question about a
native .Net version of the minibroker driver that you mentioned
on your website. http://kindel.com/blogs/charlie/archive/2004/04/16/246.aspx

His question thread is here.
http://www.cocoontech.com/forums/index.php?showtopic=17738

 

[ckindel]

Great a new member who knows a lot about Premise,
another member here (John In VA) had a question about a
native .Net version of the minibroker driver that you mentioned
on your website. http://kindel.com/blogs/charlie/archive/2004/04/16/246.aspx

His question thread is here.
http://www.cocoontech.com/forums/index.php?showtopic=17738

I been lurking for a while... I finally got some time to dig into fixing some things with my system. I had completely forgotten about the minibroker.NET and that blog post! I think the whole minibroker.net project died. I'll keep people posted as I figure out what I want to do...

 

[georgejm]

Charlie

I'm very glad you are here! The prototype url's you show in your post are very interesting. Do you have any more details on the subscription URL? What are subid and subname? If we can crack the property subscription problem, we can build our own .net "minibroker-like" component that would work with any .net compatible os (including 64 bit windows).

Thanks

John