šŸ’¬ Security & Signing

  • Hardware Contributor

    I understand šŸ™‚
    The last thing: what's the sense of this message:

    Skipping security for command 3 type 17


    Thank you!

  • Contest Winner

    @sineverba it means that message is not signed. Because it is of a type not suitable for signing. Typically an ack or a handshake message. You can look the type up in the api specification. In this case it is a handshake message (a nonce reply to be precise).

  • Hello!! I'm also trying to implement SOFT Signature, but because of my poor English I have many problems !!
    Someone could post the socket of a node + a working MQTT gateway.

    So you can study the code and understand how it works !!!

    Thanks 1000 in advance to who can help me

  • Contest Winner

    @sindrome73 There is no difference for a MQTT gw than from other GW:s. There are code examples in the documentation. See this post and follow the Doxygen links.

  • As I said, my English is not good and therefore it is difficult for me to follow the discussions.

    That's why I was asking for a snapshot already done, in order to study the code and understand how to solve ....
    Ā  If anyone can help me ????

  • Contest Winner

    @sindrome73 I am afraid it will be difficult to help if you can't read the code. There is code in the documentation, and you ask for code? There is also a sequence of steps required to do personalization, so you have to be able to understand english to some extent, or find someone who can translate for you.

    If it helps, I have pasted the code here in case you for some reason can't find it (I assume you use a official 2.0 release):

    How to use this

    Before we begin with the details, I just want to emphasize that signing is completely optional and not enabled by default. If you do want the additional security layer signing provides, you pick the backend of your choise in your sketch. Currently, two compatible backends are supported; MY_SIGNING_ATSHA204 (hardware backed) and MY_SIGNING_SOFT (software backed). You can either enable these globally in MyConfig.h or in your sketch for sketch specific/local use.

    Firstly, you need to make sure to pick a backend to use as described above.

    //#define MY_SIGNING_SOFT
    #define MY_SIGNING_ATSHA204
    #include <MySensors.h>

    Make sure to set the define before the inclusion of MySensors.h. It is legal to mix hardware- and software-based backends in a network. They work together.

    You also need to decide if the node (or gateway) in question require and verify signatures in addition to calculating them. This has to be set by at least one of the node in a "pair" or nobody will actually start calculating a signature for a message. Just set the flag MY_SIGNING_REQUEST_SIGNATURES and the node will inform the gateway that it expects the gateway to sign all messages sent to the node. If this is set in a gateway, it will NOT force all nodes to sign messages to it. It will only require signatures from nodes that in turn require signatures. If it is desired that the gateway should require signatures from all nodes, MY_SIGNING_GW_REQUEST_SIGNATURES_FROM_ALL can be set in the gateway sketch.
    If you want to have two nodes communicate securely directly with each other, the nodes that require signatures must send a presentation message to all nodes it expect signed messages from (only the gateway is informed automatically). See signerPresentation().
    A node can have three "states" with respect to signing:

    Node does not support signing in any way (neither MY_SIGNING_ATSHA204 nor MY_SIGNING_SOFT is set)
    Node does support signing but don't require messages sent to it to be signed (MY_SIGNING_REQUEST_SIGNATURES is not set)
    Node does support signing and require messages sent to it to be signed (MY_SIGNING_REQUEST_SIGNATURES is set)

    Secondly, you need to verify the configuration for the backend.
    For hardware backed signing it is the pin the device is connected to. In MyConfig.h there are defaults which you might need to adjust to match your personal build. The setting is defined using MY_SIGNING_ATSHA204_PIN and the default is to use pin A3.
    Similar to picking your backend, this can also be set in your sketch:

    #define MY_SIGNING_ATSHA204
    #define MY_SIGNING_ATSHA204_PIN 4
    #include <MySensors.h>

    For the software backed signingbackend, 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_SIGNING_SOFT_RANDOMSEED_PIN and the default is to use pin A7. The same configuration possibilities exist as with the other configuration options.

    Thirdly, if you use the software backend, you need to personalize the node (see personalization).

    #define MY_SIGNING_SOFT
    #include <MySensors.h>

    An example of a node that require signatures is available in SecureActuator.ino.

  • Hardware Contributor


    I image not, but... the pin need to be to same in every node?

    And.. will the library auto manage the PIN (in this case the #7) rendering it floating or need to explicity set it as INPUT on sketch?

    Thank you!

  • Contest Winner

    @sineverba It is assumed that you do any configurations in your sketch, before including MySensors.h so no, it does not need to be the same on every node. It just need to be left unconnected. And yes, the library takes care of the rest.

  • Mod

    The pin does not need to be the same.

    The library will set it to the required mode, there is no need to do anything in the sketch.

  • Hi
    I have a gateway mysensors on my RPI3 with radio RFM69HW. Is any chance to build gateway on RPI3 but also with chip ATSHA204A ? And how build it...

  • Contest Winner

    @pepson the driver has not been designed with rPi in mind. And you'd probably be better off with an I2C variant for rPi. But we currently don't offer a driver for that so you'd have to write it yourself.
    But, for a gw, you typically keep those secured physically, so using a atsha device is less important, compared to "roaming" nodes.

  • @anticimex
    I don't understand. I want secure my nodes... By Atsha204a. How I can secure it by other solution.

  • Contest Winner

    @pepson I have implemented a sw emulator for the atsha which offers compatible security infrastructure but without readout protection. Readout protection is needed if someone steals your node and extracts your hmac key. Your gw won't typically be stolen, so it don't need readout protection and can rely on the soft signing option which is compatible with nodes using atsha204a personalized with the same hmac key. The rPi port support the atsha204a emulator so you can use that to secure nodes that has a real atsha204a device.

  • @anticimex

    Can you show me full manual how implement it on Gateway on RPI and how add this to sketch on nodes ? Please...
    If you can describe me very good. I am begginer...

  • Contest Winner

    @pepson you have the links to the documentation in the article this thread is commenting on. At the very top.

  • @anticimex
    But please show me as you have to have example...

  • Contest Winner

    @pepson I don't run on raspberry pi so I don't. But the documentation does have specific configuration examples for raspberry pi, so you have all information needed listed there in "how to use this" section.

  • Hardware Contributor

  • @sineverba
    Very very good manuals...
    But i dont understand what i must type number in this placeand how get it ? It is MAC number network from RPI ?:

    #define MY_SIGNING_NODE_WHITELISTING {{.nodeId = GATEWAY_ADDRESS,.serial = {0Xaa,0Xbb,0Xcc,0XF9,0X82,0XB2,0X50,0XF2,0XAB}}} // got from gateway setup

    And what is diffrent with MySensors 2.3.0 ?
    I must do all point from MySensors 2.2.0 and additional point for 2.3.0 ?

    After got your ./configure instruction, type
    sudo nano /etc/mysensors.conf
    And add your KEYs to the specific section on bottom of the file.
    To get your first KEYs follow guide for 2.2.0

    And in version 2.3.0 i must do this under building gateway ?

    And add serial,HMAC,AES in this place in mysensors.conf

    Software signing settings

    Note: The gateway must have been built with signing

    support to use the options below.

    To generate a HMAC key run mysgw with: --gen-soft-hmac-key

    copy the new key in the line below and uncomment it.


    To generate a serial key run mysgw with: --gen-soft-serial-key

    copy the new key in the line below and uncomment it.


    Encryption settings

    Note: The gateway must have been built with encryption

    support to use the options below.

    To generate a AES key run mysgw with: --gen-aes-key

    copy the new key in the line below and uncomment it.


    and then build gateway ?

  • Hardware Contributor

    @pepson You use RFM69(H/W/HW). So I. My hint is remain with 2.2.0. I got so many issues with 2.3.0 and RFM that I reverted to 2.2.0 in 1 minute.

    HMAC is not LAN MAC, is HMAC got from MYsensors gateway. Same for other 2 keyes.

    I think that in long explain on my guide you have all info to get your keyes. I follow my same guide everytime I need to reinstall mysensors / domoticz / an entire PI. It is fully tested šŸ™‚

  • @sineverba
    Yes i use radio RFM69HW. I also on 2.3.0 have big problem... and back to 2.2.0. What you have problem on 2.3.0 with radio RFM69 ?

    I read all your guide and it is ok. But i dont know what i must put in place:
    #define MY_SIGNING_NODE_WHITELISTING {{.nodeId = GATEWAY_ADDRESS,.serial = {0Xaa,0Xbb,0Xcc,0XF9,0X82,0XB2,0X50,0XF2,0XAB}}} // got from gateway setup

    Put serial from this:
    sudo mysgw --gen-soft-serial-key

    We will get:

    SOFT_SERIAL | 7850987FA6601F6538

    The next line is intended to be used in SecurityPersonalizer.ino:
    #define MY_SOFT_SERIAL 0X78,0X50,0X98,0X7F,0XA6,0X60,0X1F,0X65,0X38

    To use this key, run mysgw with:

    And i must put my keys to mysensors.conf when i use version 2.2.0 ? Or only when use 2.3.0 ?

    Software signing settings
    Note: The gateway must have been built with signing
    support to use the options below.
    To generate a HMAC key run mysgw with: --gen-soft-hmac-key
    copy the new key in the line below and uncomment it.

    To generate a serial key run mysgw with: --gen-soft-serial-key
    copy the new key in the line below and uncomment it.

    Encryption settings
    Note: The gateway must have been built with encryption
    support to use the options below.
    To generate a AES key run mysgw with: --gen-aes-key
    copy the new key in the line below and uncomment it.

    or only send command

    sudo mysgw --set-soft-serial-key=7850987FA6601F6538 && sudo mysgw --set-aes-key=768859210B4A75FACC78B757ADAFE75B && sudo mysgw --set-soft-hmac-key=0298FF121DD3194BCC33DC8185055B9D981EBE0A90D847A4777A9E65CCE4F524 ?

  • Hardware Contributor


    Too many ack lost and slow communication. And other that I don't remember.

    That line on the sketches means that you need add on the node that you want whitelist the serial of gateway.

    You got serial gateway on the steps for 2.2.0.

    You have it.

    You don't need to put anything in no file with 2.2.0. In my guide is NOT mentioned. In my guide, at the bottom, there is the final "set keyes" with only a line OR you can set them everytime you get them.

    Please, take your time to read 1, 2, 3 times before type anything. I think it is very clear, and every step is write down for you.

    šŸ˜‰ Enjoy šŸ™‚

    PS Don't offend, I want help you, 'cause I used a bit of times before getting security working. And I used so many time write down a guide. But you need to read and follow carefully

  • @sineverba I also have the same problem with communication. But tell me you send issue to developer ? I send but nothing done.

    Ok in point 4 in your guide in sketch for node i must put serial key from gateway ? Yes ?

    And tell me how remove setup serial, HMAC and AES when i dont want to use it ? How remove it from gateway ?

  • Any help ?

  • Hardware Contributor

    @pepson no need to remove. Simply, in your sketches, don't use signing at all.

  • @sineverba said in šŸ’¬ Security & Signing:

    no need to remove. Simply, in your sketches, don't use signing at all.

    ok but if on gateway it was generate and setup keys and when in skethces i dont use keys will nody connect? and what the purpose of the signature is then ?
    I thought that if the gate has a set of keys and will try to connect noda without a key that it will not connect ....

  • Hardware Contributor

    @pepson you can use a special flag define to "downgrade/reduce" security MY_WEAK_SECURITY

  • @sineverba

    Ok summary
    When i have setup on Raspberry Gateway , generate keys.

    When i write in node all keys with sketches.... Node connect ok.

    But when write to node only sketches without keys.,... node connect to gateway or not connect to gateway ?

  • Hardware Contributor

    @pepson you need to setup gateway with weak security.

    You need generate keyes and set in gateway.

    You need to personalize nodes with the sketch and set keyes on Arduino EEPROM.

    From now, you have two ways: Your node need security? Set use security bla-bla on top with other define(s).

    Don't Need security? Don't define use security.

    Simpler than ever.

  • Contest Winner

    @pepson if you find the security setup to be too complicated, I highly recommend sticking with the simple password flags. The documentation has it all.

  • @sineverba said in šŸ’¬ Security & Signing:

    setup gateway with weak security.

    But when configure my gateway without flag setup gateway with weak security i can only use nodes with setup in sketches keys. yes ?

  • @anticimex

    Can you share me this document when is describe how define only pass ? I want also read this.

  • Hardware Contributor


    Let's summarize. Last time.

    1. compile gateway with weak security (make your research, also in my github guide, there is šŸ˜‰ )
    2. create the 3 keyes for gateway
    3. set the 3 keyes for gateway.
    4. clean your EEPROM arduinos with the sketch present in my guide and in examples of library
    5. set the keyes in EEPROM arduinos.

    Stop. End. Fin. Fine. These steps are MANDATARY. You NEED to do.

    You will have in EEPROM the keyes (arduino) and in gateway.

    From now, you select:

    a) Do I need security? Perfect, in sketch arduino add #define bla bla bla on top with security and other stuff.
    b) Do I NOT need security? Perfect, in sketch arduino DON'T ADD #define bla bla related to security.

  • Hardware Contributor

    @pepson And, last all, you can use the mysensors debug options. Try. Try. Try! This is the best option offered to you to learn. Try!
    At max, nothing works šŸ˜‰

  • @sineverba
    ok all is very good.

    But what give me this if i can connect nodes also with defines bla bla bla in skethc and also without define bla bla bla in sketch?
    But Do I think right ? In each of these accidents in the eeprom I need to have the keys loaded?

  • Hardware Contributor

    @pepson only one word. Try. Really, you are lost in 1 cm of water. Try. And if it doesn't work, open your topic, showing exactly your sketches and what have you done.

  • ok thanks

  • Ok i build my gateway on RPI on MySensors 2.2.0 with this configuration:

    ./configure --my-transport=rfm69 --my-rfm69-frequency=868 --my-is-rfm69hw --my-gateway=ethernet --my-port=5003 --my-signing=software --my-signing-request-signatures

    Then generate 3 key and setup it on gateway.

    Then clear_epprom on Arduino MIni Pro, and then send sketch security with add serial, HMAC, and AES. Then put sketch with add this on top sketch with my SERIAL generated on gateway RPI.

    #define MY_SIGNING_SOFT
    #define MY_SIGNING_NODE_WHITELISTING {{.nodeId = GATEWAY_ADDRESS,.serial = {0X2C,0X61,0X17,0X2E,0XEE,0XDD,0XCC,0XBB,0XAA}}} // got from gateway setup

    After that i run HA and he not found my nodes...
    WHat is wrondg ?

  • Contest Winner

    @pepson well for starters, don't start out with whitelisting unless you know exactly what you are doing. First you have to verify that your network is stable enough to handle the security protocol. The simplest option is to only enable encryption, or use the simple password flag options. Once you have established that your gw and nodes are capable of communicating securely you can move on to personalization and whitelisting.

  • @anticimex
    What you mean white list?

    Before adding all security my nodes and gateway works perfect.

  • Contest Winner

    @pepson you define whitelisting so I presume you use it. But I don't see your gw flags specifying it so of course it does not work. So get rid of that flag from your config unless you know what it mean so that you set it up properly.

  • @anticimex

    What flag i must remove ?
    This :
    #define MY_SIGNING_NODE_WHITELISTING {{.nodeId = GATEWAY_ADDRESS,.serial = {0X2C,0X61,0X17,0X2E,0XEE,0XDD,0XCC,0XBB,0XAA}}} // got from gateway setup

    But on GW i setup this:
    sudo mysgw --set-soft-serial-key=2C61172EEEDDCCBBAA && sudo mysgw --set-aes-key=9D2AD43CF909875C4C77111111111111 && sudo mysgw --set-soft-hmac-key=A2A64C48EA6765C5DAEFA12A1E41E2F038515A9CAED9FED73D11111111111111

  • Contest Winner

    @pepson please just read the documentation. And more importantly, follow it.
    Isn't it obvious that it is the flag that mention whitelisting that is supposed to be removed unless you intend to use whitelisting, in which case you ought to know how to set it up properly at both ends?

  • @anticimex

    Sorry i dont undestand

  • Contest Winner

    @pepson https://www.mysensors.org/apidocs/group__MySigninggrpPub.html

    Note that it is the documentation for the latest release (simple password flags work differently compared to previous releases, see release notes for the latest release).

  • HI
    i don as describe...

    1. install gateway on raspberry with this configuration:
      ./configure --my-transport=rfm69 --my-rfm69-frequency=868 --my-is-rfm69hw --my-gateway=ethernet --my-port=5003 --my-leds-err-pin=12 --my-leds-rx-pin=16 --my-leds-tx-pin=18 --my-signing=software --my-signing-request-signatures --my-signing-weak_security --my-signing-debug

    and then generate serial, aes and hmac

    pi@raspberrypi:~/MySensors $ sudo mysgw --gen-soft-serial-key
    SOFT_SERIAL | 8FC828503E6EB14C5D

    The next line is intended to be used in SecurityPersonalizer.ino:
    #define MY_SOFT_SERIAL 0X8F,0XC8,0X28,0X50,0X3E,0X6E,0XB1,0X4C,0X5D

    To use this key, run mysgw with:
    pi@raspberrypi:~/MySensors $ sudo mysgw --gen-soft-hmac-key
    SOFT_HMAC_KEY | 0D682ED05106E5F361C64288D68AAE1B34F5FFB62B4E39773C9D92DED04B6514

    The next line is intended to be used in SecurityPersonalizer.ino:
    #define MY_SOFT_HMAC_KEY 0XD,0X68,0X2E,0XD0,0X51,0X6,0XE5,0XF3,0X61,0XC6,0X42,0X88,0XD6,0X8A,0XAE,0X1B,0X34,0XF5,0XFF,0XB6,0X2B,0X4E,0X39,0X77,0X3C,0X9D,0X92,0XDE,0XD0,0X4B,0X65,0X14

    To use this key, run mysgw with:
    pi@raspberrypi:~/MySensors $ sudo mysgw --gen-aes-key
    AES_KEY | 8FDB1EE8D0351CFF874D337731BF37AE

    The next line is intended to be used in SecurityPersonalizer.ino:
    #define MY_AES_KEY 0X8F,0XDB,0X1E,0XE8,0XD0,0X35,0X1C,0XFF,0X87,0X4D,0X33,0X77,0X31,0XBF,0X37,0XAE

    To use this key, run mysgw with:
    pi@raspberrypi:~/MySensors $

    and setup it on my gateway

    sudo mysgw --set-soft-serial-key=8FC828503E6EB14C5D && sudo mysgw --set-aes-key=8FDB1EE8D0351CFF874D337731BF37AE && sudo mysgw --set-soft-hmac-key=0D682ED05106E5F361C64288D68AAE1B34F5FFB62B4E39773C9D92DED04B6514

    all is ok to this moment


    1. clear eeprom in node Arduino pro mini with this sketch:
    2. write sketch security with setup my serial, aes and hmac


    at the top setup...
    /************************************ User defined key data ***************************************/

    /** @brief The user-defined HMAC key to use unless @ref GENERATE_HMAC_KEY is set */
    //#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_HMAC_KEY 0XD,0X68,0X2E,0XD0,0X51,0X6,0XE5,0XF3,0X61,0XC6,0X42,0X88,0XD6,0X8A,0XAE,0X1B,0X34,0XF5,0XFF,0XB6,0X2B,0X4E,0X39,0X77,0X3C,0X9D,0X92,0XDE,0XD0,0X4B,0X65,0X14

    /** @brief The user-defined AES key to store in EEPROM unless @ref GENERATE_AES_KEY is set */
    //#define MY_AES_KEY 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
    #define MY_AES_KEY 0X8F,0XDB,0X1E,0XE8,0XD0,0X35,0X1C,0XFF,0X87,0X4D,0X33,0X77,0X31,0XBF,0X37,0XAE

    /** @brief The user-defined soft serial to use for soft signing unless @ref GENERATE_SOFT_SERIAL is set */
    #define MY_SOFT_SERIAL 0X8F,0XC8,0X28,0X50,0X3E,0X6E,0XB1,0X4C,0X5D

    /***************************** Flags for guided personalization flow ******************************/

    1. then write my sketch relay with added at the top this info:

    #define MY_SIGNING_SOFT
    #define MY_SIGNING_NODE_WHITELISTING {{.nodeId = GATEWAY_ADDRESS,.serial = {0X8F,0XC8,0X28,0X50,0X3E,0X6E,0XB1,0X4C,0X5D}}} // got from gateway setup

    and now on my Home assistant in file

    found my node but wthout full information like name....
    "0": {
    "battery_level": 0,
    "sketch_name": null,
    "sketch_version": null,
    "children": {},
    "type": 18,
    "protocol_version": "2.2.0",
    "sensor_id": 0
    "33": {
    "battery_level": 0,
    "sketch_name": null,
    "sketch_version": "1.0",
    "children": {
    "1": {
    "type": 3,
    "id": 1,
    "values": {
    "2": "1"
    "description": ""
    "type": 17,
    "protocol_version": "2.2.0",
    "sensor_id": 33

    and in Home Assistant is not show in devices this node. Not found it.
    What i done wrong ?

  • Contest Winner

    @pepson said in šŸ’¬ Security & Signing:


    How many times do I need to tell you to get rid of the whitelisting flag?

  • @anticimex
    Ok read... but...
    when i use MY_SIGNING_NODE_WHITELISTING i must on node in sketch add serial number my gateway and also serial number for node. But from where i can get serial number for my arduino pro mini ? I dont know...becasue i don use ATSHA204 but i use only soft signing....

  • Hardware Contributor

    @pepson This is the serial OF GATEWAY. Not your Arduino. You need to put serial of GATEWAY.

    Please, first of all, DONT' USE WHITELISTING. And pay attention: if you enabled it, remove it and:

    1 - clear eeprom
    2 - flash eeprom with keyes
    3 - reload sketch (without whitelisting)

  • Hardware Contributor

    @pepson Don't need all copy and paste, enough link :).

    Btw, before move to Home Assistant, where is the output of debug of MySensors?

    sudo mysgw -d

    Of course, you need before stop service.

    Resetting the node, what you get in debug?

    When ALL ok, move to HomeAssistant.

    And remember, after check that debug is ok...

    sudo make install && sudo systemctl enable mysgw.service && sudo systemctl start mysgw.service

  • In my first time I use only serial number gateway in flag whitelistening and also not working.

  • Hardware Contributor

    @pepson Last time. Please.

    Clear EEPROM and paste here output of debug. No other.

  • @sineverba
    OK wait for info

  • @pepson

    Ok i removed Whitelisting and switch is show in Hoem Assistant and works.

    pi@raspberrypi:~/MySensors $ sudo ./bin/mysgw -d
    mysgw: Starting gateway...
    mysgw: Protocol version - 2.2.0
    mysgw: MCO:BGN:INIT GW,CP=RPNGLS--,VER=2.2.0
    mysgw: SGN:PER:OK
    mysgw: SGN:INI:BND OK
    mysgw: TSF:LRT:OK
    mysgw: TSM:INIT
    mysgw: TSF:WUR:MS=0
    mysgw: TSM:INIT:TSP OK
    mysgw: TSM:INIT:GW MODE
    mysgw: TSM:READY:ID=0,PAR=0,DIS=0
    mysgw: Listening for connections on
    mysgw: MCO:BGN:STP
    mysgw: MCO:BGN:INIT OK,TSP=1
    mysgw: TSF:MSG:READ,3-3-0,s=255,c=3,t=1,pt=0,l=0,sg=0:
    mysgw: !SGN:VER:NSG
    mysgw: TSF:MSG:READ,33-33-0,s=255,c=3,t=16,pt=0,l=0,sg=1:
    mysgw: SGN:SKP:MSG CMD=3,TYPE=16
    mysgw: SGN:SKP:MSG CMD=3,TYPE=17
    mysgw: TSF:MSG:SEND,0-0-33-33,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE>
    mysgw: SGN:NCE:XMT,TO=0
    mysgw: TSF:MSG:READ,33-33-0,s=255,c=3,t=1,pt=0,l=0,sg=1:
    mysgw: SGN:BND:NONCE=44E4127024F4EB1003DCBF3701D8469E4664CC454E2A20A257AAAAAAAAAAAAAA
    mysgw: SGN:BND:HMAC=E1EE2D4046FEF0AEC323AA737A8367A2F290CCEFB7A4663448AD0B155FFD5A74
    mysgw: SGN:VER:OK
    mysgw: TSF:MSG:READ,33-33-0,s=1,c=3,t=16,pt=0,l=0,sg=1:
    mysgw: SGN:SKP:MSG CMD=3,TYPE=16
    mysgw: SGN:SKP:MSG CMD=3,TYPE=17
    mysgw: TSF:MSG:SEND,0-0-33-33,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE>
    mysgw: SGN:NCE:XMT,TO=0
    mysgw: TSF:MSG:READ,33-33-0,s=1,c=1,t=2,pt=1,l=1,sg=1:0
    mysgw: SGN:BND:NONCE=4AD7D9430FA96BBD0B18D4F57480F009BE31C6F3821F182766AAAAAAAAAAAAAA
    mysgw: SGN:BND:HMAC=3AADB41A42B91C0B2137BE2C2C76F57E3ADB7082F3669DECCA85B993C955D36E
    mysgw: SGN:VER:OK
    mysgw: TSF:MSG:READ,33-33-0,s=1,c=3,t=16,pt=0,l=0,sg=1:
    mysgw: SGN:SKP:MSG CMD=3,TYPE=16
    mysgw: SGN:SKP:MSG CMD=3,TYPE=17
    mysgw: TSF:MSG:SEND,0-0-33-33,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE>
    mysgw: SGN:NCE:XMT,TO=0
    mysgw: TSF:MSG:READ,33-33-0,s=1,c=1,t=2,pt=1,l=1,sg=1:1
    mysgw: SGN:BND:HMAC=5AF82BD16724069A436E0735229D32F532108A45407EF0DE7CABDADA1F7E39A0
    mysgw: SGN:VER:OK
    mysgw: TSF:MSG:READ,3-3-0,s=255,c=3,t=1,pt=0,l=0,sg=0:
    mysgw: !SGN:VER:NSG
    mysgw: TSF:MSG:READ,33-33-0,s=1,c=3,t=16,pt=0,l=0,sg=1:
    mysgw: SGN:SKP:MSG CMD=3,TYPE=16
    mysgw: SGN:SKP:MSG CMD=3,TYPE=17
    mysgw: TSF:MSG:SEND,0-0-33-33,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE>
    mysgw: SGN:NCE:XMT,TO=0
    mysgw: TSF:MSG:READ,33-33-0,s=1,c=1,t=2,pt=1,l=1,sg=1:0
    mysgw: SGN:BND:NONCE=61F78D66E675349B8A63B1370E81D2D1AB44BC1D0BB1F988D6AAAAAAAAAAAAAA
    mysgw: SGN:BND:HMAC=04EEE2B60E0C71CC092E13C68C07F3088D66F264A826C23426053C17C2353DED
    mysgw: SGN:VER:OK
    mysgw: TSF:MSG:READ,33-33-0,s=1,c=3,t=16,pt=0,l=0,sg=1:
    mysgw: SGN:SKP:MSG CMD=3,TYPE=16
    mysgw: SGN:SKP:MSG CMD=3,TYPE=17
    mysgw: TSF:MSG:SEND,0-0-33-33,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE>
    mysgw: SGN:NCE:XMT,TO=0
    mysgw: TSF:MSG:READ,33-33-0,s=1,c=1,t=2,pt=1,l=1,sg=1:1
    mysgw: SGN:BND:HMAC=65503227CDB04C1A2DCB03D0E5BAFD35A4EBA956E8EBA917B2DF40FB09520092
    mysgw: SGN:VER:OK
    mysgw: TSF:MSG:READ,33-33-0,s=1,c=1,t=2,pt=1,l=1,sg=1:1
    mysgw: !SGN:VER:FAIL
    mysgw: TSF:MSG:READ,33-33-0,s=255,c=3,t=16,pt=0,l=0,sg=1:
    mysgw: SGN:SKP:MSG CMD=3,TYPE=16
    mysgw: SGN:SKP:MSG CMD=3,TYPE=17
    mysgw: TSF:MSG:SEND,0-0-33-33,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE>
    mysgw: SGN:NCE:XMT,TO=0
    mysgw: TSF:MSG:READ,33-33-0,s=255,c=3,t=1,pt=0,l=0,sg=1:
    mysgw: SGN:BND:NONCE=32CE07784E14ED2B6D455C2C5C4D83E025185970838C0B743AAAAAAAAAAAAAAA
    mysgw: SGN:BND:HMAC=F04885315D93DB7FC95F3B190D68009055495ECEE698E0ADF6F50292157A8927
    mysgw: SGN:VER:OK
    mysgw: TSF:MSG:READ,33-33-0,s=1,c=3,t=16,pt=0,l=0,sg=1:
    mysgw: SGN:SKP:MSG CMD=3,TYPE=16
    mysgw: SGN:SKP:MSG CMD=3,TYPE=17
    mysgw: TSF:MSG:SEND,0-0-33-33,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE>
    mysgw: SGN:NCE:XMT,TO=0
    mysgw: TSF:MSG:READ,33-33-0,s=1,c=1,t=2,pt=1,l=1,sg=1:0
    mysgw: SGN:BND:HMAC=392AB4EAFDE59AC0CC9BE6EE667FC33A69A33E86AD5CB3EC49C6C114722941F5
    mysgw: SGN:VER:OK
    mysgw: TSF:MSG:READ,33-33-0,s=1,c=3,t=16,pt=0,l=0,sg=1:
    mysgw: SGN:SKP:MSG CMD=3,TYPE=16
    mysgw: SGN:SKP:MSG CMD=3,TYPE=17
    mysgw: TSF:MSG:SEND,0-0-33-33,s=255,c=3,t=17,pt=6,l=25,sg=1,ft=0,st=OK:<NONCE>
    mysgw: SGN:NCE:XMT,TO=0
    mysgw: TSF:MSG:READ,33-33-0,s=1,c=1,t=2,pt=1,l=1,sg=1:1
    mysgw: SGN:BND:HMAC=53795E79C8FE9D599D1A88363F7E2BA607ADBB265E4E99356886B65C3D0A06D0
    mysgw: SGN:VER:OK
    mysgw: TSF:MSG:READ,3-3-0,s=255,c=3,t=1,pt=0,l=0,sg=0:
    mysgw: !SGN:VER:NSG

  • Contest Winner

    @pepson your gw is configured to require signing from all nodes.
    Your node 33 is set up to use signing. Your node 3 is not. Hence messages from node 3 will be rejected by the GW.
    Either set up all nodes to use signing or set up weak security on the GW to only require signing from nodes that require it in turn.
    This is documented behaviour. Please read the documentation. That is what it is for.

  • But still I don't know how use white listening...?

  • Contest Winner

    @pepson I suggest you avoid it. It require good tracking of all serials in your network and is part of the more advanced security mechanisms. And I suspect you will get issues when you add new nodes to your network as you cannot get it to work with just two nodes (you still have not enabled it on your gw). So just avoid whitelisting all together.

  • @anticimex
    OK but how I can get serial from my Node on Arduino Pro Mini?

    And when I want use chip AtSHA204A what I must change on my GW and on Node?
    Can I build GW on Rpi with this chip AtSHA204A?

  • Contest Winner

    @pepson Please. Read. The. Documentation.
    And no, atsha204a is not supported on rPi. Nor does it need to be.

  • @anticimex
    But still I don't know how read serial number from Node on Arduino Mini Pro when I want use White Listening...

  • Contest Winner

    @pepson have you read the documentation? Do you understand the concept of personalization? Where have you found information on from where the serial number is obtained?
    I will only say this once more: don't use whitelisting unless you know these things. Serial is only used for whitelisting. Don't use something you do not understand.
    All your questions so far can be answered by citing the documentation so please read it!

  • I have my network with NRF24+'s with HW signing. Now, due to performance limitations of the NRF's I'll move to RFM69's which supports encryption.
    How can I set encryption in Mysensors? Is it already available? Can I have both signing and Encryption?

  • Contest Winner

    @joaoabs yes, it's all in the documentation šŸ˜‰
    Let me know if you can't find it. Links are in the readme.md in git and in github.

  • Hi,
    I've been a while on MySensors forum, most time as a reader. Read the docs about signing and have a couple of questions - possibly stupid as I might not understand well the docs.

    1. I'd like to ask if the flags --my-signing-weak_security and --my-signing-request-signatures (yes I have RPi gw) are complementary or separate: if I define both, do I get a "weak security" feature or the "request security" is on top of that and only signed messages would be accepted? Or maybe I need to define one of them only depending on security level I want to achieve?
    2. Whitelisting - many things were said here, I am not planning to use it for now nor anytime for gateway on nodes as I do not find it necessary as gw is not supposed to be compromised, but did a quick test following the @sineverba tutorial and it failed indeed as pepson said. The serial which I provided in sketch in #define MY_SIGNING_NODE_WHITELISTING {{.nodeId = GATEWAY_ADDRESS,.serial = {myserial}}} was the one generated by mysgq --gen-soft-serial-key (and then applied by --set-soft-serial-key ofc) - is that correct? I also tried to replace GATEWAY_ADDRESS with 0 and no success. Maybe there are some other steps that I should take (@Anticimex said something like "But I don't see your gw flags specifying it" which I dont understand in this context)
    3. Is the encryption possible to be enabled only by compiling the gw with --my-rf24-encryption-enabled (for my nrf24) and personalizing gw and node with the same AES key obtained in this docs and by defining the proper flags in sketches on all nodes or is this procedure is more complicated? If this is not the subject for the scope of this thread please tell me I will search more.

    Thank you for understanding my possibly dumb questions šŸ™‚ I try my best but I am a beginner iot, but work in IT so not a total newbe in programming or technologies.

  • Contest Winner

    @damian There are no stupid questions on complex matters. Security is a complex matter (unfortunately).

    1. The weak security flag allows a node to inform a GW that it no longer require signing. Thus, an attacker might "take over" a node and replace it with a non-secure one possibly without you noticing.
      The request signature flag lets a node (or GW) informe a GW (or node) that it require signatures. That allows the other side to understand that it has to sign messages sent to the destination. It is therefore not to be confused with "weak security". It is more a "enable security".

    2. Writing #define MY_SIGNING_NODE_WHITELISTING {{.nodeId = GATEWAY_ADDRESS,.serial = {myserial}}} in a node, tells the node to requrie the GW to salt the signatures with it's serial (that should match the serial you entered in the node).
      If the messages fail to verify, it suggests that the GW either has not realized it is expected to salt the signatures, or it uses the wrong serial to do it. Unfortunately I do not have a rPi setup to check this, so any help in troubleshooting that would be appreciated.

    3. Yes, just make sure to also enable encryption on the node. Also, do notice that ALL nodes on the same network needs to use encryption with the same key.

    I hope this clarifies the things a bit šŸ™‚

  • @anticimex thanks for the answer.

    1. I understand the idea. However, I think I might asked not clear enough. I would like to know how the mysgw daemon would work after the compilation depending on the flags I provide.
      I understand that when I compile my gw with only --my-signing-request-signatures it will require all nodes in the network to sign messages. But if I want only some of them to sign messages and some not, do I have to compile the gw with both flags: --my-signing-request-signatures AND --my-signing-weak_security or only: --my-signing-weak_security ?
    2. I think it might be an RPi issue, because the idea and setup seems to be correct. I'll try one day to test it in node-to-node communication or some test serial gw on Arduino. This is not so important to me as the signing itself works fine, just was curious.
    3. clear, hope it work. In the meantime I found: https://forum.mysensors.org/topic/2005/software-aes-encryption-for-nrf24 which looks worth testing as well. TL;DR carefully yet.

  • Contest Winner


    1. You need to compile with --my-signing-request-signatures AND --my-signing-weak_security. See https://www.mysensors.org/apidocs/group__SigningSettingGrpPub.html#gaf44407e0f498eca7069adf5e59ffe052
    2. RF24 encryption is implemented in SW and currently available (with static IV). See https://www.mysensors.org/apidocs/group__EncryptionSettingGrpPub.html

  • @anticimex Thank you so much for clarification I owe you a beer šŸ˜‰

    So another question for future considerations - is it possible to read eeprom to get the keys? I suppose the answer is yes as the whitelisting feature is introduced, but is it a hard task or keys could be fetched by a simple script reading eeprom?

  • Contest Winner

    @damian Reading EEPROM is quite trivial for a determined attacker, hence I discourage SW based security as it does not have the means of storing secrets securely on devices as the atmega328p.
    HW based signing is available using the atsha204a in which case signing keys are protected. Encryption keys are not unfortunately as all encryption is currently SW based (or HW accelerated but still SW dependent).
    "Security V3" will resolve this, but I unfortunately have no ETA.

    You are welcome! šŸ»

  • I've just applied signing to my own written sketch and hit a wall. Basically the signing works fine - I get time from controller and it works fine - any signed time packets from controller are read. However I've got issues with my receive(const MyMessage &message) function. The function gets the state change for the relay from the controller and to determine which relay should be changed it uses message.sensor method. When the signing is turned off it returns 0 or 1 (for 2 relays). However, when the signing is enabled it returns always 255. Any ideas why?

  • Contest Winner

    @damian the only thing I can think of is that you don't read the part of the message you think you read. Could you please provide some logs where you print the message in its entirety? The signing backend also has flags for verbose debugging (see the flags in the docs).

  • @anticimex I will send logs, for now do not have access to hardware (I'm out of home). I am curious what could be the reason, as I said, I set all keys and the signing itself seems to work well. When I disable:

    //#define MY_SIGNING_SOFT

    the sketch works fine. When they are enabled, I can see that the messages are received (I can see the change of the state of relay but I cannot read which relay should be change. Here's a part of my sketch, maybe there is a trivial mistake in it:

    #define NUMBER_OF_RELAYS 2
    #define R_CHILD_ID 0
    #define RELAY_PIN 3
    MyMessage msg[NUMBER_OF_RELAYS];
    bool relayState[NUMBER_OF_RELAYS] = {false};
    bool controllerState [NUMBER_OF_RELAYS] = {false};
    void presentation() {
      for (int i=0, r_id=R_CHILD_ID; i<NUMBER_OF_RELAYS; i++, r_id++) {
      present(r_id, S_BINARY);
      msg[i] = MyMessage(r_id, V_STATUS);                                   
    void receive(const MyMessage &message) {
      if (message.type==V_STATUS) { 
        controllerState[message.sensor] =  message.getBool();                       
        if (controllerState[message.sensor] != relayState[message.sensor]) {                        
          relayState[message.sensor] = controllerState[message.sensor];                             
        Serial.print("Message Sensor id: ");
        digitalWrite(RELAY_PIN+message.sensor, relayState[message.sensor] ? RELAY_ON : RELAY_OFF); 

    when I dump to console controllerState[message.sensor] value I can see it changes, no matter the fact that it points on the table out of the range as I check it later when read message.sensor value. So it leads me to conclusion that message.getBool(); works OK (now I think I should Serial.println(message.getBool()) to get straight the value and make sure it really works fine... I will test it), however:

    Serial.print("Message Sensor id: ");

    gives me always the value of 255 instead of 0 or 1 in this case. Of course I gave here only the most important parts of my code which I think causes problems.

  • Contest Winner

    @damian It sure looks like message.sensor is cleared/reset for some reason. The verbose logs should show more details and hopefully reveal when in the call path, this happens.

  • @anticimex
    Should I look rather in gw logs or node's? Or both?

  • Contest Winner

    @damian I'd start with the nodes. I suspect it is at that end something is overwritten after the message is received and verified.

  • @anticimex here are some logs from the node:

    1. Actions without signing - relay 0 on -> off -> relay 1 on -> off
    message.getBool: 1
    message.sensor: 0
    message.getBool: 0
    message.sensor: 0
    message.getBool: 1
    message.sensor: 1
    message.getBool: 0
    message.sensor: 1```
    1. Actions with signing the same sequence as in the above:
    message.getBool: 1
    message.sensor: 255
    message.getBool: 0
    message.sensor: 255
    message.getBool: 1
    message.sensor: 255
    message.getBool: 0
    message.sensor: 255
    1. Same as the 2nd but with debug logs from the node start:
    39 SGN:PER:OK
    73 SGN:SGN:NREQ=255
    117 SGN:SKP:MSG CMD=3,TYPE=8
    2111 SGN:SKP:MSG CMD=3,TYPE=24
    2124 SGN:SKP:MSG CMD=3,TYPE=25
    2127 SGN:PRE:SGN REQ
    2131 SGN:SKP:MSG CMD=3,TYPE=15
    2136 SGN:PRE:XMT,TO=0
    2138 SGN:PRE:WAIT GW
    2147 SGN:SKP:MSG CMD=3,TYPE=15
    2153 SGN:SKP:MSG CMD=3,TYPE=16
    2157 SGN:SGN:NCE REQ,TO=0
    2160 SGN:SKP:MSG CMD=3,TYPE=17
    2163 SGN:NCE:FROM=0
    2252 SGN:BND:HMAC=59CC2807188FF377BB1F83CB2DA7BC10A645A87453318738B3CCCD736468BA8B
    2259 SGN:SGN:SGN
    2265 SGN:SKP:MSG CMD=3,TYPE=16
    2270 SGN:SGN:NCE REQ,TO=0
    2277 SGN:SKP:MSG CMD=3,TYPE=17
    2280 SGN:NCE:FROM=0
    2369 SGN:BND:HMAC=16F18AB2C520A05498608CC2BFBA42889B02A694A2565160084EACCBCD1B9F1C
    2376 SGN:SGN:SGN
    2394 SGN:SKP:MSG CMD=3,TYPE=16
    2411 SGN:SKP:MSG CMD=3,TYPE=17
    2416 SGN:NCE:XMT,TO=3
    2525 SGN:BND:HMAC=671770009DDF1D4F1CA94CF9F13071E003346CB8C56222692DA13ECD73DD2F68
    2532 SGN:VER:OK
    2534 SGN:SKP:MSG CMD=3,TYPE=16
    2539 SGN:SGN:NCE REQ,TO=0
    2543 SGN:SKP:MSG CMD=3,TYPE=17
    2546 SGN:NCE:FROM=0
    2635 SGN:BND:HMAC=ECFD84CCB0B8FCCBE8E6D4501F3405E6CCE99018A13D5D2859F43E58050B9508
    2642 SGN:SGN:SGN
    2647 SGN:SKP:MSG CMD=3,TYPE=16
    2653 SGN:SGN:NCE REQ,TO=0
    2660 SGN:SKP:MSG CMD=3,TYPE=17
    2663 SGN:NCE:FROM=0
    2752 SGN:BND:HMAC=D6DC1E4A5BC8BF47DEE26831C97F7B83E6C8C0CEBACA27BB7A79366686D2AE1F
    2759 SGN:SGN:SGN
    2763 SGN:SKP:MSG CMD=3,TYPE=16
    2768 SGN:SGN:NCE REQ,TO=0
    2776 SGN:SKP:MSG CMD=3,TYPE=17
    2779 SGN:NCE:FROM=0
    2868 SGN:BND:HMAC=693077E51746266A70C0D8C28A8A9707E585F27FB7717D18E985AA6EC52A538C
    2876 SGN:SGN:SGN
    2880 SGN:SKP:MSG CMD=3,TYPE=16
    2885 SGN:SGN:NCE REQ,TO=0
    2892 SGN:SKP:MSG CMD=3,TYPE=17
    2895 SGN:NCE:FROM=0
    2984 SGN:BND:HMAC=B17C1213603F41C583F92A70DF4D6F5D83ADB41DBC812F022A5ED4FE46A0B7F2
    2992 SGN:SGN:SGN
    2997 SGN:SKP:MSG CMD=3,TYPE=16
    3002 SGN:SGN:NCE REQ,TO=0
    3009 SGN:SKP:MSG CMD=3,TYPE=17
    3012 SGN:NCE:FROM=0
    3014 SGN:BND:NONCE=FB23A24F06C2D2A87E36D048354D5A0A8C56BD15C54444D6D3AAAAAAAAAAAAAA
    3101 SGN:BND:HMAC=737991E978781664A5B3FC188BECA847272541F2FE4C8B21E9E769D886C7644A
    3108 SGN:SGN:SGN
    3112 SGN:SKP:MSG CMD=3,TYPE=16
    3119 SGN:SGN:NCE REQ,TO=0
    3126 SGN:SKP:MSG CMD=3,TYPE=17
    3129 SGN:NCE:FROM=0
    3131 SGN:BND:NONCE=14517440F7E1361682BB145FE43624B7EEB5434C86F13B49CBAAAAAAAAAAAAAA
    3218 SGN:BND:HMAC=D869103E10D562870FBA6E5AC62085B9F905921B8EDAE6156E4D161ADBAAFB10
    3225 SGN:SGN:SGN
    3229 SGN:SKP:MSG CMD=3,TYPE=26
    3243 SGN:SKP:MSG CMD=3,TYPE=16
    3260 SGN:SKP:MSG CMD=3,TYPE=17
    3265 SGN:NCE:XMT,TO=3
    3287 SGN:BND:NONCE=7025F04837E08FAA04A3A58239C1AAED9278F5C6B8DF197C68AAAAAAAAAAAAAA
    3374 SGN:BND:HMAC=7A5F0817D6F53120AD81F2C2BDE5DFF223677C0C21AED391B73B35827665C33C
    3382 SGN:VER:OK
    Setup b_pin:14
    Setup b_pin:15
    3389 SGN:SKP:MSG CMD=3,TYPE=16
    3394 SGN:SGN:NCE REQ,TO=0
    3402 SGN:SKP:MSG CMD=3,TYPE=17
    3405 SGN:NCE:FROM=0
    3407 SGN:BND:NONCE=5E16EC77B417638DBB3F43BDCA2735B6A1531082F59BF3800DAAAAAAAAAAAAAA
    3494 SGN:BND:HMAC=71012A7427B1601C6D44EC925FFD8D5514A9165AC2D1CD0808EDDD1ABA9DED62
    3502 SGN:SGN:SGN
    3530 SGN:SKP:MSG CMD=3,TYPE=16
    3548 SGN:SKP:MSG CMD=3,TYPE=17
    3553 SGN:NCE:XMT,TO=3
    3662 SGN:BND:HMAC=EFDE9C7F1E12B34EDADDA2023F81516FD8874EBAF8B4F1D37326FA8DED62D5F9
    3670 SGN:VER:OK
    4171 SGN:SKP:MSG CMD=3,TYPE=16
    4176 SGN:SGN:NCE REQ,TO=0
    4179 SGN:SKP:MSG CMD=3,TYPE=17
    4183 SGN:NCE:FROM=0
    4185 SGN:BND:NONCE=8B545E858FA04E5A4727F1BF48B26EE26053A2CE8F5C7891A9AAAAAAAAAAAAAA
    4272 SGN:BND:HMAC=5E5C4D1D6A3DFF01611E255672BB5400AD770CD2283A12513D3750D4BB6D2A62
    4279 SGN:SGN:SGN
    4312 SGN:SKP:MSG CMD=3,TYPE=16
    4329 SGN:SKP:MSG CMD=3,TYPE=17
    4334 SGN:NCE:XMT,TO=3
    4356 SGN:BND:NONCE=6308AD00528416DA333EA85DDE684956B56223CDE6D11A5727AAAAAAAAAAAAAA
    4443 SGN:BND:HMAC=0548D4EF289A5786E5406BCB77C7C890AD1AABE7A23481DD0C8B3F79165C74DF
    4451 SGN:VER:OK
    4452 SGN:SKP:MSG CMD=3,TYPE=16
    4457 SGN:SGN:NCE REQ,TO=0
    4461 SGN:SKP:MSG CMD=3,TYPE=17
    4464 SGN:NCE:FROM=0
    4466 SGN:BND:NONCE=3FB114975E4199204F9B011C209A9CEF8BBFFB4D4D60595449AAAAAAAAAAAAAA
    4553 SGN:BND:HMAC=409A234B96D417FA1681C449A0C597B1FF907D25DE8758D534C0E77BEB3281E7
    4560 SGN:SGN:SGN
    4564 SGN:SKP:MSG CMD=3,TYPE=16
    4571 SGN:SGN:NCE REQ,TO=0
    4590 SGN:SKP:MSG CMD=3,TYPE=17
    4593 SGN:NCE:FROM=0
    4682 SGN:BND:HMAC=723C8DFFA1C465D6694A5629D99EC4A09594830BABBA1A9CF6AE0156113BAEA3
    4689 SGN:SGN:SGN
    4717 SGN:SKP:MSG CMD=3,TYPE=16
    4734 SGN:SKP:MSG CMD=3,TYPE=17
    4740 SGN:NCE:XMT,TO=3
    4848 SGN:BND:HMAC=758DAAA39E40F746690F6E02C6DE89310E936F57C493D5AC56097714A57D91FD
    4855 SGN:VER:OK
    4857 SGN:SKP:MSG CMD=3,TYPE=16
    4862 SGN:SGN:NCE REQ,TO=0
    4867 SGN:SKP:MSG CMD=3,TYPE=17
    4870 SGN:NCE:FROM=0
    4959 SGN:BND:HMAC=9D408CB8DA13CFA94279EE0702E103781834A513C3F34AD717EFB5D14DB61F41
    4966 SGN:SGN:SGN
    5000 SGN:SKP:MSG CMD=3,TYPE=16
    5005 SGN:SGN:NCE REQ,TO=0
    5016 SGN:SKP:MSG CMD=3,TYPE=17
    5019 SGN:NCE:FROM=0
    5021 SGN:BND:NONCE=16862976C5196352B14CAE8F8A3B2E3CBFB4CE386634795AA3AAAAAAAAAAAAAA
    5108 SGN:BND:HMAC=0378AC5CB5E8ABFAF33484182C562E07FF03E2912124B91A4B9C5F6F7F52EE5E
    5115 SGN:SGN:SGN
    5143 SGN:SKP:MSG CMD=3,TYPE=16
    5160 SGN:SKP:MSG CMD=3,TYPE=17
    5166 SGN:NCE:XMT,TO=3
    5274 SGN:BND:HMAC=7FCC823173527CABF27C64426A0D1AF07537FF15ABCB5028200F3DAA2BD07B2B
    5281 SGN:VER:OK
    5283 SGN:SKP:MSG CMD=3,TYPE=16
    5288 SGN:SGN:NCE REQ,TO=0
    5293 SGN:SKP:MSG CMD=3,TYPE=17
    5296 SGN:NCE:FROM=0
    5297 SGN:BND:NONCE=373E37CB72669C31D416237755EA68B89157428B655B6CC973AAAAAAAAAAAAAA
    5385 SGN:BND:HMAC=9DA54DE18AF1CA6617FC43B0DDD01A2145326273DD74C22DDB6CCE1CD4E3F7AD
    5392 SGN:SGN:SGN
    5396 SGN:SKP:MSG CMD=3,TYPE=16
    5401 SGN:SGN:NCE REQ,TO=0
    5410 SGN:SKP:MSG CMD=3,TYPE=17
    5413 SGN:NCE:FROM=0
    5415 SGN:BND:NONCE=406A1D152B330A40A612A57D399559A8F47115693377E3B267AAAAAAAAAAAAAA
    5502 SGN:BND:HMAC=5D1DA2557B3A97E62DF813F9541D7A127F8B438C5EB0196B1E76820B9C0F7D81
    5510 SGN:SGN:SGN
    10000 SGN:SKP:MSG CMD=3,TYPE=16
    10005 SGN:SGN:NCE REQ,TO=0
    10008 SGN:SKP:MSG CMD=3,TYPE=17
    10011 SGN:NCE:FROM=0
    10100 SGN:BND:HMAC=ADD52CA0428CB8A8903ECEF0A73F5CB38E20FED867B00D307A71F8E79789DCB4
    10108 SGN:SGN:SGN
    10135 SGN:SKP:MSG CMD=3,TYPE=16
    10152 SGN:SKP:MSG CMD=3,TYPE=17
    10158 SGN:NCE:XMT,TO=3
    10266 SGN:BND:HMAC=20366FF89BB97D4CCBDCC50DF13AC8743B6A295CAC02250602C40EF3795325CA
    10273 SGN:VER:OK
    10275 SGN:SKP:MSG CMD=3,TYPE=16
    10280 SGN:SGN:NCE REQ,TO=0
    10285 SGN:SKP:MSG CMD=3,TYPE=17
    10288 SGN:NCE:FROM=0
    10377 SGN:BND:HMAC=BB4935918379CB79BBFB2A3D8F292E53B44E5FCB142922EE42C0E615DC525E2E
    10384 SGN:SGN:SGN
    10388 SGN:SKP:MSG CMD=3,TYPE=16
    10394 SGN:SGN:NCE REQ,TO=0
    10400 SGN:SKP:MSG CMD=3,TYPE=17
    10403 SGN:NCE:FROM=0
    10405 SGN:BND:NONCE=E99F224609C718E42AD2AC14EBFADF26950842F4CB063B2169AAAAAAAAAAAAAA
    10492 SGN:BND:HMAC=866B4C8A5C1F8165A87BF84742EC952E05F743FC938CEF7B6D1B73A0885779F6
    10501 SGN:SGN:SGN
    15000 SGN:SKP:MSG CMD=3,TYPE=16
    15005 SGN:SGN:NCE REQ,TO=0
    15009 SGN:SKP:MSG CMD=3,TYPE=17
    15012 SGN:NCE:FROM=0
    15101 SGN:BND:HMAC=67DE95797F8E6CCC7B5309A8013705D4188BFC02A8674C7F2805268748108A25
    15110 SGN:SGN:SGN
    15136 SGN:SKP:MSG CMD=3,TYPE=16
    15154 SGN:SKP:MSG CMD=3,TYPE=17
    15159 SGN:NCE:XMT,TO=3
    15180 SGN:BND:NONCE=8C36F618FA823CC1F3A58F0E66B7C017C17ECC76970A2F0190AAAAAAAAAAAAAA
    15267 SGN:BND:HMAC=5AB3164CBB27647596B8D2B1B9F90117C6E08AADA353E2D34FED7F83778EE158
    15275 SGN:VER:OK
    15277 SGN:SKP:MSG CMD=3,TYPE=16
    15282 SGN:SGN:NCE REQ,TO=0
    15286 SGN:SKP:MSG CMD=3,TYPE=17
    15289 SGN:NCE:FROM=0
    15378 SGN:BND:HMAC=957C1BEC30090937D37D8A24FFC1BA14B555BD02EDD102604307AB13785252A0
    15385 SGN:SGN:SGN
    15389 SGN:SKP:MSG CMD=3,TYPE=16
    15395 SGN:SGN:NCE REQ,TO=0
    15411 SGN:SKP:MSG CMD=3,TYPE=17
    15414 SGN:NCE:FROM=0
    15416 SGN:BND:NONCE=56298BFDE86C4703C51543AE0871D81399B0E9145541409D9CAAAAAAAAAAAAAA
    15503 SGN:BND:HMAC=7A6B3750629013E0BC83C10EC80AC1225FFA9A040FFBD3928241177AFAFA48DA
    15511 SGN:SGN:SGN
    20000 SGN:SKP:MSG CMD=3,TYPE=16
    20005 SGN:SGN:NCE REQ,TO=0
    20012 SGN:SKP:MSG CMD=3,TYPE=17
    20015 SGN:NCE:FROM=0
    20017 SGN:BND:NONCE=FF0556E0DFF7A13EF551B1B3E54AB9B13C63435CB48133C220AAAAAAAAAAAAAA
    20104 SGN:BND:HMAC=5A9C54621EFF46E4C8A70EBA5F3B65FCE30B7796414FF42C4A3CC9FD7CA5DB3F
    20112 SGN:SGN:SGN
    20139 SGN:SKP:MSG CMD=3,TYPE=16
    20156 SGN:SKP:MSG CMD=3,TYPE=17
    20161 SGN:NCE:XMT,TO=3
    20270 SGN:BND:HMAC=CDDB74748AB4E9D08125B8C52EE7D68BF1124ECC606CC130DBE3A678214393EE
    20277 SGN:VER:OK
    20279 SGN:SKP:MSG CMD=3,TYPE=16
    20284 SGN:SGN:NCE REQ,TO=0
    20288 SGN:SKP:MSG CMD=3,TYPE=17
    20291 SGN:NCE:FROM=0
    20293 SGN:BND:NONCE=CD06A773772E6B0B92A49BE56849DA60D7B454072899AAC3A6AAAAAAAAAAAAAA
    20380 SGN:BND:HMAC=FF28B0DF2A3FB90C5B55C0CE2CCF33B8FD77D8BAA24A95BD4956A93449C8AE0F
    20387 SGN:SGN:SGN
    20392 SGN:SKP:MSG CMD=3,TYPE=16
    20398 SGN:SGN:NCE REQ,TO=0
    20404 SGN:SKP:MSG CMD=3,TYPE=17
    20407 SGN:NCE:FROM=0
    20409 SGN:BND:NONCE=6A915CB133C69C103E3DE553695780998995AD0BA05EA9DB5DAAAAAAAAAAAAAA
    20497 SGN:BND:HMAC=BEB1AA435B6212CFFD7A67CE4B0A87AD94A132F9500DFFBAC101DAF6E4AF066D
    20504 SGN:SGN:SGN
    24542 SGN:SKP:MSG CMD=3,TYPE=16
    24559 SGN:SKP:MSG CMD=3,TYPE=17
    24564 SGN:NCE:XMT,TO=3
    24586 SGN:BND:NONCE=16E64CA5D7019688D81965E587288B967D214AD5DE3567E064AAAAAAAAAAAAAA
    24673 SGN:BND:HMAC=DB24231C4D79AC2CBDD8C1D9AD87103EC6B73ABD94F6E038BDE40406D929AF18
    24680 SGN:VER:OK
    message.getBool: 1
    24782 SGN:SKP:MSG CMD=3,TYPE=16
    24787 SGN:SGN:NCE REQ,TO=0
    24794 SGN:SKP:MSG CMD=3,TYPE=17
    24797 SGN:NCE:FROM=0
    24799 SGN:BND:NONCE=260E9FC73FF1B54D7559524400F589FFC658DE8AEC707D09CCAAAAAAAAAAAAAA
    24886 SGN:BND:HMAC=FE572B069ECD3303C73700F543A87FCB8CB106515A76D35379711DBBAADAA437
    24894 SGN:SGN:SGN
    message.sensor: 255
    25000 SGN:SKP:MSG CMD=3,TYPE=16
    25006 SGN:SGN:NCE REQ,TO=0
    25015 SGN:SKP:MSG CMD=3,TYPE=17
    25018 SGN:NCE:FROM=0
    25020 SGN:BND:NONCE=285E2D30B1ECC8BF0625F022708E3FFC30D4831003BD358CDEAAAAAAAAAAAAAA
    25108 SGN:BND:HMAC=D324AACB08FF60F71BFEE5747F7313FEF1C82CF2FE3455C350CB131F15C04EDB
    25115 SGN:SGN:SGN
    25148 SGN:SKP:MSG CMD=3,TYPE=16
    25165 SGN:SKP:MSG CMD=3,TYPE=17
    25170 SGN:NCE:XMT,TO=3
    25192 SGN:BND:NONCE=931A1DE011E34E7D177D87295313CF9490FF5D42DF59B2A1CAAAAAAAAAAAAAAA
    25280 SGN:BND:HMAC=CB7C16051F2CCA51A054FAE7327637DE3921A4C67D865F1859E21E763FB91698
    25287 SGN:VER:OK
    25289 SGN:SKP:MSG CMD=3,TYPE=16
    25294 SGN:SGN:NCE REQ,TO=0
    25297 SGN:SKP:MSG CMD=3,TYPE=17
    25300 SGN:NCE:FROM=0
    25303 SGN:BND:NONCE=08A188872AB23EA761709E2DB033898424A307D8019B42D048AAAAAAAAAAAAAA
    25391 SGN:BND:HMAC=190D48C11DD42052CCBE6368EF48CB757B66E6E228247ECCCEA73680016C079F
    25398 SGN:SGN:SGN
    25402 SGN:SKP:MSG CMD=3,TYPE=16
    25407 SGN:SGN:NCE REQ,TO=0
    25427 SGN:SKP:MSG CMD=3,TYPE=17
    25431 SGN:NCE:FROM=0
    25433 SGN:BND:NONCE=40C6955CD073344B1624FEE815B91F31BE7AD215918727C1B5AAAAAAAAAAAAAA
    25520 SGN:BND:HMAC=235D7ECC1516626F8BFF5F849FC6E3B9391549DC2BAD21694E55F734D3E3F676
    25527 SGN:SGN:SGN
    26334 SGN:SKP:MSG CMD=3,TYPE=16
    26351 SGN:SKP:MSG CMD=3,TYPE=17
    26357 SGN:NCE:XMT,TO=3
    26379 SGN:BND:NONCE=4B62932D0B5AC2BF336C8D16E184503798CD3B5569D8872CC4AAAAAAAAAAAAAA
    26466 SGN:BND:HMAC=30FC8A4DDFD59DAEFB11B1429A66A4AFE12E90BF9CD2E3B2673621536A1EAB84
    26473 SGN:VER:OK
    message.getBool: 0
    26575 SGN:SKP:MSG CMD=3,TYPE=16
    26580 SGN:SGN:NCE REQ,TO=0
    26587 SGN:SKP:MSG CMD=3,TYPE=17
    26590 SGN:NCE:FROM=0
    26679 SGN:BND:HMAC=88CDBE83E92EA22CE06347744EE117F2D7E5DA3BB9A391073A4709B0FD5F60B4
    26686 SGN:SGN:SGN
    message.sensor: 255
    28345 SGN:SKP:MSG CMD=3,TYPE=16
    28362 SGN:SKP:MSG CMD=3,TYPE=17
    28368 SGN:NCE:XMT,TO=3
    28381 SGN:BND:NONCE=3410F5DD4084EA0068B3F0C8F3A4D5DA7AC120762E5B606115AAAAAAAAAAAAAA
    28468 SGN:BND:HMAC=8E073350CC53B595DA09FBF8A78450DFBDC3221014D3B4ECEB7ACD327BC4D61A
    28475 SGN:VER:OK
    message.getBool: 1
    28577 SGN:SKP:MSG CMD=3,TYPE=16
    28582 SGN:SGN:NCE REQ,TO=0
    28589 SGN:SKP:MSG CMD=3,TYPE=17
    28592 SGN:NCE:FROM=0
    28594 SGN:BND:NONCE=4F49C817A6B4A064689E304275F1DFB4F294C84E49DCF9BD34AAAAAAAAAAAAAA
    28682 SGN:BND:HMAC=0D40969334248E05273CC27EC628090DA6BA701D05D3CFF0C2EF41EA494C4DF0
    28689 SGN:SGN:SGN
    message.sensor: 255
    29425 SGN:SKP:MSG CMD=3,TYPE=16
    29443 SGN:SKP:MSG CMD=3,TYPE=17
    29448 SGN:NCE:XMT,TO=3
    29469 SGN:BND:NONCE=1A791FA57B8D29F02B6E90717970377F8BBC3BC91DF40AC63AAAAAAAAAAAAAAA
    29557 SGN:BND:HMAC=8B41F3C94CB62376D5529C49A1B2E0C05E414149B087673570548A56949B8640
    29564 SGN:VER:OK
    message.getBool: 0
    29666 SGN:SKP:MSG CMD=3,TYPE=16
    29671 SGN:SGN:NCE REQ,TO=0
    29678 SGN:SKP:MSG CMD=3,TYPE=17
    29681 SGN:NCE:FROM=0
    29770 SGN:BND:HMAC=A942BFA7D6AC7108F0AFADA0F7C36D89582F2421E2012962526DECADCB8B7A0E
    29777 SGN:SGN:SGN
    message.sensor: 255
    30000 SGN:SKP:MSG CMD=3,TYPE=16
    30005 SGN:SGN:NCE REQ,TO=0
    30009 SGN:SKP:MSG CMD=3,TYPE=17
    30012 SGN:NCE:FROM=0
    30014 SGN:BND:NONCE=64B61596FC3FDC279789EF4E74C2A833DA04EA7A5C0A36584BAAAAAAAAAAAAAA
    30101 SGN:BND:HMAC=B7DE1CC94D2B2F889AD51703F0C314277FEFB23DF4DBAB0A169AC348E71D2D27
    30108 SGN:SGN:SGN
    30136 SGN:SKP:MSG CMD=3,TYPE=16
    30153 SGN:SKP:MSG CMD=3,TYPE=17
    30159 SGN:NCE:XMT,TO=3
    30259 SGN:BND:HMAC=614DC54F0BCECADE45A0D32B1021FE4BDE17C70C61460DABDDFDA14039913A60
    30267 SGN:VER:OK
    30268 SGN:SKP:MSG CMD=3,TYPE=16
    30274 SGN:SGN:NCE REQ,TO=0
    30277 SGN:SKP:MSG CMD=3,TYPE=17
    30280 SGN:NCE:FROM=0
    30282 SGN:BND:NONCE=567D002CB82F6B8DEE82F874B97E5E31A51A8549345648C18BAAAAAAAAAAAAAA
    30370 SGN:BND:HMAC=0AC28DBFBCF43A810C985DDD44E27752B681E22ADC6E95537B83D47BC2FF821C
    30377 SGN:SGN:SGN
    30382 SGN:SKP:MSG CMD=3,TYPE=16
    30387 SGN:SGN:NCE REQ,TO=0
    30394 SGN:SKP:MSG CMD=3,TYPE=17
    30397 SGN:NCE:FROM=0
    30486 SGN:BND:HMAC=A36CAC6FDD59A5E5D33E6E0FC49E0B5F52EB207EEC4B1A739C1572896534693B
    30494 SGN:SGN:SGN
    35000 SGN:SKP:MSG CMD=3,TYPE=16
    35005 SGN:SGN:NCE REQ,TO=0
    35012 SGN:SKP:MSG CMD=3,TYPE=17
    35015 SGN:NCE:FROM=0
    35105 SGN:BND:HMAC=95B08DF42306303146921FAFBE413552BD5E759DD8E251BBAACA69F6C77B7677
    35112 SGN:SGN:SGN
    35139 SGN:SKP:MSG CMD=3,TYPE=16
    35156 SGN:SKP:MSG CMD=3,TYPE=17
    35163 SGN:NCE:XMT,TO=3
    35271 SGN:BND:HMAC=5ABF9477680B454863769B902AD384002FAF779084FB1073DE82EFCD68150CBF
    35278 SGN:VER:OK
    35280 SGN:SKP:MSG CMD=3,TYPE=16
    35286 SGN:SGN:NCE REQ,TO=0
    35290 SGN:SKP:MSG CMD=3,TYPE=17
    35293 SGN:NCE:FROM=0
    35389 SGN:SGN:SGN
    35393 SGN:SKP:MSG CMD=3,TYPE=16
    35399 SGN:SGN:NCE REQ,TO=0
    35405 SGN:SKP:MSG CMD=3,TYPE=17
    35408 SGN:NCE:FROM=0
    35410 SGN:BND:NONCE=428C535E657135E2F03563064E550BAEA922F19AE16CF4AB87AAAAAAAAAAAAAA
    35499 SGN:BND:HMAC=4217532A927DEF4D1B0810B06EE32BC9BE3877C32CC3203B122576626A818E4A
    35506 SGN:SGN:SGN
    40000 SGN:SKP:MSG CMD=3,TYPE=16
    40005 SGN:SGN:NCE REQ,TO=0
    40013 SGN:SKP:MSG CMD=3,TYPE=17
    40016 SGN:NCE:FROM=0
    40018 SGN:BND:NONCE=8D65E89103046004EF7EC22E7D962F9ED3B687D509B2E4BA76AAAAAAAAAAAAAA
    40105 SGN:BND:HMAC=3F900CD97363E50EE6B357613F769DAF886E048FFDA7C49151E2DEB21BF9F379
    40114 SGN:SGN:SGN
    40140 SGN:SKP:MSG CMD=3,TYPE=16
    40158 SGN:SKP:MSG CMD=3,TYPE=17
    40164 SGN:NCE:XMT,TO=3
    40184 SGN:BND:NONCE=874FA416122E07E959949E7DE32BE457046122688B7977E971AAAAAAAAAAAAAA
    40272 SGN:BND:HMAC=A7D7D8B4281C5F6F2C7B596928C5B109A177A90D376DBC64CC9824131BE5397D
    40280 SGN:VER:OK
    40282 SGN:SKP:MSG CMD=3,TYPE=16
    40287 SGN:SGN:NCE REQ,TO=0
    40290 SGN:SKP:MSG CMD=3,TYPE=17
    40293 SGN:NCE:FROM=0
    40295 SGN:BND:NONCE=B53BE35890A4BED128978360388906AC10959E2177B896F645AAAAAAAAAAAAAA
    40383 SGN:BND:HMAC=37C7C6BF1B3E669444F0805DDB510954598E12AD1CB66D554B6F6F8860E341F1
    40390 SGN:SGN:SGN
    40394 SGN:SKP:MSG CMD=3,TYPE=16
    40400 SGN:SGN:NCE REQ,TO=0
    40407 SGN:SKP:MSG CMD=3,TYPE=17
    40410 SGN:NCE:FROM=0
    40412 SGN:BND:NONCE=F040D59227D7B10262574740CE5575419ABDADBF019EFEE09FAAAAAAAAAAAAAA
    40499 SGN:BND:HMAC=6333224230F7EFFE3317FD7E139EDE907E0B2065F2C792AE9E8A59C74396426C
    40507 SGN:SGN:SGN
    45000 SGN:SKP:MSG CMD=3,TYPE=16
    45005 SGN:SGN:NCE REQ,TO=0
    45016 SGN:SKP:MSG CMD=3,TYPE=17
    45019 SGN:NCE:FROM=0
    45109 SGN:BND:HMAC=354D1FF390248F8870A76461996E9C6EC8C9B821470FDA6B6BD517B4D28AD054
    45116 SGN:SGN:SGN
    45143 SGN:SKP:MSG CMD=3,TYPE=16
    45160 SGN:SKP:MSG CMD=3,TYPE=17
    45165 SGN:NCE:XMT,TO=3
    45274 SGN:BND:HMAC=23843CEAE27BBE91CB06909B4C586289CFE6C44F568E337093D9025EF3FE786B
    45282 SGN:VER:OK
    45283 SGN:SKP:MSG CMD=3,TYPE=16
    45289 SGN:SGN:NCE REQ,TO=0
    45292 SGN:SKP:MSG CMD=3,TYPE=17
    45295 SGN:NCE:FROM=0
    45297 SGN:BND:NONCE=0EB891A61B11543A7790E05C52857CA3336974DD3A407E8783AAAAAAAAAAAAAA
    45384 SGN:BND:HMAC=55A35830E7B6E445CFD2F37C49D893FAE25F03ED57AB651F765F877F8A1B7631
    45392 SGN:SGN:SGN
    45396 SGN:SKP:MSG CMD=3,TYPE=16
    45402 SGN:SGN:NCE REQ,TO=0
    45409 SGN:SKP:MSG CMD=3,TYPE=17
    45411 SGN:NCE:FROM=0
    45413 SGN:BND:NONCE=ACC5047C74CDE5746F7C174E6F6DAB7BEA032788B322C93660AAAAAAAAAAAAAA
    45501 SGN:BND:HMAC=4DEAC30628039766C0B217A89F8A9F4B10C37CEB45529D04C108DE556541C17C
    45508 SGN:SGN:SGN

    I looked via log parser and it is not looking bad for me. Do you find any suspicious behaviour here? I didn't mention - I use MySensors 2.2. Should I switch to 2.3?

  • Contest Winner

    @damian interesting. It would appear that verified messages has part of the header overwritten. I will take a closer look tomorrow. If you want, please test with the latest release, although there have not to my knowledge been made any changes relating to this issue.
    If you want, please also add some debug printing on the sensor value of the message buffer as it is received and goes though the process of verification and propagates out of the internals in the library. I will look in the code to see if I can find an explanation for the corruption.

  • Contest Winner

    @damian Can you please share your sketch including your debug statements? It appears to me that your node between the print "message.getBool: 1" and "message.sensor: 255" is sending something to the GW. That initiates security handshaking so "message" will not be the same between the first and second print.

  • @anticimex Sure, here it is (still under development so there are some minor, I hope, bugs)

    // Enable debug prints to serial monitor
    //#define MY_DEBUG
    #define MY_SIGNING_SOFT
    #define MY_RADIO_NRF24
    #define MY_TRANSPORT_WAIT_READY_MS 5000                         
    #define MY_NODE_ID 3                                            
    #include <MySensors.h>
    #include <Bounce2.h>
    #include <DHT.h>
    #define R_CHILD_ID 0                                          
    #define BUTTON_PIN A0                                         
    #define RELAY_PIN 3                                           
    #define NUMBER_OF_RELAYS 2
    #define RELAY_ON 1                                            
    #define RELAY_OFF 0                                           
    #define T_CHILD_ID 10
    #define H_CHILD_ID 11
    #define DHT_PIN 8
    #define SENSOR_TEMP_OFFSET 0
    unsigned long waitDelay = 100;                                  
    unsigned long connStatusCheckPeriod = 5*1000.;                   
    unsigned long tempHumCheckPeriod = 300*1000.;
    Bounce debouncer[NUMBER_OF_RELAYS];  
    DHT dht;
    bool metric = true;
    float temp = 0.0;
    float hum = 0.0;
    MyMessage msgTemp(T_CHILD_ID, V_TEMP);
    MyMessage msgHum(H_CHILD_ID, V_HUM);
    MyMessage msg[NUMBER_OF_RELAYS];                               
    bool firstRun = true;                                          
    bool relayState[NUMBER_OF_RELAYS] = {false};                   
    bool connectionState = false;                                 
    bool controllerState [NUMBER_OF_RELAYS] = {false};                                 
    bool wasOffline = true;                                         
    unsigned long currentTime = 0;
    unsigned long oldTime = 0;
    unsigned long oldTimeSensor = 0;
    unsigned long receiveTimeOld = 0;
    unsigned long receiveTimeNew = 0;
    bool buttonValue[NUMBER_OF_RELAYS] = {0};
    bool oldButtonValue[NUMBER_OF_RELAYS] = {0};                                         
    void before() {
    void setup(){                                                    
      for (int i=0, r_pin=RELAY_PIN, b_pin=BUTTON_PIN; i<NUMBER_OF_RELAYS; i++, r_pin++, b_pin++) {
        pinMode(b_pin, INPUT_PULLUP);                            
        pinMode(r_pin, OUTPUT);                                   
        digitalWrite(r_pin, RELAY_OFF);
      Serial.print("Setup b_pin:");
    void presentation() {
      sendSketchInfo("MultiRelay", "1.0");                                
      for (int i=0, r_id=R_CHILD_ID; i<NUMBER_OF_RELAYS; i++, r_id++) {
        present(r_id, S_BINARY);
        msg[i] = MyMessage(r_id, V_STATUS);                                   
      present(H_CHILD_ID, S_HUM);
      present(T_CHILD_ID, S_TEMP);
      metric = getControllerConfig().isMetric;
    void loop() {                                                     
      currentTime = millis();                                      
      if (firstRun) {                                                 
    if (currentTime - oldTime >= connStatusCheckPeriod) {             
      oldTime = currentTime;
      connectionState = checkConnection();
      if (connectionState && wasOffline){
        for(int i=0;i<NUMBER_OF_RELAYS;i++) {
          send(msg[i].set(relayState[i]), false);                            
      Serial.print("Temp / Hum: ");
      Serial.print(" / ");
    if (currentTime - oldTimeSensor >= tempHumCheckPeriod) {             
      oldTimeSensor = currentTime;
      temp = dht.getTemperature();
      temp += SENSOR_TEMP_OFFSET;
      hum = dht.getHumidity();
      send(msgTemp.set(temp, 1));
      send(msgHum.set(hum, 1));
      for(int i=0;i<NUMBER_OF_RELAYS;i++) {
          buttonValue[i] = debouncer[i].read();
        if (buttonValue[i] != oldButtonValue[i] && buttonValue[i]==0) {
          relayState[i] = !relayState[i];
          switch (connectionState) {
            case 0:
            case 1:
        oldButtonValue[i] = buttonValue[i];                                   
    void receive(const MyMessage &message) {
      if (message.type==V_STATUS) {                                     
          if (firstRun) {                                               
            relayState[message.sensor] = message.getBool();
            } else {                                                    
            controllerState[message.sensor] =  message.getBool();                       
            Serial.print("\nRelay State: ");
            Serial.print("Switching to: ");
            if (controllerState[message.sensor] != relayState[message.sensor]) {                        
              relayState[message.sensor] = controllerState[message.sensor];                             
              send(msg[message.sensor].set(relayState[message.sensor]), false);                         
            Serial.print("Relay state after if: ");
            digitalWrite(RELAY_PIN+message.sensor, relayState[message.sensor] ? RELAY_ON : RELAY_OFF); 
    void firstRunFunc() {
        connectionState = checkConnection();                          
        for (int i=0, r_pin=RELAY_PIN, r_id=R_CHILD_ID ;i<NUMBER_OF_RELAYS;i++, r_pin++, r_id++){
          switch (connectionState) {
            case 0:                                                     
              relayState[i] = false;                                      
              Serial.print("First Run: Offline: ");
              digitalWrite(r_pin, relayState[i] ? RELAY_ON : RELAY_OFF);
            case 1:                                                    
              request(r_id, V_STATUS);                          
              Serial.print("First Run: Online: ");
              digitalWrite(r_pin, relayState[i] ? RELAY_ON : RELAY_OFF); 
              send(msg[i].set(relayState[i]), false);                         
        firstRun = !firstRun;                                         
    void workOffline() {
      wasOffline = true;
      for (int i=0, r_pin=RELAY_PIN;i<NUMBER_OF_RELAYS;i++, r_pin++){
        Serial.print("Pracujemy offline: ");
        digitalWrite(r_pin, relayState[i] ? RELAY_ON : RELAY_OFF);
    void workOnline() {
      wasOffline = false;
      for (int i=0, r_pin=RELAY_PIN;i<NUMBER_OF_RELAYS;i++, r_pin++){
        Serial.print("Pracujemy online. Stan przekaznika ktory wysylamy do HA: ");
        digitalWrite(r_pin, relayState[i] ? RELAY_ON : RELAY_OFF);
        send(msg[i].set(relayState[i]), false);
    void receiveTime(unsigned long ts) {
      if (firstRun) {
       receiveTimeNew = ts;
       Serial.print("Receive time first run old / new: ");
       Serial.print(" / ");
      } else {
        Serial.print("Received time:");
        receiveTimeNew = ts;
    bool checkConnection() {
        bool rt = requestTime(false);
        if ((receiveTimeNew != receiveTimeOld)) {
          Serial.print("Online, odebrany czas: ");
          receiveTimeOld = receiveTimeNew;
          return true;
      Serial.print("Offline, received time: ");
      return false;

  • Contest Winner

    @damian Hm, I don't find your debug prints you used earlier.
    But in general, I would say that the message object might be overwritten by the library, so if you need to use parts of it, make a copy of the parts you use first and then reference the copy to make sure a new incoming message does not overwrite it.
    Eg, in receive():

    void receive(const MyMessage &message) {
      if (message.type==V_STATUS) {                        
          bool value = message.getBool();
          uint8_t sensor = message.sensor;
          if (firstRun) {                                               
            relayState[sensor] = value;
            } else {                                                    
            controllerState[sensor] =  value;                       
            Serial.print("\nRelay State: ");
            Serial.print("Switching to: ");
            if (controllerState[sensor] != relayState[sensor]) {                        
              relayState[sensor] = controllerState[sensor];                             
              send(msg[sensor].set(relayState[sensor]), false);                         
            Serial.print("Relay state after if: ");
            digitalWrite(RELAY_PIN+sensor, relayState[sensor] ? RELAY_ON : RELAY_OFF); 

    And I believe the cause for your problem is that you do

    send(msg[message.sensor].set(relayState[message.sensor]), false);  


    Serial.print("Switching to: ");

    but before

    Serial.print("Relay state after if: ");

    so message might be changed between since the send() will request a nonce from the GW which then overwrites the buffer referenced by message.

  • @anticimex Thank you, I'll test it and let you know if it helped. PS. debug prints sent before was created in cito, this is my original script. But you find it well, it was instead of:

    Serial.print("\nRelay State: ");


    Serial.print("Relay state after if: ");

    So basically the sections that you've mentioned as a possibly buggy.

  • @anticimex Yep, remodelling receive() function by adding variables and assigning values respectively message.sensor and message.getBool at the beginning got the job done. Now it works like a charm. Moreover, the whitelisting feature also works now - I had to do something wrong previously. Thank you once again for your help.

  • Contest Winner

    @damian great to hear! Happy secure home automating šŸ™‚

  • Plugin Developer

    This page is not up to date, and this is causing some confusion:

  • Contest Winner

    @alowhum but that is not part of the core library, right? So this thread is perhaps not the best place for discussing 3rd party tools.

  • Plugin Developer

    "This thread contains comments for the article "Security & Signing" posted on MySensors.org."

    @Anticimex This thread is the thread attached to a page on MySensors.org about security.

    I pointed to that (awesome) tool on Github as an example that the page has caused some confusion about whether or not MySensors supports encryption.

  • Contest Winner

    @alowhum ok, thanks. Well we do. So please notify that author.

  • Contest Winner

    @alowhum as for the link back to mysensors documentation, that documentation is about message signing which is not to be confused with encryption. And on the top of the article is links to the latest documentation which should reflect the latest status on both signing and encryption.

  • Contest Winner

    @alowhum @hek we should perhaps retire that article or reduce it to a reference to the "actual" documentation instead to reduce the risk of confusion?

  • Admin

    Yes, maybe we could add a more prominent link in the article to the auto generated documentation. Right now the link easily missed in the ingress.... and it does not link directly to the overview documentation here:

    I don't think we should scrap the page entirely as it contains the none API technical parts as a good overview.

  • Plugin Developer

    @hek said in šŸ’¬ Security & Signing:


    That link still only refers to details about signing, and not encryption. So a user wanting to learn about security might still come away with the idea that only signing is supported.

  • Contest Winner

  • Plugin Developer

    @anticimex Great!

  • Hi All not sure if this should be under gateway or security sections but just wondering If it is possible to run 2 seperate gateways for mysensors netwok

    • a fully secured network with signing required both node and gateway for all nodes required to send and or receive signed data.
      -A second unsecured network for gerneral sensor data and equipment not requiring any security

  • Contest Winner

    @Yoshu it is possible. When you have two gateways, the networks will be completely isolated so you can run one of them secured while the other is not.
    You might need to distinguish the nodes on in your controller by giving them static unique ID:s unless your controller ties the identifiers to each gateway or it might be difficult to determine which mysensors network a node belong to.

  • @Anticimex more important is to set different network id or you'll have lot of collisions and lost packets

  • Contest Winner

    @lood29 That is correct, assuming the same radio technology is used. Typically, you set up a separate gateway because you want to run a sensor network on a different radio family due to longer distances or similar.

Log in to reply

Suggested Topics

  • 3
  • 584
  • 110
  • 10
  • 2
  • 5