Hi all,
I'm fetching from a db an int with the lenght of 13 digits and I don't know which kind of variable I should use.
Do you know which is the best?
Thx you all
char array
the largest integral number the compiler can handle directly is a long long on 64 bits - you can use the type int64_t for that (the Arduino Print library does not know how to print such a number)
that will represent up to 263 − 1 which equals 9,223,372,036,854,775,807
int32_t are only on 4 bytes and will represent up to 231 − 1 which equals 2,147,483,647 so not enough for your 13 digits need
1 Like
The function from the library fetchs the data as an Int (I think)
Firebase.RTDB.getInt(&fbdo, "/test/real/timestamp");
float i = fbdo.intData();
So, I'm using: Release v2.3.7 · mobizt/Firebase-ESP-Client · GitHub this library
I'll try it now. Thx
your challenge is that the method returns just an int (so 32 bits on an ESP)
you might need to find an alternate way to extract the information. How does it get there in the first place? what's the type of the data?
if you could have it as an ASCII string you might be able to handle a larger type using the strtoll() function
As you already said the method just return a 32bits value.
I previously used the method as this Firebase.RTDB.setTimestamp(&fbdo, "/test/real/timestamp"); to print the actual timestamp in realtime values and when I want to store the data (every 30sec) I fetch this value and put it in a .JSON file and push the file into the db.
Maybe I can try using a different method: String jsonString(); maybe the API call include the implicit conversion from int to string
Totally not familiar with this but can you use getString() instead of getInt() and store it in a character array. And process that as indicated in post #6?
it's likely in ASCII format in the JSON when you get it then so indeed use getString() and then strtoll() to get the 64 bit version
The main question is:
what is the purpose of the 13 digits?
as a real number this represents 1 Million Billions = 10^12
What application needs such great numbers?
I can't think of anything senseful except maybe number of molcules in a mass of something in the range of grams. But then instead of the pure number of molecules the unit "mol" is used to have small numbers again.
So I guess it might be some ID-number which is a composite of some smaller parts
or no number at all.
So please tell us: what is the purpose of the 13 digits?
best regards Stefan
The purpose is: use the already existing function to register the timestamp in ms in the realtime database
It does return an empty value in the node by this way.
The only other think that come in my mind is to actually try to convert the value before uploading it by modify the method... But I'm not this experienced in changing already existing method in functioning libraries
I do not really understand what this means
If I calculate back
10^12 milliseconds / (1000 milliseconds per second * 3600 seconds per hour * 24 hours per day * 365 days per year) = 31.709 years. So this seems to be epoc the milliseconds since unix started counting around 1970. (I'm not really familiar with "epoc")
But epoc is a very common "data" So I'm pretty sure that especially for epoc there are functions to handle this.
Would it be sufficient to have second precision and drop the milliseconds?
best regards Stefan
When you do
Firebase.RTDB.getstring(afbdo,….
String i = fbdo.stringData();
Can you print that ?
It does return an empty value.
I found the method to push this value onto the db:
At the moment I'm thinking a way to clone this function and actually return this value instead of the bool outcome of the formula
it would be interesting to understand where the timestamp comes from (internal to the DB?) and what's the actual type used (I don't use Firebase)
edit; just checked the doc and they say
A Timestamp represents a point in time independent of any time zone or calendar, represented as seconds and fractions of seconds at nanosecond resolution in UTC Epoch time. It is encoded using the Proleptic Gregorian Calendar which extends the Gregorian calendar backwards to year one. It is encoded assuming all minutes are 60 seconds long, i.e. leap seconds are "smeared" so that no leap second table is needed for interpretation. Range is from 0001-01-01T00:00:00Z to 9999-12-31T23:59:59.999999999Z. By restricting to that range, we ensure that we can convert to and from RFC 3339 date strings.
seems the format is a string
Which database is able to store faster than in a single nano-second?
The "laser-database" flashing laser-pulses of femto-seconds??
use a string or use a different database that is less ludicrous
Don’t forget nowadays database can be in RAM and on multi GigaHetz cores with a 64 bits server architecture that allows for nanosecond time stamps
But That’s not the point of how long it takes - it’s just the point in time when an order was received
You could otherwise argue there is no point in having access to a mictoSeconds function on our small MCUs
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.