Device sleep period - does not seem apply

Ive got 2 lilygo t-beam flashed with 1.2.30 firmware. With 2 android phones trying to send messages. Im trying to keep the bluetooth keep alive and trying to set the “Advanced settings / Device sleep period” to 0 on the Android app in order to have a stable connection with the tbeam for at least 24 hours. My problem is that after setting this value to 0 , the device still goes to sleep. Theres no save button, so I assume I just have to click enter. When I force it to come back the setting is set to 300 again. No problem with pairing. It can catch up again when device wakes up for some reason (radio packet or pressed button), but it would be much better to have the bluetooth and the device always on.
How can I keep the device alive for long time? Or do you have a good exmplanation for this? I know this topic comes back again often, but didnt find good answer nor in the doc, nor in forum. Thanks!

1 Like

I think 0 is the same as saying ‘default’, hence it returns to 300. Try a larger number.

1 Like

Thanks for the answer. Ive tried to set Device sleep = 126000, Broadcast position period = 28, Network = Medium Z. Still no success. But it seems better. After 1 minute the devices are going to sleep. BUT not always. So I dont undserstand that. Messages are lost for those Android phones who are offline when the message was sent. The radio in sleep mode does not wake up and store the message on the device.The radio in sleep mode only handles and forwards the radio packages but not wakes up the device and stores the message. Is that right?
So as I understand messaging is not reliable, unless maybe if I create a “server” that is always on and keeps the messages and send again to those who were offline? Anybody created / programmed a server and Android app like this?

Question B / GPS: In spite of the messages are lost, the position broadcast are still going on when device is in sleep mode? So is it good to track something ? What setup is needed to track something in the field out there?

Thanks!

You may still be bumping into a recent bug around message delivery and odd sleep times, so @geeksville would want to know about that or may have some ideas.

OK. thanks, Then I will do more tests and read the docs. And wait for some answer. Anyways If you have a suggestion for a good version of the firmware then I would appreciate it. I’ve only found a topic on reliable messages but it is old and think this is already built into the code: How to send reliable messages with the python api?