Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 05 18:24
    Makuna closed #122
  • Jan 05 13:22
    coreydaley opened #122
  • Sep 29 2020 21:20
    Makuna unlabeled #110
  • Sep 29 2020 21:20
    Makuna closed #110
  • Sep 29 2020 21:15

    Makuna on master

    enable travis build using platf… (compare)

  • Sep 29 2020 21:15
    Makuna closed #116
  • Sep 23 2020 20:22
    Makuna closed #120
  • Sep 23 2020 20:22
    Makuna updated the wiki
    FAQ-#5
  • Sep 23 2020 20:13
    Makuna updated the wiki
    FAQ
  • Sep 23 2020 08:34
    T0m92 opened #120
  • Aug 27 2020 15:58
    Makuna closed #119
  • Aug 27 2020 15:58
    Makuna labeled #119
  • Aug 27 2020 15:55
    Makuna closed #118
  • Aug 27 2020 08:15
    Bredahl opened #119
  • Aug 03 2020 15:39
    Flavian opened #118
  • Aug 01 2020 19:24
    Makuna closed #117
  • Aug 01 2020 17:19
    lucagrosshennig opened #117
  • Jul 31 2020 17:46
    thijstriemstra opened #116
  • Jul 25 2020 23:30

    Makuna on 2.3.5

    (compare)

  • Jul 25 2020 23:28

    Makuna on NextRelease

    (compare)

WireFighter1
@WireFighter1
@Makuna I have an ESP2866 and set the Date-Time from NTP ;) The Epoch is from NTP at 1970 Your Code is at 2000. I have change the OriginYear to 1970 and Epoch32OfOriginYear to 2208988800. Than i put the NTP in the Rtc.SetDateTime(). This is not a good Action but in your Sketch Examples is no set Time-Date from NTP inside :) Is this in the Feauters in There?
Michael Miller
@Makuna
You are miss reading the code. The origin year in RtcDateTime is not the Epoch origin; it is the standard Arduino origin.
Please read the FAQ, https://github.com/Makuna/Rtc/wiki/FAQ-%233
WireFighter1
@WireFighter1
Ohh, I apologize a lot and I'm happy that you answered anyway :)
promise to read in your FAQ for the next question.
Michael Miller
@Makuna
NP, I wish the Wiki was more discoverable.
Michela Limaco
@m1ch3l4
Hi there! I need the SQW to trigger when the alarm is triggered - go HIGH to LOW and HIGH again.
I'm looking in the library for the method responsible for the alarm action, but I can not find it.
I also tried SetSquareWavePinClockFrequency set to 1Hz but it did not work as I expected.
What do you recommend?
Michael Miller
@Makuna
@m1ch3l4 What RTC are you using? Some do not have the feature.
CTS
@connessionetech

Hi i am having trouble with using the library with nodemcu. My issue is exactly similar to : Makuna/Rtc#68

my arduino ide is 1.8.8 on windows. According to library managerthe latest available is shown as 2.3.0. I Also tried cloning from repo directly but it didnt have any impact.

Please help !
CTS
@connessionetech
my board manager says i already have 2.4.2 of esp8266
CTS
@connessionetech

Same thing works fine when i run same thing with same rtc on arduino uno. On node mcu i connect D1-> SCL an D2 -> SDA. If i run it on arduino uno first and set the time then move the rtc to nodemcu it read correct time. My RTC is Ds3231.

