Frequency of Checking Schedule about farmbot_os HOT 5 CLOSED

#13

There was the idea to send one command to get a status and it keeps sending
the status for x minutes.

The resource cost to get the status is practically zero. What the resource
cost is for receiving/sending I haven't checked.

On Thu, Nov 27, 2014 at 10:41 AM, Rory Aronson [email protected]
wrote:

I was wondering if the frequency that the pi checks the schedule could be
increased? Is there a significant cost in doing so?

Increasing the check rate would allow the manual control page to feel more
'real-time' than it currently is - a major 'wow' factor I think most people
will like especially when they are using the widget to show off their bot
to their friends.

—
Reply to this email directly or view it on GitHub
#43.

from farmbot_os.

I meant when I send the bot a command it gets put in the schedule nearly instantly. The pi seems to check the database locally every 1 second or 1/2 second. Could that frequency be increased so it checks it every 1/10 of a second in order to decrease the lag of manual control?

from farmbot_os.

Ah, there was a bug in that part due to the emergency stop code that caused
a delay. That's changed. The frequency now should be 0.1 seconds in the
next push. The limiting factor is then the database (sqlite) speed.

On Thu, Nov 27, 2014 at 10:56 AM, Rory Aronson [email protected]
wrote:

I meant when I send the bot a command it gets put in the schedule nearly
instantly. The pi seems to check the database locally every 1 second or
1/2 second. Could that frequency be increased so it checks it every 1/10 of
a second in order to decrease the lag of manual control?

—
Reply to this email directly or view it on GitHub
#43 (comment)
.

from farmbot_os.

Oh!! Is that what was going on?

I was working on Farmbot last night for the read_status command and was getting ~4 second delays from the time I fetched to the time it was displayed the message.

I thought maybe MeshBlu was under heavy load. Is it on our end?

from farmbot_os.

No, the read status is something different. The status command is handled
before it reaches the command scheduling. As far as I can deduce it: the
handling of the status reading is hanging (indefinitely) on a certain
variable. Because it's hanging instead of raising an error, you don't see
it. And because it's an event, the rest keeps running instead of blocking
everything. Will fix that soon.

On Thu, Nov 27, 2014 at 3:32 PM, Rick Carlino [email protected]
wrote:

Oh!! Is that what was going on?

I was working on Farmbot last night for the read_status command and was
getting ~4 second delays from the time I fetched to the time it was
displayed the message.

I thought maybe MeshBlu was under heavy load. Is it on our end?

—
Reply to this email directly or view it on GitHub
#43 (comment)
.

from farmbot_os.