Premise A fresh new face for Premise.

I realize there are precious few Premise users still monitoring this forum. However, for anyone still listening, here's a summary of my recent attempt to put a fresh new face on Premise.

First, if you're looking for screenshots or demos, you can stop reading now because I don't have any; I'm not there yet. I'm only at the stage of understanding the best way to connect Premise to a product called Home Remote. http://www.thehomeremote.com/

• Currently, the software is free (that'll probably change this year).
• It offers native apps for Windows, iOS, and Android (all available in their respective app stores; no rooting/jail-breaking/sideloading required).
• You design a custom UI using Windows-based Home Remote Designer.
• It can connect to many popular devices but can also be extended to support anything that can be controlled via TCP, MQTT, or HTTP (hello Premise).
• You upload your custom UI to your phone or tablet.
• The UI's appearance is native to the device (i.e. on an iPhone it looks like a native iOS app not some 'fish-out-water' transplanted from Windows or Android).
• The product's author is very helpful and responsive to suggestions.

So far I've only dipped a toe into this project. The first hurdle was to find a way to talk to Premise via HTTP (without using AutomationBrowser, MiniBroker, or similar derivatives).

Many thanks to Charlie Kindel for reverse-engineering Premise's native WebClient HTTP protocol.
It revealed how to get and set a Home object's property values as well as execute methods (scripts) on the Premise Server.
 
NOTE: the leading "http:" has been removed in all URLs to prevent them from becoming active links.

In a nutshell this gets values:
//PremiseServer/sys/Home/LivingRoom/Floorlamp!PowerState

This sets values but it's an HTTP POST operation, not your usual HTTP GET.
//PremiseServer/sys/Home/LivingRoom/Floorlamp?e?PowerState
The message body must contain 0 or 1 (off or on). If you were setting Brightness, the message body would contain a decimal value between 0 and 1.

This one executes methods on Premise server.
//PremiseServer/sys/Home?d??MyCustomFunction()
You'd use this if you wanted Premise to perform some task or to respond with custom information (and not just the status of one Home object).

That's it! With these three URLs you can control most anything in Premise. Of course, as with most things, the devil is in the details!

I'm still a newbie with Home Remote but I did manage to create a simple UI to control one light and it works perfectly. Response time is within a second and it promptly displays the light's status (i.e. if I change the light's brightness using the wall-switch, the slider in the UI updates accordingly).

To achieve this required a little bit of tinkering. Controlling lights is not like controlling a thermostat. You probably only have one thermostat. So if you use this:
//PremiseServer/sys/Home/Hallway/Thermostat!_XML
Premise will reply with all the thermostat's properties in XML format. Nice!

In Home Remote, you would use XPATH statements to extract the desired property values (CurrentSetPoint, Mode, FanStatus, etc) from Premise's response. It's easier than it sounds. The hardest part was learning how to use XPATH to convert temperature (Premise reports temperature in Kelvin).

Undoubtedly, you have more than one light in your house. Yes, you can use this:
//PremiseServer/sys/Home/LivingRoom/Floorlamp!_XML
then use XPATH to extract PowerState and Brightness (if it's a dimmer) from Premise's XML response. Straightforward.

HOWEVER, the way Home Remote is structured, it's simpler if you can request the status of all lights and then use XPATH to extract the properties of the one light you want. Why? Because the UI you create will undoubtedly have several lights on the same page, not just one. You want to poll Premise once, and get the status of all lights shown in the UI, instead of polling Premise for each light, one at a time.

Fine. Except Premise has no HTTP command to list the status of all lights. This is where I needed to create a custom method.

It's quite simple; it's all in a Module. All it does is collect all lights in Home (but only the ones that are visible, namely Navigation=Default) then produces an XML response containing each light's relevant properties.

In fact, Premise objects have the built-in ability to spit out their properties in XML format! However, the result contains extraneous properties like BoundObject, ID, Class, Flags, blablabla, etc. The result is kind of bloated so I wrote a few lines of script to produce my own, compact XML response containing just Name, PowerState, and Brightness.

All my lights have unique names. However, if your home has duplicated names (i.e. CeilingLight is used in more than one room), the XML response would have to contain each light's full path in order to differentiate between /Home/Bedroom/CeilingLight and /Home/Garage/CeilingLight. Thats an easy modification to the method.

Anyway, all this to say, things are looking good so far! Aside from writing a few methods to list all lights, sensors, contacts, etc, most of my time will be invested in designing a custom UI with Home Remote Designer.

Wow!  It's been a while since there's been anything new around here   Good to see that you're still at it.  Can't wait to see this.

So here's where I'm at. I created a Module for a new Device called HTTP_API. After importing it, it lets you create a new Device called API. Done! Now you can use URLs like this to make Premise crank out XML lists (on port 80) of Lights, Appliances, Scenes, etc. That's precisely the kind of information needed by a remote-client like Home Remote. However, I'll hazard a guess it can also be used by others like Simple Control, DemoPad, and iRule (which is being mothballed). You could probably even use it to share information with other Home Automation software.

Currently, API has 7 functions that list the following Home objects:

• Lights()
• Appliances()
• Scenes()
• SecurityZones()
• TemperatureSensors()
• Thermostats()
• SecuritySystems()

The functions produce very compact, and terse, XML output. I feel it doesn't really need to be 'human-readable' because it's intended to be consumed by the remote-client software. It's trivial to extract the property values with XPATH.

Lights() shows Name, PowerState, and Brightness (if it exists). Appliances() shows the subset of all Appliances containing a PowerState (many Appliances don't have this property). It lists the Name and PowerState. Scenes() shows Name and Play. SecurityZones() shows Name and Triggered. TemperatureSensors() shows Name and Temperature in Kelvin. You can convert it with XPATH to your preferred units at the remote-client end. Alternately, you can tweak the code and have the function convert the values upfront. Thermostats() lists Name, CoolingSetPoint, HeatingSetPoint, TemperatureMode, FanControl, Temperature, CurrentSetPoint, OutdoorTemperature, Mode, UserHold, HeatingStatus, and FanStatus. The units are Kelvin. SecuritySystems() lists Name, SecurityState, StatusLastFunction, LastStateChange, LastZoneTriggered, LastFunction, TriggeredZones, and SecurityReady. There's an eighth function called MediaZones() but it's incomplete. I doubt I'll ever finish it mostly because I don't use Premise's MediaZones. What you see below is Premise's native XML output (not my stripped-down version) for a MediaZone and MediaShortcuts. You'll notice almost all of the property values are ObjectIDs (pointers to other objects within Premise), even for "Content". There's a bit of work to be done in order to suss out the 'human-readable' data for use by the remote-client software. Premise has a bazillion categories of Home objects, like HumiditySensor, LightSensor, MediaPlayer, Television, RelayDevice, etc. I'm not using them so I haven't written functions to support them. However, unlike a MediaZone, many of the other objects are simple. It would be easy to copy/paste an existing function and tweak it to support additional Home objects.


Next step is to start using this stuff in Home Remote!

Can't wait to see where this goes.  Of course, I use Media Zones a lot.  I have actually begun looking at doing something completely different.  Although I have no idea yet what that may be.

FWIW, here's my story (so far) regarding the search for Premise's replacement. Grab a coffee because I had a lot on my mind to share.

Over the past decade, I've been spoiled by Premise's ease-of-use, functionality, flexibility, and (importantly) its reliability. However, to safeguard against what ultimately happened to Premise (becoming an orphaned closed-source product), I focused on popular open-source solutions. This narrows the field considerably but introduces many compromises.

A paid product provides refinement, stability, and reliability (re: CQC, Homeseer). Open-source software, with an enthusiastic user-community, supports a lot of devices, albeit the focus is on late-model devices. It also lacks some of the refinement found in paid software (i.e. ease of use), stability, and the documentation largely depends on what volunteers put into it.

The key problem for old HA codgers like me is that I have a houseful of old but functional gear (X10, ELK M1, UPB) that open-source solutions either don't support or do so minimally. The new HA kids are into zwave, MQTT, Hue, LIFX, Alexa, blablabla etc. Some forego purpose-built alarm systems and roll-their-own. Others make their own remote sensors and switches with ESP8266 SOC's. Much of this home-brew stuff is glued together with MQTT. ELK M1?!? What's that, Grandpa?

It makes no economic sense for me to scrap and replace all my lighting (and gut my alarm system) just so I can use "free" open-source software! The three open-source products generating buzz are openHAB, Home Assistant (HASS), and Domoticz. openHAB now supports X10 CM11A and UPB but in a limited fashion (compared to Premise). HASS uses Linux's "heyu" utility to handle X10 and offers nothing for UPB. As for ELK M1, openHAB has nothing whereas someone in the HASS community has been developing one ... for over a year.

One option is to just sit tight and wait for someone in the open-source community to write drivers for my old gear. That can be a very long wait (and for something merely rudimentary). The situation is exacerbated by the fact the three solutions I listed above were all born in Europe. That means the community has focused on non-North American lighting solutions (no surprise there). Gear with a decidedly North American bent, like UPB and ELK M1, gets no attention. It'll take someone on this side of the pond to roll up their sleeves and write a driver (gee, sounds like Premise ten years ago).

Having said that, I investigated what's involved in developing drivers, in openHAB and Home Assistant, and it's a steep hill to climb. Sure, it's a given that one may have to learn a new programming language (openHAB=Java, Home Assistant=Python) but the development process isn't like using Premise Builder. It's more like developing Premise's native drivers in C++ using Visual Studio. I did that once (for the USB-UIRT) and the development cycle is much slower, and more tedious, compared to the ease of using Premise Builder.

So how do you create rules and 'automation logic' with these things? Both openHAB and Home Assistant use text files. openHAB uses a custom syntax whereas HASS uses YAML. Modify the YAML file and you have to restart HASS to make it take effect (say what?!?).

There's something to be said for the simplicity of text files. They can be easily edited, duplicated, moved to another system, etc. However, you can forget about Builder's visual representation of your Home in a friendly tree-structure that's easily created with a few right-clicks and menu selections. In HASS and openHAB you start with a blank text file and, using appropriate syntax, manually type all the bells and whistles.

Fortunately, openHAB supports the use of Visual Studio Code. Overlook the onerous "Visual Studio" part because it's just a text editor, but a powerful one. You know how Premise Builder highlights keywords and offers code-completion? That's what VS Code does for openHAB (and for other things if you configure it appropriately).

openHAB V2 introduced automatic discovery of devices (like Premise drivers do whenever possible/practical) and presents them in a browser. That's its new direction, to add "Things" and "Items" automatically and you configure them using the browser's UI (not via editing text files). However, it's only partially baked because it doesn't currently offer all the power of the old way of using text files AND it allows both techniques to be used (so you there's the potential for confusion caused by having stuff configured in two different places).

openHAB has an experimental Rules Editor, in the browser's UI, but the standard way is via text files. You write rules in Xtend which is a dialect of Java. HASS's rules are written in Python. Without the assistance of code-completion, writing rules for these products can be clumsy (compared to Premise Builder). There are no wizards or helpers to speed things along (like a visual way of making Scenes or Schedules). In Premise you can easily extend the behavior of existing Home objects or even invent new ones. There's no facility to do that in openHAB (I'm not certain about HASS but I doubt it). Domoticz offers Google Blockly for visual rule-building which is a plus but it's limited when the time comes for heavy-lifting.

One nice thing openHAB and HASS share is the ability to use Node-Red. It lets you graphically compose programming logic (something like Premise's logic diagrams but more powerful). Node-Red was developed at IBM for the Internet of Things and can be used for general home automation without relying on openHAB or HASS or any other HA software.

Skim the community forums and you'll discover each new release introduces either a fresh batch of stability issues or breaking changes. The products are evolving, which is a good thing, but the QA aspect is not quite up to par with paid software.

After weeks of research, I chose to install openHAB on a Raspberry Pi 3. Mostly because it's more mature than HASS and it claims to support CM11A and UPB. I got as far as using the new UI to install the Yahoo Weather driver ("binding" in OpenHAB parlance) ... and instantly took a dislike to the process. It's the "new way" of doing things in openHAB, yet it felt so crude compared to Premise Builder. Despite all the reading I had done, actually sitting in from of my PC and using it fell way below my expectations. The concepts are similar to Premise, namely virtual Items you bind to physical Things via their Channels (i.e. bind Home objects to Devices via their Properties) but, holy hell, the way you do it is so tedious and clumsy.

I decided to take a holiday from openHAB and focus on what I'm missing in Premise, namely MQTT and a modern way of interfacing with Apple and Android devices (a fresh new face). While looking for an Android MQTT client, I accidentally discovered Home Remote (because it also supports MQTT). I realized that if I can use it to give Premise a face-lift then half of what I want is done. Adding MQTT support to Premise is more of a future-proofing initiative and not something I need today.

Sam, if you're still reading this, take some time to experiment with Home Remote. I've seen some impressive UIs created by others for controlling A/V equipment. The only hurdle I foresee is that you may also have a houseful of old, but functional gear, including old A/V equipment, and Home Remote will not support it out-of-the-box.

Sigh...  It makes me wish that V3 of Premise had made it out.  Not to mention the idea of having it released as open source.  Wish I knew who actually owned that code last.  I actually tried to trace it and made calls and sent emails to various entities post Motorola.  But no one knew anything.
 
Anyway, I'll take a look at Home Remote. 
 
The only thing for me that has stopped me from switching has been your problem of stuff.  I went head first into UPB way back when.  Then there is my whole house music setup.   Old school matrix switcher (Xantech).  None of the kids today seem to even understand why you'd use one.  For me, I don't even automate that much.  Basic scheduling on a few things.  LOTS of scenes.  And music.  80% of my use of Premise is to control music all over the house.
 
I ALMOST pulled the trigger on CQC.  But, frankly right now, I have other places that need my money.  And I have found like you, that all of the open source stuff just isn't there yet.  And probably won't be.
 
One of my biggest frustrations has been that so many people getting into this now have an App mentality.  The idea of one app/software to rule them all is anathema.
 
So I will keep watching this space

123,

Have you considered the ISY994i? It's probably not as featureful as Premise, but it has native integration for the Elk M1, as well as support for X10/Insteon and Z-Wave (the Z-Wave support is still a work in progress but is mostly there).

It has a pretty comprehensive rules engine, and in the V5 firmware, supports "Node Servers" which allow you to interface it with a wide variety of hardware and services. It also supports integration with Amazon Echo/Google Home.

It also sports a great user community and the company (Universal Devices) is very responsive and helpful.

Sent from my SM-N9500 using Tapatalk

Thank you for your suggestion but the ISY994i is not for me. https://www.universal-devices.com/residential/

First and foremost, it's a closed-source hardware solution.

Second, I see no mention of support for UPB (or MQTT).

Third, many of the features you described are paid add-ons. The ELK M1 option tops the list at an additional $99. To get all the functionality I currently have, minus UPB, the ISY994i would cost US$405. Device $199, ELK M1, $99, Network $49, Climate $49, Enhanced X10 $9.

Your Elk has a UPB module available, so the ISY would be able to control your UPB devices via the Elk.

I'll grant you there's no MQTT implementation for the ISY (yet!), although if you're feeling enterprising, there's no reason a node server couldn't be created to add MQTT support to the ISY. The ISY has a pretty well-documented API, as well as an open source Python library called Polyglot for developing node servers (although you are free to develop them in any language you want).

You're right in that the ISY is closed source hardware, but most of the node servers are open source. I'm in agreement with you in that in general open source is best, but at least for me, the ISY filled a need that had not yet been served by the OSS community.

While the ISY may cost a bit of money by the time you get all the modules, at least for me it was still cheap compared to what I spent on the M1 and outfitting my house with Insteon light switches.

Either way, best of luck to you and I hope you find a solution that works for you

Cheers

Sent from my SM-N9500 using Tapatalk

Adding UPB functionality to the ELK M1 means another expenditure for either their add-on serial port (to connect a UPB PIM) or even more money for ELK's UPB hardware. Combine that with the cost of the ISY and it's hundreds of dollars to get the functionality I already have ... minus the MQTT support I desire. If I have to 'roll my own MQTT' via a node server then that's the same task I currently face with Premise (without the additional hardware costs).

PS
I genuinely appreciate your suggestion but, as you can see, it's difficult to move to a new platform that offers the functionality I currently have, plus desired new functionality, without spending several hundred dollars. I'm trying to avoid that because moving to a modern HA platform would be nice but not worth that much money to me.

@123
 
Good to see you are doing well.  This looks very intriguing.  I can't wait to see the end results, keep up the good work
 
I haven't done much with Premise lately.  However, I will post a 4x20 VFD Matrix Orbital module for Premise once my case comes in a month or so.  Waiting for the case so I can test button functionality.  In my testing I have full integration with JRiver as well as volume functions.
https://www.matrixorbital.com/product_info.php?products_id=253
 
Custom case is similar to this one but rack mounted: http://www.atechfabrication.com/products/HeatSync_7000.htm
 
I bring this case up because your work here makes me think it would be neat to mount a larger phone into one of the custom cases from the site above.  One would have to send them the phone and pay some additional design costs though...  However, I guess success would depend on how well WIFI would work with the phone mounted in an aluminum HTPC case.  Now that UHD 4k backup and mkv playback is possible, the only thing left that an HTPC can't do in a superior fashion is decode Atmos or DTS-X, which doesn't matter to me right now.  When I say superior fashion I mean it too.  Playing back unconverted blu-rays or 4k video with a GTX 1080 card with MadVR as the renderer is superior to any stand alone player, plus the stuff you can do with audio is really neat too and on par with AV processors costing $15k and up.
 
Since Premise can track what is being played back (have this working for JRiver and was using it with KODI before), I assume that you could display song name and cover art, etc...  on a phone or tablet using polling.  Plus control anything in the house with one interface.  It would seem with the app you link to, one could have a single interface that talks to Premise, but also talks to other systems directly as needed (Phillips Hue, Sonos, etc...), bridging them into a single cross platform UI.  This would appear to be very useful indeed!

I've created my first Home Remote project, limited to controlling Lights. The most tedious part is defining the needed "HTTP variables" for each light. An "HTTPvariable" contains all the information needed to transmit data, to Premise, to control a light (such as controlling its PowerState and Brightness).

• If it's a simple on/off light you must define an HTTPvariable to represent its PowerState.
• If it's a dimmer then you need two HTTPvariables, one for PowerState and another for Brightness.

Each one of these variables contains 7 properties therefore a single dimmer involves editing 14 properties! There's the tedious part I was talking about. If Chuck's house has 93 dimmers, that's 93x14=1302 properties. Ouch! In fairness, creating any custom GUI will involve lots of editing. Such is the nature of the beast.
 
After entering all the necessary variables (and properties) for about a dozen lights, I looked inside the file produced by Home Remote. Everything is in XAML so it's human-readable. Here's a snippet representing just two lights: HallwayLight is a dimmer and GarageLight is not.
 
 

  <Sources>
    <HttpClient ID="0" ConnectionRetries="1" Name="Premise.Lights" IgnoreCertificateErrors="false" URI="http://PremiseServer" RefreshRate="1000">
      <Variables>
        <HttpVariable Name="HallwayLight_PowerState" Content="$HomeRemote.HallwayLight_PowerState.RequestedValue" ContentType="text/plain" Method="POST" URI="/sys/Home/Hallway/HallwayLight?e?PowerState" StatusSource="StatusRequest" StatusPath="//L[@N='HallwayLight']/@PS" />
        <HttpVariable Name="HallwayLight_Brightness" Content="$HomeRemote.HallwayLight_Brightness.RequestedValue" ContentType="text/plain" Method="POST" URI="/sys/Home/Hallway/HallwayLight?e?Brightness" StatusSource="StatusRequest" StatusPath="//L[@N='HallwayLight']/@B" />
        <HttpVariable Name="GarageLight_PowerState" Content="$HomeRemote.GarageLight_PowerState.RequestedValue" ContentType="text/plain" Method="POST" URI="/sys/Home/Garage/GarageLight?e?PowerState" StatusSource="StatusRequest" StatusPath="//L[@N='GarageLight']/@PS" />
      </Variables>
      <Headers />
      <StatusRequest Method="GET" URI="/sys/devices/customdevices/api?d??Lights()" Content="" />
    </HttpClient>
  </Sources>
 
 
It dawned on me that Premise could be used to produce this list. Instead of me typing all these details into Home Remote's Designer, I could have Premise generate it (in XAML format) and then I could copy-paste it into Home Remote's file. It would save a lot of typing-time and eliminate typing errors.
 
This envisioned "XAML Generator" will export all relevant Home objects (Lights, Appliances, SecurityZones, Thermostats, etc). I haven't created it yet but it's on the drawing board.
 
This isn't to say there won't be any work left in Home Remote. Just like in Premise, where you bind Home objects to appropriate Devices, you must bind each "control" you create (Button, Slider, ToggleSwitch, etc) to appropriate HTTPvariables.
 
For example, if HallwayLight's PowerState is represented by a ToggleSwitch control, you must bind the control to "HallwayLight_PowerState". Fortunately, there's no typing involved, just picking from a list of HTTPvariables (the list created by the "XAML Generator").


NOTE
 
For the curious, here's the "HTTPvariable" representing HallwayLight's PowerState.
 

<HttpVariable Name="HallwayLight_PowerState"
Content="$HomeRemote.HallwayLight_PowerState.RequestedValue"
ContentType="text/plain"
Method="POST"
URI="/sys/Home/Hallway/HallwayLight?e?PowerState"
StatusSource="StatusRequest"
StatusPath="//L[@N='HallwayLight']/@PS" />
 

It defines the variables name and parameters for performing an "HTTP POST" operation.

1. "Name" is self-explanatory.
2. "Content" is the payload to send to Premise (namely the new value for HallwayLight's PowerState).
3. "ContentType" indicates the payload is just plain old text.
4. "Method" is the type of HTTP operation (POST as opposed to GET or PUT or etc).
5. "URI" is the full path to HallwayLight in Premise plus the magical incantation "?e?PowerState". It indicates this operation will set the PowerState to whatever payload is in "Content".
6. "StatusSource" fuhgeddaboudit for now.
7. "StatusPath". Some background first. Way up top in the XAML example, there's "RefreshRate" indicating the polling frequency in milliseconds (1000 ms = 1 s). Basically, Premise is polled every second and it replies with a list of all lights showing their current status (in XML format). "StatusPath" contains an XPATH statement that efficiently extracts HallwayLight's PowerState from that list.
    

Hallelujah! Now I can officially stop development on my Dante's Inferno Minibrowser module... I think I will continue into the last circle...
 
I am thrilled with Home Remote - maybe as it (or I) evolves, it will allow more of an overall view of one's home, but I think that will take some time.
 
But I will also keep pressing and looking forward in 123's progress...and mine!

If you're itching to try this stuff, here you go!

Installation Overview

• Download and extract files.
• Install the HTTP_API module in your Premise Server.
• Install The Home Remote's Designer on a Windows PC.
• Load the sample Home Remote Project into Designer and customize it for your Premise Home.
• Within Designer, run the Simulator to test your customized project.

1) Download

• Download the attached zip file (THR-Premise_V1.zip)
• Extract its two files: Sample_V1.hrp and HTTP_API_V1.xdo

2) Install HTTP_API module

• Using Premise Builder, import the module (HTTP_API_V1.xdo).
• In Builder, right-click Devices > CustomDevices and select New > API. Don't modify the default name "API".
• Done! Now Premise will respond to status requests (Lights, Appliances, SecurityZones, etc). For example this URL requests the status of all lights. Premise will respond with a list of all (non-hidden) lights in XML format.
   
  
  http://PremiseServer/sys/devices/customdevices/api/?d??Lights()
   
   
  

3) Install The Home Remote Designer

• Designer (Windows PC only): http://thehomeremote.com/downloads/designer/setup.exe

4) Load the sample

• Start Designer and open Sample_V1.hrp.
• First thing to do is set the URI for your Premise Server.
• On the left-hand side of the screen, ensure Project > Devices > Premise.Lights is selected (click it). You'll know it's selected if the Variables list is populated.
• Now look over at the right-hand side and locate Properties > Settings > URI. The default value is http://PremiseServer. Change this to point to your actual Premise Server (host name or IP address).
• NOTE: I have not tested this with a Premise Server requiring authentication! However, I think this API works with or without authentication enabled.
• RefreshRate is set to 2000 milliseconds (2 seconds). That's the polling frequency. Change it if you wish.

5) Customize the lights

• Let's say you want to control a dimmer in your Premise Home called "/Home/First/Dining/Spots".
• In the Variables list, located on Designer's left-hand side, double-click the first variable "MantleLight.PowerState".
• In the popup form, replace every instance of "MantleLight" with "Spots".
• In "URI", replace "/Home/Family/MantleLight" with "/Home/First/Dining/Spots".
• Click OK to save your modifications.
• In the Variables list, double-click "MantleLight.Brightness".
• Repeat the instructions above for modifying the URI and replacing all instances of "MantleLight" with "Spots".
• Click OK to save your modifications.
• The final touch is to change the Label from "Mantle" to "Spots".
• The center of Designer's screen shows a simulation of an Android phone. Locate the Label "Mantle" and click it.
• Over on the right, locate Properties > Common > Text > Text. Change "Mantle" to "Spots".
• Save the modified project (File > Save).

6) Run the Simulator

