Everything syncs (beans, recipes, existing roasts, and roast downloads) except new roasts in RoasTime [solution provided]

What host or service has to be whitelisted in order for RoasTime < - > Roast.World sync to work?
Is there a document explaining this?

unofficial answer:
I think it’s https://api.roast.world and google services like *.api.googleapis.com.


@damon is right about whitelisting https://api/roast.world. You might also need to include *.googleapis.com to enable Firebase services to work as expected.

1 Like

I did few more roasts today.
I added a new bean via Roast.World and clicked Sync button in Beans page in RoasTime and my new bean popped up in RoasTime.

Completed the roast.
As far as I can see RoasTime is talking to the world. :expressionless:
Most requests are allowed.
But my new roasts are not syncing back.

On startup

During explicit data sync from Beans page

During explicit data sync from Roast History page

On settings update

During firmware updates check

Periodically without any user actions

I might be a bit wrong about what triggers particular requests… Some requests are scheduled by timer and not trigger by my app interactions.
But it’s not that important in this context.

It would be nice if Allio tech people could shed some light into sync workflow.

Is there any application logs I can check?

Hey @kelis,

The only time requests are not trigged by you is when some data is changed on Roast World. RoasTime is then notified that it needs to perform a re-sync and then it carries out the sync automatically.

When something is CRUD-ed (created, updated, etc.), RT pushes the changes to our servers in the background. These can explain the calls to *.googleapis.com. You mentioned that your roasts are not syncing? From what I can tell, there’s nothing blocked by the Firewall that should be preventing this from happening.

There’s might be some corrupt data that is preventing syncing from working correctly. If you’re available this week or next, I’m happy to jump on a call to help debug this.


1 Like

@kelis which direction is syncing of your roasts not working? From RW->RT or RT->RW?

First of all - thanks to everyone who is spending their time looking into my issue - really appreciate it.

I did a bit more troubleshooting.
It is a little unexpected but whitelisting icanhazip.com fixed most RT->RW sync issues (possible all, need to figure it out).
So RT really wants to know my ip-address to upload the data. :slight_smile:
Can’t really see the technical reason for that - backend will know my IP address anyway.

My observations at this moment.
Both RT->RW and RW->RT sync works.

Both RT->RW and RW->RT most likely works - I can change something in my roasts and I can see updates on the other side.
Might requires a bit more testing with new roasts later but I haven’t finished drinking my previous batch yet :smiley:

Both RT->RW and RW->RT sync works.

So it looks like unavailability of http://ipv4.icanhazip.com was the obstacle blocking the sync.

1 Like

@kelis You are the man! Thank you for helping us debug this issue. For context, we use a library to check if you are online before taking multiple actions. This library pings icanhazip.com to make sure you are online as one of the steps and that must be why it is not syncing.

1 Like

Thanks for helping debug this, @kelis! The solution is to whitelist icanhazip.com so that RoasTime is able to detect that it is connected to the internet & can push the new roasts data.

1 Like

Thank you @mcaillio and @derrxb for your input.

To be fair blocking icanhazip.com is not stopping other requests - RoastTime is still trying to access googleapi and firing all other requests. Might be just not trying to sync with Firebase.

Also as far as I understand it’s not just a ping to icanhazip.com but HTTPS request. So pointing that name to another host didn’t help (I played with hosts file in my system :smiley:).

But that’s Ok. A can see my data syncing now when legit icanhazip.com is accessible.
I am good now.

Thank you again for your help.