Support for IOTTIMER WiFi Clock

[stefan-oskamp]

The following ESP-12 based alarm clock looks very nice and is very hacking-friendly.

Product developer page:
https://mastergong.cn/archives/364.html

Aliexpress:
https://www.aliexpress.com/item/1005006684061080.html

The naming of the item is not very consistent. IOTTIMER seems to be a series of similar items. This model is called "WHEN" but the print on the back says "THEN" -- logical isn't it.

I have bought one and I would like to run Tasmota on it. I currently use an XY-Clock with Tasmota as my smart-home-integrated alarm clock. (I had contributed the TM1650 display driver for it.) The IOTTIMER clock has a bigger display and, most importantly, has a proper enclosure.

Initially, the clock opens its own WiFi. The description explains how to enter your WiFi credentials. The form is in Chinese. Filling it in is not complicated, but you have to know that the left button (at the bottom) is the OK button. Once the clock is in your WiFi, you can look up its address in your router and connect to it. The second entry from the bottom in the main menu is "System" settings where you can change the language to English (just search for the drop-down list that contains "English" and press OK. The language does not change immediately, though.

The software is rather complete for an alarm clock, but a bit complicated. For integrating it in your smart home environment, you could trace the POST requests of the web GUI in your browser and mimic settings from you smart home central by sending the proper JSON to it. However, I prefer replacing the firmware with Tasmota.

To flash new firmware, you could just open the RTC battery compartment on the back and connect to the D0/GND/TX/RX/VCC pads that are marked accordingly. But, of course, you wouldn't know how to configure Tasmota.

For reverse engineering, you can open the clock by peeling off the display cover. (Leave the protective film on the display cover.) Slide in a prying tool at the edge and carefully lift it off the LED mask. There are two narrow strips of double-sided tape; one between the two hour digits and one to the right of the minute digits. You can then unscrew and remove the display board. After that, you can remove the controller board. The display mask is snapped onto the display board and can be easily removed. The whole thing is very nicely designed and easy to disassemble and re-assemble.

The controller board contains an ESP-12 module (ESP8266) and an RTC (R8010). It also holds the RTC battery, the three push buttons, a buzzer, and a temperature sensor (M1601).

On the display board there is a TM1640 controller, the LEDs, and the ambient light sensor.

The two boards are connected by six wires with a connector on either end.

The designer of the clock provided schematics in a post further down:
https://github.com/user-attachments/files/16987817/SCH_WHEN_V3_2024-09-13.pdf

I traced the wiring of the display board:

Segment wiring

TM1640B pinout

GRID12	1		28	GRID11
GRID13	2		27	GRID10
GRID14	3		26	GRID9
GRID15	4		25	GRID8
GRID16	5		24	GRID7
VSS	6		23	GRID6
DIN	7	TM1640B	22	GRID5
SCLK	8	Top View	21	GRID4
SEG1	9		20	GRID3
SEG2	10		19	GRID2
SEG3	11		18	GRID1
SEG4	12		17	VDD
SEG5	13		16	SEG8
SEG6	14		15	SEG7

Non-standard segment numbering

Digit segments are wired to the TM1640B in a non-standard way:

	7
8		1
	2
6		4
	5

This is the same for all digits.

Main display area (left)

The digits in this area have two LEDs per segment, controlled by separate grid lines. From the software perspective, you can think of it as two displays on top of each other and with four digits each. You could control brightness in 15 steps instead of just 7, but it would look strange and would be cumbersome to implement.

Element	Grid	Segment (a,b,c,d,e,f,g or dp)
Hour x 10	13,14	7,1,4,5,6,8,2
Alarm	13	3
PM	14	3
Hour	15,16	1-7
Upper dot	15	3
Dash	16,6	3
Lower dot	5	3
Minute x 10	5,6	7,1,4,5,6,8,2
Minute	12,2	7,1,4,5,6,8,2

Temperature display area (upper right)

Element	Grid	Segment (a,b,c,d,e,f,g or dp)
Left digit	10	7,1,4,5,6,8,2
First dec. point	11	3
Middle digit	11	7,1,4,5,6,8,2
Second dec. point	9	3
Rightt digit	9	7,1,4,5,6,8,2

Seconds display area (lower right)

Element	Grid	Segment (a,b,c,d,e,f,g or dp)
Left digit	7	7,1,4,5,6,8,2
Right digit	8	7,1,4,5,6,8,2
Dot	8	3

arendst implemented a driver for the R(X)8010 (see post further down). However, the clock has been designed with two separate I2C buses for the display board and the RTC. Tasmota on ESP8266 does not support two I2C buses, so we cannot use the RTC for now.

Edit:

• Corrected information about temperature sensor and ambient light sensor.
• Added photos
• Added link to schematics and documentation of segment wiring

[s-hadinger]

The protocol for TM1640 looks very simple. Happy to provide you any needed support to develop the drivers.

Since it's ESP8266 based, no possibility to use Berry. You will need to go for C++

[stefan-oskamp]

Yeah, did the same for the XY-Clock, i.e., created the TM1650 driver in C++ based on similar code.

[MacSass]

Interesting - thanks for sharing and good luck with the drivers, although I find it a bit on the expensive side with 27€ here from AliExpress. Roughly 4 times the price of XYclock, although the enclosure is nice of course. Similar "non wifi" models are available for about 1/3 of the price.

Also I´d be interested to understand how "dark" you can dim the LED as I was looking for this being my night clock with only very dim light at night (the XY is way to bright even on lowest level).

Looks like we will be seeing more and more "wifi clocks" from Chinese manufacturers (here is another one https://de.aliexpress.com/item/1005006744696913.html), guess it is only a matter of time until some with ESP32 crop up too.

I´ll keep watching - but although being a wifi-clock aficionado I´m currently not getting that model :-) - good luck!

[stefan-oskamp]

@MacSass, specifically for you a comparison of the IOTTimer with the XY-Clock in daylight and in the dark:

Displaydimmer is set to 100 % for daylight and minimum level in the dark.
The XY-Clock is covered by a piece of plain white paper. The IOTTimer has a black-tinted screen in front of the light-diffusing mask.

The IOTTimer is a lot bigger, but I reckon it will be a lot less bright in total at night.

[sfromis]

While the images indeed appear to show the IOTTimer being less bright per segment area, it has a lot larger segments, and two additional smaller digits. Maybe the total emitted light (if not looking directly on the digits) will not be all that dissimilar. That also seems to be indicated by the table illumination, even if the different color temperatures makes it harder to compare.

Of course, photos always have the risk of the camera (especially if a smartphone) "improving" the image, instead of "only" showing how much light the sensor pixels captured.

[MacSass]

Thanks @stefan-oskamp for taking the time to take those pictures - I´m afraid for me it still would be too bright - my GFis extremely sensitive to anything bright at night ... sometimes even a single aircon status LED has to be taped ...
Right now, in order to satisfy my Wifi-Clock addiction, I plan to use a ESP32 with an LCD - that gives me all the flexibility in what I want to put on the screen, as well as it allows me to adjust brightness by using non-white (grey) letters.

I´m just lacking time right now to get that put together ...

Thanks again for your work on this - still have several Wifi Clocks right in front of me on my "working" table :-)

