Archived Forum

Responding to my own question:

A new input processing action would fix the above, I believe. Something along the lines of "Signed to Unsigned", which would add a certain value (configurable?) to the input data, if the input data<0. Otherwise leave do nothing.

Hmm... Unless someone is already working on this I guess I'll have to brush up my php skills..

This is really Trystan Lea's area. I don't know the emonCMS system at all, however my feeling is that it doesn't actually matter now the data is passed around (as an array of char, signed integer or unsigned), it's how it is interpreted at the destination that matters. So I think you're right in thinking the problem is in the PHP.

As a work-around, can you add a number at source (i.e. base your temperature scale at -50°C, say) then subtract it again in the processing?

So this actually turned to be pretty easy. Adding a new input processor to the already existing ones is next to trivial (if I've understood things correctly).

Making the following changes to the Models/process_model.php fully solved my problem:

After the existing process definitions:

$list[20] = array(
    _("Combine to long"),
    1,
    "combine_to_long",
    0,
    0
  );

The define the function combine_to_long at the end of the same file:

function combine_to_long($id, $time, $value)
{
  // Note: This process should ONLY be applied to the most significant word in a long
  if ($value < 0) {
    $value_msword = ($value + 65536) * 0.10 * 65536;
  }
  else {
    $value_msword = $value * 0.10 * 65536;
  }
  // Most significant word now ready. Add least significant word

  $result = db_query("SELECT value FROM input WHERE id = '$id'");
  $row = db_fetch_array($result);
  $value_lsword = $row['value'];

  if ($value_lsword < 0) {
    $value = ($value_lsword + 65536) * 0.10 + $value_msword;
  }
  else {
    $value = $value_lsword * 0.10 + $value_msword;
  }

  return $value;

}

A couple of notes:

a) I needed to scale down the values by a factor of 10. I took a shortcut and placed that scaling directly in the function. With a bit of retrospect I should instead have used the scaling process - it would make the above code more usable. 

b) The above input processor should be applied to the most significant word. For example, if a long value is sent from the tx node as node1_4 (least significant word = 2 bytes) and node1_5 (most significant word = 2 bytes), the above should processor should be applied to the node1_5 input, and node1_4 should be given as parameter to the processor. 

Works like a charm!

Trystan: feel free to include this in the standard code base if you find it useful. Or is the preferred way a git pull request?

Hello Goran, that's an interesting idea to move the data type conversion to emoncms as input processes, I wonder if there would be a better initial format for the nanoderf to send rather than 2byte integers?

You need a struct or a union in PHP!  SO has some suggestions.

Well... I guess you just have to decide on a way to encode the data, and then stick to it. And then create whatever type casting functions that are needed. 

In my case I get 4 byte long integers via RS-485 from an energy meter. I get them as two two-byte words from the meter, LSW first. So at the tx node I just create a regular C long out of those two words, assign that long to a variable in an array and send it off over RX with the jeelib. Exactly the same way your tx node does, in other words. It's easy, clean and it works. I like..