Undefined node list up

I I replaces to LowPowerLab RFM69 driver.
Only node 8, 9 send to emon hub.
but other node came up which is not exist.
Please advice me how to find this node comes.

They are “noise” picked up by the RFM network usually.

I notice you are using LowPowerLabs so i’m unsure how much of this will be relevant to you but ordinarily, with JeeLib . . .

When a transmission is received by the RFM2Pi/emonPi it has to pass CRC, this filters a lot of noise (mainly transmissions from non-JeeLib/OEM devices eg doorbells, car remotes, garage openers etc etc) but occasionally unwanted stuff gets through.

I suspect (but unproven) when there is enough noise, the values found in the CRC bytes occasionaly just happen to be correct by chance.

It would ordinarily be quite unusual to have so many in such quick succession, maybe after not checking for a few months I might see a couple. I do not know if what you are seeing there is due to being in a particularly noisy airspace or the LPL lib not filtering to the same level as JeeLib?

They are easier to remove than stop, although that is a far from ideal solution I know. http://server.com/emoncms/input/clean (add the apikey if not logged in) will remove any inputs that do not have a process list, this means any valid inputs you have with no process list will also be deleted and then recreated next time the input is updated. I make a point of adding a redundant process to any inputs that are valid but unused so as to keep the input list in order (ordered by input id so newly replaced inputs will appear at the end).

There are backdoor ways of keeping these rogue inputs under control, either you could run the input/clean by cron once a day/week etc or if you use emonhub, you can add bogus nodes entries to make emonhub discard data eg

[[1]]
    [[[rx]]]
        datacode = b

[[2]
    [[[rx]]]
        datacode = b
        

will delete anything claiming to be node 1 or node 2 that is not exactly 1 byte long, looking at your data you would probably need 256 entries (including the valid ones), the best solution is to find the source or improve the filtering at the receiver.

All of the above assumes the JeeLib CRC checks are done, since you are using LPL have you made sure that this line of the emonpi sketch is doing it’s job?

otherwise all incoming data will be passed out with an “OK” prefix rather than a “?” prefix (if quiet mode false) to denote it’s a “discarded packet”, emonhub only processes the “OK” packets and just prints the “?” packets to the emonhub.log for debugging without sending to emoncms. It seems LPL has something similar called CRCPass() but I can only see that in the rfm12 lib not the rfm69 lib, but I didn’t look too long, perhaps it’s tied in with encryption? or deal with another way.

LPL sets encryption function to RFM69 register, and check radio.receiveDone(),
So I think this would do decryption logic.
But i m not sure this routine check packet is good or not.

void RF69_Setup(){    
    radio.initialize(bandToRFM69(RF_freq),nodeID,networkGroup);
    radio.encrypt(KEY);
    radio.promiscuous(false);
    radio.setPowerLevel(RF_PowerLevel);
}

bool RF69_Rx_Handle(){
  if (radio.receiveDone())
  {
    Serial.print("OK ");
    Serial.print(radio.SENDERID, DEC);
    Serial.print(" ");
    for (byte i = 0; i<radio.DATALEN; i++)
    {
  Serial.print((word)radio.DATA[i]);
  Serial.print(" ");
    }
    Serial.print("(");
    Serial.print(radio.readRSSI());
    Serial.print(")");
    Serial.println();

    if (radio.ACKRequested()) radio.sendACK();

    double_LED_flash();
  }
}

I need to study more details.
Thanks.