Archived Forum

Nice idea, I guess you could sent the calibrations in the control packet. you'd need to assign the calibration value received using the packetgen example code to the calibration values in the emontx sketch.

If you copied the following code into the emontx sketch at the start of the loop here:

https://github.com/openenergymonitor/emonTxFirmware/blob/master/emonTxV3...

if (rf12_recvDone() && rf12_crc == 0 && (rf12_hdr & RF12_HDR_CTL) == 0)
  {
    int node_id = (rf12_hdr & 0x1F);
    // Emoncms node id is set to 15
    if (node_id == 15)
    {
      // The packet data is contained in rf12_data, the *(EmoncmsPayload*) part tells the compiler
      // what the format of the data is so that it can be copied correctly
      emoncms = *(EmoncmsPayload*) rf12_data;
      Ical1 = emoncms.ical1;

    }
  }

with the packet definition at the top of the sketch, that might work.

OK, I will try your code as soon as possible. Not before end of january. For sure, it will ease the calibration setup.

I would like to be able to do same thing for the node ID. It will ease the deployment of several EmonTx as they all come with the same Node Id in the main EmonTx sketch. Powering them one by one should allow to give them a specific node ID. Is it technically possible to modify the sketch in that way  ?

Thank's

Eric

I find this very interesting and as I am currently working on remotely uploading sketches from 1 pi to multiple nodes via ssh this idea would mean sketches could be uploaded to multiple nodes and then be tailored rather than manually editing the sketch to each node prior to install and calibration adjustments would no longer require replacing the sketch....brilliant!

Would it work to use the sketches existing nodeID variable to determine if the package is valid rather than hard code? ie change line 5 of Trystans code from 

if (node_id == 15)

to

if (node_id == nodeID)

and add a new variable to the packetgen transmission called new_id, this value could be used to change nodeID for example adding the following before the 2 closing braces of Trystans example

{

if (new_id != 0 && new_id != nodeID)          

// added 2nd condition to prevent rfm reinitializing more than once

{

nodeID = new_id

rf12_initialize()

}

}

If the default node id in the sketch is never used as a actual permanent node id and each nodes id is changed on install then any new nodes could be added without powering down existing nodes and as the node id is to remain the same during any calibration adjustments using a value of 0 in new_id.will avoid any change to node id or rfm settings.

I apologise in advance for any code errors (especially the rf12_initialize() line) but I'm sure you get the gist of my suggestion.

Node 15 is the control packet nodeid, are you thinking that the rfm12pi sends out packets destined for a particular node on the target node id? It would be possible but would need changes to the current implementation of packetgen to allow specification of the nodeid that it should be sent as.

Okay scrap that then!

how about 2 new variables in the packet old_id and new_id? I think the target node would need to be identified in any case as the calibration figures may not be the same across all nodes

if (rf12_recvDone() && rf12_crc == 0 && (rf12_hdr & RF12_HDR_CTL) == 0)

{

int node_id = (rf12_hdr & 0x1F);

// Emoncms node id is set to 15

if (node_id == 15)

{

if (old_id == nodeID)

{

// The packet data is contained in rf12_data, the *(EmoncmsPayload*) part tells the compiler

// what the format of the data is so that it can be copied correctly

emoncms = *(EmoncmsPayload*) rf12_data;

Ical1 = emoncms.ical1;

if (new_id != 0 && new_id != nodeID

          {

          nodeID = new_id

          rf12_initialize()

          }

}

}

}

This way although the transmission is received by all nodes only the target node would update its calibration data and then only if there was a non zero value in new_id that differed to the current node id would it update nodeID.

The more I think about updating nodes via PG (packetgen) the better it sounds, but if I understand the how PG works correctly it is designed to continually tx one fixed set of variables, which may not be ideal for this purpose and so I wonder can PG be altered to either stop transmitting or even better accommodate multiple tx profiles?

Maybe a tx interval of "never" in the "Send packet every:" menu could be a quick fix but that would leave the PG unusable for anything else and that would be a shame.

If a second profile could be loaded temporarily to do the updates and then the first profile reloaded to resume normal activity that would be great as the original functionality would be retained along with the additional function.

Another option may be to use a TX id as the first variable so that more packets can be sent at independent intervals and then the nodes could just process relevant transmissions eg TX_ID 10 has heating data and is repeated every 5 secs, TX_ID 11 has node calibration data and is transmitted once per second for 30 seconds from initiation, TX_ID 12 with other data every 10mins or every hour etc. all the variables could still be added to the PG page with an additional TX_ID field to attach them to a transmission. 

or is there a simpler method?

I must also point out I think the project is really great as it is and I'm only bouncing ideas to find out what's possible and if anyone else has similar thoughts :-)

I agree, multiple packet types, and ability to push packets in a non periodic way would be useful.

One of the things I think would be great to be able to do is have near realtime control. Lets say we have a light button on a dashboard that when that light button is clicked (this would happen in the browser / javascript) the browser immediately sends an AJAX or websocket request up to the server which updates the light state variable in the packetgen variables list. Packet gen then sensing that a variable has changed immediately transmits the updated packet state. So no waiting for 5-10s.

I guess the ideal is to have the flexibility to send any thing we might want to in that 66 byte packet and to be able to specify the nodeid and group it is transmitted on and then have a special interface that generates nodeid changing control packets and so on.

For anyone interested in playing about with emoncms creating new interfaces modules and so on I created a tutorial for this a couple of weeks back its on the blog and on github here too https://github.com/emoncms/development/tree/master/Modules/myelectric_tutorial