433Mhz remote sockets - Part 1

Purchase

A few days ago, as I was in a nearby DIY store (looking for something I didn't find in the end), I came by the Electricity aisle and noticed cheap remote sockets. These are a not new thing, I owned some more than 25 years ago — so unstable there were switching on and off randomly — and in France at least, the Belgian company Chacon made a successful product (DI.O) with this kind if items.

One of the major issue with them is that they are without any feedback of the status like you could have on a modern "smart plug". Yet, where a Z-wave socket alone is at least 40€, here a pack of 2 sockets was less than 15€ including the remote and its battery. The "manual" includes a EC Declation of Confirmity so I assume there are safe to use. The power is limited to 1000W but for Christmas lights, this is not an issue!

Obviously, the idea was also the do the reverse engineering on the protocol and if possible try to emulate the remote itself like I did several times in the past. Turns out that this very model of remote is used in dozens of packs and the circuit inside is well known and even officially documented!

Protocol and Home Automation

A quick search show pages and pages on the subject. These one are now called "Smart Home" but were previously sold under the Phenix brand by IDK. Protocol seems virtually identical to the Elro Home Easy plugs.

The main references about the subject seem to be:

• https://github.com/sui77/rc-switch for Arduino
• https://github.com/r10r/rcswitch-pi for Rasberry Pi
• http://www.princeton.com.tw/Portals/0/Product/PT2262_5.pdf for the Datasheet

The next question was: What is the best to integrate these elements in the existing installation? There are two main parts for this: controlling the sockets but also making the most of the remote (especially the two unused ON/OFF buttons).

As usual... A suivre!

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

Wifi with ESP8266 - Part 3

Having received (in less than 2 weeks in fact) my devkit ordered from ebay, I was able to carry on my investigations.

As noted before, the devkit comes with a USB connection and power regulator. Same principle as on the Arduino boards. The version bought is the newest devkit 1.0 (AKA v2 on Seeedstudio).

First try

NodeMCU 0.9.5 build 20150403  powered by Lua 5.1.4
Will run user.lc/user.lua in 1000ms
> Please run file.remove("user.lua") before first use.
Please run file.remove("user.lua") before first use.
Please run file.remove("user.lua") before first use.
Please run file.remove("user.lua") before first use.

OK... bizarre but a quick check with Google gives a workaround:

file.remove("user.lua")
node.restart()

According to one post, there are two Lua files inside a new board: init.lua and user.lua. These are used for factory testing purpose only. Now the message has become:

NodeMCU 0.9.5 build 20150403  powered by Lua 5.1.4
Will run user.lc/user.lua in 1000ms
> cannot open user.lua

And for information purpose, the content of the "init.lua" file:

> file.open("init.lua", "r")
> print(file.read())
--init.lua, something like this
print("Will run user.lc/user.lua in 1000ms")
tmr.alarm(0,1000,1,function()
  tmr.stop(0)
  local s,err
  if file.open("user.lc") then
    file.close()
    s,err = pcall(function() dofile("user.lc") end)
  else
    s,err = pcall(function() dofile("user.lua") end)
  end
  if not s then print(err) end
end)

> file.close()

So far so good...

Connecting to the Internet

Same procedure as last time:

• Setting "Wifi Station" mode => OK
• Registering SSID and password => OK
• Obtening a IP address => OK
• Connecting to an external website => variable
• Connecting from a browser to the module => KO

For some reason, there is a incompatibility between most firmwares and my Wifi router. :-(

Time to try with a different/more recent firmware.

Flashing disaster

As we say in french "Never Two Without Three". So after the HM-12 and the ESP-201, something was bound to go awry!

Using the latest version of esptool, I uploaded a new firmware... flashing was reported as successful but the module couldn't even boot! And this was the case with all firmware I tried.

As as I discovered, this is because the devkit 1.0 is based on the ESP-12E board. The "E" letter is important as it means the flash is 4 MB (or 32Mb) instead of the 512 KB (2Mb) standard model. The mechanism address the flash seems different and it is essential to use specific parameters like:

./esptool.py write_flash -fm=dio -fs=32m  0x0 nodemcu_latest.bin

I.e. using DIO for flash_mode (instead of QIO) and 32Mb for flash_size (instead of 2Mb).

Then, at least I could boot! But the filesystem (used by LUA) was destroyed and the list of files was returning strange data.

It took me long while to find a way clear it (obviously file.format() didn't work) but I, at last, managed it by running:

./esptool.py erase_flash

That said, it is still impossible to open any file from LUA. There are a few comments about this problem on the Seeedstudio page, so I am not alone. I actually wonder if the nodemcu builds are truly compatible with this new hardware!

EDIT (02/07/2015):

Many thanks to Johny Mattsson for his workaround to this issue and for taking the time to notify me. I am happy to report that the new esptool.py (on dev branch) now unlocks the filesystem. See pull-request note Workaround write-protected flash when using esptool.py to flash in DIO mode for more information.

New access point

I happened to have a spare (old) wifi router.

And with this new set-up, TCP connections were fine either as a client or as a server!!!!

How annoying (and unpractical as I don't really want to multiply routers). And also what a waste of time and energy. Since all types of firmwares (AT, nodemcu, arduino's) are plagued by this problem, it might be link to the Espressif's SDK I presume. But I still can't pinpoint what exactly is happening and why some IPs are reachable while others are not.

At least, I could play with my two modules.

The story so far...

• 2 modules 'ESP-201' and devkit 1.0 (using an ESP-12E)
• Can't use my main Wifi Router but works fine on another one (except with a very old original firmware for the ESP-201)
• LUA Filesystem broken on the devkit 1.0 (haven't retried on the ESP-201) making the use of nodemcu very unpractical

Like this blogger, who seems to have quite a lot of experience on ESP8266 modules, I am now convinced that Arduino's ecosystem is the way to go, at least for now.

TBC...