-
|
I have the following RTC Clock + ESP8266 module.
I know that Tasmota has support for DS3231 chip. PCF8563T also works with I2C. I could not find any info on whether Tasmota has drivers for PCF8563T though the following discussion come to a close match: Trying to Tasmotize Ubibot WS1 #17336 Can somebody enlighten me whether any progress has been made to incorporate drivers for PCF8563T? |
Beta Was this translation helpful? Give feedback.
Replies: 7 comments 20 replies
-
|
PCF85363 is supported since Apr 2022 way before the thread you are refering |
Beta Was this translation helpful? Give feedback.
-
|
Your GPIO configuration is wrong* *on ESP32, tasmota32 as limited support for 2 buses but only a couple of drivers have been modified to support it |
Beta Was this translation helpful? Give feedback.
-
|
On ESP8266, you cannot have two I2C busses. You need to connect both the display and sensor on the same I2C pins. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks. Well I have a strange piece of hardware. If I trace the connections using continuity checks, my original diagram stands correct:
Hardware looks like this:
Display is connected to GPIO4 & GPIO5
Display works fine when I2C bus is defined for these pins. If I remove this definition and use GPIO12/GPIO14 for the I2C bus then both Display and RTC Chip get detected. However the display does not work in this configuration ie. DisplayText command does nothing. NTP Syncing works towards RTC Chip: However if I remove the internet connection and reboot, time never gets synced back from RTC Chip, but continuous attempts are being made to sync with NTP servers. What could be the reason for this? (I will park the Display Issue for now. However note that I have two units of this HW, one still running Factory Firmware. It works fine with both display and RTC Clock working at the same time. When running with the battery, the time gets saved and retrieved successfully. Unfortunately there isn't any detail published by the sellers about the original FW. I do not even know who to change the time.) Also I noticed that there is a hard coded NTP server (0.pool.ntp.org) apart from the 3 x #defines in |
Beta Was this translation helpful? Give feedback.
-
|
If all's well expect a response like this: In this case the Shelly EM3 was pulled from the bin hence the time difference between the battery powered PCF85363 and NTP. NTP synced the PCF85363 and on next power cycle it reports near realtime. |
Beta Was this translation helpful? Give feedback.
-
|
To get around the issue with the hardware seeing I2C as two busses, I'd add wires connecting gpio 4/5 to 14/12 respectively (short wires across the ESP-12E module, or what works best for you), and leave the latter two unconfigured. The I2C bus is designed to serve multiple devices on the same two pins, instead of multiple busses, and this is what Tasmota was designed for too. |
Beta Was this translation helpful? Give feedback.
-
OK. Something that I learned new. The following messages indicate the driver presence but not the presence of the actual device. I physically disconnected the display but could see the messages. That eliminated part of the confusion that I had as to how the display get detected when it is connected to a different set of pins. Next I will try soldering the wires as suggested to get the display working. |
Beta Was this translation helpful? Give feedback.
-
|
After flashing the second device configuring only 1x I2C bus, I have another confusion. The first unit which was originally configured with 2 x I2C busses detected the display only at first. Then I removed the GPIO4/5 I2C config and then it was showing two drivers getting detected. On the second unit through I have the display drivers compiled in, I defined only the GPIO12/14 as I2C for the RTC. [Note that I have not flashed the new firmware with BM8563 driver in to this device] Wonder whether some kind of caching happens when you try to detect a driver and then the GPIO's are released, the previously detected device driver still shows up. |
Beta Was this translation helpful? Give feedback.
-
|
There is no caching at all. When configuring I2C pins twice, only the first set is used, the 2nd is just ignored. When you see both BM8663 and SSD1306 on the "first unit" with I2C on gpio 12/14, are they both working? If yes, that would imply that they are already wired up reasonably, without needing the suggested extra wiring, which may still be relevant for the "second unit". |
Beta Was this translation helpful? Give feedback.
-
The way I simulated loss of internet was to remove the WAN link from the WiFi router. However the router's cache may be giving out the DNS resolution. When this happens I do not see the RTC Clock helping to to get the time synced. All I see is repeated attempts to sync via internet and the syncing resumes when WAN link is restored. In between no attempt is being made to sync from RTC. I do not see RTC driver kicking in immediately after boot like in the example above.
|
Beta Was this translation helpful? Give feedback.
-
|
In your colorful screenshots I do not see the relevant test case, which would be to first boot with both PCF85363 and NTP server access. This will allow Tasmota to synchronize the PCF85363 with the real time from the NTP server. Only near the end there is the important message about When this has been done, I'd expect the next boot to be able to get time from the PCF85363 in the same way as in the log clips posted by arendst. |
Beta Was this translation helpful? Give feedback.
-
|
It is in fact the log after a subsequent reboot. Here I tested again. When internet is there: Afterwards I disconnected internet and rebooted: It continues to look for NTP server but no attempt is made to sync from RTC |
Beta Was this translation helpful? Give feedback.
-
|
First test case could have been to reboot without disconnecting Internet, and verify whether it was actually able to get time from the PCF85363. The log suggests that the answer would be no, meaning that having Internet connection or not is likely not part of the case. Just like the log clips posted by arendst, where the 2nd boot first gets time from the PCF85363 and later synchronizes with NTP getting same time (or very close) again. Anyway, the log you posted now does indeed suggest failure to get the time from the PCF85363 after the boot. I do not know much about the chip, but your images suggest that you did not have a battery installed. Just pure speculation, but maybe it only provides time if having battery power? |
Beta Was this translation helpful? Give feedback.
-
I have a battery installed. The battery directly supplies power to the chip via a diode (reverse polarity protection and voltage drop I suppose). Anyway I have two units. I will flash the second one also and test in case if the HW is faulty. The default firmware in the unit works fine even with the separate connections of RTC and Display. May be the code changes the pin definition dynamically. Without the battery it always starts time with 00:00 but once the battery is installed, it loads correct time after a powered down period.
Although the product is called "WiFi Clock" sellers (all the sellers that I checked) have no instructions published for operation of the device or details about original code. So I have to flash them for any usage of mine (either write my own code or Tasmota) |
Beta Was this translation helpful? Give feedback.
-
|
Looking at your pictures, what made you think you have a PCF85363? From what I see it looks more like a BM8563 also supported by Tasmota. |
Beta Was this translation helpful? Give feedback.
-
|
FYI, I flashed the second unit also and configured only GPIO12/14. Same observation as first unit. So that confirms that hardware is ok. During boot PCF8563 does not get accessed. |
Beta Was this translation helpful? Give feedback.
-
|
Again, the issue is not BM or PCF. The issue is 8563 vs 85363!!! So you need USE_BM8563 |
Beta Was this translation helpful? Give feedback.
-
|
I'm responsible as I overlooked the question and pointed to USE_PCF85363 |
Beta Was this translation helpful? Give feedback.
-
|
Finally!
THANK YOU ALL! PS: |
Beta Was this translation helpful? Give feedback.
-
No issue. "To err is human!". Thanks @arendst. Even I was dumb not being able to distinguish the difference. I will try the suggestion. Thanks for being with me all this long. I am also learning new things. I will let you know how it goes. I want to configure this device as a NTP server for few Tasmota devices which use some timers where internet connection will not be available except when some manual intervention is made. |
Beta Was this translation helpful? Give feedback.
-
|
Another option for a total independent NTP time source of wifi is adding a cheap GPS receiver to Tasmota. This way you get a high precise NTP time source. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks. I have seen that. May be my next testing attempt once I acquire a GPS module. |
Beta Was this translation helpful? Give feedback.
-
|
Enabling NTP Server Just for completeness of the post, I am adding the steps that I followed in enabling the NTP server.
I have two devices running Tasmota 12.3.1.3.
Initially I had a |
Beta Was this translation helpful? Give feedback.
Finally!