Reworking the AI-Thinker T5 – Part VII

For the last in our current series of updates, we’re going to modify the board to make switch K2 into a mode control button.  Pressing the button during power-on will initiate a simple light show (it’s going to be very simple …there are only three LEDs).

Switch K2 is the one closest to the LEDs and we’re going to wire it up to GPIO4 on the ESP module.  If you recall our previous instalment describing the rework for switch K1, you’ll remember that  we already added the 22K pull-up resistor for K2 at the same time, so this final bit of rework is simply adding one wire.Switch K2 Wiring  The photograph shows the routing for that wire, down the side of the original jumper block and then skirting K2 itself to connect to the pin on K2 which is closest to the corner of the PCB (the bare wire on the other side is the leg of the pull-up resistor).  With the previous experience of adding the LED and K1 wires, this last one should be a breeze.  The GPIO pin is on the side of the ESP module which is closest to the switch and soldering to the pins (at both the ESP and K2) is easier than trying to tack down to the QFP pads (without bridging them).  If you route the wire close to the jumper block you’ll only need a couple of right-angle turns and you’ll leave the area around the LEDs clear of any visual obstruction.  As with the previous mods, hold the wire down to the PCB with super-glue or melted hot-glue at several points along the run.

That was easy!

The updated code for the K2 “mode” switch is already available in the GitHub repository.  The code changes the power-on behaviour to add a 3-second delay (with a prompt squirted to the serial port) to allow the user to press switch K2 to go into “blinkenlights” mode.  The ESP will run a brief display on the LEDs and then automatically drop back into normal operating mode.  The other changes are:-

  • The power-on “I’m alive!” indicator has been changed to two, brief flashes of the green LED.
  • The sensor-read indicator has been changed to a single, brief flash of the red LED (Note:- the red LED may flash more than once if the ESP sees bad data coming from the DHT11 and issues a re-try).

As I mentioned at the start of this post, this will be the last of this series of updates.  We do have one free GPIO pin left and we do still have the beeper and its driver circuitry intact (a small miracle, given its history).  However, I have to admit to having no great longing to connect the two together at this moment in time.  Depending upon how the board performs over time in its primary role as a battery-operated sensor, I might decide to add the beeper functionality back in (but basically, if it continues to work without devouring too many batteries on a monthly basis, it will probably stay in-situ, as it is).

I also mentioned in a previous post that I would be using the pads freed-up by the removal of the relay and screw-down connector to add a diode (to allow the board to draw power from the 5v USB adapter), but as the batteries are holding up quite well so far (and because of the possibility of someone — me! — accidentally leaving the batteries in while the USB is connected), I’m postponing that to some, unspecified later date (a hairline this side of never), too.

Let me know how you get on with your own versions of these hardware and software mods and, if I remember, I’ll try to leave an update here every now and then to let you know how the modded T5 is holding up long term.

Update – Well, after a couple of months running this as a battery-powered sensor node I’d like to add a couple of observations.  First, the battery life isn’t great.  I’m using deep sleep of course, but I had trouble getting the wireless to reliably reconnect to the preconfigured access-point if I disabled wireless at start-up and only initialized it when I wanted to talk to the MQTT server (which would conserve more power).  Second, the DHT11 sensor is fairly crap (as many have noted before), with occasional readings being way, way off from the previous or following measurements.  I’ve recently had much better luck using a BME280 sensor unit, which also includes barometric pressure (as well as using the standard, Dallas one-wire sensors for just plain, vanilla temperature measurement).  On a slightly more positive note though, the ESP8266 sensor nodes do seem to be very reliable (given a good set of batteries) and the MQTT broadcast timestamp and generation of sensor data works very well.

 

 