• Locate the Green "Start" button in Designer's ribbon menu (upper left). Click it.
• Designer should now be communicating with your Premise Server and polling it for the status of all lights every 2 seconds (or whatever value you have in RefreshRate).
• Turn on "Spots" by clicking its ToggleSwitch to the on position (right). The actual light in your home should turn on. Within 2 seconds or less, its Slider should indicate the light's current Brightness (ostensibly 100%).
• Move the Slider to the midway position (50%). The actual light in your home should dim to 50%.
• Turn off "Spots" by clicking its ToggleSwitch to the off position (left). The actual light in your home should turn off. Within 2 seconds or less, its Slider should indicate the light's current Brightness (0%).

Assuming all of this works for you, you can continue to customize the sample. When you're done, the next step is to install Home Remote's Android client (from the Google Play store) on your Android phone. Copy Sample_V1.hrp onto your phone and load it into the Home Remote client (use an Android file manager app, transfer it via Google Drive, DropBox, etc or just email it to yourself).

Each Home Remote project is targeted for a specific platform and screen-size: Windows, iOS, Android. If you want to run Sample_V1.hrp on an iPhone, use Designer to change the "Design Platform" from Android to iOS. Then change the Screen Size and Aspect Ratio to match your iPhone model. The appearance of the simulated phone will change accordingly. You many need to adjust some of the controls to fit the iPhone's screen dimensions. Proceed to download Home Remote's iOS client (from the Apple App store) and copy Sample_V1.hrp to your iPhone.

As I was reviewing my code and how I was polling vs how you described HR polling, I think we did it somewhat similarly, which may how I'm able to poll many objects without the slowness one might expect. I get the latest status on all of the objects I'm interested in, (e.g. lights), then replace the status for each object with the new status, using the ObjectID as the <div> css ID/Class variable.
 
Thanks for sharing the THR! After working with THR last night, it seems promising; tying it to Premise gives it even more promise...
 
[update] 123! WOW!  This is absolutely fantastic!! Great job in deciphering it and making it a winning combo. Well done!