High gain external antenna for Wemos ProMini

I have some IoT projects that would benefit from range afforded by a better antenna than the on-board antennas in most ESP8266 modules.

The Wemos ProMini has an on-board IPX socket for an external antenna so it is a candidate. Note that a 0R 0603 resistor needs to be removed and another or a wire link soldered in to route the RF to the IPX socket.

Above the Wemos ProMini with a 7dBi SMA-RP antenna ($1.80) and flylead SMA-R(F) to IPX (M) ($1.00).  Continue reading High gain external antenna for Wemos ProMini

A search for some mid power white wide angle LEDs

I have a project which needs some mid power (~3W) white wide angle (120+°) LEDs.

The obvious source ie eBay which means running the gamut of Chinese sellers, sellers who rarely understand the product they sell and probably expect the same of buyers.

Buying electronic components on eBay

Component sales tend to fall into categories:

  1. those with headline descriptions that have very brief description of characteristics; and
  2. those whose descriptive content claims well known part numbers for which datasheets can separately be found;
  3. those with detailed specifications offered.

In the case of category 1, it is very hard to have confidence that the components will deliver required performance, and headline descriptions on eBay are often used as competitive search keywords and do not apply to the goods on offer. These are probably best skipped unless they are the only option.

Category 2 provides a better option, and the question then on delivery is whether the goods are compliant with the part number offered. There is a considerable risk of counterfeit or fake parts that are not equivalent to the claimed part number, even where brand names are cited.

The third category can provide suitable product, but it takes some leg work, more than ‘due diligence’ to check the description for consistency and form an idea about its reliability, fit to the requirements and then value for money, seller reputation etc. This can be a lot of work for a few dollars worth of parts, but is a better option than category 1.  Continue reading A search for some mid power white wide angle LEDs

ESP8266 relay module review – Yunshan WiFi relay

After scouring eBay for a packaged esp8266 with 220V 10A relay, two products were identified:

  • Yunshan WiFi relay; and
  • LC Technology relay.

As is usually the case, finding a schematic and specifications is very difficult and the sellers were of no help (no surprises).

The LC Technology device was offered with indistinct pics that hinted it had a 8Mb flash chip, ESP8266EX processor, and a STC 15F104 8 bit processor on board for some unidentified purpose.

A schematic was eventually located for the Yunshan board, and from pics it appeared to have a 12E module on it which hinted the flash size.

A Yunshan module was purchased for about $10 posted, and it was indeed a 12E with flash-id 4016, so 4MB of flash memory.

The board does not incorporate a USB-TTL adapter which is a nuisance not just requiring an external adapter for programming, but there is no integration of the RTS and DTR signals as in the NodeMCU devkit. Adding a quality USB adapter (eg CP2102) would not increase the price a lot, you can keep the CH340G etc). Continue reading ESP8266 relay module review – Yunshan WiFi relay

Reset helper for NodeMCU ESP8266 modules

A common scheme for Lua scripted NodeMCU modules with automaticlly start the script init.lua is to incorporate some logic to test the condition of a GPIO pin to determin wether to boot to the application or drop to the lua prompt for programming etc. In fact the scheme can be elaborated to provide a simple multi level selection based on the time the input condition is applied.

The obvious pin to use is the pin that commonly has a “BOOT” or “FLASH” button on it, GPIO0 or D3. It is used to activate the ESP8266 boot loader if it is low during boot, so it must be left high at boot to allow the lua interpeter to run, but it can be pulled low shortly after boot up and tested from init.lua.

An example init script follows.

print("\n\nHold Pin00 low for 1s t0 stop boot.")
print("\n\nHold Pin00 low for 3s for config mode.")
tmr.delay(1000000)
if gpio.read(3) == 0 then
  print("Release to stop boot...")
  tmr.delay(1000000)
  if gpio.read(3) == 0 then
    print("Release now (wifi cfg)...")
    print("Starting wifi config mode...")
    dofile("wifi_setup.lua")
    return
  else
    print("...boot stopped")
    return
    end
  end
print("Starting app.lua")
dofile("app.lua")

 

Above is a pic of the helper. The DIP switch allows selection of the BOOT pulse in 1s increments. It has four connections, ground, Vdd, BootOut, and Reset (optional). The button near the DIP switch resets the helper which in turn will apply a 10ms reset pulse to the Reset line. Continue reading Reset helper for NodeMCU ESP8266 modules

ESP8266 IoT DHT22 temperature and humidity – evolution 2

This article documents a first project with the Espressif ESP8266 in its second evolution.

The objective is a module that will take periodic temperature and humidity measurements and publish them to an MQTT message broker.

