MySensors 1.4 Released
-
@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 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? -
Ok, I'll download 1.5.7 and test again. Can't find any map-file anywhere in the build directory.
-
@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!
@Yveaux said:
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.Ok, 16! Hmm..not good.
Could you perhaps do some more verifications with removed ackPayload/writeAckPayload while sniffing to see that everything works as expected with the whole findParent?
Would be a nice addition to get this removed while you refactor findParent. -
@Yveaux said:
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.Ok, 16! Hmm..not good.
Could you perhaps do some more verifications with removed ackPayload/writeAckPayload while sniffing to see that everything works as expected with the whole findParent?
Would be a nice addition to get this removed while you refactor findParent. -
@Yveaux said:
Everything is Radiohead now
:O
You sniffing is really helpful finding bugs and quirks in the radios bwt!
-
@hek yeah I know. I can't think of developing any networking stack without knowing what's really going on...
Why don't you build one yourself ? ;-) -
I would really love to, but unfortunately I don't have any computer to lobotomize with windos.
-
@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). -
I spoke too soon...
I'm going crazy trying to find out why my sensors with DS18B20 keep locking up.... Today I had to clear and re-upload a sketch to a locked up sensor and it would not convert to F.. Severals hours later, still would not convert..
RJ_Make
-
I spoke too soon...
I'm going crazy trying to find out why my sensors with DS18B20 keep locking up.... Today I had to clear and re-upload a sketch to a locked up sensor and it would not convert to F.. Severals hours later, still would not convert..
-
@ServiceXp
You could test some other ds18b20 library and add a capacitor on the powerline to the temp-sensors.
@hek said:> @ServiceXp
You could test some other ds18b20 library and add a capacitor on the powerline to the temp-sensors.
I now believe it's related to the DS18D20 sensor. The same sensor locked up again when I got home, and interestingly enough they locked up @ -7.0 F. both times.
- I power cycled sensor, (Still Locked Up)
- Pushed sensor reset button. (Still Locked Up)
- I removed from freezer, warmed sensor; power cycled sensor again (Still Locked Up)
- Disconnected the DS18D20 from sensor and what do you know I was able to get it to recover.
So either this is just a freak of coincidence or the DS18D20 is some how locking up the Arduino in my environment. I installed a .47uF cap between the sensors VCC and GND wires, so we shall see.
Here is the serial output of the sensor:
-
Locked up again this morning @ 7:37am with a temp of -0.1. So a .47uF cap isn't the answer....
-
###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.
@hek Can you help me to understand how to get the update, and what parts are updated? I followed the download link to the library and installed the files. I then updated my gateway but I didn't see any version number change and I'm still having trouble with temperature readings coming through in Imperial units rather than metric.
Thanks, and keep up the great work!
Troy.
-
@hek Can you help me to understand how to get the update, and what parts are updated? I followed the download link to the library and installed the files. I then updated my gateway but I didn't see any version number change and I'm still having trouble with temperature readings coming through in Imperial units rather than metric.
Thanks, and keep up the great work!
Troy.
-
@hek said:
You followed the download link for 1.4 on the main site?
Hi Hek,
Yeah from the main page, I went to the Download page and then hit the Download button under the 1.4 Latest Release section. The readme file in the archive says 1.4, but I'm looking for 1.4 Update 1 which has the fixes for the imperial vs. metric units with temperature sensors. I rebuilt my gateway with the code anyway but no change. Am I missing something?
Thanks,
Troy. -
@hek said:
You followed the download link for 1.4 on the main site?
Hi Hek,
Yeah from the main page, I went to the Download page and then hit the Download button under the 1.4 Latest Release section. The readme file in the archive says 1.4, but I'm looking for 1.4 Update 1 which has the fixes for the imperial vs. metric units with temperature sensors. I rebuilt my gateway with the code anyway but no change. Am I missing something?
Thanks,
Troy.Then you're using the latest 1.4 version.
You'll have to look at the debug prints on the sensor to see what is happening and determine if there's communication problem. I suspect that your sensors messages can reach the gateway but not the other way around (sometimes).
-
Then you're using the latest 1.4 version.
You'll have to look at the debug prints on the sensor to see what is happening and determine if there's communication problem. I suspect that your sensors messages can reach the gateway but not the other way around (sometimes).
@hek I did some testing and it appeared to be a sync issue. First I looked at the gateway and the debug messages showed Imperial units which matched the Vera UI. Then I unplugged the temp. sensor from power and plugged it into my laptop and it was reporting Metric units in the debug, and then Vera started showing Metric. So I unplugged the sensor from my laptop, plugged it back into it's original location and the units switched back to Imperial. Finally I just rebooted the gateway and the sensor and now Metric is working.
Anyway, thanks for your help!
T.
-
@hek I did some testing and it appeared to be a sync issue. First I looked at the gateway and the debug messages showed Imperial units which matched the Vera UI. Then I unplugged the temp. sensor from power and plugged it into my laptop and it was reporting Metric units in the debug, and then Vera started showing Metric. So I unplugged the sensor from my laptop, plugged it back into it's original location and the units switched back to Imperial. Finally I just rebooted the gateway and the sensor and now Metric is working.
Anyway, thanks for your help!
T.