After moving it to nodemcu it again starts losing time after some time. :(

Michael Miller
@Makuna
The issue you referenced is really not a good example to mention, the user was using a sketch that put the RTC into a sleep mode, which of course it would not keep time after such an action.
Start with the example DS3231_Simple, what does it show in debug output?
Then modifiy the example and JUST comment out every case of Rtc.SetDateTime. Run it again, what does the output show?
CTS
@connessionetech

RTC lost confidence in the DateTime!
85/165/2009 37:165:
-0.25C

if i pull out the battery and put it back again and run the DS3231_Simple code again it becomes ok for some time. I have tested battery with multimeter. i use a cr2032 cell and it is new so it shows 3.04v. What could be wrong ?

Michael Miller
@Makuna
@connessionetech Its the battery. Please read this about cr2032 testing
CTS
@connessionetech
Thank you. I will get new battery and check and report back. I really appreciate your response 💪 in helping out.
CTS
@connessionetech
Battery it was 😇
Albertox0404
@Albertox0404
hi
I have an ESP32 and a DS3231, the library works very well but I have another device connected to pin 22 (SCL) and because of this randomly both devices stop working until the microcontroller is completely reset.
How can I change the ESP32 pins to use a pin that is not busy? I have tried the example of "DS3231_Simple" the part of "Wire.begin (16, 17);" which is supposed to work on an ESP-01 but on ESP32 it does not work for me. This information always shows that it is not communicating correctly (If I put pins 21 and 22 then everything works perfectly for a while (due to the other device))
RTC lost confidence in the DateTime!
85/165/2009 37: 165:
-0.25C
Thank you
Michael Miller
@Makuna
@Albertox0404 Review Makuna/Rtc#37 and specifically This Reply
Michael Miller
@Makuna
And for Esp32, they think the issue is fixed espressif/arduino-esp32#349
Michael Miller
@Makuna
And espressif/arduino-esp32#2261 Has lots of great suggestions for tracking down the culprit.
Michael Miller
@Makuna
And it looks like others are seeing it with (open issues)[espressif/arduino-esp32#1998]
I would suggest bringing this up to the Esp32 guys.
Michael Miller
@Makuna
BTW, I just added a method to check for an error code and updated the samples to show how to use it.
Florian Laforest
@NatsuOnFire
Hi, why "RtcDateTime now = Rtc.GetDateTime();" return : "15/31/2099 00:10:32" and not the real now ?
Michael Miller
@Makuna
@NatsuOnFire What sketch are you using? There can be many reasons without having a context of what you are doing. Like, has the time ever been set on the RTC? Did the check for IsDateTimeValid() return false? What does Rtc.LastError() return?
Florian Laforest
@NatsuOnFire
@Makuna I run "DS1302 Simple", first initialization when the condition "if(now > compiled)" => nothing
I change the code, "if(now > compiled)" => Rtc.setDateTime(compiled) and it's perfect
I remove it after and now it's the real dateTime and not "15/31/2099 ..."
Michael Miller
@Makuna
@NatsuOnFire I guess the samples should check if the delta in time is greater than specified amount rather than just less than or greater than.
victorh800
@victorh800
hi. regarding the RtcDS3231 class, why is the temperature returned as a RtcTemperature object instead of an int or a float? I do understand that the library has to do some math manipulations with a pair of 8-bit registers from the chip in order to reconstruct the actual value. but I don't understand why such math was abstracted away from RtcTemperature::GetTemperature() method into a wholly new class. maybe I'm failing to understand the rationale for this. library version: 2.3.2
Michael Miller
@Makuna
@victorh800 There two main reasons for this design decision.
1) Any object that can multiple representations (C or F) will need conversion helper routines, so standard OOP is to provide to an object that you can access association methods.
2) In the case of Arduino, not all platforms support float natively; so the use of float at all can be expensive for program memory (all the routines to support it) and program memory to contain it (32 bits) Arduino Float. My representation is only 16 bits and leaves the decision to use it as floats to the sketch owner.
An example of a very restricted Arduino is the ATTiny platforms; where the most common have only 512 bytes of ram, and the less common have less.
victorh800
@victorh800
indeed, I just noted that when I switched from AsCentiDegC() to AsFloatDegC()the program storage space from a test sketch jumped up + 8kiB! I agree with that design decision.
however I'm still curious why this code
int16_t scaledDegC = ((highByteDegreesC << 8) | (lowByteDegreesC & 0xC0)) >> 6; _centiDegC = scaledDegC * 100 / 4;
resides in the RtcTemperature constructor and not in the RtcDS3231::GetTemperature() method, which is conceptually closer to the hardware from it gets the data.
Michael Miller
@Makuna
This came down how long you store the value and then how often you convert it. If you only store and use (like print it) once for the lifetime of the RtcTemperature, there is no real difference of it being in either location. If you keep the RtcTemperature around and print it (use it) more than once, then you would run that convertion each time you print it; thus less optimal.
Also, on the theory side of this, that calc is about how the hardware stores and sends the data, so it converted at construction to a standard. When used, it is converted to the sketch needs at that point.
victorh800
@victorh800

interesting. having myself worked in the past on very restricted environments (e.g. a PIC with 256 bytes of RAM), I always paid attention to whose details. but more recently I've been working on a bigger hardware (Arduino MKR) and suddenly I forgot to consider such nuances and optimizations.

thank you very much for your promptly input!

koosiekloek
@koosiekloek
hi Everyone
koosiekloek
@koosiekloek
i am fairly new to Arduino so sorry if i ask stupid questions. i am using a Arduino pro mini with DS1302 RTC my code is the ds1302 simple example with only the connection pins and time delay changed. the problem is every second loop that displays time gives 00/00/2000 00:00:00 and the very next loop gives correct time. what is the problem here and how can i fix it please, thanks for any help!
Serial log
09:50:54.530 -> 04/18/2019 09:50:43
09:50:59.551 -> 00/00/2000 00:00:00
09:50:59.551 -> RTC lost confidence in the DateTime!
09:51:04.527 -> 04/18/2019 09:50:53
09:51:09.515 -> 00/00/2000 00:00:00
09:51:09.561 -> RTC lost confidence in the DateTime!
09:51:14.547 -> 04/18/2019 09:51:03
09:51:19.525 -> 00/00/2000 00:00:00
09:51:19.572 -> RTC lost confidence in the DateTime!
09:51:24.561 -> 04/18/2019 09:51:13
09:51:29.526 -> 00/00/2000 00:00:00
09:51:29.580 -> RTC lost confidence in the DateTime!
09:51:34.531 -> 04/18/2019 09:51:23
09:51:39.557 -> 00/00/2000 00:00:00
09:51:39.557 -> RTC lost confidence in the DateTime!
09:51:44.527 -> 04/18/2019 09:51:33
09:51:49.532 -> 00/00/2000 00:00:00
09:51:49.579 -> RTC lost confidence in the DateTime!
09:51:54.566 -> 04/18/2019 09:51:43
09:51:59.537 -> 00/00/2000 00:00:00
09:51:59.537 -> RTC lost confidence in the DateTime!
09:52:04.560 -> 04/18/2019 09:51:53
09:52:09.547 -> 00/00/2000 00:00:00
09:52:09.547 -> RTC lost confidence in the DateTime!
09:52:14.525 -> 04/18/2019 09:52:03
Michael Miller
@Makuna
@koosiekloek What did you change the delay to? The sample uses 10 seconds. Does it work correctly with 10 seconds? If it does, try slowly decreasing the delay until it doesn't work anymore. I suspect there is a required delay time between transactions that is not correctly accounted for in the ThreeWire.h.
Michael Miller
@Makuna
Also, make sure the pins you are using are not used for something else.
koosiekloek
@koosiekloek

i changed Delay now as below seems 10sec is working fine but i need a bit shorter time per loop as i will have button input for logging as well. always every second display is wrong down to 1sec delay at 0.5 sec delay two displays are right then two displays are wrong? seems like only uneven number of seconds can be displayed? see last log of 0.7sec Delay only uneven seconds are displayed?
10 Sec Delay
10:17:46.085 -> compiled: Apr 18 201910:17:35
10:17:46.138 -> 04/18/2019 10:17:35
10:17:46.138 -> RTC lost confidence in the DateTime!
10:17:46.185 -> RTC is the same as compile time! (not expected but all is fine)
10:17:46.285 -> 04/18/2019 10:17:35
10:17:56.197 -> 04/18/2019 10:17:45
10:18:06.201 -> 04/18/2019 10:17:55
10:18:16.201 -> 04/18/2019 10:18:05

7 Sec Delay
10:20:56.795 -> compiled: Apr 18 201910:20:45
10:20:56.795 -> 04/18/2019 10:20:45
10:20:56.842 -> RTC is the same as compile time! (not expected but all is fine)
10:20:56.896 -> 04/18/2019 10:20:45
10:21:03.833 -> 00/00/2000 00:00:00
10:21:03.880 -> RTC lost confidence in the DateTime!
10:21:10.845 -> 04/18/2019 10:20:59
10:21:17.843 -> 00/00/2000 00:00:00
10:21:17.881 -> RTC lost confidence in the DateTime!
10:21:24.833 -> 04/18/2019 10:21:13

5 Sec Delay
10:23:07.322 -> compiled: Apr 18 201910:22:55
10:23:07.375 -> 04/18/2019 10:22:55
10:23:07.375 -> RTC lost confidence in the DateTime!
10:23:07.422 -> RTC is the same as compile time! (not expected but all is fine)
10:23:07.475 -> 04/18/2019 10:22:55
10:23:12.444 -> 00/00/2000 00:00:00
10:23:12.444 -> RTC lost confidence in the DateTime!
10:23:17.464 -> 04/18/2019 10:23:05
10:23:22.438 -> 00/00/2000 00:00:00
10:23:22.438 -> RTC lost confidence in the DateTime!
10:23:27.415 -> 04/18/2019 10:23:15