This inital implementation is very basic, it is largely configured in code, though it does use DHCP. Later extensions might include a web interface for configuration of WLAN parameters etc, but for the moment the emphasis is assessment of reliability given some reports on the ‘net.

Evolution 2

The original design embedded key configuration variables in the main source code for simplicity in getting the code working.

Evolution 2 separates configuration variables from code, and provides a web interface for configuring the most common variables. The screenshot above shows the configuration screen including the use of a datalist on the SSID input field.

Hardware

A module was purchased with on board CP210x USB to serial chip. The only other component needed was the DHT22 digital temperature and humidity sensor.

NodeMCU was chosen for the ESP2866 firmware because of the inbuilt support for ‘interesting things’, including the DHT22.

Above is a breadboard of the system for development. The board had a 4MB (32Mb) flash chip on it. Continue reading ESP8266 IoT DHT22 temperature and humidity – evolution 2

DHT22 (AM2302) input for the generic heating / cooling controller

The generic heating / cooling controller (hcctl) is a flexible bang-bang thermostat controller based on an ATTiny25.

The project has been expanded to accept the Aosong DHT22 temperature and humidity sensor. The DHT22 produces a digital output (signed tenths of a degree) has a range of -40° to 80°, accuracy of about 0.5°, and 0-99.9% RH and costs a few dollars. hcctl can be configured for either temperature or humidity sensing (not both simultaneously).

Above is a development prototype with the DHT22 being heated by a small incandescent dial lamp to test function.

Continue reading DHT22 (AM2302) input for the generic heating / cooling controller

NodeMCU devkit V1 deep sleep

Low cost implementations of the NodeMCU devkit V1.0 abound on eBay, and are featured in lots of projects.

Deep sleep mode is used in a lot of projects, the MCU is but into sleep mode and it requires circuitry so that the  from the /WAKE pin (D0, GIO16) can pull the /RST pin to wake the processor up.

The problem

The common schematics as above simply wire /WAKE pin (D0, GIO16) to /RST (yellow wire), but this disrupts operation of the reset circuit, which degrades development productivity. Continue reading NodeMCU devkit V1 deep sleep

ESP8266 IoT DHT22 temperature and humidity

This article documents a first project with the Espressif ESP8266.

The objective is a module that will take periodic temperature and humidity measurements and publish them to an MQTT message broker.

This inital implementation is very basic, it is largely configured in code, though it does use DHCP. Later extensions might include a web interface for configuration of WLAN parameters etc, but for the moment the emphasis is assessment of reliability given some reports on the ‘net.

Hardware

A module was purchased with on board CP210x USB to serial chip. The only other component needed was the DHT22 digital temperature and humidity sensor.

NodeMCU was chosen for the ESP2866 firmware because of the inbuilt support for ‘interesting things’, including the DHT22.

Above is a breadboard of the system for development. Continue reading ESP8266 IoT DHT22 temperature and humidity

EmonTx3 v3.4 ‘wired’ implementation

Introduction

EmonTx3 is a measurement node for an energy measurement system. It has measurement inputs for 4 current transformers, AC voltage, 6 DS1820B temperature sensors and a meter pulse counting sensor.

The standard configuration uses a HopeRF RFM69CW radio transceiver to emonhub running on some host.

This article describes modifications to the system to use a wired serial connection to the emonhub host.

Above is the emonTx3 board.

The approach taken is a minimal change to existing firmware and software, no change to existing hardware, and inexpensive components to extend the connection.

Outline of the solution

The existing firmware writes a debug stream to the connector used for firmware upgrade. It is a different format to that used for the radio link, and there are good reasons for that, but it means writing an interface handler for emonhub to parse the debug stream.

emonTx V3.4 Discrete Sampling V2.80
OpenEnergyMonitor.org

No EEPROM config
RFM69CW Node: 8 Freq: 433Mhz Group: 210

ct1:-51,ct2:0,ct3:0,ct4:0,vrms:23910,pulse:0,t0:223
ct1:-71,ct2:0,ct3:0,ct4:0,vrms:23924,pulse:0,t0:223
ct1:-6,ct2:0,ct3:0,ct4:0,vrms:23921,pulse:0,t0:223

The solution involves some hardware to interface the emonTx3 to the wire line, and a similar interface at the other end to the host running emonhub.

Hardware

Above is the debug stream from the modified firmware.
Above is an adapter (~$3) from the TTL levels of the UART port to RS485. The port is currently run at 115200bps, and that can be carried 800m with good noise immunity on good copper using RS485.

USB-485-10

