intermittent error using "node.sleep()" function

[RonNeal]

I am having an intermittent error using the "node.sleep()" function. Most of the time (90%) it works fine but occasionally the following error is displayed "System.Application Exception: 'Failed to read the LXRS+ Protocol Version (EEPROM 126) from node 14818'. Enclosing node.sleep() with try / catch does NOT prevent a system crash. The last time I checked I have the latest version of MSCL and firmware in the base station and the nodes.

[msclissa]

If not already done, could you try increasing the WirelessNode read/write retries value - in SensorConnect we set it to two for three total read attempts (node.readWriteRetries(2)) but feel free to increase this more if it does end up helping avoid this issue.

Is anything else being done to the node directly before or after calling node.sleep()? Is the node in a location you're able to see it - does the LED indicate it has been successfully put in sleep mode and it's just failing in the application or is it still idle after the error is thrown?

I'm surprised that a try/catch is not catching the exception - would you mind providing the relevant section of code?

Thanks!

[RonNeal]

Adding node.readWriteRetries(3) to the BaseStation and nodes did not help. However adding the following code seems to have taken care of the problem:

mscl.PingResponse response = node.ping(); If (response.success()) { If(node.sleep)) {...

I hadn’t used the PingResponse code because I didn’t think it was necessary having successfully put the node to sleep. Also most of the time the node was put to sleep even when the error occurred.

Is there a place to see all of the potential error messages for Mscl and possible causes for them?

Thanks!

Ron Neal

Sent from my iPad

On Sep 10, 2021, at 3:32 PM, mglord @.***> wrote:

If not already done, could you try increasing the WirelessNode read/write retries value - in SensorConnect we set it to two for three total read attempts (node.readWriteRetries(2)) but feel free to increase this more if it does end up helping avoid this issue.

Is anything else being done to the node directly before or after calling node.sleep()? Is the node in a location you're able to see it - does the LED indicate it has been successfully put in sleep mode and it's just failing in the application or is it still idle after the error is thrown?

I'm surprised that a try/catch is not catching the exception - would you mind providing the relevant section of code?

Thanks!

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.