MySensors 1.4 Released

hek

###1.4 update 1 released

NOTE: This release does not require you to update all nodes . Nothing has changed in protocols.

All outgoing messages from gateway included a newline character. This has now been fixed.
The msg.getByte() wrongfully used atoi() conversion if payload was of string type.
The getByte-bug caused problems when receiving Metric/Imperial settings from controller.
A new sleep-method added to allow wake-up on both external interrupts.
A new example BinarySwitchSleepSensor showing the new sleep function (thanks @Anticimex).
Library code (RF24) reduced by 624 bytes (thanks @Damme)
Many people has reported powering problems when using amplified version of the NRF-chip on their gateway. The Arduino Nanos 3v3 output does not seem to be sufficient for PA_MAX. The radio needs to be feeded separately with a stable 3v3 to work. Defaulting gateway PA-level to LOW now and if you are using a vanilla radio on gateway you can switch back to MAX in your MyConfig.h.

epierre

This post is deleted!

mikeones

@hek I am having an issue assigning a node ID since the last update. I have cleared the eprom in one of my nodes and I am trying to assign a node id of 1 via the serial monitor on the GW. I am sending "255;255;3;0;4;1" in response to the node ID request of "255;255;3;0;3;".

This is the console log from the node with debug enabled.

send: 255-255-255-255 s=255,c=3,t=7,pt=0,l=0,st=fail:
read: 0-0-255 s=255,c=3,t=8,pt=1,l=1:0
new parent=0, d=1
req node id
send: 255-255-0-0 s=255,c=3,t=3,pt=0,l=0,st=ok:
read: 0-0-255 s=255,c=3,t=4,pt=0,l=1:1
id=49
sensor started, id 49
send: 49-49-0-0 s=255,c=0,t=17,pt=0,l=3,st=ok:1.4
send: 49-49-0-0 s=255,c=3,t=6,pt=1,l=1,st=ok:0

Here is the console log from the GW.

0;0;3;0;14;Gateway startup complete.
255;255;3;0;3;
49;255;0;0;17;1.4
49;255;3;0;6;0

What I don't understand is why the node would get assigned ID "49" when I sent "1" as the new node ID. Should the node get an ID of "1" or "49" for the command below?

255;255;3;0;4;1

hek

@mikeones

Darn, yes, you are so right. The getByte fix affected the node-id functionality. Please update again (MySensor.cpp) and report back.

mikeones

@hek After updating, I have tested this via the serial monitor and it seems ok.

send: 255-255-0-0 s=255,c=3,t=3,pt=0,l=0,st=fail:
read: 0-0-255 s=255,c=3,t=4,pt=0,l=1:1
id=1

When I send this string via a (ago) controller, the node sets an id of 0 again. Do you see any issue with this string format?

255;255;3;0;4;1

Serial monitor output. Does "l=0:" indicate there was an issue with the payload?

send: 255-255-255-0 s=255,c=3,t=3,pt=0,l=0,st=fail:
read: 0-0-255 s=255,c=3,t=4,pt=0,l=0:
id=0

hek

@mikeones

Hmm. I wonder which control characters Argcontrol sends ( \n and/or \r ). It could be that Vera sends both. I'll have to check when I get home.

mikeones

@hek

It appears sending "255;255;3;0;4;1\r\n" fixes my issue.

send: 255-255-255-0 s=255,c=3,t=3,pt=0,l=0,st=fail:
read: 0-0-255 s=255,c=3,t=4,pt=0,l=1:1
id=1
sensor started, id 1

hek

@mikeones

Ok thanks. I will make this more robust. It should be ok to skip the carriage return character.

mikeones

What does st=fail represent? Is that stating the ack failed or sending failed? Would this error show up for all messages if debug is enabled on the sensor node and not the gateway.? Maybe this is a non issue? I am trying to confirm if gw.getConfig and gw.requestTime requests are reaching the GW since they don't seem to be set consistently in my environment.

sensor started, id 3
send: 3-3-0-0 s=255,c=0,t=17,pt=0,l=3,st=fail:1.4
send: 3-3-0-0 s=255,c=3,t=6,pt=1,l=1,st=fail:0
send: 3-3-0-0 s=255,c=3,t=11,pt=0,l=8,st=ok:Humidity
send: 3-3-0-0 s=255,c=3,t=12,pt=0,l=3,st=ok:1.0
send: 3-3-0-0 s=0,c=0,t=7,pt=0,l=3,st=fail:1.4
send: 3-3-0-0 s=1,c=0,t=6,pt=0,l=3,st=fail:1.4
send: 3-3-0-0 s=1,c=1,t=0,pt=7,l=5,st=fail:25.8
T: 25.80
send: 3-3-0-0 s=0,c=1,t=1,pt=7,l=5,st=fail:50.4
H: 50.40
send: 3-3-0-0 s=1,c=1,t=0,pt=7,l=5,st=fail:25.8
T: 25.80
send: 3-3-0-0 s=0,c=1,t=1,pt=7,l=5,st=fail:50.4
H: 50.40

