We are happy to announce a major release of the MySensors library to 2.0.0!
For details, see here.
Doxygen links on the master github frontpage are not working. These are the correct links:
master development

Signing support has now been implemented and is available from release 1.5 of the MySensors library.
From version 2.0.0, all documentation is managed using doxygen, and you find the most current documentation here for releases and here for development branch.
You can find the signing documentation under "modules" and "MySensors internal APIs and functionalities > MySigning".

In an effort to normalize the technical playing field for all forum members I will describe what this means, and why it is important. And I will also briefly touch on the generic concept of authentication and verification, motivate the need for this (and explain why encryption is not part of this) and go on to explain the architecture used for MySensors and how to enable and use this new feature.

Background and concepts

Suppose two participants, Alice and Bob, wants to exchange a message. Alice sends a message to Bob. In MySensors “language” Alice could be a gateway and Bob an actuator (light swich, electronic lock, etc). But to be generic, we will substitute the term “gateway” with Alice and a “node” with Bob (although the reverse relationship is also supported).

Alice sends a message to Bob. This message can be heard by anyone who wants to listen (and also by anyone that is within “hearing” distance). Normally, this is perhaps not a big issue. Nothing Alice says to Bob may be secret or sensitive in any way.
However, sometimes (or perhaps always) Bob want to be sure that the message Bob receives actually came from Alice. In cryptography, this is known as authenticity. Bob need some way of determining that the message is authentic from Alice, when Bob receives it. This prevent an eavesdropper, Eve, to trick Bob into thinking it was Alice that sent a message Eve in fact transmitted. Bob also need to know how to determine if the message has been repeated. Eve could record a message sent by Alice that Bob accepted and then send the same message again. Eve could also in some way prevent Bob from receiving the message and delay it in order to permit the message to arrive to Bob at a time Eve chooses, instead of Alice. Such an attack is known as a replay attack.
Authenticity permits Bob to determine if Alice is the true sender of a message.

It can also be interesting for Bob to know that the message Alice sent has not been tampered with in any way. This is the integrity of the message. We now introduce Mallory, who could be intercepting the communication between Alice and Bob and replace some parts of the message but keeping the parts that authenticate the message. That way, Bob still trusts Alice to be the source, but the contents of the message was not the content Alice sent. Bob needs to be able to determine that the contents of the message was not altered after Alice sent it.
Mallory would in this case be a man-in-the-middle attacker.
Integrity permits Bob to verify that the messages received from Alice has not been tampered with.
This is achieved by adding a signature to the message, which Bob can inspect to validate that Alice is the author.

The signing scheme used, needs to address both these attack scenarios. Neither Eve nor Mallory must be permitted to interfere with the message exchange between Alice and Bob.

The key challenge to implementing a secure signing scheme is to ensure that every signature is different, even if the message is not. If not, replay attacks would be very hard to prevent.
One way of doing this is to increment some counter on the sender side and include it in the signature. This is however predictable.
A better option would be to introduce a random number to the signature. That way, it is impossible to predict what the signature will be. The problem is, that also makes it impossible for the receiver (Bob) to verify that the signature is valid.
A solution to this is to let Bob generate the random number, keep it in memory and send it to Alice. Alice can then use the random number in the signature calculation and send the signed message back to Bob who can validate the signature with the random number used.
This random number is in cryptography known as a nonce or salt.

However, Mallory might be eavesdropping on the communication and snoop up the nonce in order to generate a new valid signature for a different message. To counter this, both Alice and Bob keep a secret that only they know. This secret is never transmitted over the air, nor is it revealed to anybody. This secret is known as a pre-shared key (PSK).

If Even or Mallory are really sophisticated, he/she might use a delayed replay attack. This can be done by allowing Bob to transmit a nonce to Alice. But when Alice transmits the uniquely signed message, Mallory prevents Bob from receiving it, to a point when Mallory decides Bob should receive it. An example of such an attack is described here.
This needs to be addressed as well, and one way of doing this is to have Bob keep track of time between a transmitted nonce and a signed message to verify. If Bob is asked for a nonce, Bob knows that a signed message is going to arrive “soon”. Bob can then decide that if the signed message does not arrive within a predefined timeframe, Bob throws away the generated nonce and thus makes it impossible to verify the message if it arrives late.

The flow can be described like this:

The benefits for MySensors to support this are obvious. Nobody wants others to be able to control or manipulate any actuators in their home.

Why encryption is not part of this

Well, some could be uncomfortable with somebody being able to snoop temperatures, motion or the state changes of locks in the environment. Signing does not address these issues. Encryption is needed to prevent this.
It is my personal standpoint that encryption should not be part of the MySensors “protocol”. The reason is that a gateway and a node does not really care about messages being readable or not by “others”. It makes more sense that such guarantees are provided by the underlying transmission layer (RF solution in this case). It is the information transmitted over the air that needs to be secret (if user so desires). The “trust” level on the other hand needs to go all the way into the sketches (who might have different requirements of trust depending on the message participant), and for this reason, it is more important (and less complicated) to ensure authenticity and integrity at protocol-level as message contents is still readable throughout the protocol stack. But as soon as the message leaves the “stack” it can be scramble into “garbage” when transmitted over the air and then reassembled by a receiving node before being fed in “the clear” up the stack at the receiving end.

There are methods and possibilities to provide encryption also in software, but if this is done, it is my recommendation that this is done after integrity- and authentication information has been provided to the message (if this is desired). Integrity and authentication is of course not mandatory and some might be happy with only having encryption to cover their need for security. I, however, have only focused on integrity and authenticity while at the same time keeping the current message routing mechanisms intact and therefore leave the matter of secrecy to be implemented in the “physical” transport layer. With the integrity and authenticity handled in the protocol it ought to be enough for a simple encryption (nonce-less AES with a PSK for instance) on the message as it is sent to the RF backend. Atmel does provide such circuits as well but I have not investigated the matter further as it given the current size of the ethernet gateway sketch is close to the size limit on an Arduino Nano, so it will be difficult to fit this into some existing gateway designs.
Also it is worth to consider that the state of a lock can just as readily be determined by simply looking at the door in question or attempting to open it, so obfuscating this information will not necessarily deter an attacker in any way.
Nevertheless, I do acknowledge that people find the fact that all information is sent “in the clear” even if it require some technical effort for an intruder to obtain and inspect this information. So I do encourage the use of encrypting transport layers.
This is however not covered by this topic nor my implementation.

How this is done

There exist many forms of message signature solutions to combat Eve and Mallory.
Most of these solutions are quite complex in term of computations, so I elected to use an algorithm that an external circuit is able to process. This has the added benefit of protecting any keys and intermediate data used for calculating the signature so that even if someone were to actually steal a sensor and disassembled it, they would not be able to extract the keys and other information from the device.
A common scheme for message signing (authenticity and integrity) is implemented using HMAC which in combination with a strong hash function provides a very strong level of protection.
The Atmel ATSHA204A is a low-cost, low-voltage/current circuit that provides HMAC calculation capabilities with SHA256 hashing which is a (currently) virtually unbreakable combination. If SHA256 were to be hacked, a certain cryptocurrency would immediately be rendered worthless.
The ATSHA device also contain a random number generator (RNG) which enables the generation of a good nonce, as in, non-predictable.
As I acknowledge that some might not want to use an additional external circuit, I have also implemented a software version of the ATSHA device, capable of generating the same signatures as the ATSHA device does. Because it is pure-software however, it does not provide as good nonces (it uses the Arduino pseudo-random generator) and the HMAC key is stored in SW and is therefore readable if the memory is dumped. It also naturally claims more flash space due to the more complex software. But for indoor sensors/actuators this might be good enough for most people.

How to use this

Before we begin with the details, I just want to emphasize that signing is completely optional and although it is enabled by default, it will use a default backend that does not require signing and does not enforce signature checks. However, if you really do not want any additional "cost" in program space related to signing, you can disable MY_SIGNING_FEATURE in MyConfig.h.

Firstly, you need to make sure MY_SIGNING_FEATURE is enabled in MyConfig.h. You then select which backend to use by passing the appropriate handle when constructing the MySensor object. The handle is passed as the third argument (example here uses the real ATSHA without whitelisting):

#include <MySigningAtsha204.h>

MyTransportNRF24 radio;  // NRFRF24L01 radio driver
MyHwATMega328 hw; // Select AtMega328 hardware profile
MySigningAtsha204 signer; // Select HW ATSHA signing backend

MySensor gw(radio, hw, signer);

If the software equivalent if the ATSHA is desired instead do

#include <MySigningAtsha204Soft.h>

MyTransportNRF24 radio;  // NRFRF24L01 radio driver
MyHwATMega328 hw; // Select AtMega328 hardware profile

// Change the soft_serial value to an arbitrary value for proper security
uint8_t soft_serial[SHA204_SERIAL_SZ] = {0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09};
MySigningAtsha204Soft signer(true, 0, NULL, soft_serial);  // Select SW ATSHA signing backend

MySensor gw(radio, hw, signer);

It is legal to mix MySigningAtsha204 and MySigningAtsha204Soft backends in a network. They work together.

Secondly, you need to verify the configuration for the backend. Currently, only MySigningAtsha204 and MySigningAtsha204Soft backends have a specific configuration.
For MySigningAtsha204 it is the pin the device is connected to. In MyConfig.h there are defaults for sensors and gateways which you might need to adjust to match your personal build. The setting is defined using MY_ATSHA204_PIN and the default is to use pin A3.
For MySigningAtsha204Soft, an unconnected analog pin is required to set a random seed for the pseudo-random generator. It is important that the pin is floating, or the output of the pseudo-random generator will be predictable, and thus compromise the signatures. The setting is defined using MY_RANDOMSEED_PIN and the default is to use pin A7.

Thirdly, if you use the MySigningAtsha204Soft backend, you need to create/set a HMAC key to use. This key is 32 bytes wide and should be an arbitrarily chosen value. A string is OK, but as this key never needs to be “parsed” a completely random number is recommended. The key is stored in our sketch and is passed when constructing the MySigningAtsha204Soft object.

If you use the “real” ATSHA204A, before any signing operations can be done, the device needs to be personalized. This can be a daunting process as it involves irreversibly writing configurations to the device, which cannot be undone. I have however tried to simplify the process as much as possibly by creating a helper-sketch specifically for this purpose in libraries/MySensors/examples/Sha204Personalizer/sha204_personalizer.ino

The process of personalizing the ATSHA204A involves

• Writing and locking chip configuration
• (optionally) Generating and (mandatory) writing HMAC key
• (optionally) Locking data sections

First execute the sketch without modifications to make sure communications with the device can be established. It is highly recommended that the first time this is done, a device with serial debug possibilities is used.
When this has been confirmed, it is time to decide what type of personalization is desired.
There are a few options here.
Firstly, enable LOCK_CONFIGURATION to allow the sketch to lock the chip configuration. The sketch will write the default settings to the chip because these are fine for our purposes. This also enables the RNG which is required to allow the sketch to automatically generate a PSK if this is desired.
Now it is possible to execute the sketch to lock the configuration and enable the RNG.
Next step is to decide if a new key should be generated or an existing key should be stored to the device. This is determined using USER_KEY_DATA, which, if defined, will use the data in the variable user_key_data.
If USER_KEY_DATA is disabled, the RNG will be used to generate a key. This key obviously need to be made available to you so you can use it in other devices in the network, and this key is therefore also printed on the serial console when it has been generated.
The key (generated or provided) will be written to the device unless SKIP_KEY_STORAGE is set. As long as the data zone is kept unlocked the key can be replaced at any time. However, Atmel suggests the data region to be locked for maximum security. On the other hand, they also claim that the key is not readable from the device even if the data zone remains unlocked so the need for locking the data region is optional for MySensors usage.
For devices that does not have serial debug possibilities, it is possible to set SKIP_UART_CONFIRMATION, but it is required to set USER_KEY_DATA if this option is enabled since a generated and potentially unknown key could be written to the device and thus rendering it useless (if the data zone is also locked).
For devices with serial debug possibilities it is recommended to not use SKIP_UART_CONFIRMATION as the sketch without that setting will ask user to send a ‘space’ character on the serial terminal before any locking operations are executed as an additional confirmation that this irreversible operation is done. However, if a number of nodes are to undergo personalization, this option can be enabled to streamline the personalization.
This is a condensed description of settings to fully personalize and lock down a set of sensors (and gateways):
Pick a “master” device with serial debug port.
Set the following sketch configuration of the personalizer:
Enable LOCK_CONFIGURATION
Disable LOCK_DATA
Enable SKIP_KEY_STORAGE
Disable SKIP_UART_CONFIGURATION
Disable USER_KEY_DATA