[s-hadinger]

Awesome.

About Led darkness, the current Tasmota implementation uses 10 bits (1024 levels), so the darkest you can get out-of-the-box is 1/1024th of the full power. This might seem too light for a night clock.

The bad news is that we are quite limited on ESP8266, because it is entirely interrupt driven. The PWM interrupt driver took years to stabilize. While in theory we could do better, nobody is willing to reopen the interrupt driver implementation.

On ESP32 (including ESP32C3), PWM is hardware based so we could much more easily tweak the resolution.

I'm just hoping that the manufacturers will quickly move to ESP32C3 or even ESP32C2 (ESP8684)

[stefan-oskamp]

The PWM for the LEDs is done by the TM16xx controllers. Brightness is controlled over I2C with seven levels resolutions (plus 0, IIRC). So that should not be an issue.

The IOTTIMER clock has display screen that is quite dark. It's not one of these mirror-type screens that you see a lot in cheap clocks on Aliexpress. It has a smooth black tint. I can provide a comparison picture of the XY-Clock and the IOTTIMER clock once I have re-assembled the latter.

BTW: The sensor on the display board actually is the photo resistor. The original firmware controls the display brightness based on the ambient light.

[s-hadinger]

Interesting enough, it is now out of stock on Alix

[MacSass]

A comparison of the display on low-level would be great!
Also if you don´t mind a picture of the disassembled clock would be interesting to see .. thanks!
Wondering if the temperature sensor inside makes any sense or if it gets heated up by the electronics / display ...

[Jason2866]

For clock addicted people ;-) This one looks nice too. Could imagine that the matrix LEDs are driven from the esp8266

[trip5]

I forgot to follow the new thread but yes this one is very nice. I have 3 now... two large and 1 small red.

I am very proud of my ESPHome YAML: https://github.com/trip5/EspHome-Led-PixelClock

[MacSass]

As we seem to be the "wifi clock addicted self-help group" here - just today I found a very nice "nixie" style clock that uses small LCD or OLEDs to fake real nixie tubes.

It´s driven by an ESP32 as you can see from a video here:
https://www.youtube.com/watch?v=zWBmsEkEooA

The "original" design is fairly expensive, but there are several clones that start at around 34€ at AliExpress:
https://de.aliexpress.com/item/1005006796853777.html

Some guys already developed alternat firmware here:
https://www.nixies.us/projects/elekstubeips-clock/elekstube-ips-v1/

Would be interesting to find out if that could run Tasmota as well. Does Tasmota support more than one display at a time?

I´m tempted to get one to add to my wifi clock collection ;-)

[sfromis]

#define USE_MULTI_DISPLAY should allow up to 3 displays.

[barbudor]

but then MAX_MULTI_DISPLAYS can be overridden

#ifdef USE_MULTI_DISPLAY

#ifndef MAX_MULTI_DISPLAYS
#define MAX_MULTI_DISPLAYS 3
#endif

it only seems to drive the size of that array:

struct MULTI_DISP {
  Renderer *display;
  uint16_t fg_color;
  uint16_t bg_color;
  int16_t disp_xpos;
  int16_t disp_ypos;
  uint8_t color_type;
  uint8_t auto_draw;
  uint8_t model;
  uint8_t used;
} displays[MAX_MULTI_DISPLAYS];

[MacSass]

For that Nixie thingie it obviously would have to be 6.
I have never looked at Tasmota and displays - but I´m really tempted to get one now ... 34€ is not too bad and I like the look ...

[MacSass]

Yes - I admit:
I suffer from WCAS (Wifi Clock Addiction Syndrom) - could not resist it any longer and just ordered the Nixie clock from the link above :-)

[sfromis]

Another good candidate for a Tasmota clock is the Unexpected Maker Bling! with 8x40 neopixels (spacing 2 mm), RTC chip, I2S audio (speaker connector and onboard mic), ESP32-S3 with PSRAM, buttons, battery connector, SD card and Stemma connector. Somewhat similar to the Ulanzi TC001, but better specs and much smaller. Still not cheap....

[MacSass]

Yes - that looks really nice and flexible - although really not cheap (50$) and seems to be out of stock.

[master-gong]

I'm surprised to see discussions about this clock here. As a technical person, I know that creating a good product is not easy, and issues can arise in various aspects, such as the confusion with model naming. I'm providing the hardware schematic of this clock, hoping it will be helpful. If needed, I can also provide a sample program for the display board driver later. Although it's known that the TM1640 is used, creating a driver requires a code table, and testing and organizing this takes a lot of time.

I noticed some comments about pricing. I don't have the time or resources to manage international sales channels, so currently, it's only sold in China. The domestic price is significantly lower than similar products. Considering the completion, functionality, performance, and price, it's a highly cost-effective clock, and the software is continuously updated. As for the pricing in your region, I can't do much about it for now. I understand that traders have additional costs like shipping, after-sales service, and product loss, and they also need to ensure some profit, which raises the price.

SCH_WHEN_V3_2024-09-13.pdf
BOM_WHEN_V3_WHEN_V3_2024-09-13.xlsx

[sfromis]

Agree that the price seems well in line with what I'd expect for such a desk-ready product.

While I'd prefer ESP32 instead of ESP8266, it would be straightforward to replace the ESP-12 module with an ESP32-based one in the same form factor. Such modules exist (at least) with ESP32-C3 and ESP32-S2.

[trip5]

@master-gong I'm curious how much do you actually get from the Aliexpress sellers who sell your clock? Do you get anything?

Sometimes it feels like certain tech things, we do because we love it and there's very little money to be had from it.

That said, it's a fantastic design and if I wasn't knee-deep in digital clocks already, I'd definitely go for it.

[master-gong]

@Noschvie During the early selection phase, we considered the ESP32, but chose the ESP8266 due to cost reasons. Currently, the ESP8266's resources can meet the needs of a standard clock. For more advanced clocks in the future, we'll use the ESP32 because the ESP8266 has limited pins and PWM capabilities. However, this will take some time.

[master-gong]

@trip5 The significance of traders purchasing from me:
1.It allows my clocks to reach a global audience, which is exciting even if there aren't specific benefits, haha.
2.I don't have to deal with after-sales issues like I do with domestic users, and traders usually don't require my technical support. However, I do respond to emails from international users.
3.Each clock sold adds a bit to my income. It's not much, but every little bit helps. My profit per unit is about a dozen RMB, which is roughly 1-2 Euros.
I started this project out of passion, creating clocks for myself and gradually selling them online, improving based on user feedback. Initially, I worked with clock modules, and the WHEN clock is my first formal product since I designed every part myself. This is quite fulfilling as a tech enthusiast. I plan to design more clocks in different styles, but my progress is slow due to various commitments. I hope to earn enough to keep going.

[trip5]

Thanks for the reply @master-gong - that is really encouraging to hear. I guess you can't make a living off it but some part of me always wonders when I see items on Aliexpress if I am supporting a factory owner or the person who put the work in to develop something cool. I am happy for you!

[arendst]

@stefan-oskamp any progress on the drivers?

If not I'll focus on the rtc chip. Just ordered one clock module today based on the @master-gong info.

[stefan-oskamp]

Hi @arendst, I have not made any progress due to other projects and activities that require good weather :-). But with summer ending here in NL and with the attention of Mr. Tasmota himself and the designer of the clock (master-gong), I'm now feeling hard-pressed to pick up work on it again.

If you could look into the RTC, that would be great.

I will have a look at the TM1640 and the docs provided by master-gong.

[arendst]

As a quote from @master-gong

If needed, I can also provide a sample program for the display board driver later

I suppose you'll benefit a lot from his driver code.

[sfromis]

I was playing with a Berry driver for a 8x8 TM1640 display some time ago, didn't do much with it, but it does illustrate how it can be handled:
http://sfromis.strangled.net/tasmota/berry/examples/tm1640.be

[stefan-oskamp]

Thanks, @sfromis, that looks a lot like the other code samples I found for the TM1640, especially the bit-banging instead of I2C. I will do the same for the Tasmota display driver.

[stefan-oskamp]

The RTC (R8010) and the TM1640 are connected on separate I2C buses:

Is that actually possible with Tasmota on ESP8266?

[arendst]

Good find!

In that case we just drop the RTC and go for NTP and TM1640 (unless I find a way to support second I2C bus on ESP8266).

[stefan-oskamp]

Rewiring the I2C of the RTC would be feasible. You would have to bend the pins of the RTC off the pads and add two 10 mm wires. But I agree, that is not ideal for most users.

@arendst, do you think it is possible to implement I2C as part of the R8010 driver, or do you see any other option in Tasmota for ESP8266 to deal with the two I2C buses?

[stefan-oskamp]

Our posts crossed. Starting without RTC is a good pragmatic choice.

[sfromis]

What I meant by rewiring was simpler, just adding small connecting wires on the ESP-12 module, and then leaving one pair unconfigured (floating).

[arendst]

Support for RX8010 is now in dev branch. It supports both busses on ESP32.

[stefan-oskamp]

I updated my original post and added the link to the schematics and documentation about the wiring of the LED segments (traced by me).

The driver will be very specific for this clock because of how segments are wired to the TM1640B.

I'm thinking of using xdsp_20_tm1650.ino as a basis. I don't think it makes sense to merge support for the TM1640B and how it is wired into that code. So, I would create a new xdsp_... driver for it.

@master-gong, if you could provide sample code containing the mapping between digits and segments, that would be great.

[master-gong]

I just extracted the relevant display driver part from my source code. Please refer to the usage examples. I hope this helps you. I'm using software-emulated I2C.
https://github.com/master-gong/DC01L3L9-TM1640-.git

[stefan-oskamp]

Thanks for sharing your code, @master-gong.

The link in your comment does not work, therefore I repeat it here pointing to the right location:
https://github.com/master-gong/DC01L3L9-TM1640-

I identified the mapping in accordance with the segment wiring and the bit-banging code (soft I2C). Both will be useful in implementing the driver.

I also searched for other sample code for the TM1640, and they all seem to use bit-banging. I'm not even sure whether the wire protocol actually is I2C. Therefore, I plan on doing the same for the Tasmota driver. This way, we still have the I2C bus of the ESP8266 for the RTC.

[sfromis]

In my testing with Berry and another TM1640-based display, it worked fine with standard I2C communication.

Of course, on ESP8266 without any hardware I2C, bit-banging is the only option.

[master-gong]

I'm under the impression that the TM1640 communication protocol isn't standard I2C, but rather a similar one. I suggest using software to emulate the protocol. The data volume is small, and the blocking time is short. By reducing the delays, you can make the communication even more efficient.

[sfromis]

Right, I got something mixed up. TM1640 is not at all I2C.

[arendst]

Hi @stefan-oskamp any progress?

I received mine recently and verified it seemed to work fine with provided code.

I then installed Tasmota-4M.bin and alas fail to see the M1601B (should be DS18B20 compatible) and the I2C RTC. In fact I don't see anything on the I2C bus and as it uses GPIO16 I never expect to see anything on the bus either as I2C is not suppose to work on this pin on ESP8266. Wonder if it ever worked in the original code.

This is the config I use based on the schematics:

And this is the power on log:

00:00:00.001 HDW: ESP8266EX
00:00:00.025 UFS: FlashFS mounted with 1992 kB free
00:00:00.085 CFG: Loaded from File, Count 36
00:00:00.091 QPC: Count 1
00:00:00.104 MCP: Invalid template
00:00:00.107 ROT: Mode 1
00:00:00.109 SRC: Restart
00:00:00.110 Project tasmota - IotTimer Version 14.2.0.4(theo)-2_7_7(2024-09-23T13:15:16)
00:00:00.128 DSB: Sensors found 0
00:00:00.184 WIF: Attempting connection...
00:00:01.001 WIF: Connecting to AP1 indebuurt_IoT Channel 11 BSSId 18:E8:29:CA:17:C1 in mode 11n as iottimer...
00:00:02.515 WIF: Connected
00:00:02.768 HTP: Web server active on iottimer with IP address 192.168.2.187
00:00:04.296 NTP: No reply from 127.0.1.1
00:00:04.317 RTC: UTC 2024-09-23T12:07:57Z, DST 2024-03-31T02:00:00, STD 2024-10-27T03:00:00
14:07:57.000 RTC: Synced by NTP
14:07:57.232 MQT: Attempting connection...
14:07:57.246 MQT: Connected
14:07:57.249 MQT: tele/iottimer/LWT = Online (retained)
14:07:57.251 MQT: cmnd/iottimer/POWER = 
14:07:57.253 MQT: Subscribe to cmnd/iottimer/#
14:07:57.255 MQT: Subscribe to cmnd/tasmotas/#
14:07:57.257 MQT: Subscribe to cmnd/DVES_1B1E5E_fb/#
14:07:57.265 MQT: tele/iottimer/INFO1 = {"Info1":{"Module":"Generic","Version":"14.2.0.4(theo)","FallbackTopic":"cmnd/DVES_1B1E5E_fb/","GroupTopic":"cmnd/tasmotas/"}}
14:07:57.277 MQT: tele/iottimer/INFO2 = {"Info2":{"WebServerMode":"Admin","Hostname":"iottimer","IPAddress":"192.168.2.187"}}
14:07:57.288 MQT: tele/iottimer/INFO3 = {"Info3":{"RestartReason":"Software/System restart","BootCount":16}}
14:07:57.299 MQT: stat/iottimer/RESULT = {"POWER":"OFF"}
14:07:57.304 MQT: stat/iottimer/POWER = OFF
14:07:58.327 QPC: Reset
14:08:00.243 APP: Boot Count 16
14:08:01.338 CFG: Saved to flash at 3FB, Count 37, Bytes 4096
14:08:01.347 MQT: tele/iottimer/STATE = {"Time":"2024-09-23T14:08:01","Uptime":"0T00:00:10","UptimeSec":10,"Heap":24,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"POWER":"OFF","Wifi":{"AP":1,"SSId":"indebuurt_IoT","BSSId":"18:E8:29:CA:17:C1","Channel":11,"Mode":"11n","RSSI":100,"Signal":-49,"LinkCount":1,"Downtime":"0T00:00:04"}}
14:08:01.412 MQT: tele/iottimer/SENSOR = {"Time":"2024-09-23T14:08:01","ANALOG":{"Voltage":2.345}}
14:08:04.811 CMD: i2cscan
14:08:04.812 SRC: WebConsole from 192.168.2.1
14:08:04.815 CMD: Grp 0, Cmd 'I2CSCAN', Idx 1, Len 0, Pld -99, Data ''
14:08:04.835 MQT: stat/iottimer/RESULT = {"I2CScan":"No devices found"}

I hope you have more luck.

BTW the buttons and buzzer work OK.

NOTE1: A test for I2C on a wemos using GPIO16 and GPIO14 fails as expected. Bad board design.

[master-gong]

@stefan-oskamp The RTC driver I used also employs IO port simulation of I2C timing, rather than using the chip's designated pins. My approach prioritizes convenient hardware wiring, with software adapting to the hardware setup. I'd be happy to share the driver program I used.
RTC.zip

[arendst]

Thx for the RTC.zip. Tasmota is kind of bound to the arduinoespressif8266 framework so your solution won't work. I fiddled around with the framework and am no able to use GPIO16 as I2C_Clk needed for IotTimer:

00:00:00.001 HDW: ESP8266EX
00:00:00.023 UFS: FlashFS mounted with 1992 kB free
00:00:00.083 CFG: Loaded from File, Count 72
00:00:00.088 QPC: Count 1
00:00:00.094 I2C: Bus1 using GPIO16(SCL) and GPIO14(SDA)
00:00:00.096 I2C: RX8010 found at 0x32
00:00:00.099 RTC: UTC 2084-09-24T13:45:21Z, DST 2084-03-26T02:00:00, STD 2084-10-29T03:00:00
15:45:21.000 RTC: Synced by RX8010
15:45:21.015 MCP: Invalid template
15:45:21.020 ROT: Mode 1
15:45:21.022 SRC: Restart
15:45:21.024 Project tasmota - IotTimer Version 14.2.0.4(theo)-2_7_7(2024-09-24T15:44:11)
15:45:21.041 DSB: Sensors found 0
15:45:21.339 WIF: Attempting connection...
15:45:22.001 WIF: Connecting to AP1 indebuurt_IoT Channel 11 BSSId 18:E8:29:CA:17:C1 in mode 11n as iottimer...
15:45:23.514 WIF: Connected
15:45:23.766 HTP: Web server active on iottimer with IP address 192.168.2.187

This is the console output WITHOUT the suggested hardware change but with a tweaked framework file core_esp8266_si2c.cpp:

static inline __attribute__((always_inline)) void SCL_LOW(const int twi_scl)
{
//    GPES = (1 << twi_scl);
    (twi_scl != 16) ? GPES = (1 << twi_scl) : GP16O &= ~1;
}
static inline __attribute__((always_inline)) void SCL_HIGH(const int twi_scl)
{
//    GPEC = (1 << twi_scl);
    (twi_scl != 16) ? GPEC = (1 << twi_scl) : GP16O |= 1;
}
static inline __attribute__((always_inline)) bool SCL_READ(const int twi_scl)
{
//    return (GPI & (1 << twi_scl)) != 0;
    return (twi_scl != 16) ? (GPI & (1 << twi_scl)) != 0 : (GP16I & 0x01);
}

void Twi::init(unsigned char sda, unsigned char scl)
{
    // set timer function
    ets_timer_setfn(&timer, onTimer, NULL);

    // create event task
    ets_task(eventTask, EVENTTASK_QUEUE_PRIO, eventTaskQueue, EVENTTASK_QUEUE_SIZE);

    twi_sda = sda;
    twi_scl = scl;
    pinMode(twi_sda, INPUT_PULLUP);
    if (16 == twi_scl) {
      pinMode(twi_scl, OUTPUT);
    } else {
      pinMode(twi_scl, INPUT_PULLUP);
    }
    twi_setClock(preferred_si2c_clock);
    twi_setClockStretchLimit(150000L); // default value is 150 mS
}

As the tweak changes the internal timings of the software I2C protocol I'm not sure what the impact will be at higher I2C speeds. For now I won't release the change to our ESP8266 core library.

EDIT: I've provided the changes to our core team. If incorporated it will fix GPIO16 as I2C CLK.

[arendst]

Latest dev branch v14.2.0.5 now supports I2C CLK on GPIO16 for ESP8266. No need for hardware hack anymore.

[stefan-oskamp]

Thanks, @arendst, that's great news. If that goes into the main branch, I will probably remove my h/w hack.

I will now look into the display driver for Tasmota. I was wondering whether the driver should be called TM1640B, or if it is better to call it IOTTimer because the same output would result in a completely different display on other devices using the TM1640B. But then again, it might be possible to control this by means of the display sub-type in the configuration.

[arendst]

Let's call it iottimer for now. A rename is the most simple task to do ;-)

[arendst]

Latest dev branch v14.2.0.5 now supports M1601B configured as DS18x20.

[Noschvie]

Hello
I successfully installed tasmota-4M.bin.gz on this device and selected the IotTimer template, but the display remains dark... what did I do wrong?
Thanks!