3 Sec Delay
10:24:48.776 -> compiled: Apr 18 201910:24:37
10:24:48.776 -> 04/18/2019 10:24:37
10:24:48.814 -> RTC lost confidence in the DateTime!
10:24:48.861 -> RTC is the same as compile time! (not expected but all is fine)
10:24:48.908 -> 04/18/2019 10:24:37
10:24:51.894 -> 00/00/2000 00:00:00
10:24:51.894 -> RTC lost confidence in the DateTime!
10:24:54.864 -> 04/18/2019 10:24:43
10:24:57.879 -> 00/00/2000 00:00:00
10:24:57.879 -> RTC lost confidence in the DateTime!
10:25:00.892 -> 04/18/2019 10:24:49

1 Sec Delay
10:26:01.916 -> compiled: Apr 18 201910:25:50
10:26:01.963 -> 04/18/2019 10:25:50
10:26:01.963 -> RTC lost confidence in the DateTime!
10:26:02.017 -> RTC is newer than compile time. (this is expected)
10:26:02.064 -> 00/00/2000 00:00:00
10:26:02.064 -> RTC lost confidence in the DateTime!
10:26:03.069 -> 04/18/2019 10:25:51
10:26:04.071 -> 00/00/2000 00:00:00
10:26:04.071 -> RTC lost confidence in the DateTime!
10:26:05.065 -> 04/18/2019 10:25:53
10:26:06.052 -> 00/00/2000 00:00:00
10:26:06.099 -> RTC lost confidence in the DateTime!
10:26:07.041 -> 04/18/2019 10:25:55

0.5 Sec Delay
10:27:01.559 -> compiled: Apr 18 201910:26:50
10:27:01.612 -> 04/18/2019 10:26:50
10:27:01.612 -> RTC is older than compile time! (Updating DateTime)
10:27:01.659 -> 00/00/2000 00:00:00
10:27:01.659 -> RTC lost confidence in the DateTime!
10:27:02.180 -> 00/00/2000 00:00:00
10:27:02.180 -> RTC lost confidence in the DateTime!
10:27:02.668 -> 04/18/2019 10:26:51
10:27:03.139 -> 04/18/2019 10:26:51
10:27:03.663 -> 00/00/2000 00:00:00
10:27:03.663 -> RTC lost confidence in the DateTime!
10:27:04.182 -> 00/00/2000 00:00:00
10:27:04.182 -> RTC lost confidence in the DateTime!
10:27:04.683 -> 04/18/2019 10:26:53
10:27:05.185 -> 04/18/2019 10:26:53

0.7 Sec Delay

