123
Senior Member
Thanks!
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++.
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++.