11 thoughts on “Reworking the AI-Thinker T5 – Part VII

  1. Hi,
    enjoyed Your writing very much. Thanks for the work.
    Just in case You have not found that already, there is a download page at AI Thinker:

    http://bbs.ai-thinker.com/forum.php?mod=viewthread&tid=1237&extra=&highlight=T5&page=1

    and a quick start tutorial in Chinese at gitbooks:

    https://anxinke.gitbooks.io/balckboard/content/kuai_su_kai_shi.html

    Using google to read – my first Cinese lesson – download the Andoid app, register at the cloud and you should be able to connect and play with the LEDs on board – certainly just a short excitement. Sorry, I don’t own Android phone.

    Good luck
    Werner

    Like

    • Werner,

      Thanks for the feedback. Yes, I’m like you. I found the links but don’t have an Android phone either (plus, people who do have the necessary phone complained that it didn’t work anyway). 😦

      I was disappointed that I couldn’t get the 8051-based micro to talk to me through its own UART, either. What a waste!

      Anyway, if you’re still looking for an ESP8266 unit to do mains control, I can recommend the ITEAD Studio “Sonoff”. It’s tiny, it’s cheap and it’s easy to reprogram to use MQTT instead of needing to use their (ITEAD’s) “cloud”.

      -John-

      Like

      • Thanks John for coming back so quick.

        the Sonoff looks really nice, serious product at a good price.

        I ran into the ESP8266 abt 1 month ago and ordered several moduls of different kind, now waiting to get them. Anyway, your posting helped me a lot and I will contact you again in case I found out something worthwile. I am not very experienced in these things but I find them very interesting. Its sort of a playground for me. Maybe I go into sensor measurement. Don’t think I’ll do main control this way.

        Werner

        Like

  2. I could re-program that STC chip using keil uVision to compile and upload with a program called STC-ISP (in english fortunally). But the programing enviroment and the lack of memory make me decide to do this “surgery” and re-wiring. Thank you for your post.

    Like

    • Cristian,

      Many thanks for the information on the programming method. I’m sure that some of the 8051 die-hards will find that useful. It did seem a bit of a shame to destroy a perfectly good micro. 🙂

      -John-

      Like

  3. I have my modified my board fairly successfully . I added a 10:1 voltage divider to allow monitoring of the battery voltage. As you say, battery life is not great. Nail polish is useful to secure wiring once in place.

    I have wired K1 to GPIO0 for initiating programming along with the red LED. K2 is wired to reset.

    Yes, the DHT11 is pure crap. I have a DHT22 on the slow boat from China.

    I have wired up the relay circuit. It was a bit frustrating. The relay was bad. Fortunately I had a suitable replacement relay. The component and build quality on these boards is pretty poor but the price is right.

    Like

    • Bill,

      Thanks very much for letting us know your experiences with the “T5”. The voltage divider to get the battery-pack voltage is a great idea and much more practical than relying on the VCC level -after- the voltage regulator.

      My “T5” has just completed its second winter season in the basement (to give us a freezing alert if the temperature drops too close to zero), with a change of batteries towards the end of January. Not brilliant …but good enough.

      I haven’t tried it, but it would seem that the Sonoff TASMOTA software should work on the “T5” if you want to use the relay for control. You’d need to play around with the GPIO settings, but the ESP13 has enough memory to handle the OTA updates. Let us know what route you go with your mod; there are still lots of people interested in workable mods for this board.

      Best wishes,

      -John-

      Like

  4. Thank you for the kind words and information.

    Sadly, I still have not come up with a final application for my board. Soon …..

    Until you mentioned them, I had not run across the Sonoff units. Interesting. I wish they were UL,CE or equal, however. If something should happen, non-UL devices are a traditional way here in California for insurance companies to renege on a claims. The odds of something happening are low, of course.

    I loaded up the Tinkerman Wemo emulator on the modified T5. I t tested with four outputs (three LEDs and the relay). It works great. Worked on the first try too. https://tinkerman.cat/emulate-wemo-device-esp8266/

    I considered using the outputs to close contacts on an FOB to make a cheap Wemo system. I bought one of these, but it is going back. https://www.harborfreight.com/indoor-wireless-remote-system-3-pc-62575.html

    The plugs with no load get hot. Scary hot. Also, there is no way to turn on the plugs locally. You have to use the FOB (or Alexa in my proposed situation). That would not pass the spousal acceptability test.

    Getting back to my first posting, I can not stress enough the desirability of using nail polish to secure the wiring mods. They are so delicate. If you buy Red and Black nail polish (the clerk at CVS did look at me funny). You can color code any connections or plugs you may be using. For instance, a red and a black stripe on each end of the “camera’ connector.

    I will forge onward.

    Thanks,

    Bill

    Like

  5. A few of additional comments in no particular order.

    I have purchased three of these board so far. Only one has booted the ‘Thinker code’ on power up . Since we remove the square processor, it doesn’t really matter.

    Of the three board, two have had bad relays or bad solder joints on the relay. On relay was just plain bad and I replaced it with another relay from my junk box. The other non-functional relay could be heard clicking so I heated it for 10 seconds per pin and it started to work. I do not think it was a bad solder joint. I think it was the heat.

    One Chinese supplier is permanently out of stock of these boards, so if you want one, get it now.

    I have had considerable difficulty keeping a good WiFi connection on all of these EPS8266 board. If the WifFi frequency changes, DHCP is renewed or some other random WiFi event occurs they may appear to hang. Sometimes the EPS8266 thinks it is connected but the routed does not, making automatic recovery difficult since the ESP8266 does not detect that anything is wrong. I have tried most of the stock solutions to this problem found with Google. None have worked 100%. My best solution is for the ESP8266 to ping the server every 6 minuets. If the server can not be reached the ESP8266 restarts. This seem to work really well and my be THE solution for me.

    I did a cut and past out of existing code. Hopefully I did not include anything undded or exclude anything needed. Consider it an untested example:

    #include
    #include
    #include

    const IPAddress remote_ip (your_server);
    WiFiServer server(port for your server);

    const char* ssid = “your_ssid”;
    const char* password = “your_password”;

    void setup() {

    // Connecting to WiFi network
    Serial.println();
    Serial.print(“Connecting to “);
    Serial.println(ssid);
    WiFi.begin();

    while (WiFi.status() != WL_CONNECTED) {
    delay(500);
    Serial.print(“.”);
    }
    Serial.println(“”);
    Serial.println(“WiFi connected”);

    // Starting the web server
    server.begin();
    Serial.println(“Web server running. Waiting for the ESP IP…”);
    delay(2000);
    }

    void loop() {

    //Serial.println (millis()%60000);
    //turn on every hour, 60000 = one minuite
    if(millis()%360000 < 10){
    if(Ping.ping(remote_ip)) {
    Serial.println("ping Success!!");
    } else {
    Serial.println("ping Error :(");
    ESP.reset();
    }
    }

    Like

    • Bill,

      Many thanks for the informative updates, especially the keep-alive tip. On that issue, I’ve found that if my ESPs connect via one of my OpenWRT routers, the other hosts tend to drop the ESP MAC from their arp table after a while. I have no idea why this should be (why specifically the ESPs when everything else works without a hitch?). Manually adding a permanent arp entry is another solution, but not a very good one. I like your keep-alive option much better.

      -John-

      Like

Leave a comment