Premise A fresh new face for Premise.

Motorola Premise
A few thoughts about improvements:
Currently, the API lets you request separate categories of Home objects like Lights, Thermostats, Appliances, SecurityZones, TemperatureSensors, etc. In other words, each one is isolated from the other and requesting the status of all Lights won't also deliver the status of all Appliances (that's a separate request). This is efficient if, for example, you create a Home Remote project that is just for lighting and you don't care about the rest. It's still efficient if you're only interested in Lights and Thermostats (two separate status requests).
If the goal of a Home Remote project is to view/control just about everything in your Premise Home then separate requests, for each category, is just a needless complication. In this situation, a single request that delivers the status of everything is probably the neater, simpler solution (I think).
Adding an "All()" function to HTTP_API won't be difficult. HOWEVER, it'll (probably) be a breaking change because I'll need to modify the structure of the XML response so that its contents (now containing soup to nuts) remains easy (and fast) to extract stuff out of it.
On the Home Remote side of things, I've explored the ability to minimize the need for frequent polling. Let's face it, there's no need to hammer away at the Premise Server every second, asking for status, when the UI is dormant (i.e. displayed on your phone but not being actively used). All it needs is some "lazy polling", perhaps every 10 seconds or so, to update the UI in case someone turns on a light somewhere in the house or opens a door or whatever.
What's needed is something Premise users understand and that's an "On Change" event. Currently, when you turn on a light's ToggleSwitch in Home Remote's UI, it transmits a command to Premise to activate the chosen light. Ideally, it should also immediately follow up with a request for the light's new status (or after, say, a 100 millisecond delay). In other words, on change of the ToggleSwitch, send the command AND ask for updated status.
In order to do this, Home Remote's controls need the added functionality of scripting. The author, Bill Venhaus, has started rolling out this ability, called Events. The first control to get it is Button. You can use JavaScript to do custom stuff when a Button is activated/deactivated/pressed. When other controls get this ability, it may become possible to create this "On Change" style of requesting status (with "lazy polling" for good measure) and not have to poll at a high frequency.
Home Remote supports MQTT. If Premise supported MQTT there'd be no need for polling. MQTT is a publish/subscribe protocol. Home Remote would subscribe to all lights and whenever a light's state changed Premise would publish it. All subscribers would receive the published state-change. No polling needed. It would also open Premise to communication with many other MQTT-aware devices. I've started exploring the MQTT protocol but it'll take awhile before I can figure out how to implement it in Premise. Much longer if I can't create it as a Module and have to write a native driver in C++.
123 said:
... 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. ...
Think bigger!!!

It dawned on me that everything in a Home Remote project is defined with XAML. Everything; all pages, controls, their size and position. What does this imply? It means the envisioned "XAML Generator" could scan a Premise Home and crank out XAML for a complete and functional Home Remote UI. How cool is that?

If this sounds vaguely familiar, it should. It's close to how Automation Browser works. It scans your Premise Home and automagically produces a browser-based UI. It creates a separate web-page for each Room and display the Room's contents (lights, appliances, sensors, etc). Not very pretty but functional (and requires no special skills to create).

The principal difference is what I have in mind can't be as tightly integrated as Automation Browser (add/remove a light in Premise Home and the browser is automatically updated). However, that's not a major drawback. The biggest advantage is, with little effort on your part, you get a functional UI in Home Remote. You're free to use Designer to modify all the controls and that's much easier than defining everything from scratch.

