Wifi with ESP8266 - Part 4

A few months ago, I noticed a very strange behaviour of the ESP8266 modules with my main router.

And as a workaround, I used a second Router/Access Point while carrying on tests with more recent firmwares. So far no luck. Since the problem is present with AT, LUA & "Arduino" versions, I assume the bug is more on the SDK side.

Even the latest AT firmware based on the Espressif SDK — 1.4.0 at the time of writing — still exhibits the bug dispite the hopes given with a changelog such as "WiFi compatibility problem of special network card"!

A few people reported the problem as well, all using a Orange Livebox as the router. This message describes exactly what I noticed and I agree with the explanation.

Basically, on the LAN side, the Livebox is composed of 3 interfaces, all bridged together:

• A 4-port wired Gigabit switch
• A 2.4Ghz Wifi (with its own SSID)
• A 5Ghz Wifi (with its own SSID)

And on the other side of the router, a WAN port.

The ESP8266 modules (using the 2.4Ghz) seem to work with the following conditions:

• ESP & anything outside the local network => TCP/UDP OK
• ESP & other 2.4Ghz device: Bi-directional ==> TCP/UDP OK
• ESP & 5Ghz device: UDP from ESP to device ==> OK, Others (espcially TCP) KO
• ESP & wired device: Same as above: Only UDP in one direction

This sounds a bit like a joke... the module can talk (or can be accessed if port-forwarding is set-up) to anything in the world... but not to a local server!!!

TBC...

EDIT (04/09/2016):

I was recently contacted by someone called Chris who, while trying OTA on ESP8266 found out that newer versions of the "Arduino boards" (aka firmwares) seem to solve the problem. I tried on my side and indeed, the problem seems to disappear with version >=2.0.0 (current is 2.3.0)... (click update on the "Boards Manager"). Glad to see this bug gone. Thanks Chris for this great news.

New 433Mhz sensors

La Crosse sensors

As described last year, I own a La Crosse Weather Station to which I added several additional (TX2 & TX3) sensors.

Trouble is, as the technology is phased out in favor of a 868Mhz based one, these sensors are harder to come by and are also a bit pricey.

Chance

Unexpectedly, I noticed a news about a firmware update of the RFXtrx433E from RFXCom talking about a well known chinese online shop's version of a sensor. Indeed, I was able to become the owner of a "433MHz Wireless Weather Station Digital Thermometer Humidity Sensor" for the very lucky price of US$8.88 all included.

Protocol

These sensors are apparently compatible with the Alecto WS1700 ones. The protocol was decoded and published on the Pilight wiki and forums.

It looked simple enough so I decided to modify my Arduino/Digispark script in order to decode it as well.

Pulses

Yet there was a catch! La Crosse TX3 protocol uses a variation of pulses on the high level with timing on the low level being almost identical (and ignored by my decoder's implementation).

For the WS1700... it's the opposite! Hence only a succession of 37 identical 500µS pulses was the only thing seen.

Also, the signal finishes by a "very long" (~9200µS) Low and, as usual with this kind of device, the whole sequence is repeated several times.

As an example, the pulses are like this :

H540 L1890  <-- detect
H540 L3780  <-- detect
H540 L1890  <-- detect
H540 L3780  <-- detect
H540 L3780  <-- detect
H540 L3780  <-- detect
H540 L3780  <-- detect
H540 L3780 <-- detect
[...]
H540 L3780
H540 L9180 <-- synchronise
(and again)
H540 L1890 <-- check
H540 L3780 <-- check
H540 L1890 <-- check
H540 L3780 <-- check
H540 L3780 <-- read
[...]
H540 L9180 <-- validate
(and again)
H540 L1890
[...]

If we detect at least 8 continous short high pulses, then we know it's not a TX3 sensor but probably a Alecto compatible one and therefore from now on only low pulses will be read.

The strategy is then to wait for very long pulse, read the full signal, checking the header (~1900µS ~3800µS ~1900µS ~3800µS), and at last validating with the last pulse which should be again a very long one.

The new algorithm is represented in the following flowchart:

Reporting

• The Id, which is randomly generated when inserting new batteries -- same as TX3 -- is ignored... I will assume that nobody else has a compatible sensors around and use the channel number instead.

• Channel (there is a physical switch to select it) is coded 00=CH1, 01=CH2, 02=CH3. This will be my sensor ID because it is fixed. But to avoid any clash, I add 1001 so CH1=1001, CH2=1002, CH3=1003.

• Battery will be reported as OK or KO.

• There is a small button at the back of the sensor to force the emission. Apart for tests, it is not that useful and we can ignore the bit reporting this.

• Temperature is in 10th of degrees Celcius so value is divided by 10. Negative values are taken care of as well.

• Humidity is straight out the signal received except if not read properly (0%).

Code

Code, now compatible with Lacrose TX2/3/4 & Alecto WS1700, can be used on Digispark/Arduino. See the github repository: https://github.com/guillier/la_crosse_sensors

SHT21/HTU21D Humidity and Temperature Sensor

One of the humidity sensor currently in use, on the Home Automation Project, is the ubiquitous DHT22 also known as AM2302 which came with the AirPi board I installed.

I don't particularly like it as it has a very specific protocol which need a special C-compiled software to communicate. Second problem, it sometimes crashes. And lastly, I am starting to have serious doubts about its accuracy (specially on the humidity side).

I discovered an alternative known as SHT21 or HTU21D (depending on the manufacturer) which seems quite appealing as this one use the perfectly standard I²C protocol.

That said, the chip is so tiny, the only way to use it is mounted on a breakout board (like the GY-21): For around 4€, you get the sensor, the power regulator as well as a level shifter. Which means that it can safely be used with 3.3V or 5V.

More information and datasheets

Datasheets and examples in C can be found on the manufacturers' websites:

• Sensirion
• Measurement Specialties

Basically, it works by sending a Read (humidity or temperature) command, wait (hold mode) or poll (no hold mode) for the answer and apply a mathematical formula to get the actual value.

There is a precision setting but the only effect is to reduce the measurement time and since on the default/highest setting it takes less than 50 ms, there is little need to change it.

Using it with Arduino

As I wanted to experiment with the ESP8266, I (temporarily) diverted the chip from its initial goal (i.e. replacing the DHT22) and decided to use it on the Arduino plateform. There are librairies available from Adafruit or Sparkfun but I created my own version to include soft reset as well as serial number reading.

I'll publish it as an example at some point in the future.

Later, using this chip on the Rasberry Pi with python should be trivial.

First impressions

So far, the only small drawback I found with this kind of chip is the fixed I²C address (0x40) which mean there can only be one sensor per bus. But in practice, there is little need for more than one anyway.