Execute the sketch on the “master” device to obtain a randomized key. Save this key to a secure location and keep it confidential so that you can retrieve it if you need to personalize more devices later on.
Now reconfigure the sketch with these settings:
Enable LOCK_CONFIGURATION
Enable LOCK_DATA (if you are sure you do not need to replace/revoke the key, this is the most secure option to protect from key readout according to Atmel, but they also claim that key is not readable even if data region remains unlocked from the slot we are using)
Disable SKIP_KEY_STORAGE
Enable SKIP_UART_CONFIGURATION
Enable USER_KEY_DATA
Put the saved key in the user_key_data variable.

Now execute the sketch on all devices you want to personalize with this secret key. That’s it. Personalization is done and the device is ready to execute signing operations which are valid only on your personal network.

In case you want to be able to "whitelist" trusted nodes (in order to be able to revoke them in case they are lost) you also need to take note of the serial number of the ATSHA device. This is unique for each device. The serial number is printed in a copy+paste friendly format by the personalizer for this purpose.

Signing in the MySensors network is driven from the receiving nodes. That means, if a node require signing it will inform the gateway of this. To instruct a node to require signing by the gateway, provide a suitable backend to the library constructor. Both MySigningAtsha204 and MySigningAtsha204Soft backends will by-default require signing when used.
The default constructors for these backends can be overridden to disable signing requirements if the node does not require signed messages but still need the ability to verify messages (like a gateway).

Example for a node that uses ATSHA and require signing:

#include <MySigningAtsha204.h>
MyTransportNRF24 radio;  // NRFRF24L01 radio driver
MyHwATMega328 hw; // Select AtMega328 hardware profile
MySigningAtsha204 signer; // Select ATSHA204A physical signing circuit
MySensor gw(radio, hw, signer);

Example for a gateway that uses ATSHA signing in software and do not require signing from nodes:

#include <MySigningAtsha204Soft.h>
MyTransportNRF24 radio;  // NRFRF24L01 radio driver
MyHwATMega328 hw; // Select AtMega328 hardware profile
uint8_t soft_serial[SHA204_SERIAL_SZ] = {0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09};
MySigningAtsha204Soft signer(false, 0, NULL, soft_serial);  // Select ATSHA204A software signing backend
MySensor gw(radio, hw, signer);

If a node does require signing, any unsigned message sent to the node will be rejected.
This also applies to the gateway. However, the difference is that the gateway will only require signed messages from nodes it knows in turn require signed messages.
A node can also inform a different node that it expects to receive signed messages from it. This is done by transmitting an internal message of type I_REQUEST_SIGNING and provide a boolean for payload, set to true.
All nodes and gateways in a network maintain a table where the signing preferences of all nodes are stored. This is also stored in EEPROM so if the gateway reboots, the nodes does not have to retransmit a signing request to the gateway for the gateway to realize that the node expect signed messages.
Also, the nodes that do not require signed messages will also inform gateway of this, so if you reprogram a node to stop require signing, the gateway will adhere to this as soon as the new node has presented itself to the gateway.

The following sequence diagram illustrate how messages are passed in a MySensors network with respect to signing:

None of this activity is “visible” to you (as the sensor sketch implementor). All you need to do is to set your preferences in MyConfig.h, depending on chosen backend, do personalization or key configurations and set the requestSignatures parameter to true. That is enough to enable protection from both Eve and Mallory in your network (although because of the lack of encryption, Eve can eavesdrop, but not do anything about, your messages).

Whitelisting and node revocation

Consider the situation when you have set up your secure topology. We use the remotely operated garage door as an example:

• You have a node inside your garage (therefore secure and out of reach from prying eyes) that controls your garage door motor. This node require signing since you do not want an unauthorized person sending it orders to open the door.
• You have a keyfob node with a signing backend that uses the same PSK as your door opener node.

In this setup, your keyfob can securely transmit messages to your door node since the keyfob will sign the messages it sends and the door node will verify that these were sent from a trusted node (since it used the correct PSK). If the keyfob does not sign the messages, the door node will not accept them.

One day your keyfob gets stolen or you lost it or it simply broke down.

You know end up with a problem; you need some way of telling your door node that the keyfob in question cannot be trusted any more. Furthermore, you maybe locked the data region in your door nodes ATSHA device and is not able to revoke/change your PSK, or you have some other reason for not wanting to replace the PSK. How do you make sure that the "rogue" keyfob can be removed from the "trusted chain"?

The answer to this is whitelisting. You let your door node keep a whitelist of all nodes it trusts. If you stop trusting a particular node, you remove it from the nodes whitelist, and it will no longer be able to communicate signed messages to the door node.

This is achieved by 'salting' the signature with some node-unique information known to the receiver. In the case of ATSHA204A this is the unique serial number programmed into the circuit. This unique number is never transmitted over the air in clear text, so Eve will not be able to figure out a "trusted" serial by snooping on the traffic.
Instead the value is hashed together with the senders NodeId into the HMAC signature to produce the final signature. The receiver will then take the originating NodeId of the signed message and do the corresponding calculation with the serial it has stored in it's whitelist if it finds a matching entry in it's whitelist.

Whitelisting is an optional alternative because it adds some code which might not be desirable for every user. So if you want the ability to provide and use whitelists, as well as transmitting to a node with a whitelist, you need to enable MY_SECURE_NODE_WHITELISTING in MyConfig.h
The whitelist is provided when constructing the signing backend as follows (example is a node that require signing as well):

#include <MySigningAtsha204.h>
MyTransportNRF24 radio;  // NRFRF24L01 radio driver
MyHwATMega328 hw; // Select AtMega328 hardware profile
#ifdef MY_SECURE_NODE_WHITELISTING
whitelist_entry_t node_whitelist[] = {
  { .nodeId = 55, // Just some value, this need to be changed  to the NodeId of the trusted node
    .serial = {0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09} } // This need to change to the serial of the trusted node
};
MySigningAtsha204 signer(true, 1, node_whitelist);  // Select ATSHA204A software signing backend with one entry in the whitelist
#else
MySigningAtsha204 signer;  // Select ATSHA204A software signing backend
#endif
MySensor gw(radio, hw, signer);

The "soft" backend of course also support whitelisting. However, since it does not contain a unique identifier, you have to provide an additional constructor argument when you enable whitelisting as illustrated in this example:

#include <MySigningAtsha204Soft.h>
MyTransportNRF24 radio;  // NRFRF24L01 radio driver
MyHwATMega328 hw; // Select AtMega328 hardware profile
#ifdef MY_SECURE_NODE_WHITELISTING
// Change the soft_serial value to an arbitrary value for proper security
uint8_t soft_serial[SHA204_SERIAL_SZ] = {0x09,0x08,0x07,0x06,0x05,0x04,0x03,0x02,0x01};
whitelist_entry_t node_whitelist[] = {
  { .nodeId = 55, // Just some value, this need to be changed to the NodeId of the trusted node
    .serial = {0x01,0x02,0x03,0x04,0x05,0x06,0x07,0x08,0x09} } // This need to change to the serial of the trusted node
};
MySigningAtsha204Soft signer(true, 1, node_whitelist, soft_serial);  // Select ATSHA204A software signing backend with one entry in the whitelist and our unique serial
#else
MySigningAtsha204 signer;  // Select ATSHA204A software signing backend
#endif
MySensor gw(radio, hw, signer);

For a node that should transmit whitelisted messages but not receive whitelisted messages, you can simply skip the whitelist arguments (1 and node_whitelist above). For the "soft" backend, you can set these to 0 and NULL since you then need to provide the soft_serial buffer.

It is important to emphasize that you do not have to provide a whitelist that has entries for all nodes that transmit signed messages to the node in question. You only need to have entries for the nodes that in turn have enabled MY_SECURE_NODE_WHITELISTING. Nodes that does not have this option enabled can still transmit "regular" signed messages as long as they do not match a NodeId in the receivers whitelist.

The technical stuff

How are the messages actually affected by the signing?
The following illustration shows what part of the message is signed, and where the signature is stored:

The first byte of the header is not covered by the signature, because in the network, this byte is used to track hops in the network and therefore might change if the message is passing a relay node. So it cannot be part of the signature, or the signature would be invalid when it arrives to its destination. The signature also carries a byte with a signing identifier to prevent false results from accidental mixing of incompatible signing backends in the network. Thus, the maximum size for a payload is 29-7 bytes. Larger payloads are not possible to sign. Another thing to consider is that the strength of the signature is inversely proportional to the payload size.

As for the ATSHA204SOFT backend, it turns out that the ATSHA does not do “vanilla” HMAC processing. Fortunately, Atmel has documented exactly how the circuit processes the data and hashes thus making it possible to generate signatures that are identical to signatures generated by the circuit.

The signatures are calculates in the following way:

Exactly how this is done can be reviewd in the source for the ATSHA204SOFT backend and the ATSHA204A datasheet.
In the MySensors protocol, the following new internal messagetypes has been added for handling signature requirements and nonce requests:
I_REQUEST_SIGNING
I_GET_NONCE
I_GET_NONCE_RESPONSE

Also, the version field in the header has been reduced from 3 to 2 bits in order to fit a single bit to indicate that a message is signed.

Known limitations

It is very important to emphasize that with the current implementation of message signing, OTA firmware updates are transmitted unsigned. In other words, it is technically possible for Mallory to reset a node by cutting power or some other attack, spoof a gateway and push his/her own custom firmware to the node even if the old sketch was requiring signing. The current architecture of the OTA solution prevents signing support from being implemented in the bootloader due to size constraints.
It is still possible to use OTA bootloader with a signing gateway and node, but it is important to understand this potentially provides an attack vector for compromising the security of the node.
Also, due to the limiting factor our our Arduino nodes, the use of diversified keys is not implemented. That mean that all nodes in your network share the same PSK (at least the ones that are supposed to exchange signed data). It is important to understand the implications of this, and that is hopefully covered in the "Typical usecases" chapter below.
Also be reminded that the strength of the signature is inversely proportional to the size of the message. The larger the message, the weaker the signature.

Typical usecases

"Securely located" in this context mean a node which is not physically publicly accessible. Typically at least your gateway.
"Public" in this context mean a node that is located outside your "trusted environment". This includes sensors located outdoors, keyfobs etc.

Securely located lock

You have a securely located gateway and a lock somewhere inside your "trusted environment" (e.g. inside your house door, the door to your dungeon or similar).
You should then keep the data section of your gateway and your lock node unlocked. Locking the data (and therefore the PSK) will require you to replace at least the signing circuit in case you need to revoke the PSK because some other node in your network gets compromised.

Patio motion sensor

