Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you may not be able to execute some actions.

Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).

MySensors.sleep(int) issue

marceltrapman Mod 17 Jul 2014, 17:10 last edited by marceltrapman 17 Jul 2014, 17:13

Strange...

MySensors.sleep(30000) works as expected.
MySensors.sleep(300000) screws things up and there is effectively no sleep anymore.

I use the DallasTemperatureSensor example where the sleep time is set as a long while the method takes an integer. Could that be the reason this happens?
Reply Quote 0
1 Reply Last reply 17 Jul 2014, 17:29
Loading More Posts
4
Posts

2.1k
Views
Reply

Reply as topic
Log in to reply
BulldogLowell Contest Winner 17 Jul 2014, 17:29 last edited by @marceltrapman

@marceltrapman

it is likely,

an int overflows at 32,767
Reply Quote 0
1 Reply Last reply
marceltrapman Mod 17 Jul 2014, 18:16 last edited by

@BulldogLowell I did not know the exact value but I hope it can be changed a max sleep of 30 seconds is not impressive...
Reply Quote 0
1 Reply Last reply
hek Admin 17 Jul 2014, 18:42 last edited by

No, 30 sec is not so much. I better have a look at that.
Reply Quote 0
1 Reply Last reply

4
Posts

2.1k
Views

4 out of 4

Suggested Topics

Code for beta-testing?
Controllers • 24 Mar 2014, 20:48 • andriej 9 Aug 2014, 10:44

33

0
Votes

33
Posts

15.1k
Views

9 Aug 2014, 10:44

@donnib - I didn't continue this way but instead started using node-js based controller code that connects to a standard Ethernet gateway. @hek merged the code about two weeks ago. I will provide a tutorial on how to set it up from scratch shortly...
ACK -aka ECHO beeing missed by Serial Gateway with RF24 radios. V2.3.2
Bug Reports • 15 Apr 2023, 06:27 • GaryStofer 21 Apr 2023, 17:34

8

0
Votes

8
Posts

56
Views

21 Apr 2023, 17:34

First let me say that the test "network" consists of a single node and a Serial GW with a Domoticz controller only. No repeater nodes are present and it operates at 250Kbd on a frequency outside of the WiFi spectrum verified to have no traffic. The test subjects are within 10 feet of each other and the protocol sniffer receiver is placed roughly midway between the two communicating nodes. The test node has a plugable connector for the RF modules so that I can switch them out separately. The GW has the LNA/PA module and the node is using the standard mudules. Both GW and node are set to "High" power. Looking at the problem with the promiscuous protocol sniffer and wireshark I can clearly see that packets collide mid air when both the node and the GW transmitting at the same time. This happens when the controller/GW talks to the node while having the protocol ACK request enabled and the node does not have the extra wait/delay programmed. Going through 12 RF modules node side, I can see that about 1/3 shows the problem consistently to the extent that all 16 retransmissions are used up , 1/3 to various degrees and the rest shows no problems at all. Before you say "ohh fake chips etc." these modules all came from the same batch, so more than likely not fake and non fake, but rather some parameter that the lib assumes to tight of a margin for. When turning off the protocol level ACK via the controller/GW, the package goes out without an request for the node to send back the package, only the HW ack remains in the picture. Setup like this I can see that the third of the modules that cause the persistent collisions evoke a re-send of the package by the GW after ~2 to 2.5ms , while the group that shows no problem shows one single transmission from the GW only. Since the sniffer is not fast enough to capture the quick turn around ( spec says 130us) for the short HW ack to go out I can not get say whether the node is simply not sending it or just not sending it in quick enough. All I can say is that the GW code did not see a HW ack and therefore sends out the package a second time. Meanwhile on the node side all is well, it just might get the same package twice and since no status changed there is no harm done. However when you now turn on the protocol level ACK request in the controller ( as you should) the node has to turn around and send out the echo package which then collides with the resend of the original package from the GW. The node also doesn't get an HW-ACK becasue of this and tries to resend the echo package over again until it runs out of tries. When I then introduce the wait/delay in the code above to wait out the 2.5Ms for the GW to resend the initial package this ACK/resend storm goes away because the air is clear when the node sends it's echo package. If I wait/delay for 2 ms the problem is greatly reduced and if I wait 3 ms I see no more evidence of collisions. Either wait or delay works however, I choose delay() to be positively sure that no other communication is started during that time by the node. I conclude that as a work around this solves the issue we are having with the RF24 transport, but without further investing into faster RF sniffing equipment I can't say for sure if this could be solved better on the TX side by waiting longer for the HW ack to arrive from the receiving node, however I think there would be a good chance for that. There is also a chance that the PA/LNA module used on the GW could be part of the problem by not being able to switch quickly enough back to RX mode and therefore loose the HW-ACK for nodes that respond quicker than others. Edited: Checked with a non PA/LNA module on the GW and no change could be observed, so this theory can be discounted. BTW: All of this is very reminiscent of an email communication in 2015 I had with Ekblad !! GS
Missing "__libc_init_array();" wenn using samd without USB
Bug Reports • 6 Jul 2022, 08:36 • ltigges 7 Jul 2022, 22:43

2

0
Votes

2
Posts

18
Views

7 Jul 2022, 22:43