10:35:32.521 -> compiled: Apr 18 201910:35:21
10:35:32.574 -> 04/18/2019 10:35:21
10:35:32.574 -> RTC lost confidence in the DateTime!
10:35:32.621 -> RTC is the same as compile time! (not expected but all is fine)
10:35:32.674 -> 04/18/2019 10:35:21
10:35:33.378 -> 04/18/2019 10:35:21
10:35:34.083 -> 00/00/2000 00:00:00
10:35:34.083 -> RTC lost confidence in the DateTime!
10:35:34.734 -> 04/18/2019 10:35:23
10:35:35.489 -> 04/18/2019 10:35:23
10:35:36.138 -> 00/00/2000 00:00:00
10:35:36.192 -> RTC lost confidence in the DateTime!
10:35:36.842 -> 04/18/2019 10:35:25
10:35:37.544 -> 04/18/2019 10:35:25
10:35:38.249 -> 00/00/2000 00:00:00
10:35:38.302 -> RTC lost confidence in the DateTime!
10:35:38.951 -> 04/18/2019 10:35:27
10:35:39.655 -> 00/00/2000 00:00:00
10:35:39.709 -> RTC lost confidence in the DateTime!
10:35:40.361 -> 00/00/2000 00:00:00
10:35:40.415 -> RTC lost confidence in the DateTime!
10:35:41.064 -> 04/18/2019 10:35:29
10:35:41.767 -> 00/00/2000 00:00:00
10:35:41.820 -> RTC lost confidence in the DateTime!
10:35:42.472 -> 00/00/2000 00:00:00
10:35:42.525 -> RTC lost confidence in the DateTime!
10:35:43.176 -> 04/18/2019 10:35:31
10:35:43.879 -> 00/00/2000 00:00:00
10:35:43.879 -> RTC lost confidence in the DateTime!
10:35:44.583 -> 04/18/2019 10:35:33
10:35:45.288 -> 04/18/2019 10:35:33
10:35:45.991 -> 00/00/2000 00:00:00
10:35:45.991 -> RTC lost confidence in the DateTime!
10:35:46.693 -> 04/18/2019 10:35:35
10:35:47.397 -> 04/18/2019 10:35:35
10:35:48.055 -> 00/00/2000 00:00:00
10:35:48.102 -> RTC lost confidence in the DateTime!
10:35:48.760 -> 04/18/2019 10:35:37
10:35:49.507 -> 04/18/2019 10:35:37
10:35:50.209 -> 00/00/2000 00:00:00
10:35:50.209 -> RTC lost confidence in the DateTime!
10:35:50.868 -> 04/18/2019 10:35:39
10:35:51.572 -> 00/00/2000 00:00:00
10:35:51.619 -> RTC lost confidence in the DateTime!
10:35:52.320 -> 00/00/2000 00:00:00
10:35:52.320 -> RTC lost confidence in the DateTime!
10:35:53.022 -> 04/18/2019 10:35:41
10:35:53.680 -> 00/00/2000 00:00:00
10:35:53.726 -> RTC lost confidence in the DateTime!
10:35:54.384 -> 00/00/2000 00:00:00
10:35:54.431 -> RTC lost confidence in the DateTime!
10:35:55.088 -> 04/18/2019 10:35:43
10:35:55.795 -> 00/00/2000 00:00:00
10:35:55.795 -> RTC lost confidence in the DateTime!
10:35:56.498 -> 00/00/2000 00:00:00
10:35:56.498 -> RTC lost confidence in the DateTime!
10:35:57.202 -> 04/18/2019 10:35:45
10:35:57.905 -> 00/00/2000 00:00:00
10:35:57.905 -> RTC lost confidence in the DateTime!
10:35:58.609 -> 04/18/2019 10:35:47
i am using A1, A2, A3 that is not used to my knowledge
koosiekloek
@koosiekloek
Delay on 0.1 Sec is very interesting. might there be some problem in the library math that dislikes even seconds?
00:00:00
10:40:42.145 -> RTC lost confidence in the DateTime!
10:40:54.829 -> compiled: Apr 18 201910:40:43
10:40:54.876 -> 04/18/2019 10:40:43
10:40:54.876 -> RTC is the same as compile time! (not expected but all is fine)
10:40:54.976 -> 04/18/2019 10:40:43
10:40:55.030 -> 04/18/2019 10:40:43
10:40:55.131 -> 04/18/2019 10:40:43
10:40:55.231 -> 04/18/2019 10:40:43
10:40:55.332 -> 04/18/2019 10:40:43
10:40:55.394 -> 04/18/2019 10:40:43
10:40:55.534 -> 04/18/2019 10:40:43
10:40:55.633 -> 00/00/2000 00:00:00
10:40:55.633 -> RTC lost confidence in the DateTime!
10:40:55.734 -> 00/00/2000 00:00:00
10:40:55.734 -> RTC lost confidence in the DateTime!
10:40:55.834 -> 00/00/2000 00:00:00
10:40:55.834 -> RTC lost confidence in the DateTime!
10:40:55.935 -> 00/00/2000 00:00:00
10:40:55.935 -> RTC lost confidence in the DateTime!
10:40:56.035 -> 00/00/2000 00:00:00
10:40:56.035 -> RTC lost confidence in the DateTime!
10:40:56.136 -> 00/00/2000 00:00:00
10:40:56.136 -> RTC lost confidence in the DateTime!
10:40:56.236 -> 00/00/2000 00:00:00
10:40:56.283 -> RTC lost confidence in the DateTime!
10:40:56.337 -> 00/00/2000 00:00:00
10:40:56.384 -> RTC lost confidence in the DateTime!
10:40:56.437 -> 00/00/2000 00:00:00
10:40:56.437 -> RTC lost confidence in the DateTime!
10:40:56.537 -> 00/00/2000 00:00:00
10:40:56.584 -> RTC lost confidence in the DateTime!
10:40:56.639 -> 04/18/2019 10:40:45
10:40:56.723 -> 04/18/2019 10:40:45
10:40:56.854 -> 04/18/2019 10:40:45
10:40:56.939 -> 04/18/2019 10:40:45
10:40:57.040 -> 04/18/2019 10:40:45
10:40:57.140 -> 04/18/2019 10:40:45
10:40:57.241 -> 04/18/2019 10:40:45
10:40:57.340 -> 04/18/2019 10:40:45
10:40:57.441 -> 04/18/2019 10:40:45
10:40:57.541 -> 04/18/2019 10:40:45
10:40:57.641 -> 00/00/2000 00:00:00
10:40:57.688 -> RTC lost confidence in the DateTime!
10:40:57.788 -> 00/00/2000 00:00:00
10:40:57.788 -> RTC lost confidence in the DateTime!
10:40:57.842 -> 00/00/2000 00:00:00
10:40:57.888 -> RTC lost confidence in the DateTime!
10:40:57.942 -> 00/00/2000 00:00:00
10:40:57.989 -> RTC lost confidence in the DateTime!
10:40:58.089 -> 00/00/2000 00:00:00
10:40:58.089 -> RTC lost confidence in the DateTime!
10:40:58.190 -> 00/00/2000 00:00:00
10:40:58.190 -> RTC lost confidence in the DateTime!
10:40:58.243 -> 00/00/2000 00:00:00
10:40:58.290 -> RTC lost confidence in the DateTime!
10:40:58.375 -> 00/00/2000 00:00:00
10:40:58.375 -> RTC lost confidence in the DateTime!
10:40:58.476 -> 00/00/2000 00:00:00
10:40:58.523 -> RTC lost confidence in the DateTime!
10:40:58.565 -> 04/18/2019 10:40:47
10:40:58.697 -> 04/18/2019 10:40:47
10:40:58.797 -> 04/18/2019 10:40:47
10:40:58.897 -> 04/18/2019 10:40:47
10:40:58.998 -> 04/18/2019 10:40:47
10:40:59.098 -> 04/18/2019 10:40:47
10:40:59.199 -> 04/18/2019 10:40:47
10:40:59.299 -> 04/18/2019 10:40:47
10:40:59.400 -> 04/18/2019 10:40:47
10:40:59.500 -> 04/18/2019 10:40:47
koosiekloek
@koosiekloek
have a look here might help you Lib
msparks/arduino-ds1302@5650f7d
Michael Miller
@Makuna
More than likely there is a communications problem of some sort.
I looked at their code, I have the delays already. I am following the specification of the part. The only weird thing they do is that the transition from write to read, they set the pin to input BEFORE the clock drops.
I am away from my hardware so I can't test this.
Try the ThreeWireCommFix branch and see if this fixes it for you.
koosiekloek
@koosiekloek
Thanks a mill, i am also not with my hardware now but will test in the morning and report back
koosiekloek
@koosiekloek
The changes you made fixed my problem thanks a million for the help and time spent! So much appreciated!
0.3Sec Delay
09:15:47.540 -> compiled: Apr 19 201909:15:35
09:15:47.573 -> 04/19/2019 09:15:35
09:15:47.573 -> RTC is the same as compile time! (not expected but all is fine)
09:15:47.640 -> 04/19/2019 09:15:35
09:15:47.908 -> 04/19/2019 09:15:35
09:15:48.212 -> 04/19/2019 09:15:36
09:15:48.517 -> 04/19/2019 09:15:36
09:15:48.822 -> 04/19/2019 09:15:36
09:15:49.129 -> 04/19/2019 09:15:37
09:15:49.437 -> 04/19/2019 09:15:37
09:15:49.742 -> 04/19/2019 09:15:37
09:15:50.017 -> 04/19/2019 09:15:38
09:15:50.325 -> 04/19/2019 09:15:38
09:15:50.634 -> 04/19/2019 09:15:38
09:15:50.942 -> 04/19/2019 09:15:38
09:15:51.219 -> 04/19/2019 09:15:39
09:15:51.528 -> 04/19/2019 09:15:39
09:15:51.831 -> 04/19/2019 09:15:39
09:15:52.136 -> 04/19/2019 09:15:40
Michael Miller
@Makuna
Great, I will merge that in and put out a new release
koosiekloek
@koosiekloek
:D
Leandro Boari
@leandrorepos
Hi!