RJ_Make

@hek said:> ###1.4 update 1 released

NOTE: This release does not require you to update all nodes . Nothing has changed in protocols.

All outgoing messages from gateway included a newline character. This has now been fixed.

The msg.getByte() wrongfully used atoi() conversion if payload was of string type.

The getByte-bug caused problems when receiving Metric/Imperial settings from controller.

A new sleep-method added to allow wake-up on both external interrupts.

A new example BinarySwitchSleepSensor showing the new sleep function (thanks @Anticimex).

Library code (RF24) reduced by 624 bytes (thanks @Damme)

Many people has reported powering problems when using amplified version of the NRF-chip on their gateway. The Arduino Nanos 3v3 output does not seem to be sufficient for PA_MAX. The radio needs to be feeded separately with a stable 3v3 to work. Defaulting gateway PA-level to LOW now and if you are using a vanilla radio on gateway you can switch back to MAX in your MyConfig.h.

Was this release supposed to fix the C to F conversion problem I've been having? I just updated and problem persists for me.

hek

@ServiceXp
Think I found the config problem. No wonder it didn't work. Please download and try again.

@mikeones
You should now be able to omit carriage return now.
The fail you're seeing is for the inter-node-ack.
Just verified requesting time from controller and it seems to work fine here (using the example sketch).

Yveaux

@hek When MySensors has no parent, or fails to contact parent for a number of times, the findParentNode() method is entered.
This sends a broadcast (ignoring the result) and then waits at most 2 seconds for a response.
When this response doesn't come, the sensor just carries on as if the parent has been found, sending messages until again a number of times it failed to contact the parent.

Shouldn't findParentNode() either block until the parent has been found (maybe not desirable for battery based nodes) or only reset the failedTransmissions counter when a succesful response from the parent has been received?

hek

@Yveaux said:

Shouldn't findParentNode() either block until the parent has been found (maybe not desirable for battery based nodes) or only reset the failedTransmissions counter when a succesful response from the parent has been received?

Blocking is as you say a bad idea for battery sensors (1.3 had this problem resulting in drained batteries).

How would it help to reset failedTransmissions?

hek

@Yveaux

BTW. Do you have any idea why this happens?

http://forum.mysensors.org/topic/347/1-4-error-compiling-with-pinchangeint-h-library-file/5

I can't explain why linker includes things from MyGateway.cpp when compiling sensor examples.

Yveaux

@hek said:

How would it help to reset failedTransmissions?

Just thinking out aloud:

Don't reset failedTransmissions in findParentNode()
Reset failedTransmissions only when a new parent has been found
In sendRoute() first perform findParentNode() when failedTransmissions > SEARCH_FAILURES
When succesful (failedTransmissions == 0) perform sendWrite()

This will always first try to find a parent when none has been found yet, before trying to send the message.
If it fails, the send of the message will fail and the (battery powered) sensor will just carry on as if the message has been send, and sleep the sensor as usual.
Just sending to a known-bad parent node should be avoided at all times.

hek

@Yveaux

Sounds good. Go for it!

Yveaux

@hek ;-)

Yveaux

@hek said:

I can't explain why linker includes things from MyGateway.cpp when compiling sensor examples.

Compiler & linker seem to be configured correctly in 1.5.7 (see hardware\arduino\avr\patform.txt)
Did you have a look at the map-file? What exactly is included from the MyGateway.cpp file?

Yveaux

@hek I'm also a bit puzzled by the RF24::enableAckPayload() and RF24::writeAckPayload() calls in the library, just like @Zeph .
If I disable them the findParentNode() call only seems to emit a single message (which I can understand, as auto-ack is disabled for broadcasts), while 16 will be emit when the calls are enabled.
Looks like auto-ack doesn't get disabled for broadcasts in this case.

A sending nRF24 will immediately & automatically **switch to listen to the destination node's ID **after it has sent its message. Reason for this is that the nRF24 packet format only contains a destination node address and no source. The receiving node has no idea where the message came from and does not know who to send the ack to. Therefore it just sends the ack to its own node address, which the transmitting node happens to listen to.

I tested only with a single sensor sending to a non-existent parent, but I can imagine that when auto-acks are enabled for broadcasts the s**t will definately hit the fan when there are many nodes within close proximity!

hek

@Yveaux

Ok, I'll download 1.5.7 and test again. Can't find any map-file anywhere in the build directory.

MySensors 1.4 Released

7

11.7k

11.2k

113.1k