Haiku UPB Status Updating

[lupinglade]

Regardless of whether you decide to switch to HLC, this is useful for links where the link affects more than just a single room. Scripting it in HaikuHelper would not be difficult at all, along the lines of:
 


function onUPBLink(cmd, link) {
  if(cmd == 1 && link == 240) {
    controller.unitWithNumber(10).requestStatus();
  } else if(cmd == 0 && link == 241) {
    controller.unitWithNumber(11).requestStatus();
    controller.unitWithNumber(12).requestStatus();
    // etc...
  }
  // etc...
}


The way you actually want to handle the logic is of course up to you.

 

[tannebil]

Thanks Desert_AIP and everyone else for the detailed answers. I appreciate the time and thought everyone put into it.
 
It all started to make sense once I realized that the Omni doesn't understand anything done in UpStart so everything outside of the "standard" HLC/UPB configuration has to be done in programming.  Obvious to all of you but until that moment, I was trying to understand "why" when the answer is "just because". I've been using Elve and, since it understands UpStart, I never gave it a thought when I switched.
 
Of course, understanding that doesn't necessarily mean that the choice is suddenly clear.  I think it's one of those questions where the answer is "it depends", but at least now I to understand some of the things it depends on.
 
I'll post an update once I give something a go.
 
Thanks again.

 

[tannebil]

Regardless of whether you decide to switch to HLC, this is useful for links where the link affects more than just a single room. Scripting it in HaikuHelper would not be difficult at all, along the lines of:
 


function onUPBLink(cmd, link) {
  if(cmd == 1 && link == 240) {
    controller.unitWithNumber(10).requestStatus();
  } else if(cmd == 0 && link == 241) {
    controller.unitWithNumber(11).requestStatus();
    controller.unitWithNumber(12).requestStatus();
    // etc...
  }
  // etc...
}


The way you actually want to handle the logic is of course up to you.

 

function onUPBLink(cmd, link) {
if(link == 10 || link == 11) { // Match link
controller.unitWithNumber(3).requestStatus();
}
} 
 
I tried this script and the issue I'm having is that most lights come with a 3.3 second fade out of the box.  The requestStatus happens before the fade completes so I end up with levels like 25% (fading on) 76% (fading off) when requesting status.  Is there a way to defer the requestStatus command without locking the event onUPBLink event loop?
 
I tried using setTimeOut but the status never updates with this syntax.
 
      setTimeOut(function(){controller.unitWithNumber(3).requestStatus()},5000);
 
An array with all the fade rates for the links would be a nice touch so that the status updates were timely.  Or if I was going to go crazy, it could even run a status loop every n seconds so that Haiku showed a close to real-time status during long fades.

 

[tannebil]

I guess it's a better lesson when you figure it out for yourself. My problem was that setTimeOut had to be set to a variable, i.e.
 


var myUPBTimer = null

function updateUPBstatus(unit,delay) {
myUPBTimer = setTimeout(function() {
controller.unitWithNumber(unit).requestStatus();
},delay);
}



 

function onUPBLink(cmd, link) {
  if(link == 8 || link == 9) { // Match link
updateUPBstatus(7,4000);
}
 
 

Next up is to use an array so I don't have to hard code the delays for each link.

 

[tannebil]

Looks like I'm going the HaikuHelper route.  It only takes a couple of lines of JavaScript to keep each link synced and I don't have many extra links to update since the load connected to the switch already stays synced.  None of my links are system critical so if HH is unavailable, it's not going to matter.  
 
Thanks to everyone for helping me out with this issue.