Of course, this idea is more ambitious than what I originally envisioned but much more appealing. Chuck would be spared having to configure 93 controls for his 93 lights! 
I appear to have found a showstopper for controlling Premise with an iOS device and Premise's WebClient protocol. 
The protocol uses HTTP POST and the following style of URL to set a light's PowerState and Brightness.
[URL="http://PremiseServer/sys/Home/Hallway/HallwayLight?e?PowerState%C2%A0"]http://PremiseServer/sys/Home/Hallway/HallwayLight?e?PowerState [/URL]
The HTTP POST message body should contain -1 to turn on the light (or 0 to turn it off).
If you download iCurl from the app store and submit an HTTP POST request (as described above), Premise will execute the command (i.e. set HallwayLight's PowerState to -1). However, iCurl now expects something back from Premise (not just iCurl but any app that relies on iOS's service for talkin' HTTP). All Premise does is reply with the standard "HTTP 200 OK" acknowledgement but it doesn't send back anything in the message body.
This terseness seems to be good enough for Windows and Android because they immediately stop waiting and consider the transaction done. Not on iOS. iCurl waits for 60 seconds, ostensibly until its timeout timer says "Uncle!", then reports that nothing came back from Premise in the Header nor the Content.
That's bad because Home Remote's iOS app also relies on iOS for handling HTTP transactions and it also ends up waiting for a reply that never arrives (waits about ~30 seconds). As a result, the controls don't behave as expected (long delays that affect responsiveness and accuracy) and the UI becomes unusable. Phooey!
I don't believe there's anything I can do on Premise's side because the WebClient Protocol is hard-coded into Premise's WebServer. It just won't reply to an HTTP POST beyond the standard bare-bones acknowledgement.
The author of Home Remote said he'd look into the issue at a later date. I hope he can fix it but I have my doubts because the sticking point appears to be within the iOS HTTP service. We'll see.

He says he's encountered other hurdles with the iOS HTTP service and had to include an alternate means. He says he may be able to use this alternative to fix this problem as well. Stay tuned.


  • iCurl Test Result 1.png
    iCurl Test Result 1.png
    74.2 KB · Views: 10
The 'iOS showstopper' I mentioned in my previous post has been eliminated.
Bill Venhaus, Home Remote's developer, has provided an alternate means of HTTP communications for its iOS app. This alternative fixes the problem mentioned above and now things work as they should between Home Remote's iOS app and Premise.
Currently, the correction involves manually editing the Devices.xml file and adding AlternativeImplementation="true" to the HttpClient definition.  Details here:
This is great news, can't wait to see (and use) the final product :)

I was researching the Home Remote app and note that the developer supports Amazon Alexa skills.  Since I have Premise being controlled via a few Echo devices, it would seem that this app not only will give us a super nice GUI, but will leverage the same voice control I've been using for 3-4 years without issue.
The only bad part is you'll have to say the Amazon skill name followed by the command.  You'll also have to write your own Amazon skill on AWS and forward these to your Premise server.  In the description of my youtube video on voice commands, I included the javascript I used for my custom AWS skill.  I remember it wasn't hard at all to setup and get generic commands working with the Amazon Echo.  One would have to setup the Premise module I wrote for voice control too, but there is a video showing how to do that part.
Using AWS has been 100% free for me as it is very doubtful I will ever use up the allotted free execution time.
FYI everyone: 123's example works again after I updated Home Remote Designer. If you run into an error, be sure to update Home Remote Designer.
A few instructional notes to include:
1. After you make the .hrp file using Home Remote Designer, save it to your device.  Then from the Home Remote app, go to restore and select the HRP file you saved to your device.
2. If you include Alexa Voice Service, do NOT click the second popup in the designer that offers to auto-generate variables.  This will delete all variables even ones under the Home Remote Designer device named "Premise.Lights."  Alexa voice service will still work, and has no real variables.  It lets you access any skill you have on your Amazon Alexa account, which is great because I setup a free developer account and created a skill on AWS that lets me use the SpeechParser module with my Amazon Echo devices. Now, I can seamlessly use Home Remote and just click mic at the top of the screen and say "Ask Premise" [or whatever the name you pick for your custom Alexa skill] followed by any SpeechParser command. I can't believe I have a really nice GUI on the same screen/in the same app that can also access the powerful Alexa voice service; very cool! 
If you want SpeechParser, it is posted on my YouTube account, check the description section of this video:   Also be sure to watch videos 7.2 and 7.3 that cover more details on the SpeechParser module setup.
3. Authentication also works, use this format: http://username:password@PremiseServer:portNumber   Be sure to note that the password cannot contain an @, and that many browsers are not going to work if you try to test the URL with an embedded username and password.  It does work in the Home Remote Designer simulator and I also tested this under Android.
Status Update
I've completed an alpha version of the "ExportHome" function. It export lights from Premise into a format usable by Home Remote's Designer. Eventually it'll export more than just lights but that's where I'm at now.
I tested it with Premise's "Large House" example and it successfully exported approximately 250 variables! A basic light Switch has one variable (PowerState) whereas a Dimmer has two (PowerState and Brightness).
There is one requirement for this to work and it is this: your Premise Home must not have identically named lights in the same Room. Normally, you would not do this. A bedroom with two lights bearing the same name, "TableLamp", will be difficult to differentiate when attempting to control them! If you were to import these identically named objects (residing in the same Room) into Home Remote's Designer, it'll crash. You're free to have duplicated names in different Rooms (Bedroom/TableLamp, LivingRoom/TableLamp), just not in the same Room.
FWIW, I'm thinking about creating a function that will scan your Premise Home and report any duplicated names residing in the same Room. However, the task is a bit involved and I may only get to it once everything else is finished.
The attached image shows Home Remote Designer with all the lights exported from the "Large House" example. I mentioned earlier that creating these variables manually is a tedious task. You only have to look at what each variable contains (look at Properties on the right hand side of the screen) to appreciate the magnitude of the job when faced with entering dozens of lights, appliances, security zones, sensors, etc.


  • HR Designer with imported Premise variables.PNG
    HR Designer with imported Premise variables.PNG
    512.1 KB · Views: 10
123 said:
Of course, this idea is more ambitious than what I originally envisioned but much more appealing. Chuck would be spared having to configure 93 controls for his 93 lights! 
Okay - I must 'fess up. For the minibrowser, I have included an "All Lights" function, just like the AB. I just generated a few dozen phantom lights and outlets to a) give me a testbed b) see whether polling (yeah, yeah, I know) would crash the browser or hang Premise. No crashes or hangs...
93 lights? I don't think I put that many on my Christmas tree!!
A long overdue update:
I discontinued using The Home Remote about a year ago and chose to use openHAB to provide Premise with a modern UI. The two systems communicate via MQTT and response time is excellent. Six months later, I switched to Home Assistant (again, MQTT serves as the glue). It provided me more of what I wanted for a UI.
My wall-mounted touchscreen was taken down years ago and my own needs require only basic UI functionality. Nevertheless, I have spent some time tweaking my Home Assistant-based UI to provide a balance of information and convenience. However, there's so little eye-candy that it's not worth sharing. For example, I only want to see which doors are open, not doors that are closed, so normally there's nothing to see concerning doors.
I've seen elaborate UI's that wouldn't be out of place in the cockpit of a Dreamliner. However, I recently came across one that made an impression on me because of the skill in emulating Apple's iOS UI. The default appearance of Home Assistant's Lovelace UI is serviceable and attractive but doesn't look like Apple's iOS UI. This individual (Jimzz011) leveraged Lovelace's flexibility and produced a very good approximation of it.
The details (screenshots, video demo, configuration files, etc) can be found in this post:
and in his GitHub repo: