Hi,

in the example Sketch for the Ethernet Gateway is a small Bug. Pins for CE and SS are defined:

define RADIO_CE_PIN 5 // radio chip enable

define RADIO_SPI_SS_PIN 6 // radio SPI serial select

But when initializing the Transport object, default pins are used:

MyTransportNRF24 transport(RF24_CE_PIN, RF24_CS_PIN, RF24_PA_LEVEL_GW);

This shoud be changed to
MyTransportNRF24 transport(RADIO_CE_PIN,RADIO_SPI_SS_PIN, RF24_PA_LEVEL_GW);

Otherwise, people using different pins, must find that error.

Also it is better to not define variables for the preprocessor, if they are not needed there. Use const uint8_t RADIO_CE_PIN =5 ; will clearly create that variable once using one byte of ram.

Arduino: 1.5.8 (Windows 8), Board: "Arduino Due (Programming Port)"

In file included from Z:\arduino-1.5.8-new\libraries\DigitalIO/DigitalIO.h:31:0,
from MQTTGateway.ino:59:
Z:\arduino-1.5.8-new\libraries\DigitalIO/DigitalPin.h:30:20: fatal error: avr/io.h: No such file or directory
#include <avr/io.h>
^
compilation terminated.
Ошибка компиляции.

This report would have more information with
"Show verbose output during compilation"
enabled in File > Preferences.

Hi.
Excuse my poor english.

My setup : Arduino 1.6.0 on archlinux / Arduino Uno
Dallas Sensor connected on the serial gateway (common scketch)

The scktech compile, but all the items on the Void Presentation doesn't work.
If I put this items on the void setup, it's work : my sensors are recognized by my controller via the gateway.

If a node that used to require signing is reconfigured to not support signing at all, it does not send a I_REQUEST_SIGNING to let the GW update the requirement table. Only by letting the node support signing but not require it and present it will the GW table be properly updated.

Steps to Replicate

• Upgrade the ESP8266 Arduino core to 2.0.0
• Attempt to compile the example Gateway ESP8266 MQTT Client Sketch.

What Happens

Compilation fails w/the error multiple definition of 'abort'

Current Work-Arounds

• Revert to the 1.6.5 version of the ESP8266 Arduino core
• Rename this function and subsequent calls.
  Note: I have not confirmed this actually functions correctly, only that it compiles.

Not sure this is a bug, but when I copy the libs and start my IDE, i get error/warnings about double inclusion. Removing the src directory fixes this.

Whitelisting should be supported by all nodes by default, but salting should only happen if a node has requested this as part of its signing requirement message. By including this in the signing requirement, a node has indicated that it will whitelist check incoming messages, so sender will need to salt the signature.

Hey guys,

at the moment i am working on an sensor node with an MRFC522 RFID reader beside the NRF24 on the SPI Bus.

With Version 1.5.1 it was possible to run code before the radio init function ( gw.begin(); )so that you could do something like this to stop the rfid reader on the SPI Bus so that there where no interferences on the bus with the NRF Module:

  pinMode(RST_PIN, OUTPUT);     
  digitalWrite(RST_PIN, LOW);
  pinMode(SS_PIN, OUTPUT);     
  digitalWrite(SS_PIN, LOW);
  gw.begin();

In Version 1.6 you run the setup() function after the radio init in your _beginn function so that above mentioned code comes to late and the radio init fails.

Is it possible that you could implement something like the loop or setup function that comes before? So that we can do such thing before?

I would implement this by myself but my CFu is not very good.

// Initialize library and handle sketch functions like we want to

int main(void) {
    init();
    #if defined(USBCON)
        USBDevice.init();
            USBDevice.attach();
    #endif
          if (preBegin) preBegin();  <------
    _begin(); // Startup MySensors library

    for(;;) {
        _process();  // Process incoming data
        if (loop) loop(); // Call sketch loop
        if (serialEventRun) serialEventRun();
    }
    return 0;
}

Regards

Florian

While testing my SMS Gateway node I bumped into a problem:

A normal node can send a message addressed to itself or to any node (repeater, gateway or any other node). A repeater node can pass on messages and send messages to any node (or gateway).

The problem:
When the option MY_REPEATER_FEATURE is set, sending the same message to itself (as a repeater) fails.

The working case:
e.g. My node has address 123
When sending without MY_REPEATER_FEATURE I see:

// sending the message to myself with a content which is again addressed to me
send: 123-123-0-0 s=1,c=1,t=47,pt=0,l=10,sg=0,st=ok:N123:alive
// here processing of the message happens and it is decided by my sketch to pass on the received message to node N123, message content was "N123:alive"
// passing on the stripped message to myself (since my node is nr 123). Message content is now "alive"
send: 123-123-0-123 s=1,c=1,t=47,pt=0,l=5,sg=0,st=ok:alive

When messages are received by this SMS Gateway node, in a format Nxyz:abcdef... It will pass on all text (abcdef...) after the colon to the node with address xyz. That is what we see above and is the basis for the SMS Gateway function of this node.

Now for the problematic case:
If I switch in the MY_REPEATER_FEATURE I get the following:

// sending the message to myself
send: 123-123-0-0 s=1,c=1,t=47,pt=0,l=10,sg=0,st=ok:N123:alive
// message is processed by the sketch and it is again decided to send the stripped message to '123'
// sending the stripped message to myself (being '123' AND being a repeater), this time it fails.
send: 123-123-123-123 s=1,c=1,t=47,pt=0,l=5,sg=0,st=fail:alive

The question is why this happens ? I think it should not fail. This has nothing to do with radio capacitors missing or not missing.

The messages are sent with the following code:
if (IsAddressingNode()) // check if sms is in Node addressing format
{
int NodeID = GetNodeID();

ifdef MY_DEBUG

        Serial.println();
        Serial.print("Message for node ");
        Serial.print(NodeID);
        Serial.print(" is treated: ");
        Serial.println(GetMessageContent(smsbuffer));
        Serial.println();

endif

// send a copy of the incoming message to the controller
SMSMsg.setDestination(GATEWAY_ID);
send(SMSMsg.set(smsbuffer));
// send the stripped message to the addressed node
SMSMsg.setDestination(NodeID);
SMSMsg.set(GetMessageContent(smsbuffer));
send(SMSMsg);

        strcpy(smsbuffer, "");
      }

If I comment MY_IP_ADDRESS in MQTT Client for using dhcp I get an error:

In file included from lib/MySensors/MySensor.h:137:0,
from src/main.cpp:124:
lib/MySensors/core/MyGatewayTransportMQTTClient.cpp:36:24: error: 'MY_IP_GATEWAY_ADDRESS' was not declared in this scope
IPAddress _gatewayIp(MY_IP_GATEWAY_ADDRESS);
^
lib/MySensors/core/MyGatewayTransportMQTTClient.cpp:37:23: error: 'MY_IP_SUBNET_ADDRESS' was not declared in this scope
IPAddress _subnetIp(MY_IP_SUBNET_ADDRESS);
^

I attach a patch in the gateway that fixes the error:

diff --git a/libraries/MySensors/core/MyGatewayTransportMQTTClient.cpp b/libraries/MySensors/core/MyGatewayTransportMQTTClient.cpp
index d43091f..9ba820d 100644
--- a/libraries/MySensors/core/MyGatewayTransportMQTTClient.cpp
+++ b/libraries/MySensors/core/MyGatewayTransportMQTTClient.cpp
@@ -32,8 +32,10 @@ IPAddress _brokerIp(MY_CONTROLLER_IP_ADDRESS);

 #if defined(MY_GATEWAY_ESP8266)
        #define EthernetClient WiFiClient
-       IPAddress _gatewayIp(MY_IP_GATEWAY_ADDRESS);
-       IPAddress _subnetIp(MY_IP_SUBNET_ADDRESS);
+       #if defined(MY_IP_ADDRESS)
+               IPAddress _gatewayIp(MY_IP_GATEWAY_ADDRESS);
+               IPAddress _subnetIp(MY_IP_SUBNET_ADDRESS);
+       #endif
 #else
        byte _clientMAC[] = { MY_MAC_ADDRESS };
 #endif

Hi,
I'm using a dev branch with "GatewayW5100MQTTClient example" and node with DHT11 sensor + relay.

OpenHAB <--> Mosquitto <--> MySensors Gateway (id=0) <--> DHT11 + relay node (id=9)

• Openhab + mosquitto = the same server
• Gateway = arduino UNO + W5100 + NRF24L01
• Node = arduino UNO + NRF24L01 + DHT11 + one relay

When I send a command from OpenHAB to node (id=9) this order is very very slow (5 to 10 seconds) to be executed in node id 9. But this "slow time" is randomly.

Example:
from openhab I send to MQTT server this order: mygateway1-in/9/1/1/0/2 1 (to activated the relay).
Sometimes it's fast, sometimes it's slow.
I traced MQTT protocol with tcpdump, I can see my arduino MQTT gateway doesn't answer fast. Mosquitto must resend the same mqtt message.
When was fast, mosquitto send MQTT message and MQTT gateway answer very quickly.

but when node send new data from DHT11, these data arrive quickly to OpenHAB.

to recap:

1. DHT11 --> node 9 --> MQTT Gateway --> Mosquitto --> Openhab = very fast
2. Openhab -(fast)-> Mosquitto -(slow)-> MQTT Gateway -(fast)-> node 9 -(fast)-> relay

Do you have an idea for this issue ?

thanks in advance

Messages with ACK-bit enabled bypass signing verification.

Last week I built a mysensors network, with just a serial gateway and a sensor node but since then I'm having an issue that I just can't figure out why it's happening:

Every few hours (randomly between 1 and 12hours), I lose communication between the node and the gateway. When this happens, I have to reset the sensor node and communications get back to normal.

I've soldered a capacitor directly on both nrf24l01+'s, between 3v3 an Gnd - this effectively improved communications but didn't solve the problem. I tried a separate 3v3 power supply on the sensor node just for nrf24l01. Also didn't help.

Can this be caused by software, like memory leaks on the sensor code? Recently I left a serial monitor open on the sensor node just to catch the moment. Here it is:

send: 1-1-0-0 s=13,c=1,t=0,pt=7,l=5,sg=0,st=ok:29.8
send: 1-1-0-0 s=11,c=1,t=1,pt=7,l=5,sg=0,st=ok:99.9
read: 0-0-1 s=14,c=2,t=2,pt=0,l=1,sg=0:1
send: 1-1-0-0 s=14,c=1,t=2,pt=2,l=2,sg=0,st=ok:1
read: 0-0-1 s=16,c=2,t=2,pt=0,l=1,sg=0:1
send: 1-1-0-0 s=16,c=1,t=2,pt=2,l=2,sg=0,st=ok:1
read: 0-0-1 s=15,c=1,t=2,pt=0,l=1,sg=0:0
send: 1-1-0-0 s=15,c=1,t=2,pt=0,l=1,sg=0,st=ok:0
send: 1-1-0-0 s=15,c=1,t=2,pt=2,l=2,sg=0,st=fail:0
send: 1-1-0-0 s=12,c=1,t=0,pt=7,l=5,sg=0,st=ok:18.3
send: 1-1-0-0 s=10,c=1,t=1,pt=7,l=5,sg=0,st=ok:62.1
send: 1-1-0-0 s=13,c=1,t=0,pt=7,l=5,sg=0,st=ok:29.8
send: 1-1-0-0 s=11,c=1,t=1,pt=7,l=5,sg=0,st=ok:99.9
read: 0-0-1 s=16,c=1,t=2,pt=0,l=1,sg=0:0
send: 1-1-0-0 s=16,c=1,t=2,pt=0,l=1,sg=0,st=ok:0
send: 1-1-0-0 s=16,c=1,t=2,pt=2,l=2,sg=0,st=ok:0
send: 1-1-0-0 s=12,c=1,t=0,pt=7,l=5,sg=0,st=fail:18.3
send: 1-1-0-0 s=10,c=1,t=1,pt=7,l=5,sg=0,st=fail:62.0
send: 1-1-0-0 s=13,c=1,t=0,pt=7,l=5,sg=0,st=fail:29.8
send: 1-1-0-0 s=11,c=1,t=1,pt=7,l=5,sg=0,st=fail:99.9
send: 1-1-0-0 s=12,c=1,t=0,pt=7,l=5,sg=0,st=fail:18.4
send: 1-1-0-0 s=10,c=1,t=1,pt=7,l=5,sg=0,st=fail:62.1  
(..) <-- *all the remaining lines have sends with st=fail and no more read events occur*

Any suggestions?

Nice to see the project has moved to github, this makes contributions a bit easier and transparent.

I'm Not sure why the choice is made to do development in a separate branch and have master as stable? In most projects its the other way around. If you google for git workflow, you should be able to find some additional information about it.

and this is puzzling...

people should be warned to use :
git clone https://github.com/mysensors/Arduino.git Arduino-MySensors -b master

Hello,

I can not create a sensor that use the arduino softserial library, it fails to compile because of "multiple definitions of ..."

NOTE: compiling this code using Arduino 1.06

// mysensors
#include <SPI.h>
#include <MySensor.h>

#include <SoftwareSerial.h>

MySensor gw;

SoftwareSerial softSerial( 4, 5 );

void setup() {
    softSerial.begin( 1200 );

    gw.begin();
    gw.sendSketchInfo( "softSerial Test Sensor", "0.1" );
}

void loop() {
}

Errors :

SoftwareSerial/SoftwareSerial.cpp.o: In function `__vector_3':
/Applications/Arduino.app/Contents/Resources/Java/libraries/SoftwareSerial/SoftwareSerial.cpp:305: multiple definition of `__vector_3'
MySensors/MyGateway.cpp.o:/Users/jc/Arduino/libraries/MySensors/utility/PinChangeInt.h:563: first defined here
SoftwareSerial/SoftwareSerial.cpp.o: In function `__vector_4':
/Applications/Arduino.app/Contents/Resources/Java/libraries/SoftwareSerial/SoftwareSerial.cpp:312: multiple definition of `__vector_4'
MySensors/MyGateway.cpp.o:/Users/jc/Arduino/libraries/MySensors/utility/PinChangeInt.h:573: first defined here
SoftwareSerial/SoftwareSerial.cpp.o: In function `__vector_5':
/Applications/Arduino.app/Contents/Resources/Java/libraries/SoftwareSerial/SoftwareSerial.cpp:319: multiple definition of `__vector_5'
MySensors/MyGateway.cpp.o:/Users/jc/Arduino/libraries/MySensors/utility/PinChangeInt.h:583: first defined here

I could patch the MySensors/utility/PinChangeInt.h to correct the thing but i'm afraid to break something elsewhere, is there somebody that would have a viable solution/patch to propose about that ?

thanks

Hi,

Line 367 you have var payload = new Date().getTime();
getTime is reported to be in ms, not in s.
The serial API describe Time as send in s.

Is this a bug in the nodejs or in the API page description ?

This has been reported by a Jeedom user, and as I'm using a fork of this controller, I will like to first report it and have your advice.

Thanks,

Cédric

A node should count the number of subsequent failed signature verifications and when reaching a configured limit, send a message to gw/controller that a brute force attack is being attempted. It should then write a byte to eeprom and reboot. At boot up signing backend checks this byte during early init and decides if full startup is to be permitted else lock down by sleeping/rebooting. Possibly resending a warning to gw/controller. To recover, node needs to be reprogrammed to reset the eeprom setting.

The fix for the long term, is radio abstraction...

ie: radio = rfm69c, or radio = rfm69w, or radio = rfm69hw, or radio = nRF24 or radio = xyz
This should allow using the RadioHead lib in the future... ie: any radio...

with some layer of abstraction for radio options like the ones below...

radio.set_freq= 912650000 ( this could imply the band also)
radio.set_band= 915MHZ
radio.set_channel = 72

#define MY_RFM69HW true
#define MY_RFM69_FREQUENCY RF69_915MHZ
#define RFM69_FREQUENCY 912650000
#define RFM69_NETWORKID 120
#define RF69_SPI_CS 10
#define RF69_IRQ_PIN 2
#define RF69_IRQ_NUM 0

all items like this should be abstracted to the radio level...

for now, it would be nice to have a guide for using each type of radio, with documentation on all known options...

(By the way, MY_RFM69_FREQUENCY should be MY_RFM69_BAND, as it selects the freq band the radio is in, not its (exact) frequency)

Thanks... my two bits...

for example:

1. sketch reads with getInt a value 10 sent from Server
2. temperature sensor sends a value 47.28 to the server
3. sketch reads with getInt a value 1028 (10 was sent from Server)

OR

1. sketch reads with getFloat a value 0 or -20.20 sent from Server
2. temperature sensor sends a value 1.28 to the server
3. sketch reads with getFloat a value 1.28(0 was sent from Server)
   check here:

0;255;3;0;9;Message arrived on topic: DOino<>MQTT/0/13/1/0/3
13
-20.20
0;255;3;0;9;Sending message on topic: DOino<>MQTT/0/58/1/0/0
0;255;3;0;9;Message arrived on topic: DOino<>MQTT/0/58/1/0/0
0;255;3;0;9;Message arrived on topic: DOino<>MQTT/0/13/1/0/3
im pwm
13
1.28
0;255;3;0;9;Message arrived on topic: DOino<>MQTT/0/13/1/0/3
13
-20.20

OR

1. sketch reads with getFloat a value 0 or -20.20 sent from Server
2. sketch reads with getFloat a value 20.20(0 was sent from Server)
   check here:

13
-20.20
0;255;3;0;9;Message arrived on topic: DOino<>MQTT/0/13/1/0/3
13
20.20
0;255;3;0;9;Sending message on topic: DOino<>MQTT/0/58/1/0/0
0;255;3;0;9;Message arrived on topic: DOino<>MQTT/0/58/1/0/0
0;255;3;0;9;Message arrived on topic: DOino<>MQTT/0/13/1/0/3
13
-20.20
0;255;3;0;9;Message arrived on topic: DOino<>MQTT/0/13/1/0/3
13
20.20
0;255;3;0;9;Message arrived on topic: DOino<>MQTT/0/13/1/0/3
13
-20.20

could you please check! can send you my sketch if you like!

To provide the ability to do hash calculations on generic data this api can be used (sw or hw accelerated)

I've just got a few questions about the included libraries.

Wouldn't it be much more useful for everyone using MySensors if the libraries would be cloned if necessary from the originals. The thing I'm trying to say is would it be possible that you'd report bugs/improve the original libraries and then clone them to MySensors. That way the original library is developed by more people, more bugs get fixed and features added. It would benefit the end users a lot more.

I'm mainly speaking about RF24. But there's also signing system. Wouldn't it be more beneficial if the core part of the signing system would be separately (from the MySensors) and published on github for example. That way more people could check and improve the system.

These are just my thoughts I wanted to share. What do you think?

We should move the user/local config are to end end of EEPROM so we safely can add new internal configurations without affecting/shifting the local config.

The code below will NOT override the pins defined in RFM69.h
I'm testing in ESP8266MQTTClient

I have tried prior and after #include <MySensor.h>

Only works if I make changes in RFM69.h file

we need to be able to change pin numbers in application code.

testing with 2.0 beta code, Jan 19, 2016

// If using OSH board
#define RF69_SPI_CS  2     // D2
#define RF69_IRQ_PIN 15    // D8

#include <ESP8266WiFi.h>
#include <MySensor.h>

// If using OSH board
#define RF69_SPI_CS  2     // D2
#define RF69_IRQ_PIN 15    // D8

I just flashed the MYSBootloader to nearly all of my nodes.

I've had great success w/the OTA firmware upload except on the handful of nodes that have signing enabled via #define MY_SIGNING_REQUEST_SIGNATURES. I can confirm the same node, same firmware (minus #define MY_SIGNING_REQUEST_SIGNATURES) works … until a firmware with signing enabled is uploaded.

With #define MY_SIGNING_REQUEST_SIGNATURES enabled, this is what the node startup looks like on the Gateway. Notice the nonce timeouts at the bottom.

0;0;3;0;9;read and forward: 10-10-255 s=255,c=3,t=7,pt=0,l=0,sg=0
0;0;3;0;9;send: 0-0-10-10 s=255,c=3,t=8,pt=1,l=1,sg=0,st=ok:0
0;0;3;0;9;read: 10-10-0 s=255,c=4,t=0,pt=6,l=10,sg=0:0500010010036A540101
0;0;3;0;9;Sending message on topic: mysensors_rx/10/255/4/0/0
0;0;3;0;9;Message arrived on topic: mysensors_tx/10/255/4/0/1
0;0;3;0;9;send: 0-0-10-10 s=255,c=3,t=16,pt=0,l=0,sg=0,st=ok:
0;0;3;0;9;read: 10-10-0 s=255,c=4,t=0,pt=6,l=10,sg=0:0500010010036A540101
0;0;3;0;9;Sending message on topic: mysensors_rx/10/255/4/0/0
0;0;3;0;9;Message arrived on topic: mysensors_tx/10/255/4/0/1
0;0;3;0;9;send: 0-0-10-10 s=255,c=3,t=16,pt=0,l=0,sg=0,st=ok:
0;0;3;0;9;read: 10-10-0 s=255,c=4,t=0,pt=6,l=10,sg=0:0500010010036A540101
0;0;3;0;9;Sending message on topic: mysensors_rx/10/255/4/0/0
0;0;3;0;9;Message arrived on topic: mysensors_tx/10/255/4/0/1
0;0;3;0;9;send: 0-0-10-10 s=255,c=3,t=16,pt=0,l=0,sg=0,st=ok:
0;0;3;0;9;read: 10-10-0 s=255,c=4,t=0,pt=6,l=10,sg=0:0500010010036A540101
0;0;3;0;9;Sending message on topic: mysensors_rx/10/255/4/0/0
0;0;3;0;9;Message arrived on topic: mysensors_tx/10/255/4/0/1
0;0;3;0;9;send: 0-0-10-10 s=255,c=3,t=16,pt=0,l=0,sg=0,st=ok:
0;0;3;0;9;read: 10-10-0 s=255,c=4,t=0,pt=6,l=10,sg=0:0500010010036A540101
0;0;3;0;9;Sending message on topic: mysensors_rx/10/255/4/0/0
0;0;3;0;9;Message arrived on topic: mysensors_tx/10/255/4/0/1
0;0;3;0;9;send: 0-0-10-10 s=255,c=3,t=16,pt=0,l=0,sg=0,st=ok:
0;0;3;0;9;read: 10-10-0 s=255,c=3,t=15,pt=2,l=2,sg=0:1
0;0;3;0;9;send: 0-0-10-10 s=255,c=3,t=15,pt=4,l=4,sg=0,st=ok:0
0;0;3;0;9;read: 10-10-0 s=255,c=0,t=17,pt=0,l=10,sg=0:1.6.0-beta
0;0;3;0;9;Sending message on topic: mysensors_rx/10/255/0/0/17
0;0;3;0;9;read: 10-10-0 s=255,c=3,t=6,pt=1,l=1,sg=0:0
0;0;3;0;9;Sending message on topic: mysensors_rx/10/255/3/0/6
0;0;3;0;9;Message arrived on topic: mysensors_tx/10/255/3/0/6
0;0;3;0;9;send: 0-0-10-10 s=255,c=3,t=16,pt=0,l=0,sg=0,st=ok:
0;0;3;0;9;read: 10-10-0 s=255,c=3,t=17,pt=6,l=25,sg=0:0149901E44791163512E42160B844B615405D2CAE928D4029
0;0;3;0;9;Signing backend: ATSHA204Soft
0;0;3;0;9;Message to process: 000A0E0306FF49
0;0;3;0;9;Current nonce: 0149901E44791163512E42160B844B615405D2CAE928D402A9AAAAAAAAAAAAAA
0;0;3;0;9;HMAC: A64E8650FE3345FA13FE4BC4084DBB134A3993346AE8D9A9B6A1FE9C25172AA7
0;0;3;0;9;Signature in message: 014E8650FE3345FA13FE4BC4084DBB134A3993346AE8D9A9
0;0;3;0;9;send: 0-0-10-10 s=255,c=3,t=6,pt=0,l=1,sg=1,st=ok:I
0;0;3;0;9;send: 0-0-10-10 s=255,c=3,t=6,pt=0,l=1,sg=1,st=ok:I
0;0;3;0;9;nonce tmo
0;0;3;0;9;nonce tmo
0;0;3;0;9;nonce too
0;0;3;0;9;nonce tmo

There is now new switch type(SELECTOR) presented in Domoticz. With that its now possible to handle with V_HVAC enum switches.

Functionality for presenting sensors capabilities would help the contoller software to build automatically hvac switches for example.

For example:

• gw.presentcaps(childId, listOfValues) (user could define names for these in the controller)
• or even better: gw.presentcaps(childId, listOfKeys) (in this case values would be from 0 to count of list but names are provided automatically)
• or the best: gw.presentcaps(childId, listOfValues, listOfKeys). The contoller could buid up the switch from this info.
  One design question: Would this be called after or would it be alternative for gw.present(...)?

Keys would be used in UI of contoller and values(list of 8 bit int?) are what is transferred in messages.

For example my air source heat pump has only V_HVAC_MODE modes "Off", "HeatOn", "CoolOn". Values for these could be 0, 1 and 2.

Discussion about this on mysensors forum

Hi,

looking at the function MyGateway::setInclusionMode I am wondering if there a missing braces. At least the current ident suggests an intended implementation of:

void MyGateway::setInclusionMode(boolean newMode) {
  if (newMode != inclusionMode) {
    inclusionMode = newMode;
    // Send back mode change on serial line to ack command
    serial(PSTR("0;0;%d;0;%d;%d\n"), C_INTERNAL, I_INCLUSION_MODE, inclusionMode?1:0);

    if (inclusionMode) {
      inclusionStartTime = millis();
    }
  }
}

MyMessage, used for message data transfer, is defined as follows:

    union {
        uint8_t bValue;
        unsigned long ulValue;
        long lValue;
        unsigned int uiValue;
        int iValue;
        struct { // Float messages
            float fValue;
            uint8_t fPrecision;   // Number of decimals when serializing
        };
        struct {  // Presentation messages
            uint8_t version;      // Library version
            uint8_t sensorType;   // Sensor type hint for controller, see table above
        };
        char data[MAX_PAYLOAD + 1];
    } __attribute__((packed));

The (unsigned) int types are non-portable when going from 8 bit AVR architecture to 32 bit (e.g. ESP8266, Cortex-M), which is a problem when architectures are mixed within a network.
On AVR an (unsigned) int is 16bits, on ESP it is 32 bits.
On AVR a double is 32bits (equal to float), on ESP it is 64 bits.

This probably lead to a problem described in the forum: http://forum.mysensors.org/topic/2118/esp8266-wifi-gateway-issue

For portability use uint16_t and int16_t for ints.
For consistency also use uint32_t and int32_t for longs, uint8_t and int8_t for chars.

Background

Following simple sketch can be run on different targets to identify the sizes of their datatypes:

#define SIZEOF(x) \
  Serial.print("sizeof(" #x ")="); Serial.println(sizeof(x));

void setup() {
  Serial.begin(115200);
  SIZEOF(char);
  SIZEOF(int);
  SIZEOF(short);
  SIZEOF(long);
  SIZEOF(float);
  SIZEOF(double);
  SIZEOF(uint8_t);
  SIZEOF(uint16_t);
  SIZEOF(uint32_t);
}

void loop() {
}

Output on ATMega328 (8bit)

sizeof(char)=1
sizeof(int)=2
sizeof(short)=2
sizeof(long)=4
sizeof(float)=4
sizeof(double)=4
sizeof(uint8_t)=1
sizeof(uint16_t)=2
sizeof(uint32_t)=4

Output on ESP8266 (32bit)

sizeof(char)=1
sizeof(int)=4            <-- Problematic
sizeof(short)=2
sizeof(long)=4
sizeof(float)=4
sizeof(double)=8         <-- Problematic, but not used in MyMessage
sizeof(uint8_t)=1
sizeof(uint16_t)=2
sizeof(uint32_t)=4

Signing logic is scattered throughout the MySensors library. It should be centralized in the existing signing related files to simplify maintenance and troubleshooting.

As per subject.

http://forum.mysensors.org/topic/2835/mysensors-esp8266-gw-with-relay-presentation-relay-not-working-why/2

Just pulled the master branch to migrate from 1.4 to 1.5. but it's not compiling
Error:
C:\Users\msamy\Documents\Arduino\libraries\MySensors\MyHwATMega328.cpp: In function 'void powerDown(period_t)':
C:\Users\msamy\Documents\Arduino\libraries\MySensors\MyHwATMega328.cpp:99: error: 'sleep_bod_disable' was not declared in this scope

Hek - I've got this going on some of my stuff and it seems to be working OK. Keep up the good work.

I'm embarrassed to say still don't understand how to use Git. Do I have to fork the whole project to submit a patch? Seems like overkill.

MySensor::sendBatteryLevel wants an uint8_t Would an int make more sense? Anyway couldn't get sendBatteryLevel to work - so discovered the following:

functions at MyMessage.cpp lines 200 and 207 have a mix up: P_INT16 and P_UINT16 are swapped.

Then in MyMessage::getString(char *buffer) in the case statements, the various conversion to ASCII calls appear to be called incorrectly and some call the incorrect function as well - looks like a cut & paste problem!!.

char * ltoa (long int __val, char *__s, int __radix)
char * utoa (unsigned int __val, char *__s, int __radix)
char * ultoa (unsigned long int __val, char *__s, int __radix)

Apparently case statements are hard on memory. Not sure on the truth of this or if it matters. If then else/elseif may be preferable.

In EthernetGateway.ino on line 86 need to replace Gateway with MyGateway.

I've seen EEPROM used by this library quite a bit. But would't a SD Card be a better idea, allowing more data to be stored, that data could be also modified by the PC and some things like atsha could be configured more securely by generating more random hmac for example.

Should be the same for all OTA solutions (MYSbootloader, dualoptiboot, etc).
I propose the checksum is sent in four packages. Each with a 8-byte portion of the 32-byte checksum, so that a 16-byte signature can be added.

Ethernet Gateway (also MQTT) and RFM69.c code need to be upgraded to support softSPI for this radio

Thanks

Please consider adding: S_PRESSURE, this could be used for water pressure, air pressure (like in a compressor tank) or ??

Current S_BARO imply Barometric pressure, not absolute or reference pressure like from a gauge...
One could #define S_PRESSURE S_BARO, but this is confusing..
and S_PRESSURE is generic, S_BARO is specific

my two bits...

I just tried to compile a GatewaySerial (https://github.com/mysensors/Arduino/blob/development/libraries/MySensors/examples/GatewaySerial/GatewaySerial.ino) with MY_WITH_LEDS_BLINKING_INVERSE enabled. It compiles but the Gateway can't receive any data, uncommenting this line and recompiling solve this issues. So it must be this function.
Thank you.

Something like MY_DEBUG_VERBOSE_SIGNING

Instead of the portxxxRegister functions, pinMode/digitalWrite/digitalRead could probably be used to add better hw abstraction to the driver and make it less architecture specific.

in https://github.com/mysensors/Arduino/blob/development/libraries/MySensors/core/MyProtocolMySensors.cpp#L94

should be checked if value is not null, because in the case of a message without payload (such as internal) it will not go to "case 5: // Variable value" and value will remain NULL (char *str, *p, *value=NULL;)

Thanks

in RFM69.h

You may want to put a #elif defined for ESP8266 at end ->> #elif defined(ARDUINO_ARCH_ESP8266)
with the else being a processor not define message...

// INT0 on AVRs should be connected to RFM69's DIO0 (ex on ATmega328 it's D2, on ATmega644/1284 it's D2)

if defined(AVR_ATmega168) || defined(AVR_ATmega328P) || defined(AVR_ATmega88) || defined(__AVR_ATmega8) || defined(AVR_ATmega88)

#define RF69_IRQ_PIN 2
#define RF69_IRQ_NUM 0

elif defined(AVR_ATmega644P) || defined(AVR_ATmega1284P) || defined(AVR_ATmega2560)

#define RF69_IRQ_PIN 2
#define RF69_IRQ_NUM 2

elif defined(AVR_ATmega32U4)

#define RF69_IRQ_PIN 3
#define RF69_IRQ_NUM 0

else

// ESP8266 should fall into this category now
// TODO !! Untested code! Entering unknown territory...
#define RF69_IRQ_PIN 2
#define RF69_IRQ_NUM 0

endif

I'm running ver 1.6 from 19 Jan 2016 version with a RFM69 radio, all work well for a few hours, then it appears that the gateway stops communication with the broker, looks like the MQTT task and the WiFi task are no longer communication. Re starting the GW code fixes the issue...

I can still PING the gateway, so the WiFi stack is running......

From debug port...

0;255;3;0;9;Attempting MQTT connection...
0;255;3;0;9;Attempting MQTT connection...
0;255;3;0;9;read: 1-1-0 s=1,c=2,t=24,pt=0,l=0,sg=0:
0;255;3;0;9;Attempting MQTT connection...
0;255;3;0;9;Attempting MQTT connection...
0;255;3;0;9;read: 1-1-0 s=1,c=2,t=24,pt=0,l=0,sg=0:
0;255;3;0;9;Attempting MQTT connection...
0;255;3;0;9;Attempting MQTT connection...

I've done some more testing, It stop working in 3 to 4 hours, very consistent over the last 24 hrs. I have changes ESP8266, same issue, ESP library code is ver 2.0.. 1.6.7 and 1.6.5r5 IDE

It also appears that the code may not be trying to close, reopen the WiFi connection when there is a network error... <--- this should be implemented

Issue 2:
Also, I noted that the ESP8266 WiFi stack is still acting as an access point. Is there a way to turn off just the access point??

Signing identifier serves no practical benefit in nonces. It just adds complexity.

This is happening when one of my nodes sends a message with a bad precision value (because of some magnetic noise from the sensor) causing a buffer overflow on the gateway.
This is the output from the gateway (RaspberryPi):

Debug: read: 4-3-0 s=1,c=1,t=0,pt=7,l=5,sg=0:48.6250000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Debug: send: 0-0-3-4 s=1,c=1,t=0,pt=7,l=5,sg=0,st=ok:48.6250000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

This is the rough fix I'm using, but we should probably use a better checking for this:
marceloaqno@710a094

After one week working beautifully my Arduino running GatewayW5100MQTT_client.ino stopped working.

Programme starts, connects to network, attempts to connect to the MQTT server and displays error
0;0;3;0;9;Attempting MQTT connection...
Other clients can connect without issue. Resetting / Reflashing the arduino doesn't solve the issue.

Hi,

i am using the latest Dev Version of libraries:

if i just take the Example "Gatewayw5100" no changes:

D:\03_Daten\07_Arduino\01_Projekte\libraries\MySensors\examples\GatewayW5100\GatewayW5100.ino:113:22: fatal error: Ethernet.h: No such file or directory

 #include <Ethernet.h>

compilation terminated.

even it is an Ethernet library in D:\03_Daten\07_Arduino\ORIGArduino\hardware\MySensors\samd\libraries\Ethernet\src as included in ZIP file!

if i copy the library from HARDWARE folder to original Library folder, i get this error:

D:\03_Daten\07_Arduino\01_Projekte\libraries\Ethernet\src\Ethernet.cpp: In member function 'int EthernetClass::begin(uint8_t*, long unsigned int, long unsigned int)':

D:\03_Daten\07_Arduino\01_Projekte\libraries\Ethernet\src\Ethernet.cpp:19:3: error: 'SPI_ETH' was not declared in this scope

   SPI_ETH.beginTransaction(SPI_ETHERNET_SETTINGS);

   ^

D:\03_Daten\07_Arduino\01_Projekte\libraries\Ethernet\src\Ethernet.cpp: In member function 'void EthernetClass::begin(uint8_t*, IPAddress, IPAddress, IPAddress, IPAddress)':

D:\03_Daten\07_Arduino\01_Projekte\libraries\Ethernet\src\Ethernet.cpp:68:3: error: 'SPI_ETH' was not declared in this scope

   SPI_ETH.beginTransaction(SPI_ETHERNET_SETTINGS);

   ^

D:\03_Daten\07_Arduino\01_Projekte\libraries\Ethernet\src\Ethernet.cpp: In member function 'int EthernetClass::maintain()':

D:\03_Daten\07_Arduino\01_Projekte\libraries\Ethernet\src\Ethernet.cpp:89:9: error: 'SPI_ETH' was not declared in this scope

         SPI_ETH.beginTransaction(SPI_ETHERNET_SETTINGS);

         ^

D:\03_Daten\07_Arduino\01_Projekte\libraries\Ethernet\src\Ethernet.cpp: In member function 'IPAddress EthernetClass::localIP()':

D:\03_Daten\07_Arduino\01_Projekte\libraries\Ethernet\src\Ethernet.cpp:107:3: error: 'SPI_ETH' was not declared in this scope

   SPI_ETH.beginTransaction(SPI_ETHERNET_SETTINGS);

   ^

D:\03_Daten\07_Arduino\01_Projekte\libraries\Ethernet\src\Ethernet.cpp: In member function 'IPAddress EthernetClass::subnetMask()':

D:\03_Daten\07_Arduino\01_Projekte\libraries\Ethernet\src\Ethernet.cpp:116:3: error: 'SPI_ETH' was not declared in this scope

   SPI_ETH.beginTransaction(SPI_ETHERNET_SETTINGS);

   ^

D:\03_Daten\07_Arduino\01_Projekte\libraries\Ethernet\src\Ethernet.cpp: In member function 'IPAddress EthernetClass::gatewayIP()':

D:\03_Daten\07_Arduino\01_Projekte\libraries\Ethernet\src\Ethernet.cpp:125:3: error: 'SPI_ETH' was not declared in this scope

   SPI_ETH.beginTransaction(SPI_ETHERNET_SETTINGS);

   ^

if i renew the Ethernet library with the one from Arduino github (1.0.5)

i can compile!!!! NO Errors!

but i want to use UDP to send messages to my controler!
so i TURN ON

// Enable to UDP          
#define MY_USE_UDP

and try to compile , i get this ERROR report:

In file included from D:\03_Daten\07_Arduino\01_Projekte\libraries\MySensors/MySensor.h:221:0,

                 from D:\TEMP\arduino_a6199089dc15f417b80dd389b859fb7d\GatewayW5100.ino:114:

D:\03_Daten\07_Arduino\01_Projekte\libraries\MySensors/core/MyGatewayTransportEthernet.cpp: In function 'bool gatewayTransportAvailable()':

D:\03_Daten\07_Arduino\01_Projekte\libraries\MySensors/core/MyGatewayTransportEthernet.cpp:263:36: error: no match for 'operator[]' (operand types are 'inputBuffer' and 'int')

    _ethernetServer.read(inputString[0].string, MY_GATEWAY_MAX_RECEIVE_LENGTH);

                                    ^

In file included from D:\03_Daten\07_Arduino\01_Projekte\libraries\MySensors/MySensor.h:28:0,

                 from D:\TEMP\arduino_a6199089dc15f417b80dd389b859fb7d\GatewayW5100.ino:114:

D:\03_Daten\07_Arduino\01_Projekte\libraries\MySensors/core/MyGatewayTransportEthernet.cpp:265:56: error: no match for 'operator[]' (operand types are 'inputBuffer' and 'int')

    debug(PSTR("UDP packet received: %s\n"), inputString[0].string);

                                                        ^

D:\03_Daten\07_Arduino\01_Projekte\libraries\MySensors/core/MySensorCore.h:36:40: note: in definition of macro 'debug'

 #define debug(x,...) hwDebugPrint(x, ##__VA_ARGS__)

                                        ^

In file included from D:\03_Daten\07_Arduino\01_Projekte\libraries\MySensors/MySensor.h:221:0,

                 from D:\TEMP\arduino_a6199089dc15f417b80dd389b859fb7d\GatewayW5100.ino:114:

D:\03_Daten\07_Arduino\01_Projekte\libraries\MySensors/core/MyGatewayTransportEthernet.cpp:266:50: error: no match for 'operator[]' (operand types are 'inputBuffer' and 'int')

    return protocolParse(_ethernetMsg, inputString[0].string);

In MyConfig.h

Should the #ifdef, be a #ifndev ??

// Enable this if you're running the RFM69HW model

ifdef MY_IS_RFM69HW

#define MY_RFM69HW true

else

#define MY_RFM69HW false

// Set this to true if you're running the RFM69HW model

ifndef MY_IS_RFM69HW

#define MY_RFM69HW false

endif

In the latest version (3.7.5) of the DallasTemperature library millisToWaitForConversion() has changed from a public to a private function, so if you update to the latest version, the sketch won't compile

You need to find another way to check if conversion is one

Offending lines are:

int16_t conversionTime = sensors.millisToWaitForConversion(sensors.getResolution());
sleep(conversionTime);

Simply calling setWaitForConversion(1) instead might fix the problem (at least it builds!) - as I understand, the temperature reading will block until conversion is done, when this is set. I don't have any hardware available right now to test