MY_DEBUG_OTA results in compile errors

  • Hi folks. I've been working on building my sensor network for a couple of months now and although I've had some frustration, I've been able to work through most of the issues. I've recently started to work on getting OTA updates working and am finding it a challenge.

    I wanted to try to get more debugging information specific to the OTA updates from both my test node and the gateway. In either case, when I add #define MY_DEBUG_OTA to the code in either my node sketch or my gateway's mysgw.cpp file and try to compile, I get compile errors.

    pi@gateway:~/gateways/MySensors $ make
    g++ -MT build/examples_linux/mysgw.o -MMD -MP -march=armv8-a+crc -mtune=cortex-a53 -mfpu=neon-fp-armv8 -mfloat-abi=hard -DMY_RADIO_RF24 -DMY_GATEWAY_LINUX -DMY_DEBUG -DLINUX_SPI_BCM -DLINUX_ARCH_RASPBERRYPI -DMY_PORT=8080 -DMY_RX_MESSAGE_BUFFER_FEATURE -DMY_RF24_IRQ_PIN=15  -Ofast -g -Wall -Wextra  -I. -I./core -I./drivers/Linux -I./drivers/BCM -c examples_linux/mysgw.cpp -o build/examples_linux/mysgw.o
    In file included from ./MySensors.h:42:0,
                     from examples_linux/mysgw.cpp:87:
    ./core/MyGatewayTransportEthernet.cpp: In function ‘bool _readFromClient(uint8_t)’:
    ./MyConfig.h:2097:50: error: expected primary-expression before ‘)’ token
     #define DEBUG_OUTPUT(x,...)  OTALog((MY_DEBUG_OTA), true, x, ##__VA_ARGS__) //!< debug
    ./core/MyGatewayTransport.h:82:30: note: in expansion of macro ‘DEBUG_OUTPUT’
     #define GATEWAY_DEBUG(x,...) DEBUG_OUTPUT(x, ##__VA_ARGS__) //!< debug output
    ./core/MyGatewayTransportEthernet.cpp:297:5: note: in expansion of macro ‘GATEWAY_DEBUG’
         GATEWAY_DEBUG(PSTR("GWT:RFC:C=%" PRIu8 ",MSG=%s\n"), i, inputString[i].string);
    ./MyConfig.h:2097:50: error: expected primary-expression before ‘)’ token
     #define DEBUG_OUTPUT(x,...)  OTALog((MY_DEBUG_OTA), true, x, ##__VA_ARGS__) //!< debug
    ./core/MyGatewayTransport.h:82:30: note: in expansion of macro ‘DEBUG_OUTPUT’
     #define GATEWAY_DEBUG(x,...) DEBUG_OUTPUT(x, ##__VA_ARGS__) //!< debug output
    It goes on like that for too many lines to post here.
    Makefile:98: recipe for target 'build/examples_linux/mysgw.o' failed
    make: *** [build/examples_linux/mysgw.o] Error 1

    ^^^ That's the output compiling the gateway.

    This is a MySensors 2.3.1 ethernet gateway running on a Raspberry Pi . Same RPi has MyController 1.4.0_Final.

    It compiles fine without that directive.

    Any thoughts?

  • @alphahotel

    Here's the contents of mysgw.cpp.

     * The MySensors Arduino library handles the wireless radio link and protocol
     * between your home built sensors/actuators and HA controller of choice.
     * The sensors forms a self healing radio network with optional repeaters. Each
     * repeater and gateway builds a routing tables in EEPROM which keeps track of the
     * network topology allowing messages to be routed to nodes.
     * Created by Henrik Ekblad <>
     * Copyright (C) 2013-2018 Sensnology AB
     * Full contributor list:
     * Documentation:
     * Support Forum:
     * This program is free software; you can redistribute it and/or
     * modify it under the terms of the GNU General Public License
     * version 2 as published by the Free Software Foundation.
    #include <iostream>
    #include <cstdio>
    #include <unistd.h>
    // For more options run ./configure --help
    // Config file
    //#define MY_LINUX_CONFIG_FILE "/etc/mysensors.conf"
    // How many clients should be able to connect to this gateway (default 1)
    // Serial config
    // Enable this if you are using an Arduino connected to the USB
    //#define MY_LINUX_SERIAL_PORT "/dev/ttyUSB0"
    // Enable this if you need to connect to a controller running on the same device
    // You also need to define MY_LINUX_SERIAL_PORT above with the symlink name for the PTY device
    //#define MY_LINUX_SERIAL_IS_PTY
    // Grant access to the specified system group for the serial device
    //#define MY_LINUX_SERIAL_GROUPNAME "tty"
    // MQTT options
    //#define MY_CONTROLLER_IP_ADDRESS 192, 168, 178, 68
    //#define MY_PORT 1883
    //#define MY_MQTT_CLIENT_ID "mysensors-1"
    //#define MY_MQTT_PUBLISH_TOPIC_PREFIX "mygateway1-out"
    //#define MY_MQTT_SUBSCRIBE_TOPIC_PREFIX "mygateway1-in"
    // Enable these if your MQTT broker requires username/password
    //#define MY_MQTT_USER "username"
    //#define MY_MQTT_PASSWORD "password"
    // Flash leds on rx/tx/err
    //#define MY_DEFAULT_ERR_LED_PIN 12  // Error LED pin
    //#define MY_DEFAULT_RX_LED_PIN  16  // Receive LED pin
    //#define MY_DEFAULT_TX_LED_PIN  18  // Transmit LED pin
    // Inverse the blinking feature
    // Enable software signing
    //#define MY_SIGNING_SOFT
    // Enable signing related debug
    // Enable this to request signatures
    // Enable this to to weaken security for gradual deployment purpose
    // (see signing documentation for details)
    // Enables RF24 encryption (all nodes and gateway must have this enabled, and all must be
    // personalized with the same AES key)
    // Enable inclusion mode if your HA Controller supports it (e.g. Vera Controller)
    // Enable Inclusion mode button on gateway
    // Set inclusion mode duration (in seconds)
    // Digital pin used for inclusion mode button
    #define MY_DEBUG_OTA
    //#define MY_DEBUG_VERBOSE_RF24
    #include <MySensors.h>
    #define ARDUINO 100
    // This space is intended to be used to include arduino libraries
    #undef ARDUINO
    void setup()
    	// Setup locally attached sensors
    void presentation()
    	// Present locally attached sensors here
    void loop()
    	// Send locally attached sensors data here

  • Figured out that I misunderstood the purpose of this directive. I was thinking (had assumed) that it was showing more verbose information through the serial output for firmware OTA update traffic. Once I looked at the description for it, it was clear that it is intended more as an alternative to MY_DEBUG - as in don't send debug output to the serial but send it over-the-air instead. I was declaring both and they conflict.

    EDIT: saying they conflict is inaccurate. The problem was in how I was using it (inappropriately).

    -- Allen

  • Mod

    @alphahotel thanks for reporting back. I have never used MY_DEBUG_OTA myself but if what you've found is how it is supposed to work, we should probably make the documentation clearer and maybe add a clearer compile error.

  • @mfalkvidd It was more a matter of me not mentally differentiating between OTA firmware updates and other potential OTA use cases when I searched for OTA related directives.

    I don't feel I'm yet in a position to be able to make clarifications to documentation. I would like to be able to get to the point of putting together a handful of walk-throughs for beginners but I'm still in an experimenting and learning phase.

    Time will tell.

    -- Allen

  • @alphaHotel A bit far from a compiler, so I don't test it, but did you try to define MY_DEBUG_OTA to TRUE ?

  • Mod

    @alphahotel sorry, I didn't mean that you had to make the documentation update. Hopefully someone who is more familiar with this setting can chip in.

    For reference, here is the existing documentation for MY_DEBUG_OTA:

    The define you really wanted is probably MY_DEBUG_VERBOSE_OTA_UPDATE. Documentation at

  • Mod

    I have created to enhance the documentation

  • @mfalkvidd Thank you - MY_DEBUG_VERBOSE_OTA_UPDATE does look like it's exactly what I was looking for. Further looking into the code here though, it would seem that it gets defined automatically if we define MY_DEBUG.

    Turn it around, when we define MY_DEBUG, we should see verbose FOTA (+ Core, Transport and Gateway) information in the serial log output.

    I'll attempt some more testing tonight to see what I can see.

Log in to reply

Suggested Topics

  • 1
  • 3
  • 10
  • 5
  • 198
  • 2