Your gateway is securely located inside your house, but your motion sensor is located outside your house. You have for some reason elected that this node should sign the messages it send to your gateway.You should lock the data (PSK) in this node then, because if someone were to steal your patio motion sensor, they could rewrite the firmware and spoof your gateway to use it to transmit a correctly signed message to your secure lock inside your house. But if you revoke your gateway (and lock) PSK the outside sensor cannot be used for this anymore. Nor can it be changed in order to do it in the future. You can also use whitelisting to revoke your lost node.
This is an unlikely usecase because it is really no reason to sign sensor values. If you for some reason want to obfuscate sensor data, encryption is a better alternative.

Keyfob for garage door opener

Perhaps the most typical usecase for signed messages. Your keyfob should be totally locked down. If the garage door opener is secured (and it should be) it can be unlocked. That way, if you loose your keyfob, you can revoke the PSK in both the opener and your gateway, thus rendering the keyfob useless without having to replace your nodes. You can also use whitelisting to revoke your lost keyfob.

Board releases:

• Version 1.1 [purchase](the 5x5 board as sent to manufacturing, HW verification NOT done)
• Version 1.0 [purchase](contain multiple issues, NOT recommended to use, does only cotain 5x5 layout and the release is signed with my old (revoked) PGP key)

I designed this board as a host for the hardware I have collected so far.
I have made three layouts of the board; one “low cost” 5x5 cm board (allows the cheapest option at Dirt Cheap Dirty Boards and two layouts tailored for two Superbat boxes. BOX-2252 and LE-BOX-0028.

Feature list (short version):

• Accepts Arduino Pro Mini 3.3V in all variants I am familiar with
• Supports both NRF24 and RFM69 but not simultaneously due to lack of available IO
• Supports MYSX 1.0 to 1.5 daughterboards
• Supports both “conventional” battery measurement and a low-power variant of it
  • Instead of a dual resistor divider, I use a potentiometer. That way, any analog reference level can be used, and resolution can be tuned against any expected value of battery voltage
• Two different regulators can be used (depending on input voltage)
  • 12V input or 4.2V input (step-up)
    • 4.2V regulator can be programmatically bypassed for low power operation when battery is high enough for all circuitry. Two options exist; TI TPS61221 and TI TPS61097A, both 3.3V fixed versions (no support for variable voltage versions)
• 6 different ways of powering the board
  • DC socket
  • Battery wires
  • JST socket (LiPo cells)
  • CR123 socket
  • 24.5mm coincell
  • MYSX daughterboard Vraw supply
• MYSX 3.3V power can be programmatically switched off
• ATSHA204A HW authentication/signing
• 3 dedicated switchable 3.3V/GND rail pins for discrete sensors
• Onboard SI7021 temp/hum sensor
• AVR ISP programming header
• External SPI flash for OTA

Due to limited available IO and to support various use cases some aspects of the board is configurable using jumpers:

• JP1 - Serves as current measurement tap from on-board power connectors. Has to be shorted if on-board power connectors are used.
• JP2 - Selects 3.3V regulator. Pos 1-2 for 4.2V input (max) and pos 2-3 for 12V input (max)
• JP3 - Sort to bypass regulators and tie on-board power connectors directly to 3.3V net
• JP4 - Short to skips the low-power battery sampling option. This will cause a continuous power drain on the batteries through a 1M Ohm potentiometer.
• JP5 - Short to skip the switch for MYSX 3.3V rail. MYSX 3.3V rail will be “permanently on”.
• JP6 - Short to cause MYSX_D10_A4 signal to be used to set low-voltage 3.3V regulator in bypass mode. This can be used if battery voltage is high enough to drive all circuitry without being boosted at the potential expense of the MYSX_D10_A4 pin usage of a daughterboard. JP6 serves as a mean to permit MYSX_D10_A4 to behave according to MYSX specifications if left open (at the corresponding expense of not being able to set regulator in bypass mode).
• JP7 - Serves as current measurement tap for off-board power connector through MYSX. Has to be shorted if off-board power connector is used.
• JP8 - Selects INT1 interrupt source. Pos 1-2 for MYSX_D3_INT and pos 2-3 for RF board.
• JP9 - Selects SPI SS destination. Pos 1-2 for NRF24 and pos 2-3 for RFM69.
• JP10 - Short to enable MYSX_D9_A3 to be used to take a low-power battery sample. If enabled, analog measurement of a daughterboard on MYSX_D9_A3 might not work as expected.

Feature list (the somewhat more comprehensive version):

• Any Arduino Pro Mini with A6 and A7 pins available should fit this board (A6 and A7 is required to comply with MYSX specifications.
• Although the board can take both NRF24 and RFM69 at the same time mounted, they share pin for SPI chip select, so they cannot be used simultaneously (unless you patch the board to re-route one of the chip selects to a different Arduino pin and make the necessary SW modifications)
• Support the MySensors Expansion port (MYSX) in all versions up to 1.5. MYSX specifications is available here. Depending on what battery sockets are mounted on the board, the MYSX connector may have to be “raised” so a daughterboard can fit in some of the layouts of the board.
• Flexible options for battery measurement:
  • Voltage divider is implemented using a potentiometer (1M@RV1) which makes it possible to tune the sample voltage to optimize measurement range.
  • JP4 can be shorted to connect battery net directly to potentiometer (which in turn is connected to Arduino pin A0). A footprint for an optional decoupling capacitor is available at C8 to smooth the sample value. It is not recommended to use C8 if low-power sampling option is used.
  • With JP4 open, battery samples are taken by momentarily driving MYSX_D9_A3 low (Arduino pin A1). When sample is taken, MYSX_D9_A3 is set high again, which prevents continuous drain of battery through RV1. This assumes JP10 is shorted. If a daughterboard is connected that uses MYSX_D9_A3, analog samples taken on that pin might be affected by the 0.1uF capacitor (C9) when JP10 is shorted.
• Depending of power source used, two regulator options are available.
  • For “high” voltage sources a LDO provides the regulated 3.3V voltage. Maximum accepted voltage is 12V. This is enabled by shorting JP2 pos 2-3.
  • For “low” voltage sources a step-up voltage regulator provides the 3.3V voltage. Maximum accepted voltage is 4.2V. This is enabled by shorting JP2 pos 1-2. The step-up voltage regulator also implements a pass-through option in which the regulator is turned off and the input voltage is fed right through it. The pass-through is enabled by driving MYSX_D10_A4 low (Arduino pin A2) and shorting JP6. Be aware that this also goes through the MYSX connector, so it is not recommended to use this feature if a daughterboard is connected that uses MYSX_D10_A4. There are two footprints available for this regulator alternative; SC-70 (TI TPS61221) and SOT-23 (TI TPS61097A). Both has to be the 3.3V fixed version since there is no footprints for adjustment-resistors. Also note that these two regulators are mutually exclusive. Do NOT mount them both at the same time.
• All different power source options can be simultaneously mounted (not that it has to be). But on some layouts, the BT4 and BT5 (CR123 and coin cell) connectors one of the BT4 connector legs needs to be filed down if a coin cell battery is to be fitted. But the layout will ensure no shorts are risked. On the 5x5cm board, BT4 and BT5 are omitted due to size constraints.
  The following possibilities exist:
  • DC socket (BOM will use 2.5MM part with center pin being positive and shield ground.
  • Battery wires (or virtually any power source) can be connected to a 2.54mm pitch screw terminal (or soldered directly to the board).
  • A JST (S2B-PH-K-S) connector for LiPo cells (like this or this one).
  • A CR123 socket (not available on 5x5 cm board).
  • A 24.5mm coincell holder capable of accepting up to CR2477 sizes (not available on 5x5 cm board).
  • Vraw supply from a MYSX daughterboard.
• The 3.3V pin of the MYSX connector can be programmatically switched off.
  • To switch off the 3.3V supply pin drive Arduino pin D4 low. Leave it floating to have the 3.3V pin enabled.
• ATSHA204A HW signing is available (uses Arduino pin A3).
• 3 (switchable) 3.3V/GND rail pairs is available to allow discreet mounting of wired sensors (in excess to the pins available on the MYSX connector).
• An onboard SI7021 sensors is connected to the I2C bus to provide rudimentary sensor possibilities on the motherboard itself.
• An onboard AVR ISP programming socket provides the possibility to program a custom bootloader to the Arduino (useful for OTA).
• An external flash is connected to the SPI bus to permit OTA using the Dualoptiboot bootloader.

The schematics and BOMs are done.
Schematics and layouts are all stored here and will be updated from time to time. I will notify in this topic once I have done tape-out and have manufactured the boards. I am somewhat confident on the design of revision 1.1 (with lessons learnt from revision 1.0) so I plan to finish all three boards before I manufacture any one of them.
For the LE-BOX-0028 (the largest box) the layout has all components mounted top side. It also features more silkscreen text for ease of jumper operation and it places the NRF24 module so that it can accommodate a PA/LNA "extended" module and have the antenna exit the box and still be "turnable".
Forum feedback is very welcome!
The designed is licensed under CERN OHL V1.2 and is fully Open Hardware.
And finally, some eye candy (please note that the images might not exactly resemble the actual boards, as I am still making minor tweaks to them)

The 5x5 cm board: (available for purchase at DirtyPCBs)

The BOX-2252 board:

The LE-BOX-0028 board:

Changelog: https://github.com/mysensors/MySensors/releases/tag/2.3.0

Thanks to all GitHub users who contributed to this release:

d00616
flopp999
Kartik Arora
kvoit
Marcelo Aquino
Marco Bakera
Martin Hjelmare
Mikael Falkvidd
Miloslav Kazda
Patrick Fallberg
per1234
seeers
tekka
thucar
Tombula

With the launch of the nice openhardware.io site, design licensing has become more obvious to those who design hardware.
If you decide that you want to license your design, it is important to understand what this means and what (if any) expectations are put on you as licensor (original author of the design) or licensee (user of the license, your own design or someones design you have based your work on).
I have used the CERN OHL v1.2 license and would like to clarify exactly what you need to consider when using that license. If anyone has experience from other Open Hardware licence models, feel free to add to this thread
Also feel free to discuss the CERN license and my interpretation of it.

The CERN OHL v1.2 license is a permissive license. But it still require the licensor to include certain documents with the hardware design files. These expectations are also put on any licencees.
CERN provides a howto to it's licenses where the specifics are documented, but I will try to summarize them here as well:
The licensor/licensee MUST:

• Provide a copy of the CERN license (LICENSE.TXT or LICENSE.PDF or LICENSE.ODT)
• Provide a copy of the CERN license howto (cern_ohl_v_1_2_howto.pdf or cern_ohl_v_1_2_howto.odt)
• Provide a PRODUCT.TXT specifying a contact point where licensees MAY contact the licensor about production and/or distribution of the licensed product if the licensor has indicated a desire to receive this information.
• Provide a CHANGES.TXT where the licensee specifies what modifications has been made to the original design. The licensor may also use this file to provide a changelog of the design.
• Provide the following (I personally use COPYRIGHT.TXT for these)
  • a notice that the hardware design documentation is licensed under the
    CERN OHL v.1.2, possibly with a link to http://ohwr.org/cernohl where
    the licence texts are hosted:
    • “Licensed under CERN OHL v.1.2 or later”
    • “Licensed under CERN OHL v.1.2”
  • a disclaimer of warranties
  • a Documentation Location if you wish to specify one

A licensor MAY:

• Add “Licensed under CERN OHL v.1.2” on top copper layer or silkscreen of PCB

A licensee MUST:

• Keep any existing "Licensed under CERN OHL v.1.2” text on PCB that were on the board the licensee bases the new project on.
• Redistribute the new project under the same license as the original design.
• Keep and maintain a CHANGES.TXT and keep the other copyright/warranty disclaimer notices

So to summarize a bit further. The files you need to keep with your board files are:

• LICENSE.TXT
• cern_ohl_v_1_2_howto.pdf
• PRODUCT.TXT
• CHANGES.TXT
• COPYRIGHT.TXT

For details on the CERN OHL 1.2 license and its usage, see CERN Open Hardware License 1.2 and CERNs FAQ.

We are happy to announce a maintenance release of MySensors library to 1.5.2!

This version is backward compatible with 1.5.1 and contain security related bugfixes and stabilizations:

• Backport of bugfix (#259) in repeaters when forwarding signed messages
• Prevent SecureActuator from accepting ACKs as commands
• Make sure nodes not supporting signing informs gateway
• Fixes addressing bug in _doSign bitfield
• Stabilizes Jenkins

It is recommended that you update all your nodes and gateways if you use message signing.

If you are curious on what features are planned or what fixes are scheduled for the next release or future releases, check out the MySensors projects on Github.

Once library version 2.2 is released (it is currently in beta and available on the development branch on GitHub) users that were using signing or encryption will have to re-do personalization. This is because in 2.2, a checksum has been added to the security data in EEPROM to avoid usage of tampered or accidentally wiped data.
Migrating the data is not complicated as personalization in 2.2 has been rewritten to be simpler to use.

There are a few options here. The simplest is to just re-do personalization from scratch. The new SecurityPersonalizer will guide you through the process. Just execute it unmodified on the device and follow the instructions in the serial console.

If you want to reuse an existing AES or HMAC key , follow this procedure:

1. Execute the SecurityPersonalizer example without any modification on your device. Then take note of the EEPROM contents displayed. It can look something like this:

+------------------------------------------------------------------------------------+
|                                       EEPROM                                       |
+--------+--------+------------------------------------------------------------------+
| Key ID | Status | Key                                                              |
+--------+--------+------------------------------------------------------------------+
| HMAC   | RESET  | FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF |
| AES    | RESET  | FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF                                 |
| SERIAL | RESET  | FFFFFFFFFFFFFFFFFF                                               |
+--------+--------+------------------------------------------------------------------+

1. Copy the HMAC and/or SERIAL and/or AES key (if you use soft signing) or only the AES key (if you use ATSHA204 based signing) and put the values into the following lines in the SecurityPersonalizer.ino file (leave the default values of the HMAC and SERIAL for ATSHA204 based signing):

#define MY_HMAC_KEY 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00

#define MY_AES_KEY 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00

#define MY_SOFT_SERIAL 0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF,0xFF

1. Uncomment this line:

//#define PERSONALIZE_SOFT

1. Execute the sketch again. Now the data will be rewritten to EEPROM and a checksum will be calculated and stored. For hardware based signing, the "old" HMAC key will remain in use, but the checksum will be updated for the AES key (it will also cover the software HMAC and SERIAL, but they are not used for hardware based signing).

If you do not use, nor plan to use, whitelisting, you can leave the SERIAL value as is, and execute the modified personalizer without further modifications on every devie. If you plan to use (or already use) whitelisting, you need to rewrite the proper serial on all devices as well (users of hardware based signing can ignore this, as the serial of the ATSHA204A is used and is fixed to each device.
Note that if you change the SERIAL compared to what was stored previously, you also will need to update all whitelists that has an entry for that node.

EDIT: Obviously, do NOT copy your ATSHA204A HMAC key and store it in EEPROM. It would negate the benefit of the ATSHA readback protection.

@Eurbaix thank you for your input. You are perfectly correct and the core team is currently discussing alternative approaches for more modern hardware (we have to consider that many users still base their designs on the atmga328p).
But we are looking into implementing some form of PKI based security solution which is in many ways similar to your proposal. I don't have and eta for this yet though. But the new security infrastructure will not support a atmga328p based gw.
Me and @d00616 have been discussing back and forth but we are all limited in time, and implementing security features should be done with care so things take time.

Recently, Google announced that it had succeeded in calculation colliding SHA1 checksums with "reasonable" effort and thus concluding SHA1 is now obsolete and insecure.
MySensors security backend rely on hashes as well, but rest assured there is absolutely no impact for message signatures as they are based on SHA256 and not SHA1.
For details on the cracking, see here.

@AndErn MySensors is developed by people that also have day time jobs. You can't expect to get enterprise level support for something that is

1. Free to use
2. Developed on a spare-time basis
3. Without a paid support organization

Especially, if you don't use the polite tone suggested in the forum guidelines.
People here try their best to help out as much as possible.

Harald is mature enough (one month) to start working with dad on board design

Message exchange with and without signing would look something like this:

Scenario: No one require signing:
Sending from node to GW:
node->gw (message)

Sending from GW to node:
gw->node (message)

Scenario: GW does not require signed messages, node does:
Sending from node to GW:
node->gw (message)

Sending from GW to node:
gw->node (nonce request)
node->gw (nonce)
gw->node (signed message)

Scenario: GW require signed messages, node does as well:
Sending from node to GW:
node->gw (nonce request)
gw->node (nonce)
node->gw (signed message)

Sending from GW to node:
gw->node (nonce request)
node->gw (nonce)
gw->node (signed message)

So, not counting calculation latencies, from a pure transmission point of view, a signed messages takes three times longer than a non signed message does due to handshaking.

A compilation issue was found relating to signing in 1.5.2 so we issue an emergency release of 1.5.3.
Sorry for the inconvenience.
There is no logical difference between 1.5.2 and 1.5.3 except version number and compilation fix.

And a secure new year! Who knows, a late Santa might have a few signing presents in his bag for spring

@Pierre-P because if a node is lost, you no longer control that node. So anyone could reprogram it to have it identify itself in any way possible. We have to assume an attacker has full source code access, so they can rewrite the signing algorithm to use a fake serial as salt for the signature to trick the GW to believe it is a new node. A whitelist mean the attacker has to know the ID/serial of one of the nodes you trust. Which they won't know unless they can get access to that node.

@maghac Hi,
documentation is best found here: https://www.mysensors.org/apidocs/
It is always covering the latest release. Specifically, for message types: https://www.mysensors.org/apidocs/group__MyMessagegrp.html

Exposing all of your sensors and actuators to WiFi is a bad idea from a security point of view. But all is relative.

@Nicklas-Starkel
I owe you an apology. It appears there for some configuration combinations does exist a bug for signing in 2.1. @tekka found a problem where the signing presentation in some situations would not be sent to the correct node.
That said, you do appear to also have issues with the radio (the NACKs) but you are correct in that there is an issue with signing. It will be resolved in 2.1.1.
Thank you for reporting, and again, please accept my sincere apology for failing to look more thoroughly through your logs.

I hope to be able to file a pull request with updates to the personalizer this or next week. @LastSamurai @MLs @meddie i would really appreciate if you tested and reviewed the change so that you (and others) no longer are deterred from using signing due to its complexity. I will update the pull request until you feel confident in the procedure. I will post a link here when I have something to show for.

@Nicklas-Starkel nice to hear! We are constantly trying to improve the performance in various aspects. I think it is @tekka that deserves the credit for increased rf performance as he has done a tremendous work with the drivers.

@LastSamurai I am pretty much rewriting the entire personalizer. So I am glad to have a motivated test team at hand
Ease of use is prio1 with flexibility coming in second.

@Reza Read the documentation please. https://www.mysensors.org/about/signing

My gateway build project has progressed far enough to be "announced".
Goal of the project: To create a gateway that is capable of providing serial/Ethernet/MQTT capabilities and securely authenticated transmissions. Because I like a challenge, I am doing this on a Arduino Nano. So far I have managed to squeeze in a sketch that can handle both serial and HDCP capable Ethernet (gateway becomes a serial if it cannot aquire an IP through DHCP). I am hoping to also fit MQTT code into it but I am not sure that is possible since I also want to put in a driver for my authentication chip and probably need a software SHA256 algorithm as well. But as the USB connector will be exposed, I can live with having to reprogram it, should I need to.

The bill of material is as follows (may be updated as build progresses):

• 1 Arduino Nano
• 1 NRF23L01 PA-enabled radio transceiver
• 1 W5100 Ethernet module
• 1 LE33 regulator
• 1 ATSHA204 authentication chip (on breakout board)
• 1 Red LED
• 1 Green LED
• 1 Yellow LED
• 3 330Ω resistors
• 2 0Ω resistors (optional)
• 2 4.7uF capacitors
• 1 100pF capacitor
• 1 10pF capacitor
• 2 pushbuttons
• 1 Adafruit half-size perma-proto PCB
• A few meters of leads suitable for PCB wiring
• Male/Female pin headers (cut to various sizes)
• Heat shrink tubing

This is the schematic:

also available on GitHub. gEDA is the tool used throught the HW design.
Symbols and custom footprints are also on GitHub.

I have modeled the perma-proto in the gEDA PCB tool in order to figure out the optimum wiring with respect to holes, component placement and wire widths and to make sure I do not miss any connection (almost every interconnect needs to be handwired/soldered).
This is the top and bottom placements:

And the routing of the sides (routing is done with respect to hand wiring and component clearances due to thick cables, hence the sometimes less-than-optimal routing paths). Also note that the back-side routing is displayed as viewed from the top.


Start by cutting the PCB on the bottom side so that the modules can be inserted without shorts:

After a few man-hours cutting and soldering:

Top side with components:

The LEDs are "tall" because I have not yet decided on exact box format, so this gives me some flexibility in positioning/aligning the LEDs.

Bottom side with components:

The antenna connector aligns with one of the ground-rails, so it can be soldered down on the board as well to provide additional support for the RF module:

Gateway sketch has been updated to manage the ETH_SPI_EN signal. Available on GitHub. Please note that I will at my own leisure do force-pushes to this branch, so if you clone it; you have been warned. You are welcome to copy it anyway you like.

Also note that the ATSHA204_SDA has been moved from A7 to A3 so the graphics above are not entirely true (but GitHub is).

@jpaulin I have made a pull request. My solution differs slightly from your as the I_SIGNING_PRESENTATION should never reach the _processInternalMessages function. I do however not have the ability to test so I would appreciate if you could test the PR for me?
Thanks for finding and pointing out the flaws!

@Sergio-Rius Oh, I just read your "selectively implemented by controllers" and thought that it should be up to the controller to use that.
Well, a dedicated key storage node is a thought, although as things are with and without security currently, the use of atmega328p based GW:s is coming to an end.
So we should not base future security functionality on basis that the GW is performance limited.
Me and @d00616 have been discussing a scheme where the GW generates a root key and distribute node specific keys. But there are many aspects to cover still, one such is handling of repeater nodes, and we are also constrained in time for how much time and effort we can spend on this at the moment. There is already a security scheme in place and although it is not perfect, it is adequate from a security point of view.
And personally, I currently simply don't have the time to spare to design and implement something newer right now. Suggestions and PR:s are always welcome. That's how I started out, others are welcome to do the same
Although since then I have been elevated to some form of security responsible, so I will for that sake, place some pointers to what a new security scheme need to cover:

• Authentication
• Obfuscation
• Handle node-jumping (repeater nodes)
• Support resource limited nodes (not necessarily GW:s)
• Not transmit sensitive data OTA
• Be simple to use
• Be well documented
• Either support key protection or simple key revocation (preferably on a per-node basis)

That's all I can think of right now

EDIT: Moved the location of the SHA204 personalizer in the first post since it has moved in the tree.
Also, I have noticed that recent activity on development branch seem to have broken the signing support. I am investigating the issue.
Life on the development branch is 'hard'. I am sorry about the outage, but these things are to be expected when many developers work on the same code piece and are not fully in-sync with each others activities. I will post here a SHA to a known "good" state once I have sorted the issue. I encourage all to test this out once I do, so we can get more test-coverage on this quite big feature in the library. Once we have it stabilized, it might get included in a "v1.5" of the library and then live a happy stable life on 'master'

@NeverDie that is probably correct, I just feel a responsibility to inform everyone of any known weaknesses in the security infrastructure

MYSX 2.x has been launched and does come with a reset pin

@tekka Would it be possible in a future version to have the controller save the detected network nodes? Right know, I have to re-present the nodes in order for them to appear properly in the tree every time MYSController is restarted since it starts up with an empty tree.

@noelgeorgi AES encryption is already supported for both NRF24 and RFM69 radios. See MyConfig.h on the development branch for the flag to use. Doyxgen documentation I link to in this thread on the topic post also contain the personalization instructions for encryption on the development branch.

@alowhum thanks for the shout out it is inspiring to see how the envelope really can be pushed with open source powered hardware and software. Really impressive stuff!

@Fleischtorte we have confirmed a bug in the I2C eeprom management in the samd platform. A fix is in the works.

@martinhjelmare @shabba @hek I've updated the sketch conversion post with a note about security settings: https://forum.mysensors.org/topic/4276/converting-a-sketch-from-1-5-x-to-2-0-x

@d00616 I don't however see it as a problem if you implement some underlying security solution specific to nrf5 as long as it don't require protocol "awareness". That's just a bonus so feel free to have a look at that. But things will quite fast become quite messy if we start mixing security schemes in the protocol.
The signing backend does have versioning support so it is possible to extend it with new schemes, but so far the scheme we use is supported across all radio variants and it would be a pity to give up that compatibility unless the new scheme offer some improvement over the current one.
The main drawback with the current one is the message size limitation imposed by the current protocol version which forces us to truncate the signatures but in version 3 of the MySensors protocol, this limitation will be overcome by protocol upgrades.

@meddie the development branch has been updated with a bug fix for the eeprom problem on samd based boards. If you pull the latest changes you should be able to properly personalize the AES key so that encryption will work.

@giltesa many power their devices through USB on their computers for bringing up nodes.
Often the radio is powered by the same source, and driving it at max makes the nrf24 unstable if the power supply is not rock solid.
Besides, having the default being at the lowest power, you have reasonable power optimization by default for battery powered nodes.
If it does not work you can always gradually crank it up. And not the other way around.

There is one thing I can do. I can add a third signing backend. And have it get its key from a define. It won't support whitelisting and the same define will enable signature requests and encryption. As it is much less secure, it will probably be enabled using MY_INSECURE_SECURITY_PASSWORD which also define the keys to use.
That way, the current backends are not loosing integrity, you hopefully get what you want, and everybody stays happy
Unfortunately I cannot give an ETA on when it will be completed but if you agree that this is what you are seeking, I can add an issue for it do we can track it on github. It will be a feature extension so it can get in before releasing version 3 of the library.

Is this acceptable?

@sundberg84 @mickecarlsson
It is important to remember that MYSX is agnostic from any devices.
Any names in MYSX pins bear no correlation to any device specific pin naming, so D3 and D4 mentioned on pin 9 and 10 has nothing to to with any D3 or D4 on any MCU.
If you look here, you will find that the 'A' and 'D' notation is simply an indicator of the pin function (analog or digital) and it simply increments with the pin number, so the lowest analog or digital pin number in the MYSX connector will start at '1' and then increment as the pin number increments with '2' for the next digital being on pin '6'.
Also note that since some pins are deprecated in MYSX 2.x, MYSX 2.x analog pins starts with 'A3'.

MyFactory?

@tbowmo I have also briefly discussed this with @hek and I think along the same lines as you. Having both RFM69 and NRF 24 options is actually a good idea. RFM69 also supports longer range (lower carrier frequency) and AES encryption (for us paranoid freaks). I am wondering if it actually would be possible to run them simultaneously. The gateway could keep a table of nodes using the "other" network in runtime and store it in EEPROM (similar to how it tracks nodes that require signing). I see no direct technical reason for the GW not to be able to juggle both RF solutions in a mixed network.

I am in the middle of a big internal debate with myself at the moment whether I should stick to my current gateway which I have built and continue the battle with sketch size problems and such or build me a new one.

I have also not yet designed a box for my gateway, so I am actually considering trashing it and start over with a bigger design.

Do you know if there are any Atmega1284s "breadboardable"? I did not have issues with my W5100 module which has SPI_EN available so I think I will stick to that and WiFi is for me more of a nice-to-have feature since my goal is to cover the home in nodes so my GW should be possible to place anywhere where there happens to be a RJ-socket available.

One thing that would be nice though is if the board could be powered with POE (Power Over Ethernet). That is I think definitely a selling point.

I also think that hunting size on gateways is less important than functionality. Most only have "one" and it can be tucked away from sight from "other parts of the family less technically geeky".
I would even consider adding space so that there perhaps is some prototyping space where future addons could be patched in.

@Salmoides The case design is depending on you personal build preferences. But since the base board will have a well defined range of supported modules and such, a range of suitable cases can be offered as well. An example would be one box that has cutout for external RF antennae and one that doesn't. Of course it is possible to bring out the drill, but it is prettier to have a customized case.

Hello forum users!

I have implemented support for software AES encryption for RFM95 radios. Unfortunately, I have no hardware to test it on. Is there someone here that use RFM95 radios that could be so kind to test this for me, so the PR can be merged and included in the next library release?

The PR is here.

Not only a genius, the founding father of the SenseBender series Himself

@Anduril for encryption, the difference is not significant. With personalization, the key is stored in flash/eeprom and without it is defined in your sketch. So, if you personalize, you can publish your sketch without worrying about being compromised. And encryption works transparently with the OTA solution, IF the software that implement OTA is aware of the encryption scheme. That is, the software that configures the radio (in some solutions that is the bootloader) need to configure the appropriate key to the radio hw or driver (depending on radio).
For bootloader based OTA that require personalization unless you recompile the bootloader with the encryption key and make it configure the radio accordingly.

@nca78 @sundberg84 In general, I would recommend placing the connector and align the courtyard along the edge.
That way, you will get a standard 100mil spacing to the long edge of the connector. It is tricky to put requirement on a second edge due to the pin1 orientation requirement since that essentially require all motherboards to place MYSX at the top left.
It of course helps alignment-sensitive daughterboards such as yours to ensure motherboard edge alignment, but it puts great restrictions on motherboards. It is a tricky balance.

I'd suggest you fight it out and then we update the spec if needed

I can see the merit of both alternatives.

@ximinez If possible, try to check if signing and verification of signatures work as well. I have tried to implement the use of the ATSHA to be atomic in nature, but it could be that some state is retained which is cleared on power down which might break the calculations.

@sundberg84 I will just go ahead and update the spec. Yes, it may cause some existing designs to violate the spec, but that will always be the case. We look forwards, not backwards
Spec is here.

@sineverba why did you delete them? There is nothing secret about them. They are sent over your radio link so they are to be considered very public, or signing wouldn't be useful, would it?

@Reza just stop creating new accounts please.

@wes you can pull. Just as long as you verify that your working directory is clean or only contains changes you intend to have. And you have the appropriate branch or tag checked out.

@sineverba yes, you can set weak security only on gateway and if you do, you can leave some nodes without signing or encryption enabled. You can also only set the require signatures flag on a specific node and omit it on the gateway. Just be aware that any node not having the request flag, will accept unsigned messages.

@ahmedadelhosni said:

Please bear with me. I just want to be sure I understand it well.
"For this reason, signing is not used for streams." Means that signing is not used when uploading a sketch. Does this lead to a hacker replacing my sketch ?

No, I stated that the sketch is checksummed and that checksum is signed. So no, a hacker won't (probably) be able to replace your sketch. Lest he is able to produce one that yields the exact same checksum AND manages to inject it so that the signed checksum is arrived in a timely manner for the receiver to take it into account.

Checksum will make sure that the sketch is transferred correctly so to avoid data corruption, correct ?

"Sure" in this aspect is a very relative term. But yes, that is it's purpose.

So you propose that a signature must be added with the checksum for security, correct ??

No, I say it is added if signing is enabled. But please be aware that the current version of MYSBootloader does not support signing. Future versions will do.

So in brief. OTA is not secured at the moment and the code can be replaced easily with an unsigned one, correct ?

No, as I said, dualoptiboot should be secure. But the use of CRC as checksum is not as secure as SHA256 would be, so the security is not as good as it can be.

@joaoabs I am glad that you at least came to some form of conclusion. I suspect this is just another example of the sketch running out of ram for the stack. The symptoms can be really weird and unpredictable. Just a slight change on the execution path and something that worked fine just before simply explodes or, executed something completely different.

We really are pushing it with signing on atmega328p, because the library also grows in size with time (new features come in).

I'd say, and I will probably soon update the documentation with it, that signing/security does technically work on atmega328p, but due to the limited ram, it's usability is very limited to just basic sketches.

Thanks for reporting this. It adds to the hive mind of knowledge and experience in troubleshooting

@NeverDie sounds like mysensors is not your cup of tea then.

@Reza look, a lot of people agree that the radio works fine when proper components and design is used. It will remain to be supported by the core library and the community. Alternative radios have been presented to you.
You say that the power to the radio is good. Have you measured that? You don't think putting a huge number of sensors on the same device, all consuming power and adding noise to the system combined with a rats nest of cables has an impact on the radio performance? You could put any radio in that environment and it wouldn't perform any better.

Well, as many have pointed out now, they don't have problems with range on the nrf and for even better range, use rfm, so why should we look for other radios? The ones we support are perfectly adequate.

I think you should separate the logic as one if-case to manage the lastToggle envent and a new one for reading the values.
Your code as it looks now, first requires the toggle value to be changed, then if the toggle value is changed, yo set the lastToggle variable to the current value, thus immediately makes all conditions to the first if-case false, so that after the first if-case has been true once, it will the next time, by definition, be false, so the return value will be false after each call it has returned true on.
Your comment suggests that "or the button has been pressed." But the if case actually does not distinguish from the button being pressed or not, it just triggers if the state has changed, so it is true for the button being released as well.

Simple example:

boolean lastToggleVeraRemote, lastToggleRemoteBtn;
boolean IsRemoteOnOff()
{
    updateToggles();

    if (lastToggleVeraRemote || lastToggleRemoteBtn)
    {
        return true;  //remote is active
    }
    else
    {
        return false; //remote is not active
    }
}

If you for some reason need to have logic to update the LastToggle variables on change, it is a different thing than determine if the toggles are 'active' and in my opinion they should be handled "outside" this logic.

boolean lastToggleVeraRemote, lastToggleRemoteBtn, toggle_vera_remote, toggle_remote_btn;
boolean updateRemotes()
{
    updateToggles();

    if (lastToggleVeraRemote != toggle_vera_remote)
    {  //if it was the Vera remote that changed then update the status for the vera remote
        lastToggleVeraRemote = toggle_vera_remote ;    
    }
    if (lastToggleRemoteBtn != toggle_remote_btn)
    {   //if it was the pushbutton then update the status of the button
        lastToggleRemoteBtn = toggle_remote_btn ;
    }             
}

But of course they can be combine if you prefer.

boolean lastToggleVeraRemote, lastToggleRemoteBtn, toggle_vera_remote, toggle_remote_btn;
boolean IsRemoteOnOff()
{
    updateToggles();

    if (lastToggleVeraRemote != toggle_vera_remote)
    {  //if it was the Vera remote that changed then update the status for the vera remote
        lastToggleVeraRemote = toggle_vera_remote ;    
    }
    if (lastToggleRemoteBtn != toggle_remote_btn)
    {   //if it was the pushbutton then update the status of the button
        lastToggleRemoteBtn = toggle_remote_btn ;
    }             

    if (lastToggleVeraRemote || lastToggleRemoteBtn)
    {
        return true;  //remote is active
    }
    else
    {
        return false; //remote is not active
    }
}

@tekka true. Moving the existing delay outside the preprocessor condition should help.

@petewill I can also confirm that MYSController can coexist with Vera.
I use node-red to abstract things. In my case, I want the Vera (and MYSController) to be left in the dark on how my controller is actually implemented and node-red is the ideal tool to do this.

This is my "flow"

Using it, I can have either a serial or an ethernet gw without the controllers knowing.
Instead, I create network serial pipes using socat that the controllers connect to.
I can also filter out the debug prints from the gw if I want to examine something and also prevent them from "disturbing" the controllers (if they do not explicitly support the debug messages or gets bogged down by them).

I still need to see if the node-red nodes support OTA since they key packets on '\n' currently which is not really "binary friendly" though, but for normal MySensors operation not involving binary streams, it works just fine

Quite familiar HW won't you say?
http://blog.atmel.com/2015/01/13/a-10-usb-charger-can-record-your-keystrokes-wirelessly/

EDIT 2: I found out the hard way that pin A7 cannot be used for digital IO. So I had to patch the ATSHA204 signal to use A3 insterad (this also matches other MySensors HW that uses ATSHA204, ping @tbowmo).

@joaoabs thanks for reporting.
@tekka something related to your crypto hal refactoring?

Here is my current nodeconfig:

[{"id":"c1f1131a.3e0ef","type":"subflow","name":"Manual preprocessor","info":"Processes manual specific input","in":[{"x":50,"y":30,"wires":[{"id":"b73bbc01.48c44"}]}],"out":[{"x":264,"y":30,"wires":[{"id":"b73bbc01.48c44","port":0}]}]},{"id":"b73bbc01.48c44","type":"change","z":"c1f1131a.3e0ef","name":"Topic=Manual","rules":[{"t":"set","p":"topic","to":"Manual"}],"action":"","property":"","from":"","to":"","reg":false,"x":156,"y":30,"wires":[[]]},{"id":"c542f76c.3abd08","type":"subflow","name":"Vera postprocessor","info":"Processes Vera specific output","in":[{"x":50,"y":30,"wires":[]}],"out":[{"x":160,"y":30,"wires":[{"id":"c542f76c.3abd08","port":0}]}]},{"id":"c1bbb0ac.3e445","type":"subflow","name":"MYS postprocessor","info":"Processes MYSController specific output","in":[{"x":50,"y":30,"wires":[]}],"out":[{"x":160,"y":30,"wires":[{"id":"c1bbb0ac.3e445","port":0}]}]},{"id":"56bd1bfc.a942e4","type":"subflow","name":"MyC postprocessor","info":"Processes MyController specific output","in":[{"x":50,"y":30,"wires":[]}],"out":[{"x":160,"y":30,"wires":[{"id":"56bd1bfc.a942e4","port":0}]}]},{"id":"6bb8370.f9447c8","type":"subflow","name":"MyC preprocessor","info":"Processes MyController specific input","in":[{"x":50,"y":30,"wires":[{"id":"287b2c2e.d784d4"}]}],"out":[{"x":330,"y":30,"wires":[{"id":"287b2c2e.d784d4","port":0}]}]},{"id":"287b2c2e.d784d4","type":"change","z":"6bb8370.f9447c8","name":"Topic=MyController","rules":[{"t":"set","p":"topic","to":"MyController"}],"action":"","property":"","from":"","to":"","reg":false,"x":184,"y":30,"wires":[[]]},{"id":"9a01ec1d.65fe1","type":"subflow","name":"MYS preprocessor","info":"Processes MYSController specific input","in":[{"x":50,"y":30,"wires":[{"id":"ab4674a4.54b988"}]}],"out":[{"x":320,"y":30,"wires":[{"id":"ab4674a4.54b988","port":0}]}]},{"id":"ab4674a4.54b988","type":"change","z":"9a01ec1d.65fe1","name":"Topic=MYSController","rules":[{"t":"set","p":"topic","to":"MYSController"}],"action":"","property":"","from":"","to":"","reg":false,"x":183,"y":30,"wires":[[]]},{"id":"fb0fe50f.04f018","type":"subflow","name":"Vera preprocessor","info":"Processes Vera specific input","in":[{"x":54,"y":36,"wires":[{"id":"fb4a1920.04b5e8"}]}],"out":[{"x":288,"y":36,"wires":[{"id":"fb4a1920.04b5e8","port":0}]}]},{"id":"fb4a1920.04b5e8","type":"change","z":"fb0fe50f.04f018","name":"Topic=Vera","rules":[{"t":"set","p":"topic","to":"Vera"}],"action":"","property":"","from":"","to":"","reg":false,"x":158,"y":36,"wires":[[]]},{"id":"87ad6845.785298","type":"subflow","name":"MYS dbg mgt","info":"","in":[{"x":25,"y":28,"wires":[{"id":"a5f38922.5a0c78"}]}],"out":[{"x":787,"y":25,"wires":[{"id":"87b5da5b.784a28","port":0}]},{"x":615,"y":70,"wires":[{"id":"c58c8cac.3a737","port":0}]}]},{"id":"7d24de87.82db2","type":"function","z":"87ad6845.785298","name":"Debug from Data from Ping","func":"if (msg.messageType == 3 && msg.subType == 9) {\n   return [ msg, null, null ];\n} else if (msg.messageType == 3 && msg.subType == 18) {\n   return [ null,  null, msg ];\n} else {\n   return [ null, msg, null ];\n}\n","outputs":"3","noerr":0,"x":302,"y":28.5,"wires":[["a49c42e6.5b63c"],["a49c42e6.5b63c","c58c8cac.3a737"],["c58c8cac.3a737"]]},{"id":"a5f38922.5a0c78","type":"mysdecenc","z":"87ad6845.785298","name":"Decode","x":117,"y":28,"wires":[["7d24de87.82db2"]]},{"id":"c58c8cac.3a737","type":"mysdecenc","z":"87ad6845.785298","name":"Encode","x":520,"y":71,"wires":[[]]},{"id":"a49c42e6.5b63c","type":"mysdecenc","z":"87ad6845.785298","name":"Encode","x":523,"y":25,"wires":[["87b5da5b.784a28"]]},{"id":"87b5da5b.784a28","type":"mysdebug","z":"87ad6845.785298","name":"Debug decorate","x":671,"y":26,"wires":[[]]},{"id":"a2721ec7.5d8de","type":"pushbullet-config","z":"","name":"somename"},{"id":"8160ff88.7e9f","type":"subflow","name":"MYS Pushbullet publisher","info":"","in":[{"x":68,"y":79,"wires":[{"id":"108590a6.ef7a6f"}]}],"out":[]},{"id":"e2dea93.f1d2158","type":"pushbullet","z":"8160ff88.7e9f","config":"a2721ec7.5d8de","pushtype":"note","title":"Lock status","chan":"noneofyourbusiness","name":"Lock status","x":1042,"y":1072,"wires":[]},{"id":"69c63289.9639cc","type":"function","z":"8160ff88.7e9f","name":"Format","func":"if (msg.payload == 1) {\n    msg.payload = \"Locked\";\n} else {\n    msg.payload = \"Unlocked\";\n}\nreturn msg;\n","outputs":1,"noerr":0,"x":905,"y":1072,"wires":[["e2dea93.f1d2158"]]},{"id":"9afa4e84.6505b","type":"switch","z":"8160ff88.7e9f","name":"Message type","property":"messageType","rules":[{"t":"eq","v":"0"},{"t":"eq","v":"1"},{"t":"eq","v":"2"},{"t":"eq","v":"3"},{"t":"else"}],"checkall":"true","outputs":5,"x":417,"y":129,"wires":[["a1c9e060.5e362"],["7ee958f8.8116a8"],["7ee958f8.8116a8"],["6aa07c4a.955f84"],[]]},{"id":"108590a6.ef7a6f","type":"mysdecenc","z":"8160ff88.7e9f","name":"MySensors decode","x":198,"y":79,"wires":[["9afa4e84.6505b"]]},{"id":"a1c9e060.5e362","type":"switch","z":"8160ff88.7e9f","name":"PresentationSubtype","property":"subType","rules":[{"t":"eq","v":"0"},{"t":"eq","v":"1"},{"t":"eq","v":"2"},{"t":"eq","v":"3"},{"t":"eq","v":"4"},{"t":"eq","v":"5"},{"t":"eq","v":"6"},{"t":"eq","v":"7"},{"t":"eq","v":"8"},{"t":"eq","v":"9"},{"t":"eq","v":"10"},{"t":"eq","v":"11"},{"t":"eq","v":"12"},{"t":"eq","v":"13"},{"t":"eq","v":"14"},{"t":"eq","v":"15"},{"t":"eq","v":"16"},{"t":"eq","v":"17"},{"t":"eq","v":"18"},{"t":"eq","v":"19"},{"t":"eq","v":"20"},{"t":"eq","v":"21"},{"t":"eq","v":"22"},{"t":"eq","v":"23"},{"t":"eq","v":"24"},{"t":"eq","v":"25"},{"t":"eq","v":"26"},{"t":"eq","v":"27"},{"t":"eq","v":"28"},{"t":"eq","v":"29"},{"t":"eq","v":"30"},{"t":"eq","v":"31"},{"t":"eq","v":"32"},{"t":"eq","v":"33"},{"t":"eq","v":"34"},{"t":"else"}],"checkall":"true","outputs":36,"x":723,"y":275,"wires":[[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]]},{"id":"7ee958f8.8116a8","type":"switch","z":"8160ff88.7e9f","name":"SetReqSubtype","property":"subType","rules":[{"t":"eq","v":"0"},{"t":"eq","v":"1"},{"t":"eq","v":"2"},{"t":"eq","v":"3"},{"t":"eq","v":"4"},{"t":"eq","v":"5"},{"t":"eq","v":"6"},{"t":"eq","v":"7"},{"t":"eq","v":"8"},{"t":"eq","v":"9"},{"t":"eq","v":"10"},{"t":"eq","v":"11"},{"t":"eq","v":"12"},{"t":"eq","v":"13"},{"t":"eq","v":"14"},{"t":"eq","v":"15"},{"t":"eq","v":"16"},{"t":"eq","v":"17"},{"t":"eq","v":"18"},{"t":"eq","v":"19"},{"t":"eq","v":"20"},{"t":"eq","v":"21"},{"t":"eq","v":"22"},{"t":"eq","v":"23"},{"t":"eq","v":"24"},{"t":"eq","v":"25"},{"t":"eq","v":"26"},{"t":"eq","v":"27"},{"t":"eq","v":"28"},{"t":"eq","v":"29"},{"t":"eq","v":"30"},{"t":"eq","v":"31"},{"t":"eq","v":"32"},{"t":"eq","v":"33"},{"t":"eq","v":"34"},{"t":"eq","v":"35"},{"t":"eq","v":"36"},{"t":"eq","v":"37"},{"t":"eq","v":"38"},{"t":"eq","v":"39"},{"t":"eq","v":"40"},{"t":"eq","v":"41"},{"t":"eq","v":"42"},{"t":"eq","v":"43"},{"t":"eq","v":"44"},{"t":"eq","v":"45"},{"t":"else"}],"checkall":"true","outputs":47,"x":740,"y":903,"wires":[[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],["69c63289.9639cc"],[],[],[],[],[],[],[],[],[],[]]},{"id":"6aa07c4a.955f84","type":"switch","z":"8160ff88.7e9f","name":"InternalSubtype","property":"subType","rules":[{"t":"eq","v":"0"},{"t":"eq","v":"1"},{"t":"eq","v":"2"},{"t":"eq","v":"3"},{"t":"eq","v":"4"},{"t":"eq","v":"5"},{"t":"eq","v":"6"},{"t":"eq","v":"7"},{"t":"eq","v":"8"},{"t":"eq","v":"9"},{"t":"eq","v":"10"},{"t":"eq","v":"11"},{"t":"eq","v":"12"},{"t":"eq","v":"13"},{"t":"eq","v":"14"},{"t":"eq","v":"15"},{"t":"eq","v":"16"},{"t":"else"}],"checkall":"true","outputs":18,"x":739,"y":1397,"wires":[[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]]},{"id":"8f98bd26.70674","type":"subflow","name":"DOM postprocessor","info":"Processes Domoticz specific output","in":[{"x":33,"y":143,"wires":[{"id":"699b5758.9664a8"}]}],"out":[{"x":951,"y":150,"wires":[{"id":"78766dd2.878994","port":0}]}]},{"id":"699b5758.9664a8","type":"mysdecenc","z":"8f98bd26.70674","name":"","x":139,"y":143,"wires":[["1ecc685.fe13398"]]},{"id":"1ecc685.fe13398","type":"switch","z":"8f98bd26.70674","name":"Type is SET?","property":"messageType","rules":[{"t":"eq","v":"1"},{"t":"else"}],"checkall":"true","outputs":2,"x":289,"y":143,"wires":[["73b9b1e.f8c465"],["78766dd2.878994"]]},{"id":"78766dd2.878994","type":"mysdecenc","z":"8f98bd26.70674","name":"","x":846,"y":150,"wires":[[]]},{"id":"73b9b1e.f8c465","type":"switch","z":"8f98bd26.70674","name":"Is V_LOCK_STATUS?","property":"subType","rules":[{"t":"eq","v":"36"},{"t":"else"}],"checkall":"true","outputs":2,"x":476,"y":127,"wires":[["5e7ebd41.a18144"],["78766dd2.878994"]]},{"id":"5e7ebd41.a18144","type":"function","z":"8f98bd26.70674","name":"Invert payload","func":"if (msg.payload == 1)\n    msg.payload = 0;\nelse\n    msg.payload = 1;\nreturn msg;","outputs":1,"noerr":0,"x":670,"y":113,"wires":[["78766dd2.878994"]]},{"id":"6f018651.90fe78","type":"subflow","name":"DOM preprocessor","info":"Processes Domoticz specific input","in":[{"x":31,"y":188,"wires":[{"id":"b03550b3.4fcab"}]}],"out":[{"x":894,"y":197,"wires":[{"id":"38029d29.c7fd62","port":0}]}]},{"id":"c7e52cc0.381ad","type":"mysdecenc","z":"6f018651.90fe78","name":"Decode","x":311,"y":230,"wires":[["c88ee733.377118"]]},{"id":"c88ee733.377118","type":"switch","z":"6f018651.90fe78","name":"Type is SET?","property":"messageType","rules":[{"t":"eq","v":"1"},{"t":"else"}],"checkall":"true","outputs":2,"x":446,"y":190,"wires":[["d409083c.2bf6f8"],["38029d29.c7fd62"]]},{"id":"38029d29.c7fd62","type":"mysdecenc","z":"6f018651.90fe78","name":"Encode","x":785,"y":197,"wires":[[]]},{"id":"d409083c.2bf6f8","type":"switch","z":"6f018651.90fe78","name":"Is V_LOCK_STATUS?","property":"subType","rules":[{"t":"eq","v":"36"},{"t":"else"}],"checkall":"true","outputs":2,"x":544,"y":122,"wires":[["a1467944.5eb988"],["38029d29.c7fd62"]]},{"id":"a1467944.5eb988","type":"function","z":"6f018651.90fe78","name":"Invert payload","func":"if (msg.payload == 1)\n    msg.payload = 0;\nelse\n    msg.payload = 1;\nreturn msg;","outputs":1,"noerr":0,"x":663,"y":57,"wires":[["38029d29.c7fd62"]]},{"id":"b03550b3.4fcab","type":"change","z":"6f018651.90fe78","name":"Topic=Domoticz","rules":[{"t":"set","p":"topic","to":"Domoticz"}],"action":"","property":"","from":"","to":"","reg":false,"x":157,"y":188,"wires":[["c7e52cc0.381ad"]]},{"id":"5454541d.ababac","type":"subflow","name":"Fake sensors","in":[{"x":35,"y":30,"wires":[{"id":"ff04f8fa.00fb08"}]}],"out":[{"x":666,"y":30,"wires":[{"id":"30e6a3cb.cf195c","port":0}]}]},{"id":"666dc361.99923c","type":"mysencap","z":"5454541d.ababac","name":"Temp","nodeid":"1","childid":0,"subtype":0,"internal":0,"ack":false,"msgtype":"1","presentation":true,"presentationtype":"6","presentationtext":"FakeTempSensor","fullpresentation":true,"firmwarename":"FakeTemp","firmwareversion":"0.0","x":350,"y":30,"wires":[["30e6a3cb.cf195c"]]},{"id":"ff04f8fa.00fb08","type":"function","z":"5454541d.ababac","name":"Generate temp","func":"msg.payload = \"25\"\nreturn msg;","outputs":1,"noerr":0,"x":185,"y":30,"wires":[["666dc361.99923c"]]},{"id":"30e6a3cb.cf195c","type":"mysdecenc","z":"5454541d.ababac","name":"MySensors encode","x":515,"y":30,"wires":[[]]},{"id":"6580173d.9a7fe8","type":"serial-port","serialport":"/dev/ttyMyController","serialbaud":"115200","databits":"8","parity":"none","stopbits":"1","newline":"\\n","bin":"false","out":"char","addchar":true},{"id":"65355d72.9acaa4","type":"serial-port","serialport":"/dev/ttyDomoticz","serialbaud":"115200","databits":"8","parity":"none","stopbits":"1","newline":"\\n","bin":"false","out":"char","addchar":true},{"id":"13cc7d6f.ec3383","type":"serial-port","serialport":"/dev/ttyMysC","serialbaud":"115200","databits":"8","parity":"none","stopbits":"1","newline":"\\n","bin":"false","out":"char","addchar":true},{"id":"5af61127.a509f","type":"serial-port","z":"","serialport":"/dev/ttyUSB0","serialbaud":"115200","databits":"8","parity":"none","stopbits":"1","newline":"\\n","bin":"false","out":"char","addchar":true},{"id":"29d1b211.d62e4e","type":"serial-port","serialport":"/dev/ttyVera","serialbaud":"115200","databits":"8","parity":"none","stopbits":"1","newline":"\\n","bin":"false","out":"char","addchar":true},{"id":"56e6890.fa91978","type":"debug","z":"faef2a18.0510d8","name":"CTRLR debug","active":true,"console":"false","complete":"payload","x":748,"y":465,"wires":[]},{"id":"933030f1.6ccfd","type":"serial out","z":"faef2a18.0510d8","name":"Vera","serial":"29d1b211.d62e4e","x":821,"y":196,"wires":[]},{"id":"54370c66.abc8f4","type":"serial in","z":"faef2a18.0510d8","name":"MySensorsGW","serial":"5af61127.a509f","x":77.5,"y":146,"wires":[["396eb79f.c69148"]]},{"id":"6dae78cf.925188","type":"serial out","z":"faef2a18.0510d8","name":"MySensorsGW","serial":"5af61127.a509f","x":750,"y":533,"wires":[]},{"id":"cbef03e5.3411","type":"serial in","z":"faef2a18.0510d8","name":"MYSController","serial":"13cc7d6f.ec3383","x":76,"y":527,"wires":[["992c7345.66d39"]]},{"id":"9b7faefd.64805","type":"serial out","z":"faef2a18.0510d8","name":"MYSController","serial":"13cc7d6f.ec3383","x":844,"y":243,"wires":[]},{"id":"91697766.6e9688","type":"inject","z":"faef2a18.0510d8","name":"Send version request","topic":"MySensors test","payload":"0;255;3;0;2;","payloadType":"string","repeat":"","crontab":"","once":false,"x":122,"y":434,"wires":[["5feb3ddb.a014c4"]]},{"id":"5be5bb8c.a41a44","type":"serial in","z":"faef2a18.0510d8","name":"Domoticz","serial":"65355d72.9acaa4","x":59.5,"y":631,"wires":[["1b7cf599.e4830a","80399396.7fc67"]]},{"id":"cb8a2201.3475e","type":"serial out","z":"faef2a18.0510d8","name":"Domoticz","serial":"65355d72.9acaa4","x":828,"y":343,"wires":[]},{"id":"439009ab.bc6ff8","type":"serial in","z":"faef2a18.0510d8","name":"MyController","serial":"6580173d.9a7fe8","x":70.5,"y":581,"wires":[["47f782c.fb8087c"]]},{"id":"be681116.4197f","type":"serial out","z":"faef2a18.0510d8","name":"MyController","serial":"6580173d.9a7fe8","x":838,"y":293,"wires":[]},{"id":"6cab82ec.93547c","type":"subflow:5454541d.ababac","z":"faef2a18.0510d8","name":"","x":237,"y":193,"wires":[["396eb79f.c69148","26c64377.d939bc"]]},{"id":"a7dc7c6f.58238","type":"inject","z":"faef2a18.0510d8","name":"Trig fakes","topic":"","payload":"","payloadType":"none","repeat":"","crontab":"","once":false,"x":92,"y":193,"wires":[["6cab82ec.93547c"]]},{"id":"1b7cf599.e4830a","type":"subflow:6f018651.90fe78","z":"faef2a18.0510d8","name":"","x":315,"y":631,"wires":[["1c964876.e369b8"]]},{"id":"e62acc9e.19d53","type":"subflow:8f98bd26.70674","z":"faef2a18.0510d8","name":"","x":664,"y":343,"wires":[["cb8a2201.3475e","d994688d.266b98"]]},{"id":"10218729.efde79","type":"subflow:8160ff88.7e9f","z":"faef2a18.0510d8","name":"","x":881,"y":153,"wires":[]},{"id":"396eb79f.c69148","type":"subflow:87ad6845.785298","z":"faef2a18.0510d8","name":"","x":429,"y":146,"wires":[["fe9c2881.0163d8","1ed4947e.e12b6c"],["e62acc9e.19d53","28097d6b.d7f682","6b5d7d4b.94a284","ebe581f9.141a8","10218729.efde79"]]},{"id":"fe9c2881.0163d8","type":"debug","z":"faef2a18.0510d8","name":"MYS debug","active":true,"console":"false","complete":"payload","x":638,"y":84,"wires":[]},{"id":"1ed4947e.e12b6c","type":"file","z":"faef2a18.0510d8","name":"","filename":"/home/pi/MySensors/gw_out.log","appendNewline":true,"createDir":true,"overwriteFile":"false","x":702,"y":118,"wires":[]},{"id":"28461cae.d7b9e4","type":"subflow:fb0fe50f.04f018","z":"faef2a18.0510d8","name":"","x":316,"y":475,"wires":[["1c964876.e369b8"]]},{"id":"20753984.df8ac6","type":"serial in","z":"faef2a18.0510d8","name":"Vera","serial":"29d1b211.d62e4e","x":55,"y":475,"wires":[["28461cae.d7b9e4"]]},{"id":"992c7345.66d39","type":"subflow:9a01ec1d.65fe1","z":"faef2a18.0510d8","name":"","x":315,"y":527,"wires":[["1c964876.e369b8"]]},{"id":"47f782c.fb8087c","type":"subflow:6bb8370.f9447c8","z":"faef2a18.0510d8","name":"","x":313,"y":581,"wires":[["1c964876.e369b8"]]},{"id":"1c964876.e369b8","type":"subflow:87ad6845.785298","z":"faef2a18.0510d8","name":"","x":553,"y":527,"wires":[["56e6890.fa91978","eeac51f0.1153b"],["6dae78cf.925188"]]},{"id":"28097d6b.d7f682","type":"subflow:56bd1bfc.a942e4","z":"faef2a18.0510d8","name":"","x":659,"y":293,"wires":[["be681116.4197f"]]},{"id":"6b5d7d4b.94a284","type":"subflow:c1bbb0ac.3e445","z":"faef2a18.0510d8","name":"","x":660,"y":243,"wires":[["9b7faefd.64805"]]},{"id":"ebe581f9.141a8","type":"subflow:c542f76c.3abd08","z":"faef2a18.0510d8","name":"","x":660,"y":196,"wires":[["933030f1.6ccfd"]]},{"id":"eeac51f0.1153b","type":"file","z":"faef2a18.0510d8","name":"","filename":"/home/pi/MySensors/gw_in.log","appendNewline":true,"createDir":true,"overwriteFile":"false","x":799,"y":498,"wires":[]},{"id":"5feb3ddb.a014c4","type":"subflow:c1f1131a.3e0ef","z":"faef2a18.0510d8","name":"","x":321,"y":434,"wires":[["1c964876.e369b8"]]},{"id":"26c64377.d939bc","type":"debug","z":"faef2a18.0510d8","name":"","active":true,"console":"false","complete":"false","x":419,"y":229,"wires":[]},{"id":"80399396.7fc67","type":"debug","z":"faef2a18.0510d8","name":"Domoticz out","active":true,"console":"false","complete":"payload","x":289,"y":676,"wires":[]},{"id":"d994688d.266b98","type":"debug","z":"faef2a18.0510d8","name":"Domoticz in","active":true,"console":"false","complete":"payload","x":850,"y":406,"wires":[]}]

You will need @tbowmo's mysensors node-red plugin for this flow. And be aware that the debug log management in this flow is NOT working as it is really supposed to.

To create the socat pipes I use a number of shell scripts of this form executed as root:

#!/bin/bash
while sleep 1; do
        socat PTY,link=/dev/ttyVera,mode=666,group=dialout,raw TCP-LISTEN:5003,reuseaddr
done

Typically, you can invoke such a script using

sudo ./socat_vera.sh &

which would let the script execute in the background. The while loop make sure the pipe stays available even if there is nothing connected to it.

For sure there are a lot of different things about this that can be improved and optimized, but that is what I am currently using in my testing environment.

I am already on that aspect. I have implemented support for a security chip which can sign messages using SHA256-HMAC. Eventually I will look into integrating this in the library. The scheme will protect against both man-in-the-middle as well as replay attacks and it will be using a secret pre-shared key.

@bjornhallberg i am going to put my gw hacks on a branch and publish it on github. I'll post a link when that's done.

Why? There is a protocol. It is established and MySensors specific. Supported by a multitude of controllers. And it does not violate any copyrights as Wikipedia suggests your suggestion does.

Thanks a lot for the honor! I still have some features to fix but it is always nice to receive appreciation for the effort. All contributions I have looked at have been impressive (both the ones in the contest and others out of the contest).

@dakky If you remove the regulator, RAW pin is useless. The regulator is responsible of regulating the RAW voltage into 3.3V. Remove it, and you will not be able to regulate the RAW voltage (and it will not have a path to VCC either) as you can see here.

When you program the Arduino it has to receive power. I do not know your setup, but you have two options:

1. Supply power from a 3.3V FTDI programming interface
2. Supply power from another source (and make sure a 5V FTDI programming interface does not connect to a VCC pin).

I do not know who made the picture but I would assume that it is for those with an 3.3V Arduino and a 5V FTDI board.

Original post is now updated (look at the bottom of it). (ping @bjornhallberg)

@mfalkvidd i know. I am waiting for "it" to confirm by replying. The entire topic is close to deletion.

Well, that is up to you. It depends on the HW you have used for your GW. The library is just software and how you choose to download that SW to your HW is entirely up to you This is a SW release, so you can flash it exactly as you flashed it before, or in a new way if you prefer that. But the method of flashing is totally decoupled from the contents of release 1.5.2.
And when it comes to OTA updates, there are no changes in this release compared to 1.5.1 so you can expect the same featureset with respect to OTA functionality.

A thing to remember is that while MYSBootloader does not require an external flash to intermediately store the new firmware, this means it cannot support authenticating new firmwares as well (at least not currently from what I gather).
DualOptiboot on the other hand can support this since the checksumming of the updated firmware can be signed and verified before rebooting (and overwriting the existing firmware from external flash).
If signing is enabled and required and the checksum is not properly signed, it will be rejected and the bootloader won't be "informed" to do the update. This is at least in theory. I have not yet had the time to look into OTA security. But from the little I have learned, I would recommend DualOptiboot for the paranoid for this reason. Using MYSBootloader is easy, but it is also easy for an attacker to knock out security by remotely replacing the node firmwares.

Have you considerd the MYSX connector? It provides a common interface for MySensors boards (and others too for that matter). @tbowmo's new GW will have it, as does my board. @scalz have also made use of the design for his boards.
It is by no way ment as critizism of your solution, but I just wanted to mention it in case you missed it.

In development branch, doxygen is actively being used to document various aspects of the library. Signing is a good example. You can browse the documentation on the ci server: http://ci.mysensors.org/job/MySensorsArduino/branch/development/Doxygen_HTML

@ahmedadelhosni because it is not in use by the library <yet>. Would be a shame if the library some day gets updated with support for a radio that can enter low power sleep and still wake when needed.

@Avamander "MySensors" has had support for this for quite some time yes. As you can read in the topic post of this thread. Encryption is discussed elsewhere on the forum.

Welcome to the community!
MySensors is arudino compatible and many users use pro mini so that should not be much of a problem. You need a transport (radio or wired) that is compatible though, but if you have SPI and at least one available IO from your pro mini you should be able to interface a compatible radio to it. Then you would also need a gateway that feeds your user interface with the data from the sensor. The main site describes this (www.mysensors.org)

I also use multiple controllers. Vera, domoticz and myscontroller. Node-red acts as transport which also permit me to do special management for certain controllers as well as injecting/extracting specific messages in the flow (the pushbullet plugin in node-red is especially nice).
I also use all controllers for "input" and at least for nodes that send ACK it works just fine. That is, doing an action in one controller causes the other controllers to update as well when the ACK is returned to all of them.

And with a scalpel and a soldering iron you should be able to use both interrupts by disconnecting the one reserved for nrf24. Of course that would disable the use for rfm69 om that board.

@TD22057 cool. I never even considered prefab wire antennae. I just planned to cut my own. Not sure my pcb has the appropriate hole diameter to accommodate that (and I use 868mhz). But nice to see options

@NeverDie you can run soft signing on any device. It emulates the atsha204a equally well. The performance of the MCU only affects the speed of the calculations, not the quality of the result.

I think a header for daughterboards will go far in terms of flexibility.

I have been thinking about this as well. But I discarded parts of the idea because I needed the IO for other stuff (MYSX in my case). Instead I designed a switched rail where one could attach sensor power sinks. It's not io powered but it is io controlled.
Though I did not attach the si or atsha to this switch function as I decided to make it an optional feature but wanted to make sure authentication and temp/hum would always be available.

The use of random nonce ensures (at least to a significant extent) that two signatures will never look the same even with the same payload. So replaying signed messages won't work. Based on that, it won't be possible for an attacker to provide a trusted crc of any form after it has sent the forged FW that yield the same crc as a valid firmware would.
The only way I see that this could be exploited is if the attacker managed to predict the resulting crc and black out the valid FW as it is sent OTA and instead inject the forged FW. And then it let the valid senders signed crc pass though.
But that require the attacker to know the resulting crc of the real FW. And if the OTA solution include a random component with the firmware that is covered by crc that also becomes a tricky task. @tekka might be interested in that.

@NeverDie but remember that if you use soft signing it is your own responsibility to protect the hmac key from readout by an attacker with physical access to the device.

@brolly759 No, the "daughterboard" is also potentially a power source or an other processing unit. I agree that it is a somewhat different product line, but I also maintain that we should try to collaborate with all hardware affiliated with MySensors. It serves no one that we try to compete with each other
And besides, I am not sure kickstarter approves projects capitalizing on open source hw/sw projects

And what do you mean by adding 256 encryption? The atsha204a is a signing/hashing device, not an encryption device.

@ximinez Well, without a gw the only option is to use node peer to peer transmissons to test signing. How to do it is described in the signing documentation, assuming you use development branch, you can see here. For master, look here.

I will provide a more elaborate explanation of the signing timer since my point is being missed. But I don't have the time right now so it will be later today. But in short, we have safeguards to ensure there is no way of delaying signing handshaking so if the signed crc is sent immediately after the FW, if anyone tried to delay that (and they would need to in order to inject a new FW) either the sender or receiver will detect this.

@gohan it is, but it is documented enough so that it should be available to everyone. Obviously that implies people actually read the documentation

EDIT: I went the extra mile and managed to shoehorn in an additional footprint to please @bjornhallberg:s "selfish reasons" so now there is an option to solder a SC-60 based regulator (TPS61221) instead of the SOT-23 based TPS61097A. The first post is updated with the details.

@alexsh1 like I said, signing is not in itself the problem. The problem is that big messages are failing. You can just try by generating big messages yourself and you will get the same problem. I know this by looking on what generates st=fail and it is the transport layer. Signing generates the data to be transmitted, and this data is printed and shown to be correct. Bigger messages require more reliable communications. Shorter messages has a better chance of being transmitted correctly. It is that simple. Many have reported the sake issue and have solved it by improving radio power decoupling, rearranging the sensor placement or improve the power supplies.

Let's agree to disagree anyway, the OTA security for 2.0.0 is currently under discussion and it might well be that we go for sha256 checksumming. That remains to be seen.

The guide emphasizes in bold that you have to create the local pretty paths you specify in your fp table. Have you done that?

Thanks,
well at least there are a lot of sourcing alternatives now

Well, if you think the signing implementation cause initial radio transmissions to fail I am afraid I will need your help in explaining how. Because I fail to see any connection between signing and radio behaviour. st=fail is a transmission problem, and signing implementation require flawless transmissions. I also suspect you both use nrf24 and I also suspect you will not see this if you use rfm69 although I use nrf24 myself for testing and I have not seen what you report. But I am sure you really experience this strange behaviour. But I maintain that it is due to some startup problems of the radio. I am afraid I cannot find anything I can change in the signing codebase to have an influence on st=ok or st=fail. But I am all ears to suggestions of course if you see something suspicious.

It's been decided that we do go for sha256. It will be hashed by the controller and the receiver will calculate the hash of the received payload. The controller will then send the calculated hash of the true firmware in a separate message (that will be signed if enabled) or possibly several (if we want to use the full 32 byte hash in the verification which we probably want). @tekka and me will communicate on the matter and security related activities can be tracked on the GitHub issue list.

Spacing out is done by all, glad it was such a simple "fix"

I also noticed. I think I'll flex my moderator muscles and take over the topic to keep it up2date. And relinquish my powers back to Mr penguin, should he resurface.

@alexsh1 You could also try soft signing on the sensebender and see if that makes a difference. Perhaps the atsha device interferes with the radio (this depends on routing and such things). I have no sensebender myself and I have not noticed the behavior you describe with nrf24 and atsha204a.

I am a bit short on time tonight, but here is at least some pointers to get this to work:

1. Get the patched RF24 lib
2. Download the DigitalIO library and add it to your library tree (next to MySensors lib)
3. Patch RF24_config.h to enable softspi, uncomment
   //#define SOFTSPI
   and select pins to use with
   const uint8_t SOFT_SPI_MISO_PIN = 15;
   const uint8_t SOFT_SPI_MOSI_PIN = 14;
   const uint8_t SOFT_SPI_SCK_PIN = 16;
   The setting above mean MOSI on A0, MISO on A1 and SCK on A2 on an Arduino Nano.

I am going to give it another shot to patch the code to use the hardware SPI but I need a couple of days to do it (have other things going on at the moment). If I fail I will check with @hek if the ethernet gw description should be updated with info on how to use softSPI or how we should proceed (perhaps choosing a different ethernet module). No matter what, I intend to bend the W5100 to my will and once I got it wrestled down, I will share the details. This thread would be a good place to track that: