Can I act _as_ a TM1651?

[LordMike]

Hi,

This seems cool - I'm just now realizing that the TM16xx protocol is both a read and a write one, so it seems that libraries will support both - or at least this does (due to the buttons thing).

I have a situation where I want to take over a control panel for a device (a heater) and replace it with an ESP32. The panel contains a TM1651 chip to drive a 2-digit display, the heater communicates with the panel and has the two lines needed (CLK, DIO). The panel also has a beeper and a button.

Ideally, I'll interact with the heater through this data line, and be able to read the display codes the control panel was meant to show (I'll send them over wifi). Likewise, in the end, I want to send button pushes through the data line back to the heater to have it turn on/off. I have no idea how the beeper is hooked up - maybe it uses one of the not-yet-mapped wires (6 total) and is completely separate.

Is it possible to act as a TM16xx chip, and read segments and send button pushes (or keys) through this library?

Mike.

[maxint-rd]

Hello Mike, interesting concept! I believe it should be possible to program the esp32 to emulate a TM1651, but unfortunately the TM16xx library is not implemented to do that. All it does is sending commands and data according the chip specific protocol and where possible it also reads button state.

You intend to do the reverse: receive commands and data and send the state of virtual buttons upon request. After receiving a command you want to interpret the data and act accordingly. To implement such feature you first need to make a state machine that detects activity on the DIO and CLK lines to receive the commands and data. Based on the received command it would change state to perform the requested action.

One of my ongoing side projects is to make an ATtiny13A as I2C slave to form an adressable bridge to other chips such as TM16xx chips. Due to limited features I resorted to bitbanging the I2C protocol, without interrupts. One of the challenges is to keep up with received data while performing appropriate actions.

Since the ESP32 is much more powerful (higher speed, more cores, more RAM, etc.) you might be succesful in using existing interfaces such as SPI or using interrupts. Perhaps you can use my library to to research the protocol and to send controlled data to test the ESP receiving that data. I strongly recommend you to also use a logical analyser to further examine the communication.

Hopefully these thoughts were helpful. Although I find your project interesting, unfortunately I don't have the means to provide support. Wish you all the best!

[LordMike]

If I had to start somewhere, is there a protocol or a keyword I can search for to find if someone else has made a similar project?

I'm completely oblivious to the ins and outs of the binary protocols. Is SPI similar to TM16xx? Is I2C (I'm thinking not because it's adressable, right?) ?

Will the TM16xx send data unprompted, or will it only respond to commands? I'm also kinda baffled that (seemingly) noone has made a project like this before.. It must've happened that someone was on the same side as me of some device that communicated using this :P

[maxint-rd]

Hello Mike, I'm not aware of anyone having done such a project yet. Most projects I've encountered involved using premade or homemade modules, using bare chips or reusing the display part of a used device. If you search for TM1651, you'll most likely find those kinds of projects, if any. Perhaps adding "simulate" or "emulate" as keywords will yield different results, but I don't expect many people having done such project.

In your case I would first complete the tracing, to confirm that the button is indeed connected to the K1 line of the TM1651 and to find out the connections of the buzzer. The button might also be connected directly to the MCU of your heater-panel, in which case simulating the TM1651 is limited to reading the displayed value. Unless you control the panel MCU, your ESP can only follow it's actions. Simulating button presses could be one way of controlling it, but it requires fine orchestration.

Perhaps you want to post pictures of your panel PCB here? You may find this TM1680 issue regarding display modules interesting reading too.

With regards to the TM1651 protocol: For full protocol information you need to read the datasheet. Titan Micro uses different protocols for specific chips. The protocol mostly depends on the number of interface wires. The two wire interfaces for the chips that support buttons have CLK and DIO lines. The TM1651 seems similar to TM1650 which is supported by my library. The protocol lacks addressing, so it looks more like SPI than I2C, but it does use a single line for data (like I2C). When using my logical analyser I set it to SPI and tweak the settings.

As far as I know, the TM16xx chips don't send unprompted data; they only respond to commands. The first byte is the command, which is followed by one or more data bytes. The chips I know don't have interrupt pins, so button state needs to be polled. In your case it's the panel MCU that sends unprompted data and when trying to take over the control that may give you both challenges and opportunities. Good luck with that...

[maxint-rd]

It's a few months later and now someone did exactly that! In issue #45 you can find a good example of a TM1628 based dehumidifier made smart using an ESP32 emulating the TM1628 to read displayed values and to trigger the button switches remotely. It's a very nicely executed project which even includes a component to integrate with ESPhome.