Metrics definition question?

[HeneryH]

In the case of the SwitchMote, why are there two separate metric definitions (each with a hard-coded value) for each switch state rather than one definition with two values?

I'm sure there is a good reason but with me trying to write my own metric files I want to try to understand the pros/cons of the different techniques.

As is:

Code Select Expand

  //SwitchMote buttons
  SMB0_OFF : { name:'B0', regexp:/BTN0\:0/i, value:'OFF'},
  SMB0_ON : { name:'B0', regexp:/BTN0\:1/i, value:'ON'},

Why not:

Code Select Expand

  //SwitchMote buttons
  SMB0 : { name:'B0', regexp:/BTN0\:{some sed for the number}/i, value:''},

Or perhaps change the sketch to return ON/OFF rather than 1/0 then use:

Code Select Expand

  //SwitchMote buttons
  SMB0 : { name:'B0', regexp:/BTN0\:(ON|OFF)/i, value:''},

I'm comparing to the thermostat metrics as an example:

Code Select Expand

  //Thermostat specific
  HOLD : { name:'HOLD', regexp:/HOLD\:(ON|OFF)/i, value:''},
  MODE : { name:'MODE', regexp:/MODE\:(COOL|HEAT|AUTO|OFF)/i, value:''},

Later on for the button definitions for the mote I see the use of these metrics to define the color of the button:

Code Select Expand

  SwitchMote: {
    label   : 'Light Switch',
    icon : 'icon_switchmote.png',
    controls : { B0 : { states: [{ label:'B0 (off)', action:'BTN0:1', css:'background-color:#FF9B9B;', icon:'power', condition:''+function(node) { return node.metrics['B0'] ? node.metrics['B0'].value == 'OFF' : false; }},  //http://api.jquerymobile.com/icons/
                                { label:'B0 (on)',  action:'BTN0:0', css:'background-color:#9BFFBE;color:#000000', icon:'power', condition:''+function(node) { return node.metrics['B0'] ? node.metrics['B0'].value == 'ON' : false; }}],
                       showCondition:''+function(node) { return (node.metrics && $.inArray('B0', Object.keys(node.metrics))>-1);}},
                B1 : { states: [{ label:'Off', action:'BTN1:1', css:'background-color:#FF9B9B;', icon:'power', condition:''+function(node) { return node.metrics['B1'] ? node.metrics['B1'].value == 'OFF' : false; }},
                                { label:'On',  action:'BTN1:0', css:'background-color:#9BFFBE;color:#000000', icon:'power', condition:''+function(node) { return node.metrics['B1'] ? node.metrics['B1'].value == 'ON' : false; }}]},
                B2 : { states: [{ label:'B2 (off)', action:'BTN2:1', css:'background-color:#FF9B9B;', icon:'power', condition:''+function(node) { return node.metrics['B2'] ? node.metrics['B2'].value == 'OFF' : false; }},
                                { label:'B2 (on)',  action:'BTN2:0', css:'background-color:#9BFFBE;color:#000000', icon:'power', condition:''+function(node) { return node.metrics['B2'] ? node.metrics['B2'].value == 'ON' : false; }}],
                       showCondition:''+function(node) { return (node.metrics && $.inArray('B2', Object.keys(node.metrics))>-1);}},
               },
},

[HeneryH]

While my original root cause has been fixed, I'd still be grateful if someone could explain the reason for two metrics with hardcoded values rather than one metric with two values. 

Thanks

[Felix]

Yes there are good reasons why this was done this way. Not that it could not be done better 

In fact, they are "the same metric" (B0). They are simply indexed with different names because you have to, in javascript objects. The name of the metric is what matters here, and that is the same. You could define as many states with as many custom values this way, both string (for humans to understand) and numeric (to keep logging nice and easy and compact, and keep computers happy).

You will notice that B0 is not graphed. So for this metric, yes, you could write it simpler, or do it some other way, in a single definition.
But I wrote it more explicit, so if someone wanted to graph it, they could just copy the B1 (the main button) definition.

A better example to explain why, is the B1, main button. That button is by default logged. You cannot log strings in the DB. So you cannot regex capture ON/OFF and store it. So yes, you could rely on your sketch to send you the right value, but I prefer not. The metrics have to be flexible enough to take any value, and then log a different value in the DB. For switches this is on/off or 1/0 as a logged value. For UI purposes we want strings, for logging we want numbers, these are explicitly defined, and you cannot combine both in 1 metric definition. For that reason it's simpler to define it separately.

Making more sense?

[HeneryH]

Yes, thank you.