00:00:00.001 HDW: ESP8266EX
00:00:00.016 UFS: FlashFS mounted with 2000 kB free
00:00:00.079 CFG: Loaded from File, Count 41
00:00:00.085 QPC: Count 1
00:00:00.098 Project tasmota - Tasmota Version 14.2.0.6(692a0ca-tasmota-4M)-2_7_7(2024-09-26T15:41:04)
00:00:01.001 WIF: Connecting to AP1 neunzehn.iot Channel 6 BSSId 34:FC:B9:B7:14:81 in mode 11n as tasmota-51F593-5523...
00:00:02.533 WIF: Connected
00:00:02.785 HTP: Web server active on tasmota-51F593-5523 with IP address 192.168.1.138
19:55:28.509 RSL: INFO1 = {"Info1":{"Module":"IotTimer","Version":"14.2.0.6(692a0ca-tasmota-4M)","FallbackTopic":"cmnd/DVES_51F593_fb/","GroupTopic":"cmnd/tasmotas/"}}
19:55:28.515 RSL: INFO2 = {"Info2":{"WebServerMode":"Admin","Hostname":"tasmota-51F593-5523","IPAddress":"192.168.1.138"}}
19:55:28.525 RSL: INFO3 = {"Info3":{"RestartReason":"Software/System restart","BootCount":11}}
19:55:28.533 RSL: RESULT = {"POWER":"ON"}
19:55:28.537 RSL: POWER = ON
19:55:31.302 QPC: Reset
19:55:33.245 RSL: STATE = {"Time":"2024-09-26T19:55:33","Uptime":"0T00:00:10","UptimeSec":10,"Heap":24,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":27,"MqttCount":0,"POWER":"ON","Wifi":{"AP":1,"SSId":"neunzehn.iot","BSSId":"34:FC:B9:B7:14:81","Channel":6,"Mode":"11n","RSSI":100,"Signal":-47,"LinkCount":1,"Downtime":"0T00:00:04"}}
19:55:33.305 RSL: SENSOR = {"Time":"2024-09-26T19:55:33","ANALOG":{"Voltage":3},"M1601":{"Id":"000000001A7B","Temperature":29.5},"TempUnit":"C"}
19:55:54.043 CMD: i2cscan
19:55:54.065 RSL: RESULT = {"I2CScan":"Device(s) found at 0x32"}

[stefan-oskamp]

I have changed the loop function to iterate through all LEDs times all brightness levels, one every 50 ms. (See https://github.com/stefan-oskamp/Tasmota/blob/development/tasmota/tasmota_xdrv_driver/xdrv_91_tm1640.ino)
Binary:
firmware.zip

[Noschvie]

Got it self-compiled, loaded and works with this configuration:

Thanks for now!

[stefan-oskamp]

I have checked in an initial working version of the xdsp_21_iottimer.ino and removed the LED testing loop from xdrv_91_tm1640.ino in https://github.com/stefan-oskamp/Tasmota/tree/development/tasmota.

You need the following in user_config_override.h:

#ifndef USE_RTC_CHIPS
#define USE_RTC_CHIPS                          // Enable RTC chip support and NTP server - Select only one
#endif
#ifndef USE_RX8010
#define USE_RX8010                           // Enable RX8020 RTC
#endif

#ifndef USE_TM1640
#define USE_TM1640
#endif
#ifndef USE_DISPLAY_IOTTIMER
#define USE_DISPLAY_IOTTIMER
#endif
#ifndef USE_DISPLAY
#define USE_DISPLAY
#endif
#ifndef USE_DISPLAY_MODES1TO5
#define USE_DISPLAY_MODES1TO5
#endif

Use the following commands in the console to initialize the clock:

displaymodel 21
displaytype 0
displaymode 1
displaydimmer 50
displayclock 2

DisplayMode 1 means show the clock.
DisplayDimmer is in per-cent and needs to be set to at least 11 to be on.
DisplayClock 2 is 24-hour mode, Default is 1 (12-hour mode), not remembered after power cycle.

My timezone settings:

{"Timezone":99}
{"TimeStd":{"Hemisphere":0,"Week":0,"Month":10,"Day":1,"Hour":3,"Offset":60}}
{"TimeDst":{"Hemisphere":0,"Week":0,"Month":3,"Day":1,"Hour":2,"Offset":120}}

Binary:
firmware.zip

Edit:

• Had a typo in the user_config_override.h extract, above.

[Noschvie]

Hi Stefan,
excellent work, thank you very much. Was able to compile, load and start the firmware, looks pretty good :-)
I'll take a look at the changed files over the weekend.
What I noticed is that after a firmware upload or restart, the value of displaydimmer is displayed as 50, but the display is actually shown much more dimmed. A new version of displaydimmer 50 corrects this. However, it is purely cosmetic...

[stefan-oskamp]

Hi Norbert, I changed two things that I just committed:

1. No blinking colon
2. No leading zero hour.

But there are still few things to fix/add:

• Initial dimming
• Why are there 18 buttons shown on the main page of the web console
• It does not remember the hour format ("DisplayClock 2" for 24-hour format)
• Display the temperature in the upper right sub-display
• Automatic dimming using photo diode? (I prefer rule/timer based dimming based on sunrise/sunset)
• Display the alarm status (rule-based, upper dot in ten-hour digit as virtual LED?)

[stefan-oskamp]

Update:

• The reading of the builtin temperature sensor is shown in the upper right.
• Auto adjustment of the display brightness based on the ADC value of the builtin photo diode.
• Showing the ⏰ symbol if Timer 0 is enabled.
• Showing the PM symbol in non-24-hour mode when time is p.m.

Source:
https://github.com/stefan-oskamp/Tasmota/tree/development/tasmota

Binary:
firmware.zip

To do:

• Setting DisplayClock 2 (24 hour mode) is not remembered.
• Get rid of the 16 extra buttons on the main web page. No idea where these come from.
• Remove code for generic display functions (not very useful for this "display")
• Display the date instead of, or alternating with, the time. Does anyone want this?

[Noschvie]

Hi Stefan @stefan-oskamp : what should I do to display the temperature from a remote sensor? Thanks!

[arendst]

Great answer. I use the same trick for the Sonoff POWR3xxD and THR3xxD. Have a look at file xdrv_87_esp32_sonoff_tm1621.ino for inspiration.

[stefan-oskamp]

I just queried the GlobalTemp in the web console and it returned the local temperature.

I then set the GlobalTemp to some different value and it already shows up in the green sub-display. Only problem now is that I don't know how to clear the GlobalTemp to switch back to the local temp.

[sfromis]

AFAICT, the global values should automatically fall back if not updated within 5 minutes.

Also, using the variation GlobalTemp2 you can point at the temperature source from the TelePeriod data, and this is actually where global_sensor_index is used.

The value is in TasmotaGlobal.temperature_celsius, and you can convert to the configured unit like this:
float temperature = ConvertTempToFahrenheit(TasmotaGlobal.temperature_celsius);
(Still returns celsius if that's the chosen unit)

[stefan-oskamp]

Indeed, when I set GlobalTemp to some random value, it will be reset after exactly five minutes. But it is reset to 3.8 instead of 22.something. When I then set GlobalTemp2 to 1, it displays the internal temperature correctly. It seems you need to set GlobalTemp2 to 1, even if it is already equal to 1, to switch back to the internal temperature. It seems I have not fully understood the logic around GlobalTemp and GlobalTemp2 yet.

Anyway, I think I will use it to send the outdoor temperature to the clock from Node Red. That is more useful to me than the temperature in the sleeping room.

[Noschvie]

It seems you need to set GlobalTemp2 to 1, even if it is already equal to 1, to switch back to the internal temperature.

Same behavior with me

09:54:57.641 CMD: GlobalTemp
09:54:57.648 MQT: stat/tasmota_51F593/RESULT = {"GlobalTemp":null}
09:55:02.602 CMD: GlobalTemp2
09:55:02.609 MQT: stat/tasmota_51F593/RESULT = {"GlobalTemp2":1}
09:56:32.951 CMD: GlobalTemp2 1
09:56:32.957 MQT: stat/tasmota_51F593/RESULT = {"GlobalTemp2":1}
09:56:38.405 CMD: GlobalTemp
09:56:38.413 MQT: stat/tasmota_51F593/RESULT = {"GlobalTemp":null}
09:59:01.227 MQT: tele/tasmota_51F593/STATE = {"Time":"2024-11-13T09:59:01","Uptime":"0T15:50:12","UptimeSec":57012,"Heap":16,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":28,"MqttCount":1,"POWER1":"ON","POWER2":"OFF","POWER3":"OFF","POWER4":"OFF","POWER5":"OFF","POWER6":"OFF","POWER7":"OFF","POWER8":"OFF","POWER9":"OFF","POWER10":"OFF","POWER11":"OFF","POWER12":"OFF","POWER13":"OFF","POWER14":"OFF","POWER15":"OFF","POWER16":"OFF","POWER17":"OFF","POWER18":"ON","Wifi":{"AP":1,"SSId":"neunzehn.iot","BSSId":"A8:BD:27:64:7E:40","Channel":6,"Mode":"11n","RSSI":100,"Signal":-47,"LinkCount":1,"Downtime":"0T00:00:04"}}
09:59:01.271 MQT: tele/tasmota_51F593/SENSOR = {"Time":"2024-11-13T09:59:01","ANALOG":{"Voltage":0},"M1601":{"Id":"000000001A7B","Temperature":25.4},"TempUnit":"C"}
09:59:08.893 CMD: GlobalTemp
09:59:08.901 MQT: stat/tasmota_51F593/RESULT = {"GlobalTemp":25.4}

[sfromis]

Again, the simplest would be to have the device with the sensor publish a command to set the temperature.

Or you can subscribe to MQTT payloads, and pick a field from there, to locally issue the same command to set the temperature.
https://tasmota.github.io/docs/MQTT/#subscribeunsubscribe

[Noschvie]

@arendst @sfromis Thanks for pointing out GlobalTemp, I haven't come across this feature yet.

[Noschvie]

Have compiled with these settings (KNX is currently not in use):

#ifndef SUPPORT_MQTT_EVENT
#define SUPPORT_MQTT_EVENT
#endif

#ifndef USE_KNX
#define USE_KNX         // Enable KNX IP Protocol Support (+9.4k code, +3k7 mem)
#endif

and this rule enabled:

rule1
ON mqtt#connected DO Subscribe RemoteTemp, tele/tasmota_9FBF00/SENSOR, SCD40.Temperature ENDON
ON Event#RemoteTemp DO GlobalTemp %value% ENDON

One observation is that these logs are displayed every second (using log level "2 Info"):

17:10:58.967 RUL: MQTT#CONNECTED performs 'Subscribe RemoteTemp, tele/tasmota_9FBF00/SENSOR, SCD40.Temperature'
17:10:58.973 RSL: RESULT = {"Subscribe":"REMOTETEMP,tele/tasmota_9FBF00/SENSOR/#,SCD40.Temperature"}

Is that intentional or should these messages be suppressed in “2 Info”?

The rule listed above does not work correctly because GlobTemp is not supplied or is set to null.
Thanks again!

[sfromis]

ON mqtt#connected should only fire when MQTT connection status changes to connected, what you describe (every second) is surely not "normal". And I did a quick test to verify that your rules work for me (obviously with tweaked names). The "connected" trigger fired only after boot, and the event fires every teleperiod of the other device, keeping GlobalTemp updated. Just as expected.

Do you see "surprising" count? Normally I see "MqttCount":1 in the output of Status 6, along with "LinkCount":1 in the output of commands Status 11 or State. Much more either place would suggest "undesirable instability".

[Noschvie]

Ups, sorry, missing MQTT settings. Now GlobalTemp is updated successfully.