BUG? PiGateway.ino does not process REQUESTQUEUE prefix in data string

[kni]

UPDATE:
Originally I thought the problem was my own sketch not processing the data in the ACK, but further investigation revealed the data was not being sent due to an error. Details are in the second post.

I recently (finally) updated my gateway to the latest 9.2 release. Until yesterday, I was still running 8.x. I also updated the sketch running on the gateway to the latest PiGateway.ino w/ buffered serial data.

Now that I've got everything up to date, I began testing the new node request feature. Unfortunately, when I create a node request from the UI, it just times out.

I am using a sketch that puts the moteino to sleep then wakes up ~1 minute and transmits some data. However, I am unsure how to check for data in the ACK. I was unable to find a sample sketch in the examples on github.

Specifically, what am I supposed to do, immediately following radio.sendWithRetry, in order to get to the data out of the ACK?
Calling radio.receiveDone() returns false every time and radio.DATALEN is always 0.

This is what I am working with:

Code Select Expand

  if (radio.sendWithRetry(GATEWAYID, sendBuff, sendLen, 3, ACK_TIME) ) {
    DEBUGln("ACK: OK");
    DEBUG("Value of radio.DATALEN: ");DEBUGln(radio.DATALEN);
    if (radio.receiveDone()) {
      DEBUG('Radio Data received from gateway: ');DEBUG('[');DEBUG(radio.SENDERID);DEBUG("] ");
      for (byte i = 0; i < radio.DATALEN; i++)
        DEBUG((char)radio.DATA[i]);

      DEBUGln();

      if (radio.ACKRequested()) {
        radio.sendACK();
        DEBUGln('ACK sent back to gateway');
      }
    }
  }

From the serial monitor, the sketch returns "ACK:OK" and the value of radio.DATALEN is always 0. radioreceiveDone() always returns false, and thus that block of code never executes.

I'm sure I'm missing something basic.

[kni]

So maybe the problem I've run into isn't my sketch, but the gateway. I just noticed this in my logs when I attempt a node request:

Code Select Expand

08:36:04.086 : /dev/ttyUSB0>:[36] LED:OFF SS:-40
08:35:46.329 : /dev/ttyUSB0>:[0] 36:PWR:ON:INV:ID-OUT-OF-RANGE
08:35:46.329 : /dev/ttyUSB0>:DEBUG:handleSerialData:REQUESTQUEUE:36:PWR:ON
08:35:46.329 : /dev/ttyUSB0>:DEBUG:VOIDED_commands:0
08:35:46.329 : /dev/ttyUSB0>:DEBUG:handleSerialData:36:VOID:PWR:ON
08:35:46.303 : NODE [36] Request Updated: PWR

Looks like it is complaining ID-OUT-OF-RANGE because targetId is 0, when it should be 36.

The targetId is extracted from dataPart, which is failing to do so:
https://github.com/LowPowerLab/RFM69/blob/master/Examples/PiGateway/PiGateway.ino#L249

This looks like a bug to me.
The problem seems to be with the prefix REQUESTQUEUE, added to the data string by the pigateway software. The sketch doesn't recognize that text and thus continues on without processing it. It then tries to convert that to an integer, thinking that is the targetid.

[kni]

OK, so it looks like, on May 29, PiGateway.ino was modified to look for a prefix of "RQ" rather than "REQUESTQUEUE" with this commit:
https://github.com/LowPowerLab/RFM69/commit/f77011bf0b6b5a9170ad93834e223df0d73fec31

However, I do not see a corresponding commit in the RaspberryPi-Gateway repo. Looks like these lines need to be changed:
https://github.com/LowPowerLab/RaspberryPi-Gateway/blob/master/gateway.js#L621
https://github.com/LowPowerLab/RaspberryPi-Gateway/blob/master/gateway.js#L1028

I will test this and report back.

[kni]

Confirmed. This resolves the problem. My sample sketch is receiving data like a champ now.

Issue reported along with a PR that fixes the issue:
https://github.com/LowPowerLab/RaspberryPi-Gateway/issues/45

[Felix]

Sorry I could not get back to this, just wanted to say I've seen all your messages and PRs etc.
It's more involved and modifying anything can affect a lot of things so even though you did the homework I have to check everything in detail and so I have to find some time to do that.
But glad you're making headways and figuring things out, that's great.
Thanks for the patience

[kni]

Thanks Felix. I totally understand. Respond when you can.
I had a moment of opportunity last week to finally upgrade my gateway and implement that awesome new node request feature.

I wanted to document my progress as best I could, not only so I didn't forget it but also to get it out there for others to review.

[Felix]

All merged, thanks a lot for the effort and contributions!