What makes the UI slow?

#1

I’m working on a piston which is “complex” and has also become “large”. It currently reports a size of 80% with no logs. Ideally, I’d like to know what makes the UI slow, would it simply be the size or the complexity. When I say complexity, I’m just talking about using a lot of IF’s and some nesting of IF’s. I have used large field names, mainly so I remember what they do! I also have a lot of comments.

#2

The user interface should have no bearing on the speed of execution.

UI speed is based on the speed of your machine, and perhaps what browser/plugins you are using.

Or another way to say this:
A slow UI does not mean a slow execution… just like
A fast UI does not mean a fast execution.
(they are entirely different animals)

#3

I don’t have an issue with execution speed, that seems really good to be honest. The problem I’m having is with editing\amending a piston. When I click on add and then save the new statement it can take a minute or longer to return to the main piston script.

#4

Oh yes, I know that period all too well… (watching the chunks increasing) The page is not slow while viewing or editing, only while in transition of data from web browser to the hub. (during the save)

This is normal, and to be expected on behemoths…

My recommendation is to not be hasty during that time period.
If you are impatient and hit refresh or try to leave the page, you may corrupt the piston.

20 years ago, to get reliable CDROM burns, one would have to [do a bunch of crap] to make sure the PC was not doing anything else but focus on the current read/write process.

Now I am not saying it is that fragile here, but I treat that 30 second save window with the same demeanor.

By the way, I am referring to delays when saving the piston… not a single line command.
(If you are referring to slow single lines, then I would try another browser)

#5

I’ve had the issue with both single lines and saving! I’ve decided to take a different approach, rather than one piston to handle one rooms lights, I’ve split it into 4 pistons and a raft of global variables.

It seems to all work fine when the pistons aren’t too big. I guess my tendency to aim for a softcoded framework has led to code bloat and perhaps overkill. But, I know from experience, in 12 months time when I want to make a change I’ll have forgotten how it all works and will more likely break it! Soft coding all the way for me! :sweat_smile:

#6

This is often a good move. Smaller pistons means less processing at each event, so your response times will improve. (plus, you will have “elbow room” to grow in the future)

It may be boring, but making notes is the best advice for this.

#7

I’ve changed everything to smaller pistons. I now have four, One picks the default scene (based on location mode, time of day etc), two sets the scene based on button presses, three monitors and performs Auto on and four monitors and performs Auto off.
I have to say it all works really well. Each piston is small enough to not need anything more than the comments in the piston.
I see two potential long term problems:

  1. I will end up with a LOT of pistons when I do the whole house and to support this model of 4 pistons per room just for lights.
  2. I used a lot of global variables to define the scenes and some I use as triggers for the pistons.

It’s a shame we can’t use some sort of data store as most of my globals are constants (scene definitions). I didn’t want to define them in all four pistons as that would be more work when\if a scene definition needs to be changed plus there’s always the chance I won’t keep them synced!

#8

For what it’s worth, I have over 450 pistons in my main house. I use categories on the Dashboard to help keep myself organized, but I also use naming tactics to keep similar pistons grouped together.

If you were trying to condense a bit, I bet your “auto-on” and “auto-off” pistons could be combined into a single piston.

@globals make for a decent data storage. You can also store your data in many other places, such as a Raspberry Pi, or a Google spreadsheet.

#9

I did consider condensing the AutoOn and Off but, I thought meh…May as well go the whole hog and keep each function separate.I’ve gone with naming convention but categories is a good idea too.

I’m very interested in storing data in a google spreadsheet. I’m going to google that next for an example. The Raspberry Pi is also interesting. I have one of the original’s I bought just to see what the fuss was about. I’ll save that experiment\project for a rainy day :smile:

#10

Such as leaving comments in the piston, itself.

#11

Here are a couple of links to get you started:

I am a big fan of this as well…
(at least, until my piston gets ginormous, and I start trimming the fat, LOL)

#12

Well, I’ve had a play with google sheets and based on the links WCmore added and came up with this:

function doGet(request) {
if(request != null) {

var ss = SpreadsheetApp.openById("XXXXXXXXX");

var tt=request.queryString;
var sheet;
var MaxScenarios = 20;
var Scenarios;
var FieldNames;
var VariableRowNumber = 0;
var LastScenarioColumnNumber;
var ReutrnData;
var i = 0;

sheet = ss.getSheetByName(request.parameter["XtabX"]);    

if(sheet) {
  Scenarios = sheet.getRange(5,3,1,MaxScenarios).getValues();
  Logger.log("Top");
  Logger.log("Scenarios: " + Scenarios);
  Logger.log("Scenarios.length: " + Scenarios.length);
  
  FieldNames = sheet.getRange(5,1,24,1).getValues();
  Logger.log("FieldNames: " + FieldNames);
  Logger.log("FieldNames.length: " + FieldNames.length);

    if(tt.search("Var")>=0) {
      for (i = 0; i < FieldNames.length; i++){
    
        if (FieldNames[i] == request.parameter["Var"]){
          VariableRowNumber = i+1;
          Logger.log("VariableRowNumber: " + VariableRowNumber);
          break;
        }
      }  
      if (VariableRowNumber > 0) {
        LastScenarioColumnNumber = Scenarios[0].indexOf("");
        Logger.log("LastScenarioColumnNumber: " + LastScenarioColumnNumber);
        ReturnData = sheet.getRange(VariableRowNumber + 4,3,1,LastScenarioColumnNumber).getValues();
      }
    }    
}

return ContentService.createTextOutput(ReturnData);

}
}

It works a treat. Allowing me to store variables on different tabs and lookup them up by name. I went with storing the variables down the rows and the values across the columns to help support easier retrieval of arrays as that’s what I primarily want to do.

I struggled with the language, still not entirely sure which language it is! I couldn’t find a common way to search a column and a row! It was much simpler to search a column… Any help or insight any one can offer would be very welcome. :blush:

I built a test piston to try it out:

WeobcoreGoogleSheetsTest
WeobcoreGoogleSheetsTest.jpg1178×1436 309 KB

It takes some time to load so many that the piston seems to timeout. But, adding in the waits seem to fix that. Not that I would need to load so many into a single piston but, when testing :slight_smile:

I figure, I would add an “if blank” then load it and then some sort of trigger to reload if things change, perhaps overnight.