@chey said in Where did everyone go?:

Personally when I look at the MySensors github and see Issues and PRs being created but no one is doing anything with them, that's a bit of a turn off.

When I look through the PRs I see a lot of "good stuff" there yet there is no movement.

I had the same observation and was wondering if we could do anything about this.

I maintain a dozen of open source projects and I know how unpredictable the contributions can be with life getting in the way and priorities changing. However, MySensors appears to be a project with relatively active user base and many people willing to contribute.

The latest commit to the development branch was more than 100 days ago (on July 27) and there are a bunch of pull requests that could be merge as they have had code reviews and they are very limited in scope and have little potential for introducing regressions.

Is there a way that members of the core team (or people with commit access) could give commit access to new members that have shown interest in contributing? There is always a chance that new contributors will have different approach to deciding on what features go in and how the project is maintained (and potentially introduce regressions or bugs) but that's at the cost of moving the project along and having it live.

Turns out that the RFM69 arduino library was missing two additional bytes from the packet header -- rfm69_header_t.version and rfm69_header_t.sequenceNumber in RFM69::sendFrame() (see the diff).

  select();
  SPI.transfer(REG_FIFO | 0x80); // Select the FIFO write register.

  SPI.transfer(bufferSize + 5); // rfm69_header_t.packetLen
  SPI.transfer(toAddress); // rfm69_header_t.recipient
  SPI.transfer(1); // RFM69_PACKET_HEADER_VERSION = (1u) rfm69_header_t.version header version (20180128tk: >=3.0.0 fused with controlFlags)
  SPI.transfer(_address); // rfm69_header_t.sender
  SPI.transfer(CTLbyte); // rfm69_header_t.controlFlags
  SPI.transfer(0); // rfm69_header_t.sequenceNumber

  for (uint8_t i = 0; i < bufferSize; i++)
    SPI.transfer(((uint8_t*) buffer)[i]);
  unselect();

So after adding SPI.transfer(1); as rfm69_header_t.version and SPI.transfer(0); as rfm69_header_t.sequenceNumber the packets are now being parsed correctly:

DEBUG TSF:MSG:READ,1-1-255,s=3,c=1,t=16,pt=1,l=1,sg=0:1
DEBUG TSF:MSG:BC

@chey said in Where did everyone go?:

Personally when I look at the MySensors github and see Issues and PRs being created but no one is doing anything with them, that's a bit of a turn off.

When I look through the PRs I see a lot of "good stuff" there yet there is no movement.

I had the same observation and was wondering if we could do anything about this.

I maintain a dozen of open source projects and I know how unpredictable the contributions can be with life getting in the way and priorities changing. However, MySensors appears to be a project with relatively active user base and many people willing to contribute.

The latest commit to the development branch was more than 100 days ago (on July 27) and there are a bunch of pull requests that could be merge as they have had code reviews and they are very limited in scope and have little potential for introducing regressions.

Is there a way that members of the core team (or people with commit access) could give commit access to new members that have shown interest in contributing? There is always a chance that new contributors will have different approach to deciding on what features go in and how the project is maintained (and potentially introduce regressions or bugs) but that's at the cost of moving the project along and having it live.

Turns out that the RFM69 arduino library was missing two additional bytes from the packet header -- rfm69_header_t.version and rfm69_header_t.sequenceNumber in RFM69::sendFrame() (see the diff).

  select();
  SPI.transfer(REG_FIFO | 0x80); // Select the FIFO write register.

  SPI.transfer(bufferSize + 5); // rfm69_header_t.packetLen
  SPI.transfer(toAddress); // rfm69_header_t.recipient
  SPI.transfer(1); // RFM69_PACKET_HEADER_VERSION = (1u) rfm69_header_t.version header version (20180128tk: >=3.0.0 fused with controlFlags)
  SPI.transfer(_address); // rfm69_header_t.sender
  SPI.transfer(CTLbyte); // rfm69_header_t.controlFlags
  SPI.transfer(0); // rfm69_header_t.sequenceNumber

  for (uint8_t i = 0; i < bufferSize; i++)
    SPI.transfer(((uint8_t*) buffer)[i]);
  unselect();

So after adding SPI.transfer(1); as rfm69_header_t.version and SPI.transfer(0); as rfm69_header_t.sequenceNumber the packets are now being parsed correctly:

DEBUG TSF:MSG:READ,1-1-255,s=3,c=1,t=16,pt=1,l=1,sg=0:1
DEBUG TSF:MSG:BC

@cimba007 Could you please share your latest working code for generating the packet?

I've created an ATTiny841 node with the RFM69CW radio (with a modified RFM69 library to match the radio config registers of MySensors) but the Raspberry Pi gateway is seeing the packets different.

Here is the sending part:

byte test[] = {
  1, // last
  1, // sender
  255, // destination
  0b00001010, // version_length: 2 bit - Protocol version (2), 1 bit - Signed flag (no), 5 bit - Length of payload (1 byte)
  0b00100001, // command_ack_payload: 3 bit - Command type (C_SET), 1 bit - Request an ack (no), 1 bit - Is ack message (no), 3 bit - Payload data type (P_BYTE)
  16, // type: V_TRIPPED
  3, // sensor ID
  1 // Value: 1
};

radio.send(255, packet, strlen(packet));

which is received as:

DEBUG TSF:MSG:READ,10-255-33,s=0,c=3,t=1,pt=0,l=2,sg=0:
DEBUG !TSF:MSG:LEN,6!=9

where none of the fields match the packet

Here is the packet definition in core/MyMessage.h:

uint8_t last;            	 ///< 8 bit - Id of last node this message passed
uint8_t sender;          	 ///< 8 bit - Id of sender node (origin)
uint8_t destination;     	 ///< 8 bit - Id of destination node

/**
 * 2 bit - Protocol version<br>
 * 1 bit - Signed flag<br>
 * 5 bit - Length of payload
 */
uint8_t version_length;

/**
 * 3 bit - Command type<br>
 * 1 bit - Request an ack - Indicator that receiver should send an ack back<br>
 * 1 bit - Is ack message - Indicator that this is the actual ack message<br>
 * 3 bit - Payload data type
 */
uint8_t command_ack_payload;

uint8_t type; ///< 8 bit - Type varies depending on command
uint8_t sensor; ///< 8 bit - Id of sensor that this message concerns.

/*
 * Each message can transfer a payload. We add one extra byte for string
 * terminator \0 to be "printable" this is not transferred OTA
 * This union is used to simplify the construction of the binary data types transferred.
 */
union {
    uint8_t bValue; ///< unsigned byte value (8-bit)
    uint16_t uiValue; ///< unsigned integer value (16-bit)
    int16_t iValue; ///< signed integer value (16-bit)
    uint32_t ulValue; ///< unsigned long value (32-bit)
    int32_t lValue; ///< signed long value (32-bit)
    struct { //< Float messages
        float fValue;
        uint8_t fPrecision; ///< Number of decimals when serializing
    };
    struct {  //< Presentation messages
        uint8_t version; ///< Library version
        uint8_t sensorType; ///< Sensor type hint for controller, see table above
    };
    char data[MAX_PAYLOAD + 1]; ///< Buffer for raw payload data
} __attribute__((packed)); ///< Doxygen will complain without this comment

I'll try and log the raw incoming packet on the Pi side just to confirm that the radio config is actually matching.