@ltigges Hi, I can confirm your issue. Thank you for reporting! Best will be to open a new issue in in the GitHub repo at MySensors/issues. It would be great if you could do that- thank you. BR Immo
sleep(0) in V2.1 doesn't sleep indefinitely anymore. Used to powerdown and sleep in V1.5
Bug Reports • 22 Nov 2019, 00:35 • GaryStofer 15 Apr 2023, 05:50

3

0
Votes

3
Posts

149
Views

15 Apr 2023, 05:50

@mfalkvidd No, the issue with sleep(0) still exists in V2.3.2. That is the version that the ArDuino Library installer installs currently . -- Work around is to call hwPowerDown(WDTO_SLEEP_FOEREVER) as in above code if you want the battery to last more than a day. GS
Boards esp8266 v3.1.0 or Newer Doesn't Work with MySensors
Bug Reports • 21 Feb 2023, 01:55 • d-smes 25 Feb 2023, 19:37

9

0
Votes

9
Posts

58
Views

25 Feb 2023, 19:37

@monte said in Boards esp8266 v3.1.0 or Newer Doesn't Work with MySensors: il existe tellement de solutions bon marché et faciles pour ce que font mysensors as rich in possibilities as this does not exist
NRF51-52 PA not support ???
Bug Reports • 23 Feb 2019, 16:40 • berkseo 8 Jul 2021, 11:42

17

0
Votes

17
Posts

1.3k
Views

8 Jul 2021, 11:42

@berkseo said in NRF51-52 PA not support ???: The network is simple, this node is nrf52 with an amplifier and a gateway with the nrf24 radio module with an amplifier. It would be strange if a gateway with an amplifier could not deliver ACK. Two moments, or I did a very bad control of the amplifier on the node nRF52 or in the radio driver itself, something is not working well, and may need some delay settings. If i send messages with an ECHO (soft ack) request, this works fine over very long distances. Hw ack does not work properly. Someone was able to do this for mysensors? Gateways and repeaters on nrf5 with amplifier is a very, very cool topic.

MySensors.sleep(int) issue

Suggested Topics

Code for beta-testing?
Controllers • 24 Mar 2014, 20:48 • andriej 9 Aug 2014, 10:44

ACK -aka ECHO beeing missed by Serial Gateway with RF24 radios. V2.3.2
Bug Reports • 15 Apr 2023, 06:27 • GaryStofer 21 Apr 2023, 17:34

Missing "__libc_init_array();" wenn using samd without USB
Bug Reports • 6 Jul 2022, 08:36 • ltigges 7 Jul 2022, 22:43

sleep(0) in V2.1 doesn't sleep indefinitely anymore. Used to powerdown and sleep in V1.5
Bug Reports • 22 Nov 2019, 00:35 • GaryStofer 15 Apr 2023, 05:50

Boards esp8266 v3.1.0 or Newer Doesn't Work with MySensors
Bug Reports • 21 Feb 2023, 01:55 • d-smes 25 Feb 2023, 19:37

NRF51-52 PA not support ???
Bug Reports • 23 Feb 2019, 16:40 • berkseo 8 Jul 2021, 11:42

0
Online

11.5k
Users

11.1k
Topics

112.8k
Posts

MySensors.sleep(int) issue

Suggested Topics

Code for beta-testing? Controllers • 24 Mar 2014, 20:48 • andriej 9 Aug 2014, 10:44

ACK -aka ECHO beeing missed by Serial Gateway with RF24 radios. V2.3.2 Bug Reports • 15 Apr 2023, 06:27 • GaryStofer 21 Apr 2023, 17:34

Missing "__libc_init_array();" wenn using samd without USB Bug Reports • 6 Jul 2022, 08:36 • ltigges 7 Jul 2022, 22:43

sleep(0) in V2.1 doesn't sleep indefinitely anymore. Used to powerdown and sleep in V1.5 Bug Reports • 22 Nov 2019, 00:35 • GaryStofer 15 Apr 2023, 05:50

Boards esp8266 v3.1.0 or Newer Doesn't Work with MySensors Bug Reports • 21 Feb 2023, 01:55 • d-smes 25 Feb 2023, 19:37

NRF51-52 PA not support ??? Bug Reports • 23 Feb 2019, 16:40 • berkseo 8 Jul 2021, 11:42

0Online

11.5kUsers

11.1kTopics

112.8kPosts

Code for beta-testing?
Controllers • 24 Mar 2014, 20:48 • andriej 9 Aug 2014, 10:44

ACK -aka ECHO beeing missed by Serial Gateway with RF24 radios. V2.3.2
Bug Reports • 15 Apr 2023, 06:27 • GaryStofer 21 Apr 2023, 17:34

Missing "__libc_init_array();" wenn using samd without USB
Bug Reports • 6 Jul 2022, 08:36 • ltigges 7 Jul 2022, 22:43

sleep(0) in V2.1 doesn't sleep indefinitely anymore. Used to powerdown and sleep in V1.5
Bug Reports • 22 Nov 2019, 00:35 • GaryStofer 15 Apr 2023, 05:50

Boards esp8266 v3.1.0 or Newer Doesn't Work with MySensors
Bug Reports • 21 Feb 2023, 01:55 • d-smes 25 Feb 2023, 19:37

NRF51-52 PA not support ???
Bug Reports • 23 Feb 2019, 16:40 • berkseo 8 Jul 2021, 11:42

0
Online

11.5k
Users

11.1k
Topics

112.8k
Posts