Above is the host end adapter.

Firmware changes

The firmware was changed to repurpose the output that may be used for switching power to the DS19B20 sensors, it is now used primarily as an RTS signal to the RS485 adapter to reduce current consumption when there is no traffic. In fact, the RTS signal has been asserted also at times when the DS18B20 sensors are read and it could also be used for its original purpose without conflict.

Host changes

Assigning a consistent name to the RS485 adapter

A problem with USB serial adapters is that they may acquire different device names depending on the order in which they are started.

This is solved in this solution by use of FTDI adapters which have a serial number that uniquely identifies the adapter, and setting udev rules to assign a consistent symbolic link to the device. It is this symbolic link that is used in emonhub.conf

The link is achieved by adding the file /etc/udev/rules.d/75-RS485.rules with the contents below (the contents must match the actual adapter).

#Assign fixed symlink to RS485 adapter for emonttx

SUBSYSTEM=="tty", ENV{ID_SERIAL}=="FTDI_FT232R_USB_UART_A9WRVDPD",SYMLINK+="ttyRS485-0"

The udevadm command will provide the information needed.

root@emonpi(rw):log# udevadm info -n /dev/ttyUSB0
P: /devices/platform/soc/20980000.usb/usb1/1-1/1-1.2/1-1.2:1.0/ttyUSB0/tty/ttyUSB0
N: ttyUSB0
S: serial/by-id/usb-FTDI_FT232R_USB_UART_A9WRVDPD-if00-port0
S: serial/by-path/platform-20980000.usb-usb-0:1.2:1.0-port0
S: ttyRS485-0
E: DEVLINKS=/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A9WRVDPD-if00-port0 /dev/serial/by-path/platform-20980000.usb-usb-0:1.2:1.0-port0 /dev/ttyRS485-0
E: DEVNAME=/dev/ttyUSB0
E: DEVPATH=/devices/platform/soc/20980000.usb/usb1/1-1/1-1.2/1-1.2:1.0/ttyUSB0/tty/ttyUSB0
E: ID_BUS=usb
E: ID_MODEL=FT232R_USB_UART
E: ID_MODEL_ENC=FT232R\x20USB\x20UART
E: ID_MODEL_FROM_DATABASE=FT232 USB-Serial (UART) IC
E: ID_MODEL_ID=6001
E: ID_PATH=platform-20980000.usb-usb-0:1.2:1.0
E: ID_PATH_TAG=platform-20980000_usb-usb-0_1_2_1_0
E: ID_REVISION=0600
E: ID_SERIAL=FTDI_FT232R_USB_UART_A9WRVDPD
E: ID_SERIAL_SHORT=A9WRVDPD
E: ID_TYPE=generic
E: ID_USB_DRIVER=ftdi_sio
E: ID_USB_INTERFACES=:ffffff:
E: ID_USB_INTERFACE_NUM=00
E: ID_VENDOR=FTDI
E: ID_VENDOR_ENC=FTDI
E: ID_VENDOR_FROM_DATABASE=Future Technology Devices International, Ltd
E: ID_VENDOR_ID=0403
E: MAJOR=188
E: MINOR=0
E: SUBSYSTEM=tty
E: TAGS=:systemd:
E: USEC_INITIALIZED=8089809829

Interfacer module to parse the debug stream

An additional interfacer module was written to parse the debug stream, and it was hooked to the main module.

The interfacer is configured in emonhub and port layout copied in from source.

(the contents must match the actual adapter).

#Assign fixed symlink to RS485 adapter for emonttx

SUBSYSTEM=="tty", ENV{DEVLINKS}=="*usb-FTDI_FT232R_USB_UART_A9WRVDPD*",SYMLINK+="ttyRS485-0"

Code source

Code source is available the original git emonhub repo, and in the following git repository forked from the official repo:

Test

The wired configuration is under test with emonhub installed on a Ubuntu server, and about 40m of cat5e cabling from emonTx3 to host. No issues have arisen.

References / links

EmonTx_V3.4

DS18B20 input for the generic heating / cooling controller

The generic heating / cooling controller (hcctl) is a flexible bang-bang thermostat controller based on an ATTiny25.

The project has been expanded to accept a Dallas / Maxim DS18B20 1-Wire temperature sensor. The DS18B20 produces a digital output (signed sixteenths of a degree) has a range of -85° to 125°, accuracy of about 0.5°, and costs a dollar for bare chips, a few dollars for an encapsulated probe.

Above is a development prototype with the DS18B20 being heated by a small incandescent dial lamp to test function.

Continue reading DS18B20 input for the generic heating / cooling controller