Naming stuff is one of the core decisions one has to take while designing an architecture. It might not look as important as utilising the right pattern in the right place or defining your database model but my experience says that a good naming convention helps identifying design flaws.

In a previous post I introduced the network I’m building for my home monitoring system. As I said it will be based on MQTT, a lightweight messaging protocol. An MQTT message has 4 attributes: topic, value, QoS and retain value. I will focus on the “topic” in this post but I will come back to the QoS and retain attributes sometime in the future.

The MQTT specification defines topic as “(…) the key that identifies the information channel to which payload data is published. Subscribers use the key to identify the information channels on which they want to receive published information”. But the cool thing about MQTT topics is that the protocol defines a hierarchy structure very much like the Filesystem Hierarchy Standard in use in unix, linux and mac boxes. This, along with the possibility of using wildcards to match topics, makes this structure very suitable for a WSN.

Some examples of topics are:

• /home/llivingroom/bulb1/status
• /home/door/sensor/battery
• /home/door/sensor/battery/units
• /home/outdoors/temperature
• /home/outdoors/temperature/yesterday/max
• /zigbee/0013a20040401122/dio3
• /zigbee/0013a20040410034/adc7
• …

Semantic vs. physical approach

There is a bunch of small decisions to take here. Let’s start from the beginning… When building a topic hierarchy there are two different approaches (at least). Using a semantic approach and name things for where they are and what they measure. A humidity sensor in the bathroom to detect shower times (??) could publish its data under “/home/bathroom/humidity”.

The second option is a physical approach and name things for what they are or what they are attached to. Like in the previous example the humidity sensor might be attached to the analog pin 3 of an end device radio in a Xbee mesh network, so it could as well publish its data under “/xbee/0013a20040410034/adc3″, why not?

Generally the semantic approach is preferable since it is more human friendly but the physical approach is more machine friendly (even if only slightly). Using again the previous example, the Xbee gateway could subscribe to “/xbee/+/+/set” to get all the messages that should be sent to the different radios.

Semantic approach structure

For the physical network it is easy to define a topic structure based on the path to get to the data, like in the last example: “the sensor attached to the AD converter pin 3 in the radio with address 0×00 0×13 0xa2 0×00 0×40 0×41 0×00 0×34″.

For the semantic approach there are a bunch of possibilities but most of the networks out there use a location based structure: first you physically identify the sensor by its location and then the magnitude: “/home/2ndfloor/bathroom/temperature”. As you can see this can be read quite naturally, albeit reversed: “the temperature in the bathroom of the 2nd floor at home”.

It’s worth noting that MQTT provides a way to split a large scale networks into different chunks, each with it’s own scope, via the mount_points feature. Check an interesting thread about mount_points here. So it can be a good idea to foresee how my network might grow, not only downwards but also upwards, and that’s why the “/home” in some of the examples I’m showing might not be a good root location, better use something more specific like “/buckingham palace” or “/lovenest” (I will keep using /home in the examples anyway).

And after the location part I will just provide the magnitude: temperature, pressure, humidity, air_quality, power, battery,… and status. Status is normally a discrete value (typically 0 or 1) indicating the state of the sensor or device. I find it preferable to use “/home/entrance/light/status” that simply “/home/entrance/light” to publish whether the lights are on or off.

Modifiers, prefixing and postfixing

I have already used some “particles” in the example topics above, words like ‘set’, ‘yesterday’, ‘max’,… I’ve gathered some of these particles browsing the internet searching for MQTT topic names. I have tried to classify them into different types:

• Metadata: timestamp, units, alarm,…
• Agregation: time ranges like today, last24h, yesterday, month, year, ever,… and operators like max, min or average. A special case of time range could be “now”, “last” or “current” for the last value published on a certain topic although it is usually omitted.
• Actions: get or query, set
• Structure-related: raw for, well, raw values

Some of the modifiers are clearly attributes or metadata of the data itself. In these cases postfixing makes perfect sense:

• /home/bedroom/temperature 21
• /home/bedroom/temperature/units C
• /home/bedroom/temperature/timestamp 2012-12-10T12:47:00+01:00

The reading from the bedroom temperature sensor was 21 celsius on Dec 10 at 12:47 UTC+1. As I’ve said, some people uses “current”, “now” or “last”. I used to think this as redundant but it may be necessary when graphing your network messages the way Ben Hardill explains in his d3 MQTT topic tree visualiser post, where only the leaves can have values.

Another reason to use “last” (or any of the others) is when you are also publishing aggregated information for that magnitude. In this case it looks more logical to have a structure like this one:

• /home/bedroom/temperature/last
• /home/bedroom/temperature/last/timestamp
• /home/bedroom/temperature/last24h/max
• /home/bedroom/temperature/last24h/max/timestamp
• /home/bedroom/temperature/last24h/min
• /home/bedroom/temperature/last24h/min/timestamp
• /home/bedroom/temperature/ever/max
• …

But first you should ask yourself if your messaging network is the place to publish this info. Who will use it? If the answer is only you then you should add some graphing solution like Cosm, Nimbits, Open Sen.se,  or your own. Keep in mind MQTT is a Machine to machine protocol.

But for actions and structure modifiers it’s not so evident. Postfixing (appending at the end) for actions is coherent with the “reversed natural reading” naming convention: “switch on the lights in the stairs” will be a “/home/stairs/light/status/set 1″.

But prefixing in MQTT is equivalent to creating new hierarchy roots, thus “splitting” the topics into different sub-networks, so it fits quite well for structure modifiers. You could have a /home root for sensor data using a semantic approach and a /raw root for raw sensor data using a physical approach. The network should then provide a service to map topics back and forth between both sub-networks:

• /raw/xbee/0013a20040410034/adc3 => /home/bedroom/temperature
• /home/bedroom/lights/set => /raw/xbee/0013a20040410034/dio12

This republishing service has been proposed by Robert Heckers in his MQTT: about dumb sensors, topics and clean code post and you can even use an open source implementation of an MQTT republisher by Kyle Lodge using the Mosquitto python library.

Republishing vs. publishing the right contents

There are some details I don’t like about the “republishing” approach. First you are setting up a service that will have to know about the physical network (gateways, technologies, radio addresses, pins…). Second you are doubling the traffic in your network without adding any more value apart from the topic renaming.

So my point is to make the mapping in the gateway before publishing anything. This way the messaging is agnostic of the physical structure of the radio network, the gateway is the only holder of that information. Besides, the mapper will double as a filter, filtering out unnecessary messages *and* processing values. Let’s say you configure a MCU-less sensor with an Xbee radio to report the input of an analog pin. Chances are you will have to do some maths with the reported value to get a meaningful one. For example, the supply voltage reported by the radio has to been scaled by 1200/1024 to get the actual value in mV.

Conclusions

To be honest, I’ve written this quite large post to make up my mind about the subject. These are some of the conclusions I will apply to my own system:

• The message topics should be independent from the underlying technology.
• Topics will have semantic meaning, starting with the location and then the magnitude they represent. More particles can be added to the topic to add attributes or metadata.
• The different gateways and publishers will be responsible for:
  • Abstracting the physical network architecture.
  • Filtering unnecessary messages.
  • Processing values before publishing them.
  • Adding metadata.
  • Listening and processing messages aimed to sensors under their “control”.
• Republishing will be avoided if possible.
• Aggregation data goes somewhere else.

I am not really sure about publishing content only to leaf nodes. The analogy with a linux file system is quite obvious: you only put content into leaf nodes (files), but still I find it somewhat ugly (and for me that means there is something wrong).

The final test will be to actually apply this rules to implement my MQTT topics hierarchy to see if it works. Let’s go!

Now that I have started to monitor some magnitudes at home, like power consumption or the front door opening, I have to do something with this information. The sensor information can be useful for two purposes, mainly:

• analysing it to know more about your environment or your life-style patterns (like when and how you spend the money you spend on energy)
• taking real-time actions based on events from your sensors (open a light when you pass by a dark corridor at night, receive a notification when someone enters your house,…)

To analyse the information you will first have to store it in some way you could retrieve it later, graph it, summarize it, perform different time range roll ups or moving averages or detect time patterns,… whatever. Even if the goal of the sensor information is to trigger events (watch out: the door sensor is running out of batteries!) you will probably want to have it stored somewhere and save a log of actions as well.

So, where to store this information? You have different options available:

• Relational databases (RDBMS) like MySQL or PostgreSQL. If you have some programming background this is pretty easy, we are all used to store data on a MySQL or similar. But mind the tables will GROW very quickly. A sensor reporting every minute will create more than half a million entries a year.
• NO-SQL databases like MongoDB or Cassandra. They are popular and everyone wants to use them. Cassandra is often used to store time-series data like server load or log files and the Internet is full of information about how to store it, retrieve it, partition it,… MongoDB has also some nice features like capped collections.
• Round-robin databases. They have been around for a while. RRDtool version 1.0 was born in 1999 and MRTG is even older. Data is stored in circular buffers, you can define the size of the buffer and the step or how often a new value is inserted into the buffer. When the buffer is full old data gets overwritten and this happens over and over. So you have another buffer for aggregated data (like daily data) and another one for even larger scale data (like weekly data) and so on.
• Time series databases. And finally there are a number of databases that have been specifically designed to store time-series data: fast inserts, fast range lookups, roll ups,…

Now, some companies are providing time series storage services online. They provide a public API, graphing capabilities and some of them even roll ups or data aggregation. They have been born around the Internet of Things hype. Maybe the most popular is Cosm (formerly Pachube) but it’s not the only one: TempoDB, Nimbits or ThingSpeak are very good options.

Cosm has been around for a while and it is still the most used by the IoT community. AFAIK, there is no restriction on the number of data points you can store for free if you keep your data “public”. Data is structured in “feeds” and “datastreams”. They have an API you can use to push data individually or in batches. You can also use it to backup the data you have in Cosm. Their charts are nice looking but they have predefined time ranges that automatically aggregate your data so you have little control on what and how you want to graph. They have a number of goodies like triggers, graph builder (to insert your Cosm charts in your site), tags, apps, localization based search,…

TempoDB is a relatively new player. It’s free up to 5 million data points per database, that’s roughly 9.5 years for a 1 samples/minute data. You can have several “series” of data per database. Their API is really good and they have a number of clients including a python one :^). Their charts might not be as “pretty” as those from Cosm but you have full control on the data you are visualizing: date range, interval and aggregation functions, and they are FAST (Cosm can be really sluggish sometimes). Your data is private, so there is no sense in having a search tool. They have tags and I’ve been told they are about to release a notification service.

Nimbits has a desktop-like interface base on ExtJS. It is basically a paid service (their free quota is 1000 API requests per day, which is OK for 1 sensor reporting at a rate of 1 samples every 2 minutes) and it costs $20/2 million requests (roughly $20 per year if you have 4 sensors reporting at a 1 sample/minute rate).

ThingSpeak is very similar to Cosm, data is presented in a “channel” where you can see multiple charts for different magnitudes (they call them “fields”), a map and even a video from Youtube. It’s open source, so you can clone the code from Github and install it in you server. Their web service is limited to 1 API request every 15 seconds per channel, which is OK as long as you group all the data from one channel in a single request (that’s it if you have more than one field per channel). For each field you have a lot of options to define your chart: time range, time scale, different aggregation functions, colors, scale,…

The information in this post is not very detailed but I hope it can be an introduction to anyone who is looking for ways to store or publish sensor data. Right now I’m using Cosm and TempoDB, as well as storing all my data in a local MySQL database (not the best option but it works for now). There are plenty of options I still have to explore. In my next post I will talk about the daemon I’m using to push data to Cosm and TempoDB, in the meantime you can check the code on Github.

[Update 2013-03-01] I have added more documentation on the codes these remotes use in a different post.

I’m starting to move towards not only gathering information but also acting. My first project in this subject will be controlling some lights and the house heaters. So last week I visited the urban market of “Els Encants” in Barcelona and bought some very cheap wireless outlets.

I bought two sets of three wall plugs, each set with it’s own remote. They all transmit in the  433MHz frequency and I already had a set of transmitter and receiver for that frequency so as soon as I had some time I started trying to intercept and reproduce the codes the remotes were sending.

Sample outlets from each set plus remotes

In the image above you can see an outlet and the remote for each of the sets. The left one is branded “Noru” and each outlet is rated 3kW (good for the heaters) and it features auto switch off time (1, 2, 4 or 8 hours). The remote can control a maximum of 3 outlets and apparently it is programmable, since you first have to sync the outlets with the remote.

The right one is branded “Avidsen” and rated 1000W, just below the consumption of my house electrical heaters, but good to control lights and other appliances. It’s got the very common dip switch to sync the remote and up to five outlets. There are 32 different channels available. So if your lights switch on and off randomly maybe you neighbour is using the same channel you are, then you better change the channel.

I started reading documentation about the protocol these devices use and found out there is some very useful information out there. In fact there are even a couple of libraries for Arduino. The first one is called RemoteSwitch and it is a little old, it has not been ported to Arduino 1.0 but if you are like me you will keep a copy of Arduino 0023 just for this kind of situations.

The second library is called RCSwitch and I have to say it is a neat piece of code. It has been ported to the Raspberry Pi, although the port is not as updated as the original Arduino library.

My first tests with the RemoteSwitch library were encouraging. The Show_received_code sketch dumped the codes for the Avidsen remote one by one. I though: if it can decode it, it should be able to recreate it. And it worked from scratch. Good!

But by then I knew I wanted to use the newer library. There were several reason for this: it is being actively developed, it supports more protocols, the code is much more elegant and object oriented and it has a port to RPi, which I plan to use as a central gateway soon. So I checked which one of the RCSwitch protocols matched the one I had successfully used with RemoteSwitch and started doing some more tests…

Here was when things started to get complicated. The thing did not work. So I spent a couple of hours studying the code for both libraries, decoding the codes the RemoteSwitch library had dumped before and trying to find the difference. Until I found it: RCSwitch.cpp, line 239, that ’0′ should be a ’1′… and everything started working again. Very good! I started a thread in the library forum to find out whether this is a bug or a slightly different protocol.

Index: RCSwitch.cpp
===================================================================
--- RCSwitch.cpp	(revision 219)
+++ RCSwitch.cpp	(working copy)
@@ -284,7 +284,7 @@
         if (sGroup[i] == '0') {
             sDipSwitches[j++] = 'F';
         } else {
-            sDipSwitches[j++] = '0';
+            sDipSwitches[j++] = '1';
         }
     }

By the way, the protocol of these things is pretty interesting. It’s worth a look at Sui’s post to get an overview of the implementation. The tri-bit concept is really awkward.

Then I moved to the other set of outlets. These are rated 3000W so I plan to use them to control my house heaters, which is the main reason for all this work. I followed the same steps, starting with getting the codes with the Show_received_code sketch. But weird enough the library was only able to decode some of the button presses… Only the SET button for outlet #1, the ON and OFF buttons for outlet #2, the ALL OFF button or the 2, 4 and 8H timeout buttons seemed to work.

This time it was going to be harder, since I didn’t even have all the codes. Well, a good opportunity to use my Bus Pirate!

Bus Pirate to the rescue!

So I plugged the RF receiver to the Bus Pirate and launched the OLS Logic Analyser to capture the signal from the remote.

You don’t have to configure anything to use the Bus Pirate as a (low speed) logic analyser. But since I wanted to power the radio receiver with the BP I had to enable the Power Supply mode. To do so you have to open a terminal session, type ‘?’ to get a prompt, select one of the modes that allow enabling the power supply typing ‘m’ and selecting the mode (like UART, for instance) and then type ‘W’ (uppercase to enable, lowercase to disable). Then you can close the session and it will keep the power on the 5V and 3V3 lines as long as it is plugged to the computer. Mind you have to free the port so the logic analyser software can use it. I had problems doing it with screen or minicom, but it worked great with picocom.

After some tests with the Avidsen remote (I knew what the codes were so I could compare the signal output with the actual code) I started getting the signals for each and every button in the Noru remote.

The image below shows the signal for the ON button for the outlet #1.

Signal for the #1 ON button of the Noru remote

Now, since the RemoteSwitch library was able to decode some of the signals, the protocol could not be that different. So I started to decode manually all the signals applying the same protocol. The signal is a series of 12 tri-bits plus a sync-bit. For the Avidsen-like remotes there are 3 different tri-bit values (logically), they are called 0, 1 and F, for “floating”. Each tri-bit has a pulses shape. The following tables describes the pulses:

The long pulses are about 3 times the length of the sort ones. The overall period is a characteristic of each remote. There is also a trailing high pulse followed by a long low which is called “sync bit”.

Decoding the signals from the Noru remote I found out that there was a fourth tri-bit value (well maybe I should call them tetra-bits now). In fact it is obvious since there is a forth option for an alternate sequence of 4 highs and lows. I’ve named the new tetra-bit X (for unknown, but also after my name ). The full table for the Noru remotes is:

Now the previous image for the ON#1 button can be decoded as 1F000001FFX0S. With a small patch I could make this work with the RCSwitch library. The library cannot create the code but you can feed it to the sendTriState method to generate the signal.

Index: RCSwitch.h
===================================================================
--- RCSwitch.h	(revision 219)
+++ RCSwitch.h	(working copy)
@@ -106,6 +106,7 @@
     void sendT0();
     void sendT1();
     void sendTF();
+    void sendTX();
     void send0();
     void send1();
     void sendSync();
Index: RCSwitch.cpp
===================================================================
--- RCSwitch.cpp	(revision 219)
+++ RCSwitch.cpp	(working copy)
@@ -441,6 +441,9 @@
         case '1':
           this->sendT1();
         break;
+        case 'X':
+          this->sendTX();
+        break;
       }
       i++;
     }
@@ -561,6 +564,16 @@
 void RCSwitch::sendTF() {
   this->transmit(1,3);
   this->transmit(3,1);
+}
+
+/**
+ * Sends a Tri-State "X" Bit
+ *            ___   _
+ * Waveform: |   |_| |___
+ */
+void RCSwitch::sendTX() {
+  this->transmit(3,1);
+  this->transmit(1,3);
 }

 /**

And this is a sample code for Arduino that switches on and off outlet #1 every 2 seconds.

#include <RCSwitch.h>

RCSwitch mySwitch = RCSwitch();

void setup() {

  Serial.begin(9600);

  // Transmitter is connected to Arduino Pin #11
  mySwitch.enableTransmit(11);

  // Optional set pulse length.
  mySwitch.setPulseLength(302);

  // Optional set protocol (default is 1, will work for most outlets)
  mySwitch.setProtocol(1);

  // Optional set number of transmission repetitions.
  mySwitch.setRepeatTransmit(6);

}

void loop() {
    mySwitch.sendTriState("1F000001FFX0");
    delay(2000);
    mySwitch.sendTriState("1F000001FFFX");
    delay(2000);
}

Again, comments are more than welcome!

November was a busy month and the Sonoff Dual that IteadStudio kindly sent me to review was bored in a box waiting for some free time. But it was just fair that another board that has been waiting in the boards-to-review box for longer had it’s chance to have some fresh air too. So here we have the Itead Studio Sonoff Dual and the Electrodragon ESP Relay Board face to face.

Face to face

They are both two relay boards with an Espressif ESP8266 controller. They are both powered from mains and programmable. The both have a similar size. They might look alike but they are actually quite different from the inside.

The Sonoff Dual (left) and the Electrodragon (right) face to face in the nude

* Please note that even thou the Electrodragon has 10A relays the board itself is no way able to handle such currents. The manufacturer recommends a maximum of 1A per line or 2A on a single line.

The relays in the Sonoff Dual

The Electrodragon header… the silkscreen quality is not the best

Those traces in the Electrodragon board are too thing for 10A

The Sonoff Dual is a more sturdy and end-user friendly device, it comes with a default firmware that connects to the eWeLink app for Android and iPhone and lets you manage the relays, configure schedules and much more. The Electrodragon on the other side is a hacker’s board, with a demo-firmware loaded which does very little.

Anyway I wanted to load my ESPurna firmware on both of them. It might look easy and for the Electrodragon is just a matter of adding support for multiple GPIO driven relays, but not for the Sonoff Dual.

IteadStudio Sonoff Dual

The Dual has 2 LEDs and one button meant to be used/checked from outside the enclosure. But the button is not connected to the ESP8266 (so you cannot use it to set the IC in flash mode, more about this later). The approach IteadStudio have used is pretty much the same they have in their PSB-04 modules: encapsulate the button and relay functionality in a helper microcontroller, a Silicon Labs F330. When a button is pressed the F330 reports the new status of the relays to the ESP8266 through serial. The ESP8266 can also change the relays statuses sending the proper commands to the F330.

The on-board button in the Sonoff Dual reports being button 2. Buttons 0 and 1 are available in a header properly labelled. The protocol has been reverse engineered by Markus Maeder and published in Itead’s support pages here. The messages have 4 bytes: starting byte, number of relays, status mask and stop byte.

So if the user presses the on board button (BUTTON2) the F330 will send 0xA00404A1 to the ESP8266 (provided everything was off). Bad news is that the communication is done through the hardware UART interface of the ESP8266 at 19230,8,N,1, so we cannot use it for debugging purposes.

Sonoff Dual support in ESPurna

The ESPurna firmware is released as free open software and can be checked out at my Espurna repository on GitHub.

I have added support for the Sonoff Dual to my ESPurna firmware. You can check it out in the repo but I’d like to highlight here the two chunks of code responsible for the communication between the ESP8266 and the F330.

    dualRelayStatus ^= (1 << id);
    Serial.flush();
    Serial.write(0xA0);
    Serial.write(0x04);
    Serial.write(dualRelayStatus);
    Serial.write(0xA1);
    Serial.flush();

The code above toggles the “id” relay (where “id” can be 0 or 1 for the Sonoff Dual) by xor-ing (what?) it in the “dualRelayStatus”, that is the variable that holds the status of the relays as a bit mask. This is from the ESP8266 to the F330. For the other way round we should check for the start and stop bytes:

void buttonLoop() {

    if (Serial.available() >= 4) {

        unsigned char value;
        if (Serial.read() == 0xA0) {
            if (Serial.read() == 0x04) {
                value = Serial.read();
                if (Serial.read() == 0xA1) {

                    // RELAYs and BUTTONs are synchonized in the SIL F330
                    // The on-board BUTTON2 should toggle RELAY0 value
                    // Since we are not passing back RELAY2 value
                    // (in the relayStatus method) it will only be present
                    // here if it has actually been pressed
                    if ((value & 4) == 4) value = value ^ 1;

                    // Otherwise check if any of the other two BUTTONs
                    // (in the header) has been pressent, but we should
                    // ensure that we only toggle one of them to avoid
                    // the synchronization going mad
                    // This loop is generic for any PSB-04 module
                    for (unsigned int i=0; i<relayCount(); i++) {

                        bool status = (value & (1 << i)) > 0;

                        // relayStatus returns true if the status has changed
                        if (relayStatus(i, status)) break;

                    }

                }
            }
        }

    }

}

Note some things in the code above. First we check for the message format (lines 23 to 26). Second we expect just one button to be pressed at a time so we break after a relay has changed it status (line 45). And third we intercept button2 presses and map them to button0 (line 33). So the external button toggles relay 0. Right now this is hardcoded, change it to “value = value ^ 2” to toggle relay 1 instead.

The relayStatus method does quite a few things: checks if the status has changed (returns true if so), sends the message back to the F330, synchronises other devices (more about it in a minute) and sends notifications to MQTT and websocket clients.

Flash the Sonoff Dual

Since the button is not connected to the ESP8266 GPIO0 flashing the Sonoff Dual is a bit trickier than doing the same on the TH or POW. My recommendation is to shortcut an exposed pad connected to GPIO for the first flash and then use OTA to upload the filesystem or update the firmware.

In the picture below you have a line pointing a resistor pad connected to GPIO0. Use a jumper cable to short it to ground while powering the board to get into flash mode.

GPIO0 exposed in the Sonoff Dual

Electrodragon ESP Relay Board

The Electrodragon board is relatively simple to use. It’s a board meant for developers, not for end-users. The relays are directly connected to GPIO12 and GPIO13 so it’s just a matter of handling different GPIOs in the code. I use a vector to store all defined relay pins and then directly drive them with digitalWrite method.

std::vector<unsigned char> _relays;

        #ifdef RELAY1_PIN
            _relays.push_back(RELAY1_PIN);
        #endif
        #ifdef RELAY2_PIN
            _relays.push_back(RELAY2_PIN);
        #endif
        #ifdef RELAY3_PIN
            _relays.push_back(RELAY3_PIN);
        #endif
        #ifdef RELAY4_PIN
            _relays.push_back(RELAY4_PIN);
        #endif

digitalWrite(_relays[id], status);

To flash the Electrodragon note the pinout in the picture bellow. Power the device through the 5V pin. The RX marked pin should go to your programmer TX pin and the TX to the RX. Use the button labelled BTN2 to get into flashing mode. I’ve have better results holding it down while powering the board and until the firmware has started flashing.

Right pinout in the Electrodragon

Synchronising relays

If you have 2 relays you can control 2 appliances. Easy. But you can also do some other things like synchronising them. The ESPurna firmware supports 4 options:

• No synchronisation
• All off or at most one on (so if you turn one on all the other will go off)
• One and only one on (so if you turn one on all the other will go off, but if you turn that one off again the next in the line will go on)
• All the same (turn one on and all will go on, turn one off and all will go off)

Let me stop in the “one and only one on” since this this allows for multi-way switching, which is something I’ve been after since the first Sonoff.

3-way switch from the Wikipedia, by Cburnet

This is a quite common way of switch where yo can toggle your lights from different switches in the room. A 3-way switch (like the one in the graphic) is usually implemented with a SPDT relay with exposed NO and NC terminals. But you can also use two relays with inverse sinchonisation, like the “one and only one on” mode does.

ESPurna 1.1.0

The ESPurna firmware is released as free open software and can be checked out at my Espurna repository on GitHub.

The firmware has been updated to support the Sonoff Dual and all the GPIO-based multi-relay boards out there, in particular the Electrodragon ESP Relay Board. This means a lot of changes:

• MQTT topics for each relay (i.e. /test/dual/relay/0)
• API entry points for each relay (i.e. PUT or GET /api/relay/0)
• API entry point to get all relays (GET /relay)
• Each relay is exposed as a different WeMo device
• Different relay synchronisation options

I have also removed deprecated API entry points so all API requests go trough the /api namespace and require and API key.

I plan to add more API entry points to retrieve sensor values and a “pulse” mode for the relays so they can auto off after a second.

The post ESP8266 Multi-relay boards: Sonoff Dual and Electrodragon appeared first on Tinkerman.

Really busy these days. I have some drafts ongoing but I wanted to publish this short post right away.

One of the readers of this blog, Michel Clavette, sent me these pics just yesterday. He bought 5 Ai Light bulbs and to his surprise two of them do not have an ESP8266 microcontroller but instead this IC labelled KK2015.

KK2015 powered Ai Light. Picture by Michel Clavette

It looks like a drop-in replacement for the ESP8266 since it has the same footprint and all the other components are (apparently) the same. But we have not been able to find even the slight reference to this one on the whole Internet…

So this is an open question: does anyone know about this chip?

UPDATE 20170407: I’ve been confirmed the KK2015 is the very same ESP8266 marked with a different label, reason unknown yet.

UPDATE 20170407 (bis): A new update thanks to a contact  that was involved in design of the Ai Light. The mark belongs to Konke, “a big customer of Espressif, so Espressif provides mark service for Konke in 2016.” So after all, the KK2015 is a rebranding of the ESP8266, nothing more.

Michel will try to flash it using the same procedure as for the ESP8266. Hope we will have some info from him soon.

The post KK2015 based Ai Light appeared first on Tinkerman.

Last February 7 I attended a workshop at a the SokoTech in Barcelona to assemble my own Fenderino, the coolest guitar ever (my knowledge about guitars is very limited, so take this sentence with a grain of salt).

The guitar is actually a shield for the Arduino UNO and has been designed by the people at abierto.cc, an initiative aimed to provide open(-sourced) tools for educators, created amongst others, by David Cuartielles, co-founder of Arduino. The shield is inspired by the works of two very good friends of mine: Marc Sibila (@marcsibila) and Jordi Divins (@jdivins). You really should be following these guys, they are doing very special things as Instròniks.

The Fenderino

The shield itself is a beauty.

The shape resembles a Fender Stratocaster and the purple colors would appeal Prince himself. But that’s not everything. A few details make it really shine. The 4 LED brick for the visual notifications is one of those components you invent a project just to be able to use them. The item is a KINGBRIGHT L-875/4IDT and Cuartielles pointed me to the only source I have found for it: farnell.com. It sells for 1.34€ a piece.

The other detail that really stands out is the common cathode 4x 200ohm resistor array. Not as uncommon as the LED array, it limits the current to the LEDs on the array but it doubles as the bridge of the guitar. Nice detail.

The 9 buttons cover a complete octave plus one note (from C to C) and the two potentiometers are used in the sample sketches to change the octave (actually the pitch of the first button) and the volume. There is also a handy 3 positions switch to use different configurations.

Finally the output can be the builtin high quality buzzer or your headphones (or you HiFi system) connected to the 3.5mm jack out.

Open Source Software & Hardware

On the workshop we had the opportunity to test different sample sketches, from very simple ones to test the welding connections to scales, polyphonic sounds and a simple but amazing voice synthesizer using the Talkie library by Peter Knight.

Hardware files (KiCAD) and sketches for the Fenderino will be open source. They are not yet available but Cuartielles confirmed me this point just yesterday. As you can see the hardware is licensed CC-SA-BY-NC so basically you can copy and modify it as long as you do proper attribution and you use the same license and don’t make profit out of it.

Talking MIDI

Playing the guitar was so fun from the very first moment! I was eager to contribute somehow to the project.

At home, we got a new keyboard piano for Christmas and we had it connected to a tablet with the Synthesia app to learn to play some songs. It had been my first contact with the MIDI interface and I had that feeling I could do some fun projects with it. So I started looking at how to turn the Arduino into a MIDI device.

As it turns out, adding MIDI to a USB-capable microcontroller with Arduino is very easy. There are several libraries available. Mainly the MIDIUSB by Gary Grewal & Arduino. But you have to have an USB capable Arduino, like the Leonardo. What if you want to use a Uno?

The Arduino UNO has a second microcontroller on board that handles the USB communications. An Atmel ATMega8u2 or ATMega16u2. That controller talks USB to UART only. But the good thing is that it is a programmable microcontroller (at least in the official Unos, counterfeits sometimes use an FTDI chip or alike which is not reprogrammable).

What we need is to flash that helper microcontroller with a firmware that talks MIDI. Well, there is an open source project that does just that: the HIDUINO. The HIDUINO project “(…) provides a true USB-MIDI device for plug-and-play compatibility on Windows, OSX, and Linux – just like a commercial MIDI controller”. Sounds good.

There are two drawbacks. First you will need an AVR programmer to flash the HIDUINO firmware into the ATMega16u2. There is an ISP header just by the microcontroller to do so.

Second you will need a AVR programmer to flash the ATMega328P from then on since the USB handler IC is no longer doing its job as USB to UART bridge. Actually you only need one AVR programmer so it’s not that much hustle and you can always flash the original firmware for the ATMega16u2 and get back your Arduino UNO.

To flash the ATMega16u2, first checkout the HIDUINO project and grab the arduino_midi.hex file in the compiled_firmwares folder. Connect your programmer like in the pic below. I’m using an USBASP v2.0 [Aliexpress] here with a 10-pin to 6-pin flat cable, an AVRISPMKII [Aliexpress] will also do. To flash it the fast is to call avrdude from the command line (you might need to specify absolute paths for the avrdude binary or config file):

avrdude -v -p atmega16u2 -C avrdude.conf -c usbasp -Pusb -F -U flash:w:arduino_midi.hex -U lfuse:w:0xFF:m -U hfuse:w:0xD9:m -U efuse:w:0xF4:m -U lock:w:0x0F:m

Flashing the sketch is very similar, you can do it from the IDE but again it will be faster to do it from the console:

avrdude -v -p atmega328p -C avrdude.conf -c usbasp -Pusb  -U flash:w:firmware.hex:i

Check the image to connect the 6-pin flat cable in the right orientation.

Firmware

The Fenderino MIDI sketch will probably be available as an example from the abierto.cc repository. But if you are curious you can check my repo with only the MIDI example I had worked on.

The Fenderino MIDI sketch is released under the GPLv3 license and can be checked out at my Fenderino MIDI repository on Github.

And play!

Left to right: David Cuartielles, me and Marc Sibila at SokoTech. Uma is the canine in residence.

You can now buy the Fenderino shield from the abierto.cc store.

The post Fenderino, the coolest guitar appeared first on Tinkerman.

Some weeks ago I talked about the Magic Home LED Controller as I was adding support for it in my ESPurna firmware. At the time a user pointed me to the H801 Led WiFi Controller by Huacanxing. The user in question (Minh Phuong Ly) even did a pull request with some preliminary support for it. So I decided to give it a go.

The H801 is a 5 channels controller that you can find for about 9-10€ at Ebay or Aliexpress. It’s slighly more expensive than the Magic Home Led Controller (you can find the later for 7€ at Aliexpress) but it also is quite different from the insides…

The outsides

The first thing you notice is that this is quite bigger than the one by Magic Home. The later has also more “common” connectors both for power supply (the typical 2.1×5.5mm jack) and the strip connector since most have the same 4 lines for each channel (red, green and blue) and the common anode for power. The H801 uses screw terminals for every connection, input GND and VCC and the five channels (red, green, blue and two whites) and also the common anode.

So the Magic Home is more ready for plug and play while the H801 is a more adaptative solution.

The insides

The H801 has four philips screws in the back and once you remove them you gain access to the insides of the controller. Things to notice: each channel is driven by a beefy DTU35N06 [pdf, datasheet] by Din-Tek, a 60V N-channel mosfet in a TO-252 package. These are rated 35A or 106W maximum power disipation and they use quite some space on the board, with thick traces running to the terminals. The ESP8266 interfaces the mosfets via an NXPHC245 DTU35N06 [pdf, datasheet] bus transceiver that does the level shifting.

W1 and W2 are routed back to the screw terminal using wires

The W1 and W2 lines are routed back to the terminal using wires on the back, I guess the ran out of space in the PCB. Also on the back there is a AOZ1212AI [pdf, datasheet] buck regulator that is problably set to 5V output. And then the usual ASM1117 [pdf, datasheet] to lower it further down to 3V3 for the ESP8266.

All in all it looks more roomy. Even thou I don’t know what mosfets the Magic Home Led Controller uses they are SOT-23 packages. The ones in the H801 look more solid. But the specs for both controllers are the same (according to some sources): 48W per channel. I’m not sure I would use 4A per channel on my 12V strips with the Magic Home controller, but I might try with the H801.

Flashing it

Another good thing the H801 has it that it exposes the required GPIOs for firmware flashing in an easy way, not the small pads in the Magic Home controller. There is a header with 3V3, GND, RX and TX labeled and a jumper to tie GPIO0 to ground when you want to boot into flash mode.

The header with the programming cables (3V3 not needed if you are already powering the board via the screw terminals). Also, notice the jumper in place to enter into flash mode.

ESPurna firmware supports H801 since version 1.8.0. It is defined by default as a 5-channels device (LIGHT_PROVIDER_RGB2W). If you want to use it with a standard RGB LED strip you might want to change the light provider to LIGHT_PROVIDER_RGB in the hardware.h file.

// -----------------------------------------------------------------------------
// HUACANXING H801
// -----------------------------------------------------------------------------

#elif defined(H801_LED_CONTROLLER)

    #define MANUFACTURER        "HUACANXING"
    #define DEVICE              "H801"
    #define LED1_PIN            5
    #define LED1_PIN_INVERSE    1
    #define RELAY_PROVIDER      RELAY_PROVIDER_LIGHT
    #define LIGHT_PROVIDER      LIGHT_PROVIDER_RGB2W

    #undef RGBW_INVERSE_LOGIC
    #undef RGBW_RED_PIN
    #undef RGBW_GREEN_PIN
    #undef RGBW_BLUE_PIN
    #undef RGBW_WHITE_PIN

    #define RGBW_INVERSE_LOGIC      1
    #define RGBW_RED_PIN            15
    #define RGBW_GREEN_PIN          13
    #define RGBW_BLUE_PIN           12
    #define RGBW_WHITE_PIN          14
    #define RGBW_WHITE2_PIN         4

To flash it add the jumper to J3 and connect the cables. Be aware that the labels in the header are from the programmer point of view, so wire TX to your programmer TX and RX to RX. If you are already powering the board via the screw terminals you don’t have to wire the 3V3 pin. Then run (assuming you already have PlatformIO installed):

git clone https://github.com/xoseperez/espurna
cd espurna/code
pio run -e h801-debug -t upload

Once you have ESPurna in the H801 you can control your lights via MQTT, the REST API or third party home automation systems like Domoticz or Home Assistant.

Other references

These boards have been around for a while already and I’m not the first to review them or even reflash them. Check Eryk’s blog for another review and more code.  Also Andreas Hölldorfer has an in depth review of the board.

One curious thing about those two post is that in the pictures you can clearly see that the mosfets in those boards are different from what I found in mine. They use 20N06L [pdf, datasheet] by OnSemi very similar to the DTU35N06 but with a maximum power dissipation of 60W (the 20 in 20N06L stands for 20A and the 35 in 35N06 for 35A). Aside from that the boards look exactly the same.

Also, I’d like to recommend you reading a great project by Denys Parnell where he shows how to repurpose the H801 as a motor controller. Very cool and so cheap!

The post A closer look at the H801 LED WiFi Controller appeared first on Tinkerman.

Six months ago I was reviewing the AiThinker AiLight, a great looking light bulb with an embedded ESP8266EX microcontroller, driven by a MY9291 LED driver. Just before summer IteadStudio released it’s Sonoff B1 [Itead.cc] light bulb, heavily inspired (probably same manufacturer) by the AiLight, at least on the design.

Now that IteadStudio has become popular between the home automation community you can also find the Sonoff B1 on global marketplaces like Ebay or Aliexpress for around 13€.

A closer look at the B1 uncovers some important differences. But before going deeper into the details let me first say that this post will probably look more like a review, at least more than I use to write. And second, yes: ESPurna supports the Sonoff B1

An unboxing?

Not quite so. I leave that to other people with better skills on the video editing world. Let me just tell you than the “box” is somewhat different from what I expected. You might recall the AiLight box: a simple beige drawer-like box with a “WiFi Light” text and a simple icon. No colors, pictures, specifications,… nothing.

Instead, the Sonoff B1 I received from IteadStudio comes in a colorful box, with the usual pictures and data you can find in retail products.

Inside the box the light bulb is comfy housed in a polyethylene foam, along with a quality control certification and a small “getting started” manual in English and Chinese.

A heat sink?

Don’t think so. The first thing I noticed when I opened the box was that the bulb was very similar to the AiLight, the second the only visual difference. It certainly looks like a big heat sink. I almost fear touching it while connected. But how much heat can you generate if the light is rated 6W? The bulb body houses a basic AC/DC power supply (90-250VAC to 12VDC) and is accessible unscrewing the metal frame (the heat-sink part from the smooth part with the “sonoff” logo).

The AiLight is also 6W and you can safely touch it, even when it has been at full power for a lot of time. The Sonoff B1 shouldn’t be different. So I’m lean towards thinking it’s an aesthetic decision. Unless there are some beefy power LEDs inside.

Power LEDs?

Not all of them. Anyway I think this is the aspect where the B1 clearly differentiates from the AiLight. The later has 8 cold white power LEDs, as well as 6 red, 4 green and 4 blue power LEDs. The Sonoff B1 also has 8 cold white ones. But then it features 8 warm white power LEDs and 3 5050 RGB LEDs!

I don’t have a luximeter but the difference when fully white between the two is hard to spot. But the warm white color really makes the difference in favor of the Sonoff bulb. On the other hand, the 3 5050 SMD LEDs are clearly not enough. Even more: since the RGB LEDs are closer to the center of the round PCB, just around the WiFi antenna, the shadow of the antenna is very noticeable if you are using a colored light.

Hard to tell which one is brighter for the naked eye…

The pic does not justice the difference. The right on is the AiLight with the white power LEDs at full duty. The left on is the Sonoff B1 using the warm white power LEDs (you can see the yellowish color in the wall). The cold white LEDs are brighter but, depending on the room, the warm white LEDs could be more suitable.

Both bulbs again, now with the red channel at full duty. No need for words.

3 5050 RGB LEDs, 3 shadows of the antenna

A view without the cap, red LEDs are at 100% duty cycle, white LEDs are only at 10%…

I think the Sonoff B1 could be a better choice when used to illuminate with a warm white light your living room or your bedroom than the AiLight. If you need a colorful illumination, discotheque moods or a nice cold white for your kitchen, use the AiLight. Another possible (and interesting) use for Sonoff B1 would be as a notification light using traffic light color code, for instance. Clearly visible but not disturbing colors.

The controller?

Not the same. It is actually an ESP8285. In practice, you can talk to it like if it was an ESP2866 with a 1Mb embedded flash using DOUT flash mode. So that’s my recommended configuration.

The ESP8285 and required components with the 5050 RGB LEDs

As you can see in the pictures, the PCB is actually 2 PCB, one for the power LEDs and the other one for the microcontroller, some components and the 5050 on the front, a buck converter (12VDC to 3.3VDC for the ESP8285) and the LED driver on the back. The two PCBs are soldered together and glued to the underneath support.

In the AiLight the LED driver is a MY9291 [datasheet, PDF] by My-Semi. The Sonoff B1 uses another My-Semi driver, the MY9231 [datasheet, PDF]. The MY9291 is a 4 channels LED driver but the MY9231 is just 3 channels… so how is it possible to do RGB plus white and warm? Well actually these ICs are daisy chainable, so there are two MY9231 controllers in the Sonoff B1, the first one controlling the white power LEDs and the second the 5050 RGB LEDs.

I did not want to remove the glue under the PCB. But you can glimpse one My-Semi controller through the bottom hole.

ESPurna?

The ESPurna firmware is released as free open software and can be checked out at my Espurna repository on GitHub.

Sure! You can flash the Sonoff B1 following the same procedure of the AiLight. There are 6 pads on the PCB labelled 3V3, RX, TX, GND, GPIO0 and SDA. You will need to wire the first 5 (tin you cable, apply a small drop on the pad and then heat them together). Connect RX to TX, TX to RX, GND to GND, GPIO0 to GND and finally 3V3 to the 3V3 power source of your programmer. It will then enter into flash mode (GPIO0 is grounded). You can either flash the bin file from the ESPurna downloads section or build your own image (check the ESPurna wiki for docs).

Wired flashing of the Sonoff B1

Since ESPurna version 1.9.0 you define and control any number of dimming channels, you can also define the first three to be RGB channels. If you do, the web UI will show you a colorpicker to select the color.

You can also control it via MQTT. It supports CSS notation, comma separated or color temperature, as well as brightness and status, of course.

// 100% red
mosquitto_pub -t /home/study/light/color/set -m "#FF0000";

// 100% warm white
mosquitto_pub -t /home/study/light/color/set -m "0,0,0,0,255";

// 300 mired color temperature
mosquitto_pub -t /home/study/light/color/set -m "M300";

// 4000 kelvin color temperature
mosquitto_pub -t /home/study/light/color/set -m "K4000";

Of course you can also use Home Assistant MQTT Light component. The configuration would look like this:

light:
  - platform: mqtt
    name: 'AI Light TEST'
    state_topic: '/home/study/light/relay/0'
    command_topic: '/home/study/light/relay/0/set'
    payload_on: 1
    payload_off: 0
    rgb_state_topic: '/home/study/light/color'
    rgb_command_topic: '/home/study/light/color/set'
    rgb: true
    optimistic: false
    color_temp: true
    color_temp_command_topic: '/home/study/light/mired/set'
    brightness: true
    brightness_command_topic: '/home/study/light/brightness/set'
    brightness_state_topic: '/home/study/light/brightness'
    white_value: true
    white_value_command_topic: '/home/study/light/channel/3/set'
    white_value_state_topic: '/home/study/light/channel/3'

Either way, flashing custom firmware like ESPurna on a 13€ Sonoff B1 [Ebay] device allows you to first fully control your device (no connections outside your home network if you don’t want to) and second, make it interoperate with other services like Home Assistant, Domoticz, Node-RED or any other MQTT o REST capable services.

After all, I’m talking about Technological Sovereignty.

The post Sonoff B1, lights and shades appeared first on Tinkerman.

Eight months ago I reviewed and hacked the AiLight WiFi light bulb by AiThinker. By the time there was a number of people doing the same because of a key reason: it sports an ESP8266 microcontroller and it is based on the OpenLight by Noduino, that had already provided open source code for the LED driver inside, the MY9291.

Let time pass and I was doing the same with the Sonoff B1 light bulb by Itead Studio. That was two months ago and the conclusion was that the AiLight is brighter the the B1 but the lacks warm white channel the Sonoff bulb has.

And now here I have yet another WiFi light bulb, the Arilux E27 Smart Bulb. It looks pretty much like the other two, same shape, same microcontroller, same driver, but different base again and most important: different LEDs. So how does this one compare to the other ones?

Arilux E27 Smart Bulb

Arilux has a big catalog of lights, from security outdoor lights to fancy Christmas lights or disco lights. The Arilux E27 (its proper name is “Smart Bulb”) it’s a 7W RGBW light bulb with WiFi (IEEE 802.11b/g/n) that can be used on any E27 socket around the globe (85 to 285VAC supported).

It has an ESP8266 with a 1Mb flash memory like it’s siblings and the same light driver as the AiThinker light, the 4-channel MY9291. The Sonoff B1, on the other hand, uses two daisy-chained MY9231, three channels each and uses 5 of the 6 channels available.

Flashing it

Of course, you might want to use custom firmware with your new light bulb, something that supports MQTT, Home Assistant, REST API, with a nice web interface. Something like ESPurna, for instance

Anyway, you might need to wire the bulb to flash it the first time, from then on OTA is a better option. Like the other two light bulbs, this one has a properly labeled pads on the main circuit board where you can solder thin cables and use your USB2UART programmer.

Wiring it is simpler than it may seem. Heat the pad, leave a drop of tin on it, tin your wire also and then heat them together. You will only need a fraction of a second to have the cable connected to the pad. Then just connect it to your programmer. Remember it’s a 3V3 device and you have to connect IO0 to ground before powering the board so it enters into flash mode. The follow the instructions of your firmware of choice (here the ones for ESPurna with AiLight) and you are good to go.

AiLight vs. Sonoff B1 vs. Arilux E27

LEDs

These three bulbs are functionally identical but have obvious differences due to the type of LEDs they use (aside from the warm white channel in the Sonoff B1). The table below tries to summarize the differences between the three:

But of course the number of LEDs is not enough to compare them. Actually you can see in the pictures that the power LEDs in the bulbs are quite different one from the other (5050 RGB LEDs aside).

Sonoff B1 LEDs, notice the 3 5050 RGB LEDs in the center board, too close to the antenna

The Arilux light bulbs, very similar to the AiLight but different kind of power LEDs

The power LEDs in the AiLight are bigger, brighter and evenly located, an overall better result

Light power

So, how do they compare when talking about brightness? In my previous post about the Sonoff B1, I noticed the 5050 RGB LEDs were clearly not enough, much much less bright than the power LEDs in the AiLight. It was very obvious (you can check the pictures on that post), but subjective appreciation after all.

This time I have decided to do a more “scientific” experiment. As it happens I have several luximeters at home for another project, so why not use one of those to compare the three bulbs in a controlled environment. The luximeter I have used is a UNI-T UT383. You can buy one for around 12€ from Aliexpress (UNI-T UT383 at Aliexpress) or Ebay (UNI-T UT383 at Ebay). It is on the cheap side and there is no information about how it performs for different wavelengths (only they have been calibrated at 2856K), but it should be enough to compare the three bulbs brightness.

UNI-T UT3838 luximeter

So here is the experiment set up: the three light bulbs have been tested using the luximeter at a distance of 50cm, without obstacles that might reflect light (>90 3D degrees clean around the light). I have recorded the value in luxes for each channel at 100% duty cycle (other channels off). I have also tested the three color channels together (red + green + blue) and all the channels together. This chart shows the results:

The AiLight power LEDs really make the difference. The Arilux colour LEDs perform better than the poor 3 5050 RGB LEDs in the Sonoff B1, but the later has the advantage of having a second set of white LEDs (warm white in this case) so when everything is at full power it’s actually brighter than the Arilux, but still far from the AiLight.

Price

So it looks like the AiLight might be the best option for most use cases, except when you need a warm white light bulb. The final argument might be the price.

So you can buy any of the three light bulbs for around 12€ so there is no big difference here.

Conclusions

The final verdict is very much the same as when I reviewed the Sonoff B1. If you need light power go for the AiLight. The Sonoff B1 can be a good option if you are looking for a warm white light since it’s the only one that offers such possibility. Both the Sonoff and the Arilux lights can be a good option too when looking for a notification light, a traffic light kind of visual notification for instance. The Arilux colors are a bit brighter than the ones in the Sonoff B1 (those 5050 LEDs are not a good idea), but still way fainter than the ones in the AiLight. So for most cases, you will probably want to go for the AiLight unless you happen to find a good deal on any of the three…

Update: Timo Rohner has had some trouble importing Arilux light bulbs into Poland and he had to search for CE documentation for the devices. He sent me the documentation so you can also have it in case you will need it. Here you have the Certificate of Confirmity for Arilux CC-01 to CC-08. Thank you, Timo!

The post Yet another WiFi light bulb appeared first on Tinkerman.

A few years ago (not many) I used to burn copper plates using acetic acid, a.k.a. vinegar. I was somewhat concerned about using stronger acids so it was OK to use another acid, even if it was soooo sloooow. If you were patient you could get to have decent boards using 50mil traces (or even thinner). But it required keeping a good temperature on the copper bath and regulating the ratio vinegar/hydrogen peroxide continuously, adding a little salt from time to time to speed things up.

The vinegar biting the copper

One day I saw an article about cheap Chinese PCB fabs (I think it was DirtyPCB by Dangerous Prototypes) and I decided to design my own board and send it to fab. I used Eagle (I still use it although I’m learning KICAD) and the learning process was significant. But at the end I managed to get something. I learned to use copper pours, to correctly label the board, to create my own parts, to avoid auto-route, to use design rules and create gerbers,…

And over time I have tested different fabs. I’m not an expert by any means but I wanted to write a bit about them here. The basic order I usually do is a 10 units, under 50x50mm board, 1.6mm thick, 1oz copper and HASL Lead Free due to RoHS rules in the EU. The prices and options below are based on these settings.

One more thing. I reckon these suppliers are good enough in most cases for small batches, testing boards or DIY projects. Some EE are concerned about the quality of the boards and they prefer EU-based (or US-based) fabs. I cannot offer a good reason to use these manufacturers here or to not use them in professional/industrial projects.

Smart Prototyping

Smart Prototyping (China) was the first fab I used. It offers affordable prices if you stick to their green PCBs. $9.9 for 10 boards is great. If you want to go red, blue, white… they will cost you $17.90. Uncommon colors like purple could go as high as $45 for 10 units. ENIG means $11 extra and 2oz copper is more than $30 more. Of course this is still pretty cheap.

I have never had problems with the quality of the boards. And if I had problems with the boards it has always been a design error. They add an internal order number on the boards that can be annoying.

Their green PCBs are somewhat matte. You might want to ensure you have proper space around drills. The milled slots or cut-outs are kind of rough on the edges (but that’s not an issue) and the silkscreen looks like melted sugar (does anyone know the name of this technique?).

Smart Prototyping offers stencils, PCB assembly and parts sourcing as well, but I have not used these products so I can’t tell.

SeeedStudio

SeeedStudio (China, with offices in Japan and the USA) is very well known for it’s bazaar, a place where you can find lots of low and high tech products for your next project. But also has the Fusion service, where they provide affordable PCB prototyping as well as PCBA (Assembly) services.

Price is a bit higher than with Smart Prototyping but they do not charge extra for color PCBs, so if you want something different from green Seeed’s options is cheaper. ENIG will cost you $15 extra and 2oz copper will cost you more than $30 extra.

A good thing for those of us to whom double or triple checking is never enough is that it has a gerbers viewer where you can see how the board will look like. I have gone back to the CAD a lot of times after checking the visual aspect of the board.

The milling is cleaner than with Smart Prototype service. The silkscreen is dotted and that means characters look crispier but sometimes lines look pixelated or having different widths along the line. Drill holes have a fair margin around without copper, silkscreen or any other layer, just silicon. The overall feeling is really good.

SeeedStudio’s PCBA service is so easy to use! It doesn’t have a fixed starting cost as with Smart Prototype’s one and you can get a online quote if you only use parts from their OPL (Open Parts Library) which has 600 common parts. They source the part and assembly it. You can always use a part using it’s manufacturer reference but then I think they will quote your order manually. I have used it to populate hard to hand-solder BGA packages and it’s worth it. Well basically sometimes it’s the difference between being able to fulfill the project or not being able to. Highly recommended.

WellPCB

WelPCB (China and Australia) is a new kid on the block (at least from my point of view). Unless Smart Prototyping or Seeedstudio they focus on the PCB fab service, they do not sell parts, modules, or whatever else.

Update: Howie Liu from WellPCB has contected me to remark that even thou they specialize in PCB Prototype services, they can also offer PCB Production, Component Procurement, PCB Assembly. They work with different component suppliers like Digi-key, Mouser and Element14 for small quantity orders. Arrow, Avnet and Future for mass production.

Promotion: They are also running a Christmas Promotion until December 24th: only $3.99 for PCB Prototype (≤100m*100m, 1-2layers, 10pieces). Not bad, right?

Price for 10 units (50x50mm, 1.6mm thick, 1oz copper, HASL Lead Free) is slightly higher than Seeed’s, but again they let you choose the board color without extra charge so (unless you want it green) it’s cheaper than Smart Prototype. One think you can do is choose the silkscreen color between white and black, whilst the others use a fixed color. You can get immersion gold finish for $20 or 2oz copper for just $10 extra. That’s a lot cheaper than the other two and worth it if your board uses high current traces.

The boards look and feel are very similar to those by Smart Prototypes. Their green color is more vivid, the milling is as good as with Seeedstudio and their silkscreen is thinner (makes the Smart Prototyping silkscreen look like a bold font). I have noticed a few imperfections on the board (look the pics below). I don’t know the reason or if it was a defective manufacturing but any way it’s just make up, not an issue.

WellPCB also offers PCB assembly service but it’s not integrated in their web page so you’ll need an offline quote.

There was one thing that really make it stood over the others. Along with the PCBs I received a 4-pages quality report (Final Inspection Report, E-Test Report and Microsection Analysis Report) with a lot of interesting info. Just for this it is worth testing their service.

OSH Park

OSH Park (USA) is the only service in this post that it’s not located in China. I don’t have fancy pictures to show you. I primary use their service for small boards and very small batches (3 units). Since the final price can be as low as $5.

Update: Actually, as some user have reported, there is no minimum-price, it all depends on the board size so you can get a price tag of just $1.5 for 3 units of a 0.5″ square board.

You don’t have many options. Actually you barely have any option. Their boards are purple (they are very well known for this) and gold plated. Always. You can choose 2oz copper at expense of 0.8mm thickness but for the same price. And “swift service”. And that’s it.

They claim to be able to do 6mil traces but I have had problems with that in the past. I’m not saying they have a bad quality. It’s just meant for a different user target.

One thing I don’t like about OSH Park is that they say they are focused on building a community around OSHW projects. That’s great, but the tools they offer are meant to buy them boards designed and shared by other users. You don’t have any way to share schematics, layouts, BOM, whatever that would be necessary to publish a truly OS hardware project. You only have a title and a description field.

Overall, it’s a useful platform to let other users have one or two or three copies of your board (I have used it myself for this reason) but this is not open sourcing your hardware.

Conclusions

Smart Prototyping, SeeedStudio and WellPCB offer quality at a good price for your project, either if it’s a DIY/maker project or an early stage prototype. Seeedstudio is the one offering a more complete online experience for PCB and PCBA services. WellPCB looks like being the more professional-oriented option. Either one of these two are worth giving them a the chance to become your official PCB fab.

Just go ahead and start designing your PCBs with your logo on them!

The post PCB fabs appeared first on Tinkerman.

I’ve been testing quite a few LoRaWan nodes lately for TheThingsNetwork.cat, some based on HopeRF RFM95W (over AVR, ESP8266, ESP32,…) others using Microchip’s RN2483 (an old friend of mine). I have a RAK811 waiting in the INBOX but the last one I’ve been playing with has been the new Arduino MKRWAN 1300 (so new there is no product page yet) and I liked it, quite a lot.

The device is one of the MKR series Arduino is pushing forward. So far the family includes the MKR ZERO (did they name it after the RPi Zero? actually, it’s named after the Cortex-M0+ MCU, and it had that name “far before the RPi”, as David Cuartielles has pointed out), the MKR 1000 with WiFi, the MKR FOX 1200 with SigFox support, the MKR WAN 1300 and the MKR GSM 1400.

They all sport a SAMD21 Cortex-M0+ [pdf, datasheet] 32bit low power ARM MCU clocked at 48MHz, 256Kb of flash memory (to store your code) and 32Kb of SRAM. That’s quite an improvement from the Uno family (ATMega329 / ATMega32u4). It also has a bunch of digital IO, most of them PWM, several ADC of up to 12bits depth, hardware UART, SPI and I2C and even one DAC (!!).

But the reason this is my first MKR dev board is its LoRaWan compatible module. A Murata CMWX1ZZABZ that includes a STM32 microcontroller with an AT firmware you can interface with from within your sketches.

There is still little information about the board in the Internet. Sure you can find press notes but there is little hands-on stuff yet: the MKRWAN library repo and a “Getting started” repo by Gonzalo Casas from TTN Zurich. Gonzalo uses the Arduino IDE to explain the first steps with the board. But I’m going to write here about my experience using it from my favourite environment: PlatformIO.

UPDATE: Just a small update since I have been doing some research on the board and I found out there is no info about the LDO it uses. The schematic just states a generic “LDO2SOT89-3L”. After trying to decode the label in the LDO package with a magnifier (“N8 7IT”) and googling around I think the LDO is an AP7215 [PDF, datasheet] by Diodes Incorporated. This is a low dropout voltage LDO (aprox 1:1 to Iout, i.e. 300mV at 300mA), with a maximum input voltage of 5.5V and 3.3V output at stable 600mA (max of 750mA), more than enough to power the SAMD21 and the Murata module (128mA max transmitting at full power). The LDO has also a pretty low Iq of 50uA. 

Configuring PlatformIO for the MKR WAN 1300

Yes. The MKR WAN 1300 works just fine (almost, see below) with latest Arduino IDE versions. But I just happen to use not Arduino IDE. So I quickly headed to my favourite builder, PlatformIO, listed the supported boards and… no luck. The 1300 was not there.

There are quite a few SAMD21 boards supported, starting with Adafruit’s M0 boards, some Arduino MKR and others. But not the MKR WAN 1300. Next I tried using MKR ZERO board assuming that since it is the minimum common denominator for all MKR boards I could get something out of it. Wrong.

As it turns out there are some small details as the device signature that prevent it from working with other boards. Albeit more obvious differences like available GPIOs in the headers.

Long story short, I migrated the configuration from Arduino IDE to PlatformIO, comparing them with other MKR boards already defined. There are two packages that require an update and I have submitted pull-requests for that to PlatformIO. I don’t know what’s the policy they have about supporting Arduino boards. Somewhere I read something that made me think they have an automatic process, but as of today the packages are obviously outdated.

Anyway, the changes are in the AtmelSAM platform (see PR here) and ArduinoSAM framework (PR here). While the PRs are not merged you can install support for any SAMD board and then patch those packages in you .platformio folder.

$ pio boards | grep -i mkr
mkr1000USB            SAMD21G18A     48Mhz     256kB   32kB   Arduino MKR1000
mkrfox1200            SAMD21G18A     48Mhz     256kB   32kB   Arduino MKRFox1200
mkrwan1300            SAMD21G18A     48Mhz     256kB   32kB   Arduino MKRWAN1300
mkrzero               SAMD21G18A     48Mhz     256kB   32kB   Arduino MKRZero

Voilà

The MKRWAN library

No that I can flash the MKR WAN 1300 using PlatformIO let’s go to the LoRaWan part. The people from Arduino have released a library just for that. The Murata module in the device has a STM32 frontend that exposes an AT command interface you can use from the SAMD21 using the MKRWAN library.

Both the firmware for the STM32 (mkrwan1300-fw) and the MKRWAN library are available on GitHub. But you can also install the library using the PlatformIO library manager.

$ pio lib search mkrwan
Found 1 libraries:

MKRWAN
======
#ID: 2009
Support library for MKR WAN 1300

Keywords: communication
Compatible frameworks: Arduino
Compatible platforms: Atmel SAM
Authors: Arduino

Install and test. There is a full example called FirstConfiguration.ino that does it all. Shows the device EUI so you can register it in your TTN backend and allows you to join via OTAA or ABP and send a test message. Cool.

$ cd
$ mkdir -p workspace/mkrwan1300_test
$ cd workspace/mkrwan1300_test
$ pio init -b mkrwan1300
$ pio lib install mkrwan
$ cp .piolibdeps/MKRWAN_ID2009/examples/FirstConfiguration/FirstConfiguration.ino src/
$ pio run -t upload
$ pio device monitor -b 115200
Welcome to MKRWAN1300 first configuration sketch
Register to your favourite LoRa network and we are ready to go!
Your module version is: ARD-078 1.1.2
Your device EUI is: 0123456789abcdef
Are you connecting via OTAA (1) or ABP (2)?
1
Enter your APP EUI
0123456789012345
Enter your APP KEY
01234567890123456789012345678901
Message sent correctly!

Wow. That was amazing for a first test. I was very pleased to see that OTAA worked out of the box. But ABP did not.

After digging a bit on the problem with ABP I hit a dead end when I couldn’t find the documentation for the STM32 firmware. So I decided to open an issue on the library repository on GitHub last Friday and on Monday it was solved. Not bad! As a side note, the STM32 firmware repository was not public yet (that’s why I couldn’t find any docs) but that has changed this Monday 29th January.

Updating the firmware in the STM32 inside the Murata module

Once a solution was proposed I had to flash the firmware on the STM32 and update the MKRWAN library. Fortunately the developer of the library (Martino Facchin, thank you very much) had added a firmware upgrade sketch in the examples folder that includes the latest firmware image in the fw.h file. So I removed the old library, cloned the new one and run the upgrader example:

$ pio lib uninstall mkrwan
$ git clone https://github.com/arduino-libraries/MKRWAN lib/MKRWAN
$ rm -rf src
$ cp -r lib/MKRWAN/examples/MKRWANFWUpdate_standalone src
$ pio run -t upload
$ pio device monitor -b 115200

You will now see the progress of the upgrade and a final “Flashing ok ARD-078 1.1.3” message. Good.

And finally: testing it!

Now back to the FirstConfiguration example, flash, open a connection to the device and…

$ rm -rf src
$ cp -r lib/MKRWAN/examples/FirstConfiguration src
$ pio run -t upload
$ pio device monitor -b 115200
Welcome to MKRWAN1300 first configuration sketch
Register to your favourite LoRa network and we are ready to go!
Your module version is: ARD-078 1.1.3
Your device EUI is: 0123456789abcdef
Are you connecting via OTAA (1) or ABP (2)?
2
Enter your Device Address
22334455
Enter your NWS KEY
01234567890123456789012345678901
Enter your APP SKEY
01234567890123456789012345678901
Error sending message

Now what? Well, looking at the TTN console I noticed the message actually went through… Looks like it timed out before receiving the ACK.

There are some things to improve yet but the overall initial experience is very good. They are actively working on fixing problems and that even better. Now it’s time to do some real life tests to see if this is a dev board of choice.

The post Arduino MKR WAN 1300 appeared first on Tinkerman.

It’s not that other Sonoff products are not “serious” business, but there are a number of design changes in the Sonoff S31 that make this new product a world apart. For the functional point of view it looks like a S20 with POW-powers, but they have redesigned the product completely. The result is very very interesting.

• Revamped case, more compact and sturdy
• Redesigned PCB, actually 2 different PCBs for main and control
• Different power monitor chip: the CSE7766 (same as in the new POW R2) replaces the HLW8012

The only drawback: it’s only compatible with plug types A & B, tat is central and north-america and few other countries. I’d love to see a S31-EU schuko version!

You can buy the S31 from Itead (see link above) or via the usual marketplaces. Actually the S31 is slightly cheaper [Ebay] on some of them.

Not an unboxing

You know I don’t do unboxings so  this is not an unboxing. They just happen to be pictures with the device in a box.

The device itself is kind of pretty, compact and robust. It has some appealing design choices (outside and inside) and the way everything fits together (see more pictures below) is great.

Aside from the male and female type A plugs, you have a ON/OFF button on the dark gray side and two LEDs. The red LED closer to the side shows the relay status and the blue one, closer to the plug is used for notifications.

Every time I look at a USA plug I get the same feeling. Ooooh, how is that you are so sad? But this time it was also my face. The slick design of the device gets completely ruined with the two adapters (C to A and A to C).

The design is very different from the S20. The later is used by several manufacturers for their branded smart plugs, so it’s probably someone else’s design. I can’t tell about the S31 but the level of integration makes me think it’s an adhoc design.

Opening it

Opening the case to hack the device it’s not hard. The only tricky step is to measure the strength you have to apply to first remove the dark grey cap where the ON/OFF button is.

Then you have to slide the corners to reveal 3 small Philips screws that will let you remove the top completely. The bottom side (the one with the male plugs) seems to be glued to the PCB so it is not easy to remove without risking breaking something. Anyway you don’t need to access the bottom side of the PCB where there are only a few passives and a SO8 chip, probably the switching power supply chip.

Compact design

The design is based on two PCBs. The bigger one for the AC connections, AC/DC transformer and relay. And the smaller one for the the DC circuitry, including the ESP8266, an SPI flash memory and the CSE7766 power monitoring chip. It sounds like a good idea but it gets somewhat screw because they don’t actually isolate AC from DC. AC is in the secondary PCB too since the power monitor chips needs access to mains. Also the distance between AC and DC traces is thinner than what would be desirable.

Notice that, unlike the S20 where the PCB is connected to the plug barrels via wires, in the S31 the connectors are soldered to the PCB. This saves some space for sure but probably makes the device more sturdy too. The removable cap has separators to ensure the contacts are isolated from other components, including the small cables from the transformer.

For a complete photo book of the S31 you can check the FCC database photos.

The CSE7766 power monitoring chip

IteadStudio has switched from the HLW8012 chip to the CSE7766 for power monitoring with their latests products, the S31 and the POW R2. The reason might be that the new chip by Chinese manufacturer Chipsea offers a more stable reading, according to the first tests. The good news are that both chips are pin compatible even thou the protocol is very different.

You might remember from my post about the HLW8012 that this IC uses two pins to output power and current/voltage as variable-frequency square wave. Those pins are number 6 and 7 in the SO8 package. Pin 8 is used in the HLW8012 as an input pin to select whether the output in pin 7 would be proportional to the current or the voltage.

The CSE7766 [datasheet, PDF] uses a serial protocol instead. At the moment only TX line (pin 6) is enabled. The RX line in pin 8 is flagged as “reserved” in the datasheet. Pin 7 outputs a 50% duty cycle pulse with frequency proportional to the active power, just like the HLW8012.

HLW8012 suggested application

CSE7766 suggested application with isolation

So you see that on both chips have the same AC interface (left side of the chip) and a similar interface on the MCU part (right side). Actually pins 6 and 7 are outputs and pin 8 is an input on both chips.

Mind that the CSE7766, just like the HLW8012, ties the logic ground to the mains neutral line. This is commonly known as “hot ground”. It’s not bad by itself as long as ground is not exposed outside the case.

But

We all know about Itead products. They have walked a long path since the first Sonoff Basic (or Sonoff WiFi). But still, they do not provide any electrical safety certifications (ETS, UL, ETSI) with their products. They have applied for FCC, claim to be CE and comply with RoHS but EE and professional electricians will probably not install these devices. It’s true the S31 is a plug-and-play device, no electrician required, but in some sense it’s an “AS IS” product. You are a maker, right?

Even thou IteadStudio is improving with every design, safety distance between AC and DC traces is not met.

The POW and S31 have the caveat of being non-isolated devices. Mains are connected to the logic ground and the power monitor IC output is not isolated from the MCU. Even thou the datasheet suggests an isolated application using an optocoupler I have not seen it in the S31. So please, take all the safety precautions when the PCB is exposed.

Flashing ESPurna on the S31

REMEMBER: do not do this while the device is connected to mains. The logic ground in the device is connected to the mains neutral line.

Flashing the S31 with custom firmware requires soldering some wires or a header to the pads at the edge of the small PCB. These pads expose (not only) GND, 3V3, RX and TX. Just connect them to your USB2UART programmer. Then press and hold the button (which is tied to GPIO0) and connect the programmer to your computer so it will power the board.

With GPIO0 connected to GND (that’s what the button does) the ESP8266 will enter flash mode. You will then be able to flash ESPurna (or any other firmware) to the device via serial from your favorite IDE or from the console using esptool.

ESPurna supports the Sonoff S31 since version 1.12.6. It can control the relay, the notifications LED and report current, voltage, active power and energy to Thingspeak, InfluxDB, Home Assistant, Domoticz or any other service via MQTT.

That’s it. You might have notice I’m not writing as much as I used to a few months ago. I happen to be quite busy lately which is not bad news. But I really miss to be able to spend some more time exploring new devices…

See you soon, hopefully!

The post Sonoff S31, a world apart appeared first on Tinkerman.

I do not do reviews usually, but I sometimes do exceptions. In this case, it’s worth doing it, due to 4 main reasons:

• It’s a software & hardware open source project
• It’s local (local to me, that’s it)
• It’s led by two good friends
• It’s related to LoRa and The Things Network
• It’s awesome!

OK, they were actually 5 reasons, but the last one just slipped in.

The WhiteCat ESP32 N1 Board

The WhiteCat ESP32 N1 Board is a green board in a long-ish form factor, longer than the LoPy or the Chinese ESP32-based LoRa boards. This is probably due to the fact that it is not as packed as those and it also sports some features the others lack.

The Whitecat project is sponsored by CSS Iberica and the Citilab, a Living Lab in Cornellà, near Barcelona.

Good old friends (already)

No, I’m not talking about Miguel Ferrera and Jaume Olivé, the tech heads behind the WhiteCat project. I’m talking about ESP32 and RFM95. These two you might have seen them in several LoRa boards and they team up pretty well. Actually, there’s little more you need to have a working LoRa/LoRaWAN compatible board with enough power to fulfill your darkest desires.

No USB. Didn’t you say it was a dev board?

No, I didn’t. But it certainly looks like a dev board. Actually, I was talking to Jaume the other day and they are still unsure about the form factor and I can see why.

It lacks some things to be a standalone dev board (like a USB connection) but at the same time, it is not a production board (too large, no SMD option). On the other hand, it does have reset and flash buttons, like a real dev board, and at the same time, uFL connectors like you would expect in a production board…

Don’t forget the antennas, wait…

You already know what happens when you trigger a message at full power and there is no load (antenna) attached, right? All those mW bounce back to your precious electronics and start behaving like Attila the Hun, burning everything on the way. “The grass did not grow where Attila had passed”. Well, if you didn’t know, now you do.

The N1 has uFL connectors for external antennas but it also has onboard ceramic ones. Both for the WiFi and the LoRa module. It’s a curious setup as I have always thought it is not a good idea to have two antennas attached to the same trace. But I’m not an RF engineer.

Then there is this thing about the uFL connectors. They use very little PCB space and they are very useful when using case mounted antennas. But those connectors are tiny! And they are not meant to be used over and over for more than a few tens of times. So be careful.

Schizophrenic board

So it’s kind of a schizophrenic board. I have to tell you I do like the board. It feels good. I do not like over-populated boards where you can’t click a button without touching a number of passives at the same time. I think going one-side only is a good choice. I also like the onboard antennas, forgetting about the antenna is a major issue when doing workshops. I’m not sure about the uFL connectors. I would probably go without the WiFi one. But I really miss an onboard USB with a USB-UART chip.

Even thou I strongly recommend to get the devkit (see below) it shouldn’t be necessary to have another board (the popular FTDI boards, although most of them do not use FTDI chips anymore) to use the WhiteCat N1. It might be OK for makers and other species but it is not when doing workshops or at school. But again: get the devkit

A very interesting development kit

If the N1 board is a solid but standard LoRa board, the guys at WhiteCat decided to design a carrier board for it with convenient headers to connect anything you want, as well as some specific ones for I2C, analog inputs or CAN bus.

Here I will focus on some of the features of the carrier board, you can read more in the Whitecat N1 DEVKIT user manual (only available in Spanish at the moment).

Flash it!

Yes. Here you have it. A CP2104 [datasheet, PDF] USB to UART bridge by Silicon Labs. This is all you need to connect your N1 to your computer to load the firmware or the scripts from the browser IDE and get debug messages.

It teams with a miniUSB jack. I guess they will be around for some more time yet. One thing about miniUSB jacks is that they are big enough so you get the right orientation on the first try. Much better than microUSB.

So much juice for a devkit

You might have noticed in the picture the big battery holder on the carrier board. It is meant to house a 18650 LiPo battery. This is a popular battery pack that is big enough to store up to 3000mAh some of them (be careful with the ones claiming 5000mAh or 9000mAh!!!).

The USB connector is used to charge the LiPo and to power the board. The responsible for the charging process is a TP4056 [datasheet, PDF] Li-Ion battery charger.

There is one issue here that the guys at WhiteCat should improve: If you don’t have a battery in the holder and want to power the board from the USB connector you need to connect a jumper cable from one of the 5V pins near the OSH logo and the BAT pin in the header. The cable must not be present if there is a battery in the holder.

Bypassing the ESP32 drawbacks

The ADC in the ESP32 is a pity. It suffers from non-linearity and a random noise due to the power source. They are currently working on patching it on software using curve maps and noise filters but, if they succeed, it will result in a low depth ADC at best.

That is by Miguel added an ADS1015 [datasheet, PDF], a 12-bit, 4-channel external ADC with a programmable gain amplifier included. This is a great addon for any ESP32 carrier.

Yes, it CAN

The carrier also ads an SN65HVD231D [datasheet, PDF] CAN bus transceiver and the required jumper to enable a 120Ohm termination resistor.

Sensors & storage

One little fiddling issue I stumbled upon when using the carrier was that the sensor was not being powered. The reason was that there was a missing jumper between the red and green pins in the header 3V3 pin. I don’t know why but apparently you have to explicitly connect the power rail in the carrier either to 3V3 or (the other possible option) to BAT.

Being an IoT board you will probably want to send the data from your sensors right away. WiFi, LoRa, CANbus,… you have many options. But no communication is not error free. That is why it is very convenient to have a microSD socket in the carrier.

The key is in the software

Since both the ESP32 and the RFM95 are “good old friends” we can pretty much load any firmware we would like on the WhiteCat N1. But don’t do it. Believe me: you want to play with the original firmware that the guys from WhiteCat have developed for their boards.

A browser-based IDE

The first thing you have to know is that the IDE only works with Chrome and you will need to have an agent installed to interface between the Chrome app and the board. That means (the second thing you have to know) that you have to have a compatible board connected to use the IDE.

Installing the agent is easy, just follow the instructions in the agent repository wiki. Once installed, run it and select the “Open The Witecat(sic) IDE”. It will open a web page so Chrome must be your predefined browser. If it’s not you can also open the site manually: https://ide.whitecatboard.org.

From here on there is a lot to explore. Let me just point you a couple of things.

Meet Lua

From the online IDE you can code your “sketch” using Lua. Lua is a scripting language targetted to embedded applications. It can be a bit confusing at first since its naturally asynchronous and thread based.

The language is powered with a lot of custom commands and libraries to use common interfaces (I2C, UART, CAN, SPI,…), sensors (BME280, DHT22,…) and actuators (relays, displays,…). It also provides an API for WiFi, MQTT, LoRaWan or the option to configure an SSH server or a VPN client.

You can read all the documentation about the WhiteCat Lua RTOS and the available modules in the Lua-RTOS-ESP32 wiki.

Wow! IoT with Blocky

If Lua is targetted to somewhat experimented developers, the other language option provided by the IDE is targetted to kids. What about programming an IoT device using a blocks language. Here you have it.

The interface is based on Google’s Blockly, enhanced, again, with different modules to manage WiFi, LoRa or MQTT connections, use sensors or different protocols. You can even see the corresponding Lua code by clicking the “eye” icon. unfortunately is a read-only view, you cannot change the code in Lua and go back to Blockly.

The sketch below, for instance, connects to the The Things Network LoRaWan network and sends temperature, humidity and pressure from a BME280 sensor every 120 seconds.

There is a Lua API to pack and unpack the messages in a binary format suitable for LoRaWan messages. The “pack hex string” block in the picture above is translated into something like:

pack.pack(_getsensor0_temperature(), _getsensor0_humidity(), _getsensor0_pressure())

To unpack this blob in the TTN console you can use this decoder routine:

function toNumber(bytes) {
  var bits = (bytes[3] << 24) | (bytes[2] << 16) | (bytes[1] << 8) | (bytes[0]); var sign = ((bits >> 31) === 0) ? 1.0 : -1.0;
  var e = ((bits >> 23) &amp; 0xff);
  var m = (e === 0) ? (bits &amp; 0x7fffff) << 1 : (bits &amp; 0x7fffff) | 0x800000; var f = sign * m * Math.pow(2, e - 150); return f; } function toInteger(bytes, len) { var out = 0; for (var i=len-1; i>=0; i--) {
    out = (out << 8) + bytes[i]; } return out; } function toString(bytes) { var s = ""; var i = 0; while (0 !== bytes[i]) { s = s + String.fromCharCode(bytes[i]); i++; } return s; } function toBool(bytes) { return (1 === bytes[0]); } function unpack(bytes) { // array to hold values var data = []; // first byte holds the number of elements var size = bytes[0]; // get data types var types = []; var count = 1; do { var type = bytes[count]; types.push(type >> 4);
    types.push(type &amp; 0x0F);
    count++;
  } while (types.length < size);
  types = types.slice(0, size);

  // decode data
  for (var i=0; i<size; i++) {
    var type = types[i];
    if (0 === type) {
      data.push(toNumber(bytes.slice(count,count+4)));
      count += 4;
    } else if (1 === type) {
      data.push(toInteger(bytes.slice(count,count+4), 4));
      count += 4;
    } else if (5 === type) {
      data.push(toInteger(bytes.slice(count,count+2), 2));
      count += 2;
    } else if (6 === type) {
      data.push(toInteger(bytes.slice(count,count+1), 1));
      count += 1;
    } else if (3 === type) {
      data.push(toBool(bytes.slice(count,count+1)));
      count += 1;
    } else if (4 === type) {
      var s = toString(bytes.slice(count));
      data.push(s);
      count += (s.length + 1);
    }
  }
  
  return data;
  
}

// ----------------------------------------------------

function Decoder(bytes, port) {

  var decoded = {};
  
  // BME280 @ WhiteCat
  if (port == 10) {
    var data = unpack(bytes);
    decoded.temperature = data[0].toFixed(2);
    decoded.humidity = data[1].toFixed(0);
    decoded.pressure = data[2].toFixed(2);
  }
  
  return decoded;

}

Yeah, it’s libre, so why not…

… load the Lua RTOS implementation by WhiteCat on other boards? Sure you can.

There is just one gitch. Since Lua is an interpreted language you will need to implement the proper “handlers” for your board and peripherals. This is more or less like having the right GPIO definitions (like the ones defined in the boards.txt file in the Arduino ecosystem) and the right libraries to use the sensors, protocols, displays,… you will want to use.

So your firmware image will have to have all the required components and then, from the browser IDE you will script your code in Lua using those components. And adding new features to the Blocky-based environment is surely even more involved. Good news is that the RTOS already supports a lot of common sensors and IoT-oriented protocols. And if you are not lucky, there is plenty of code to learn from in the Lua-RTOS-ESP32 repository.

Keep an eye on these guys

If you should definitely check their current development with the Lua RTOS for ESP32 or the Whitecat ESP32 N1. You won’t want to miss their upcoming projects. Just take a look at this: an ESP32-based LoRaWan gateway using the iC880A concentrator board by IMST.

Don’t you think it’s got potential? I do. Actually, I’m already working on something on the line…

The post WhiteCat ESP32 N1 appeared first on Tinkerman.

Recently we at @ttncat had to prepare a crash course on LoRa, LoRaWAN and The Things Network for a professional school in Barcelona. It was a 15 hours course that covered from the very basics to some more advanced topics on RF like link budget, attenuation or impedance matching. It was fun to go back to my years at college and revisit and update some of those topics. And at the same time it was a great opportunity to upgrade my toolbox.

I’d like this to be the first of a series of posts about radio frequency. Talking about tools and devices I already had and some of the new ones I now own. I think they might be of some interest for newbies and makers since -due to my budget- they tend to be low cost devices. At least I hope you will find it interesting to know they exist.

I don’t pretend to write these posts in any specific order but I’m just starting with what I feel is one of the most basic concepts, and it’s that a radio device outputs energy. So maybe one of the first questions is “how much energy?“.

RF Power

So RF power monitoring is the first step to analyze how a certain radio sends data by quantitatively measuring how much energy it outputs. You probably know this is called “power” and power is measured in Watts (W). Radio Liberty (a CIA-founded organization meant to broadcast anti-comunist propaganda) had a facility in Pals, Girona, from where they could reach as far as Moscow. The facility consisted on 6 radio towers with an overall output of 1.5MW (that’s megawatts).

Of course our IoT devices do not output that huge amount of energy. Actually there are several regulators that define how much energy you can use to broadcast messages depending on the frequency you are using. In Europe, the European Telecomunications Standards Institut (ETSI) defines a maximum output of 25mW (that’s milliwatts) for the 868MHz band where LoRaWan or Sigfox operate. In the US the FCC allows up to 126mW for the 915MHz band that LoRaWan uses. For the 169MHz band (unlicensed in Europe and used by Wize) the limit is set to 500mW (!!). Still, we are talking 6 to 8 orders of magnitude less that Radio Liberty.

So RF power is measured in watts (or milliwatts for the use cases we are interested in). But, actually, the units you will see all around are dBm (that means decibels referenced to 1 milliwatt). It’s just a convenient unit to represent power (also used for other magnitudes). To translate from one to the other you just have to:

Some rules for fast calculations with decibels: 3dB more means doubling the power, 10dB more means 10 times the power. Since decibels is a logarithmic scale you do calculations by adding, while with power you multiply. If you see +30dB it means 1000 times more power, so 30dBm are 1000mW or 1W. The ETSI defines the power limit for each frequency in dBm, so you will actually see that 868MHz is limited to 14dBm (aprox 25mW) and 169MHz is limited to 27dBm (or 500mW).

So, now we know we want to measure dBm. But where? Well, actually there are two different places you might want to measure it:

• The output of your transmitter, connecting your measuring device to the antenna connector of the transmitting device (instead of the antenna)
• The input of the receiver, measuring the power received by the receiver antenna

So let’s go now to test the first of the devices I’d like to present you. But before, an advice:

Always connect an antenna to a transmitting device. The role of the antenna is to dissipate the power to the air around (it doesn’t require “air” but you know what I mean). If the power is not dissipated it bounces back and it will eventually fry your device. The same can happen if the antenna is not well adapted, i.e. it has a high reflection coefficient for the transmitting frequency. We will learn how to test the antenna adaptation in a future post.

OOTDTY RF PowerMonitor 8000

The tool I’d like to present you is the RF PowerMeter 8000 RF [Aliexpress], a cheap power meter you can find on Aliexpress or Ebay for around 23€. There are several versions but the one I have covers up to 8GHz and has a sensitivity range of -45 to -5 dBm (with 0.1dBm steps). It has an ON/OFF switch, an OLED display, 5 buttons, a female SMA connector and it’s powered via USB (actually most of the places will sell it to you with a microUSB cable) and you can also monitor the output from your computer using the same USB connection.

Here you have a few pics with underneath caption explaining the few things you have to know about the device.

The RF-PowerMeter 8000 with the splash screen (press the center button to exit the splash screen). You can also see where the USB cable connects. Apparently the different versions are numbered, and version 3 is the one that covers up to 8GHz

You can change the center frequency and the offset using the left and right buttons (to move from one digit to another) and the up and down buttons to increase and decrease the value at the current position. The center button is the selector.

The female SMA connector where you have to connect the output of your transmitter or an antenna.

Since the power range it measures is limited to -45 to -5 dBm it will only let you check the power when directly connected to the transmitting device (using a attenuation) or when really close to it since you will soon get down to -45dBm for a milliwatt radio transmission. In my tests I have gone down to -60dBm and results “look” right but they are out of specs.

Reading it

You can of course read the results in the little OLED screen of the device, but since it also outputs the readings via USB I wrote a small python script to get the readings, calculate the peak value and save them to a CSV compatible file. The devices outputs data at 8 samples per second.

 #!/usr/bin/python

import os
import re
import sys
import glob
import time
import serial

def find_devices(vendor_id = None, product_id = None):
    """
    Looks for USB devices
    optionally filtering by with the provided vendor and product IDs
    """
    devices = []

    for dn in glob.glob('/sys/bus/usb/devices/*'):
        try:
            vid = int(open(os.path.join(dn, "idVendor" )).read().strip(), 16)
            pid = int(open(os.path.join(dn, "idProduct")).read().strip(), 16)
            if ((vendor_id is None) or (vid == vendor_id)) and ((product_id is None) or (pid == product_id)):
                dns = glob.glob(os.path.join(dn, os.path.basename(dn) + "*"))
                for sdn in dns:
                    for fn in glob.glob(os.path.join(sdn, "*")):
                        if re.search(r"\/ttyUSB[0-9]+$", fn):
                            devices.append(os.path.join("/dev", os.path.basename(fn)))
                        pass
                    pass
                pass
            pass
        except ( ValueError, TypeError, AttributeError, OSError, IOError ):
            pass
        pass

    return devices

ports = find_devices(0x1a86, 0x7523)
if len(ports) == 0:
    print("RF Power monitor not found")
    sys.exit(1)
port = ports[0]

ser = serial.Serial(
    port=port,
    baudrate=9600,
    parity=serial.PARITY_NONE,
    stopbits=serial.STOPBITS_ONE,
    bytesize=serial.EIGHTBITS,
    timeout=0
)

print("Connected to: " + ser.portstr)

pattern = re.compile("\$([\s0-9.-]+).*\$")
max = -60
start = time.time()

try:
    while True:
        line = ser.readline()
        result = pattern.match(line)
        if result:
            dbm = float(result.group(1).replace(" ", ""))
            if dbm > max:
                max = dbm
            t = int(1000 * (time.time() - start))
            print("{0:06d},{1}".format(t, dbm))

except KeyboardInterrupt:
    None

print()
print("Peak: " +  str(max))
print()

ser.close()

This script is released under the Lesser GPL v3 license as free open software and can be checked out at my RF-Tools repository on GitHub.

Monitoring TX power

Connecting it

When connecting the power meter to a transmitter you will need an attenuator (to reduce the output power so it is less than -5dBm), a SMA male-to-male cable and maybe some adapters (SMA female-to-female, SMA to RP-SMA,…). In the picture below you can see a transmitter (an M5Stack node I use as a tracker) connected using a SMA-male to SMA-male cable and 30dBm attenuator.

The RF powermeter connected to a LoRa node using a male-to-male SMA cable and a 30dBm attenuator.

There is a shopping list at the end of this post but here you have pictures of the different components.

10, 20, 30 and 40 dBm attenuators.

SMA male-to-male cable to connect the transmitter to the RF power meter.

Tests

So I run a few tests for 3 different TX power settings. Since 868MHz is limited in the EU to 14dBm I run the tests for 14, 10 and 4dBm. To do it I simply modified the original tracker sketch. I’m using MCCI Catena LMIC library which might be a little different from the original LMIC library for Arduino.

First I set it to use on only channel 0 at 868.1MHz.

// Set up the channels used by the Things Network, which corresponds
// to the defaults of most gateways. Without this, only three base
// channels from the LoRaWAN specification are used, which certainly
// works, so it is good for debugging, but can overload those
// frequencies, so be sure to configure the full frequency range of
// your network here (unless your network autoconfigures them).
// Setting up channels should happen after LMIC_setSession, as that
// configures the minimal channel set.
LMIC_setupChannel(0, 868100000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);      // g-band
LMIC_setupChannel(1, 868300000, DR_RANGE_MAP(DR_SF12, DR_SF7B), BAND_CENTI);      // g-band
LMIC_setupChannel(2, 868500000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);      // g-band
LMIC_setupChannel(3, 867100000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);      // g-band
LMIC_setupChannel(4, 867300000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);      // g-band
LMIC_setupChannel(5, 867500000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);      // g-band
LMIC_setupChannel(6, 867700000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);      // g-band
LMIC_setupChannel(7, 867900000, DR_RANGE_MAP(DR_SF12, DR_SF7),  BAND_CENTI);      // g-band
LMIC_setupChannel(8, 868800000, DR_RANGE_MAP(DR_FSK,  DR_FSK),  BAND_MILLI);      // g2-band

// If using a mono-channel gateway disable all channels
// but the one the gateway is listening to
//LMIC_disableChannel(0);
LMIC_disableChannel(1);
LMIC_disableChannel(2);
LMIC_disableChannel(3);
LMIC_disableChannel(4);
LMIC_disableChannel(5);
LMIC_disableChannel(6);
LMIC_disableChannel(7);
LMIC_disableChannel(8);

Second I set spreading factor to 12 using the LMIC_setDrTxpow method so the message takes longer and I can get several readings during the transmission:

void ttn_sf(unsigned char sf) {
    LMIC_setDrTxpow(sf, 14);
}

But even thou the second parameter in the previous call is the transmitting power, the library does not seem to change it so instead I’m changing the power per-band using the LMIC_setupBand method:

void ttn_pow(unsigned char pow) {
    LMIC_setupBand(BAND_CENTI, pow, 100);
}

The results for the tests are shown in this graph. As you can see there is an offset from the nominal power that’s pretty constant, but surprisingly the offset is positive, i.e. the reading is stronger than the nominal power…

Monitoring RX power

Monitoring RX power is done, obviously, by connecting an antenna to the RF power monitor. Of course the quality of the antenna will impact on the results and profiling an antenna is one of the main goals but I don’t want to focus now on this. Suffice to say I checked and used two different antennas that had a good enough response for the 868MHz frequency.

Again, depending of the antenna connector you might need SMA adapters like the one in the picture above. You might still need attenuators for close distances, a 10dBm attenuation should be enough for most cases.

RX loss with distance for three different TX power settings: 14dBm (blue), 10dBm (red) and 4dBm (yellow)

As you can see the readings are pretty much the expected. From one series to the other the distance is close to the TX power difference. On the other hand the RX power is reduced by ~5.1dBm (with a standard deviation of 1.5dBm) when doubling the distance. This falls inside the expected value which is 6dBm loss when doubling distance. This is a result of the formula above and the fact than the power loss at a certain distance is proportional to the square of the distance.

So apparently the results from the RF PowerMeter 8000 are compatible with the theory. But what if we compare it with another device?

Comparison

I happen to own an RF Explorer too (my next post will probably deal with it). So I did the exact same tests using it and compared the results.

Comparison for direct power measurement between the RF PowerMonitor 8000 (red) and the RF Explorer (blue)

Comparison for 14dBm TX power between the RF PowerMonitor 8000 (red) and the RF Explorer (blue)

Comparison for 10dBm TX power between the RF PowerMonitor 8000 (red) and the RF Explorer (blue)

Comparison for 4dBm TX power between the RF PowerMonitor 8000 (red) and the RF Explorer (blue)

As you can see in the graphs above, the readings of the RF PowerMonitor 8000 are consistently higher than those from the RF Explorer. This is actually good news since the offset is pretty constant. The calculations give 6.1dBm offset with a standard deviation of 1.6dBm and the numbers get better if we only take into account short distances and very stable for direct power measuring.

Conclusions

Let me first say that I’m comparing a 23€ device to a 246€ one. Both might be considered low-cost since actual RF monitoring equipment is way more expensive, but still there is a factor of 10 in cost between them. That said, my opinion based on the results is that the RF PowerMonitor 8000 is a really good piece of hardware for its price tag and it’s worth investing on it. Unless you already have some other equipment, of course.

Let me summarize my conclusions here:

• The RF PowerMonitor results are consistent with those from the RF Explorer, albeit they do show an offset. It requires calibration.
• A cheap way to calibrate the device is to get the readings form a direct TX output and calibrate them to aprox. 2dBm less than the nominal value to take connection losses into account. This is consistent with the results from the RF Explorer.
• The offset gets worst with distance, maybe due to the fact that the power readings are closer to the sensitivity threshold of the device (around -45dBm).
• Still, for short distances they are steady and this means the RF PowerMeter 8000 can be used to compare antenna gains.

Shopping list

These are the tools I’ve used during this post. These are affiliate links to Aliexpress or Ebay. If you plan to buy any of these components and you use the link I provide you will be helping me maintaining this blog. Thank you.

The post RF power monitoring tools on the cheap appeared first on Tinkerman.

Naming stuff is one of the core decisions one has to take while designing an architecture. It might not look as important as utilising the right pattern in the right place or defining your database model but my experience says that a good naming convention helps identifying design flaws.

In a previous post I introduced the network I’m building for my home monitoring system. As I said it will be based on MQTT, a lightweight messaging protocol. An MQTT message has 4 attributes: topic, value, QoS and retain value. I will focus on the “topic” in this post but I will come back to the QoS and retain attributes sometime in the future.

The MQTT specification defines topic as “(…) the key that identifies the information channel to which payload data is published. Subscribers use the key to identify the information channels on which they want to receive published information”. But the cool thing about MQTT topics is that the protocol defines a hierarchy structure very much like the Filesystem Hierarchy Standard in use in unix, linux and mac boxes. This, along with the possibility of using wildcards to match topics, makes this structure very suitable for a WSN.

Some examples of topics are:

• /home/llivingroom/bulb1/status
• /home/door/sensor/battery
• /home/door/sensor/battery/units
• /home/outdoors/temperature
• /home/outdoors/temperature/yesterday/max
• /zigbee/0013a20040401122/dio3
• /zigbee/0013a20040410034/adc7
• …

Semantic vs. physical approach

There is a bunch of small decisions to take here. Let’s start from the beginning… When building a topic hierarchy there are two different approaches (at least). Using a semantic approach and name things for where they are and what they measure. A humidity sensor in the bathroom to detect shower times (??) could publish its data under “/home/bathroom/humidity”.

The second option is a physical approach and name things for what they are or what they are attached to. Like in the previous example the humidity sensor might be attached to the analog pin 3 of an end device radio in a Xbee mesh network, so it could as well publish its data under “/xbee/0013a20040410034/adc3”, why not?

Generally the semantic approach is preferable since it is more human friendly but the physical approach is more machine friendly (even if only slightly). Using again the previous example, the Xbee gateway could subscribe to “/xbee/+/+/set” to get all the messages that should be sent to the different radios.

Semantic approach structure

For the physical network it is easy to define a topic structure based on the path to get to the data, like in the last example: “the sensor attached to the AD converter pin 3 in the radio with address 0x00 0x13 0xa2 0x00 0x40 0x41 0x00 0x34”.

For the semantic approach there are a bunch of possibilities but most of the networks out there use a location based structure: first you physically identify the sensor by its location and then the magnitude: “/home/2ndfloor/bathroom/temperature”. As you can see this can be read quite naturally, albeit reversed: “the temperature in the bathroom of the 2nd floor at home”.

It’s worth noting that MQTT provides a way to split a large scale networks into different chunks, each with it’s own scope, via the mount_points feature. Check an interesting thread about mount_points here. So it can be a good idea to foresee how my network might grow, not only downwards but also upwards, and that’s why the “/home” in some of the examples I’m showing might not be a good root location, better use something more specific like “/buckingham palace” or “/lovenest” (I will keep using /home in the examples anyway).

And after the location part I will just provide the magnitude: temperature, pressure, humidity, air_quality, power, battery,… and status. Status is normally a discrete value (typically 0 or 1) indicating the state of the sensor or device. I find it preferable to use “/home/entrance/light/status” that simply “/home/entrance/light” to publish whether the lights are on or off.

Modifiers, prefixing and postfixing

I have already used some “particles” in the example topics above, words like ‘set’, ‘yesterday’, ‘max’,… I’ve gathered some of these particles browsing the internet searching for MQTT topic names. I have tried to classify them into different types:

• Metadata: timestamp, units, alarm,…
• Agregation: time ranges like today, last24h, yesterday, month, year, ever,… and operators like max, min or average. A special case of time range could be “now”, “last” or “current” for the last value published on a certain topic although it is usually omitted.
• Actions: get or query, set
• Structure-related: raw for, well, raw values

Some of the modifiers are clearly attributes or metadata of the data itself. In these cases postfixing makes perfect sense:

• /home/bedroom/temperature 21
• /home/bedroom/temperature/units C
• /home/bedroom/temperature/timestamp 2012-12-10T12:47:00+01:00

The reading from the bedroom temperature sensor was 21 celsius on Dec 10 at 12:47 UTC+1. As I’ve said, some people uses “current”, “now” or “last”. I used to think this as redundant but it may be necessary when graphing your network messages the way Ben Hardill explains in his d3 MQTT topic tree visualiser post, where only the leaves can have values.

Another reason to use “last” (or any of the others) is when you are also publishing aggregated information for that magnitude. In this case it looks more logical to have a structure like this one:

• /home/bedroom/temperature/last
• /home/bedroom/temperature/last/timestamp
• /home/bedroom/temperature/last24h/max
• /home/bedroom/temperature/last24h/max/timestamp
• /home/bedroom/temperature/last24h/min
• /home/bedroom/temperature/last24h/min/timestamp
• /home/bedroom/temperature/ever/max
• …

But first you should ask yourself if your messaging network is the place to publish this info. Who will use it? If the answer is only you then you should add some graphing solution like Cosm, Nimbits, Open Sen.se,  or your own. Keep in mind MQTT is a Machine to machine protocol.

But for actions and structure modifiers it’s not so evident. Postfixing (appending at the end) for actions is coherent with the “reversed natural reading” naming convention: “switch on the lights in the stairs” will be a “/home/stairs/light/status/set 1”.

But prefixing in MQTT is equivalent to creating new hierarchy roots, thus “splitting” the topics into different sub-networks, so it fits quite well for structure modifiers. You could have a /home root for sensor data using a semantic approach and a /raw root for raw sensor data using a physical approach. The network should then provide a service to map topics back and forth between both sub-networks:

• /raw/xbee/0013a20040410034/adc3 => /home/bedroom/temperature
• /home/bedroom/lights/set => /raw/xbee/0013a20040410034/dio12

This republishing service has been proposed by Robert Heckers in his MQTT: about dumb sensors, topics and clean code post and you can even use an open source implementation of an MQTT republisher by Kyle Lodge using the Mosquitto python library.

Republishing vs. publishing the right contents

There are some details I don’t like about the “republishing” approach. First you are setting up a service that will have to know about the physical network (gateways, technologies, radio addresses, pins…). Second you are doubling the traffic in your network without adding any more value apart from the topic renaming.

So my point is to make the mapping in the gateway before publishing anything. This way the messaging is agnostic of the physical structure of the radio network, the gateway is the only holder of that information. Besides, the mapper will double as a filter, filtering out unnecessary messages *and* processing values. Let’s say you configure a MCU-less sensor with an Xbee radio to report the input of an analog pin. Chances are you will have to do some maths with the reported value to get a meaningful one. For example, the supply voltage reported by the radio has to been scaled by 1200/1024 to get the actual value in mV.

Conclusions

To be honest, I’ve written this quite large post to make up my mind about the subject. These are some of the conclusions I will apply to my own system:

• The message topics should be independent from the underlying technology.
• Topics will have semantic meaning, starting with the location and then the magnitude they represent. More particles can be added to the topic to add attributes or metadata.
• The different gateways and publishers will be responsible for:
  • Abstracting the physical network architecture.
  • Filtering unnecessary messages.
  • Processing values before publishing them.
  • Adding metadata.
  • Listening and processing messages aimed to sensors under their “control”.
• Republishing will be avoided if possible.
• Aggregation data goes somewhere else.

I am not really sure about publishing content only to leaf nodes. The analogy with a linux file system is quite obvious: you only put content into leaf nodes (files), but still I find it somewhat ugly (and for me that means there is something wrong).

The final test will be to actually apply this rules to implement my MQTT topics hierarchy to see if it works. Let’s go!

The post MQTT topic naming convention appeared first on Tinkerman.

Now that I have started to monitor some magnitudes at home, like power consumption or the front door opening, I have to do something with this information. The sensor information can be useful for two purposes, mainly:

• analysing it to know more about your environment or your life-style patterns (like when and how you spend the money you spend on energy)
• taking real-time actions based on events from your sensors (open a light when you pass by a dark corridor at night, receive a notification when someone enters your house,…)

To analyse the information you will first have to store it in some way you could retrieve it later, graph it, summarize it, perform different time range roll ups or moving averages or detect time patterns,… whatever. Even if the goal of the sensor information is to trigger events (watch out: the door sensor is running out of batteries!) you will probably want to have it stored somewhere and save a log of actions as well.

So, where to store this information? You have different options available:

• Relational databases (RDBMS) like MySQL or PostgreSQL. If you have some programming background this is pretty easy, we are all used to store data on a MySQL or similar. But mind the tables will GROW very quickly. A sensor reporting every minute will create more than half a million entries a year.
• NO-SQL databases like MongoDB or Cassandra. They are popular and everyone wants to use them. Cassandra is often used to store time-series data like server load or log files and the Internet is full of information about how to store it, retrieve it, partition it,… MongoDB has also some nice features like capped collections.
• Round-robin databases. They have been around for a while. RRDtool version 1.0 was born in 1999 and MRTG is even older. Data is stored in circular buffers, you can define the size of the buffer and the step or how often a new value is inserted into the buffer. When the buffer is full old data gets overwritten and this happens over and over. So you have another buffer for aggregated data (like daily data) and another one for even larger scale data (like weekly data) and so on.
• Time series databases. And finally there are a number of databases that have been specifically designed to store time-series data: fast inserts, fast range lookups, roll ups,…

Now, some companies are providing time series storage services online. They provide a public API, graphing capabilities and some of them even roll ups or data aggregation. They have been born around the Internet of Things hype. Maybe the most popular is Cosm (formerly Pachube) but it’s not the only one: TempoDB, Nimbits or ThingSpeak are very good options.

Cosm has been around for a while and it is still the most used by the IoT community. AFAIK, there is no restriction on the number of data points you can store for free if you keep your data “public”. Data is structured in “feeds” and “datastreams”. They have an API you can use to push data individually or in batches. You can also use it to backup the data you have in Cosm. Their charts are nice looking but they have predefined time ranges that automatically aggregate your data so you have little control on what and how you want to graph. They have a number of goodies like triggers, graph builder (to insert your Cosm charts in your site), tags, apps, localization based search,…

TempoDB is a relatively new player. It’s free up to 5 million data points per database, that’s roughly 9.5 years for a 1 samples/minute data. You can have several “series” of data per database. Their API is really good and they have a number of clients including a python one :^). Their charts might not be as “pretty” as those from Cosm but you have full control on the data you are visualizing: date range, interval and aggregation functions, and they are FAST (Cosm can be really sluggish sometimes). Your data is private, so there is no sense in having a search tool. They have tags and I’ve been told they are about to release a notification service.

Nimbits has a desktop-like interface base on ExtJS. It is basically a paid service (their free quota is 1000 API requests per day, which is OK for 1 sensor reporting at a rate of 1 samples every 2 minutes) and it costs $20/2 million requests (roughly $20 per year if you have 4 sensors reporting at a 1 sample/minute rate).

ThingSpeak is very similar to Cosm, data is presented in a “channel” where you can see multiple charts for different magnitudes (they call them “fields”), a map and even a video from Youtube. It’s open source, so you can clone the code from Github and install it in you server. Their web service is limited to 1 API request every 15 seconds per channel, which is OK as long as you group all the data from one channel in a single request (that’s it if you have more than one field per channel). For each field you have a lot of options to define your chart: time range, time scale, different aggregation functions, colors, scale,…

The information in this post is not very detailed but I hope it can be an introduction to anyone who is looking for ways to store or publish sensor data. Right now I’m using Cosm and TempoDB, as well as storing all my data in a local MySQL database (not the best option but it works for now). There are plenty of options I still have to explore. In my next post I will talk about the daemon I’m using to push data to Cosm and TempoDB, in the meantime you can check the code on Github.

The post Storing and publishing sensor data appeared first on Tinkerman.

[Update 2013-03-01] I have added more documentation on the codes these remotes use in a different post.

I’m starting to move towards not only gathering information but also acting. My first project in this subject will be controlling some lights and the house heaters. So last week I visited the urban market of “Els Encants” in Barcelona and bought some very cheap wireless outlets.

Two different remotes

I bought two sets of three wall plugs, each set with it’s own remote. They all transmit in the 433MHz frequency and I already had a set of transmitter and receiver for that frequency so as soon as I had some time I started trying to intercept and reproduce the codes the remotes were sending.

Sample outlets from each set plus remotes

In the image above you can see an outlet and the remote for each of the sets. The left one is branded “Noru” and each outlet is rated 3kW (good for the heaters) and it features auto switch off time (1, 2, 4 or 8 hours). The remote can control a maximum of 3 outlets and apparently it is programmable, since you first have to sync the outlets with the remote.

The right one is branded “Avidsen”, also 433Mhz but rated 1000W, just below the consumption of my house electrical heaters, but good to control lights and other appliances. It’s got the very common dip switch to sync the remote and up to five outlets. There are 32 different channels available. So if your lights switch on and off randomly maybe you neighbour is using the same channel you are, then you better change the channel.

Available libraries for Arduino

I started reading documentation about the protocol these devices use and found out there is some very useful information out there. In fact there are even a couple of libraries for Arduino. The first one is called RemoteSwitch and it is a little old, it has not been ported to Arduino 1.0 but if you are like me you will keep a copy of Arduino 0023 just for this kind of situations.

The second library is called RCSwitch and I have to say it is a neat piece of code. It has been ported to the Raspberry Pi, although the port is not as updated as the original Arduino library.

My first tests with the RemoteSwitch library were encouraging. The Show_received_code sketch dumped the codes for the Avidsen remote one by one. I though: if it can decode it, it should be able to recreate it. And it worked from scratch. Good!

But by then I knew I wanted to use the newer library. There were several reason for this: it is being actively developed, it supports more protocols, the code is much more elegant and object oriented and it has a port to RPi, which I plan to use as a central gateway soon. So I checked which one of the RCSwitch protocols matched the one I had successfully used with RemoteSwitch and started doing some more tests…

Slightly different protocol

Here was when things started to get complicated. The thing did not work. So I spent a couple of hours studying the code for both libraries, decoding the codes the RemoteSwitch library had dumped before and trying to find the difference. Until I found it: RCSwitch.cpp, line 239, that ‘0’ should be a ‘1’… and everything started working again. Very good! I started a thread in the library forum to find out whether this is a bug or a slightly different protocol.

Index: RCSwitch.cpp
===================================================================
--- RCSwitch.cpp	(revision 219)
+++ RCSwitch.cpp	(working copy)
@@ -284,7 +284,7 @@
         if (sGroup[i] == '0') {
             sDipSwitches[j++] = 'F';
         } else {
-            sDipSwitches[j++] = '0';
+            sDipSwitches[j++] = '1';
         }
     }

By the way, the protocol of these things is pretty interesting. It’s worth a look at Sui’s post to get an overview of the implementation. The tri-bit concept is really awkward.

Using the Bus Pirate and OLS Logic Analyser

Then I moved to the other set of outlets. These are rated 3000W so I plan to use them to control my house heaters, which is the main reason for all this work. I followed the same steps, starting with getting the codes with the Show_received_code sketch. But weird enough the library was only able to decode some of the button presses… Only the SET button for outlet #1, the ON and OFF buttons for outlet #2, the ALL OFF button or the 2, 4 and 8H timeout buttons seemed to work.

This time it was going to be harder, since I didn’t even have all the codes. Well, a good opportunity to use my Bus Pirate!

Bus Pirate to the rescue!

So I plugged the RF receiver to the Bus Pirate and launched the OLS Logic Analyser to capture the signal from the remote.

You don’t have to configure anything to use the Bus Pirate as a (low speed) logic analyser. But since I wanted to power the radio receiver with the BP I had to enable the Power Supply mode. To do so you have to open a terminal session, type ‘?’ to get a prompt, select one of the modes that allow enabling the power supply typing ‘m’ and selecting the mode (like UART, for instance) and then type ‘W’ (uppercase to enable, lowercase to disable). Then you can close the session and it will keep the power on the 5V and 3V3 lines as long as it is plugged to the computer. Mind you have to free the port so the logic analyser software can use it. I had problems doing it with screen or minicom, but it worked great with picocom.

After some tests with the Avidsen remote (I knew what the codes were so I could compare the signal output with the actual code) I started getting the signals for each and every button in the Noru remote.

The image below shows the signal for the ON button for the outlet #1.

Signal for the #1 ON button of the Noru remote

Now, since the RemoteSwitch library was able to decode some of the signals, the protocol could not be that different. So I started to decode manually all the signals applying the same protocol. The signal is a series of 12 tri-bits plus a sync-bit. For the Avidsen-like remotes there are 3 different tri-bit values (logically), they are called 0, 1 and F, for “floating”. Each tri-bit has a pulses shape. The following tables describes the pulses:

The long pulses are about 3 times the length of the sort ones. The overall period is a characteristic of each remote. There is also a trailing high pulse followed by a long low which is called “sync bit”.

A fourth tri-bit?

Decoding the signals from the Noru remote I found out that there was a fourth tri-bit value (well maybe I should call them tetra-bits now). In fact it is obvious since there is a forth option for an alternate sequence of 4 highs and lows. I’ve named the new tetra-bit X (for unknown, but also after my name :P). The full table for the Noru remotes is:

Now the previous image for the ON#1 button can be decoded as 1F000001FFX0S. With a small patch I could make this work with the RCSwitch library. The library cannot create the code but you can feed it to the sendTriState method to generate the signal.

Index: RCSwitch.h
===================================================================
--- RCSwitch.h	(revision 219)
+++ RCSwitch.h	(working copy)
@@ -106,6 +106,7 @@
     void sendT0();
     void sendT1();
     void sendTF();
+    void sendTX();
     void send0();
     void send1();
     void sendSync();
Index: RCSwitch.cpp
===================================================================
--- RCSwitch.cpp	(revision 219)
+++ RCSwitch.cpp	(working copy)
@@ -441,6 +441,9 @@
         case '1':
           this->sendT1();
         break;
+        case 'X':
+          this->sendTX();
+        break;
       }
       i++;
     }
@@ -561,6 +564,16 @@
 void RCSwitch::sendTF() {
   this->transmit(1,3);
   this->transmit(3,1);
+}
+
+/**
+ * Sends a Tri-State "X" Bit
+ *            ___   _
+ * Waveform: |   |_| |___
+ */
+void RCSwitch::sendTX() {
+  this->transmit(3,1);
+  this->transmit(1,3);
 }

 /**

And this is a sample code for Arduino that switches on and off outlet #1 every 2 seconds.

#include <RCSwitch.h>

RCSwitch mySwitch = RCSwitch();

void setup() {

  Serial.begin(9600);

  // Transmitter is connected to Arduino Pin #11
  mySwitch.enableTransmit(11);

  // Optional set pulse length.
  mySwitch.setPulseLength(302);

  // Optional set protocol (default is 1, will work for most outlets)
  mySwitch.setProtocol(1);

  // Optional set number of transmission repetitions.
  mySwitch.setRepeatTransmit(6);

}

void loop() {
    mySwitch.sendTriState("1F000001FFX0");
    delay(2000);
    mySwitch.sendTriState("1F000001FFFX");
    delay(2000);
}

Again, comments are more than welcome!

The post Decoding 433MHz RF data from wireless switches appeared first on Tinkerman.

I was not the first to arrive at the party but since I discovered the ESP8266 I’ve been enjoying it. Then I stumbled upon the Sonoff and dude was I amazed. They are cheap and so very hackable you cannot help buying them, tear them open and customize them.

Sure they are not CE or UL compliant, yet. My previous post about adding a custom RF module to a Sonoff HT got some visibility as it was published at hackaday.com. Most of the commentors there  where concerned about safety measures in the device. The truth is that early Sonoffs looked more like products for the DIY market, not for end customers.

But ITead’s home automation product line is evolving quite fast. It all started with several Sonoff models (with or without RF, with or without temperature and humidity sensors, with or without AC/DC transformer) and the Slampher I’ll be reviewing it soon.

I first ordered 3 Sonoffs and once I have them deployed at home I ordered 3 more. There were some minor but significant changes on this second batch. First there was a label with a text in chinese that (according to Google Translator) says “tore invalid”, preventing the unwanted (!!) opening of the case, as if they were telling you: from here on, under your responsibility. Also they used a slightly taller button that sticks out of the case almost 2 millimetres.

But the most curious change is that they added blobs of tin to the unpopulated RF module header!! Wow!! I almost feel like if it was my fault. I don’t really know the reason: is it because they don’t want you to solder anything there? or is it an improvement on their production flow? The first option is somewhat hard to believe… anyone willing to solder anything there would know how to remove those blobs of tin (or even use them). As for me I just heat them a bit with the iron tip and then slam down the board against the table. Anyway: small changes and no layout redesign.

A Sonoff from the second batch I bought. Notice the label and the button popping out of the hole.

Blobs of tin ion the RF header

But things are changing fast. If you visit ITead’s online store you will probably see new products every one or two weeks. And they just released the new Sonoff TH 10A/16A. Now this is a complete redesign with several interesting features:

• It still has a programming header and a button (hopefully attached to GPIO0), good!
• Up to 16A relay for the Sonoff TH 16A.
• No enclosure included, but there is a free 3D model available.
• A 3.5 jack to attach sensors, they are selling 3 different temperature and humidity sensors, but probably any sensor you can think of that requires power, ground and a digital pin would fit (PIRs, Sharp distance sensors or Parallax PING,…).
• There are some changes in the AC/DC design, they added an input fuse and a thermistor (?)  at least.
• Two LEDs, let me guess: there is one attached to the same GPIO the relay is.
• They are using push terminals, not screw ones. But even thou there are 6 of them, apparently they are not meant for NC/NO operation, according to the wiring diagram in the product page.

Sonoff TH 16A. Picture by Itead.

Pics don’t show the bottom of the board, so no idea about track thickness or creepage, but the new design (with the input and output lines on the same side of the board) provides better isolation between safe and unsafe parts of the board.

There are other new products on their site, most notably the PSF-A85 module, amongst the first to integrate Espressif ESP8285 chip (an ESP8266 with 1 Mbyte embedded SPI flash memory) and the PSA Wifi module (although they are not selling them individually yet). This last one encapsulates smart switch functionality in one module (wifi, relay and configuration button) but it looks like you cannot modify (or even access to) its firmware. There is still little information about it so we will have to wait.

But that’s not all. Last week I received a parcel from Itead with some products to review (the Slampher and the S20 Smart Socket). In the box there was a flier with products you can manage from the eWeLink app. Even thou Itead’s name is written nowhere most of the products there are available on their site. Except for two: the WiFi Wireless Wall Socket and the Snake Power (an articulated power strip with 3 individually addressable sockets and 2 USB ports). I bet they will show up in their web page soon…

eWeLink flier with teasing new products

All in all, Itead is rapidly evolving it’s smart home product line, adding new products and redesigning old ones, probably with the goal of being CE/UL compliant soon. Some will argue than wifi is not the best technology for home automation (too power hungry, limited number of devices per AP,…). But right now is probably the best option for the non-makers out there, a plug-n-play solution for your home.

The post ITead’s Evolution appeared first on Tinkerman.

Since I discovered the Sonoff I’ve been thinking about embedding it inside a switch. I started looking for old power meters, timers,… I had at home but the Sonoff is a bit too long. Why didn’t they design a square board? I event bought a bulky Kemo STG15 case with socket.

Next I decided to design my own board. It is meant to be the “official” hardware for the ESPurna project so it’s called ESPurna too. It’s opensource hardware and available at the ESPurna project repository at Bitbucket. I have some boards already for the first iteration (version 0.1). They are mostly OK but I’m already working on a revision.

But then ITead’s released their S20 Smart Socket. It’s the Sonoff in a wall socket enclosure. Almost 100% what I wanted. And at 11.70€ it’s hard to beat. There are other wifi smart sockets available, mainly Orvibo and BroadLink (an SP2 Centros should be arriving home anyday now) but ITead’s is cheaper and you can easily re-flash it. Just solder a 4 pins header, connect it to your FTDI programmer, hold the S20 button, connect the programmer to your computer and flash. Done.

OK, not so fast. Why would I do that? Why would I change the stock firmware?

The answer for me is a mixed up of philosophy and practicity. But you are right. Let’s go step by step.

Hardware

First let’s take a look at the device. The wall socket is nice looking and pretty small (at least compared to the STG15!!). In the socket you can read “16/250 ~” which I don’t know what it means since the relay inside is the same the Sonoff TH has and it’s rated at 10A and the label in the back says 2kW max, but maybe there will be a 16A version like the new Sonoff TH 16A. The ground terminals (connected from input to output) are not tightly fit and they make a metallic sound when you shake the device (OK, why should you shake it?). The ON/OFF button symbol is upside down (ehem looks like the designer thought about it with the button over the plug, which makes perfect sense since most of the time the cable hangs down). But the overall feeling is really good.

To take a look inside the enclosure you have to remove a single screw on the back of the device, but there is a “tore invalid” label covering it (hey, blame Google translate), so don’t do it.

S20 front view, yes, the ON/OFF button icon is upside down…

S20 back with the “tore invalid” label

But if you do, this is what you will see:

A detail of the “upside down” button from the inside. It looks like a communication problem between the guy that was working on the enclosure and the guy that designed the button itself…

S20 guts. The ground clip has been removed. You can see the programming header: GND, RX, TX and VCC, everything a hacker needs (almost).

On the back of the board you can see the short live tracks, the ESP8266EX, SPI flash memory and the AMS1117-3V3.

The guts of the S20 are very much like those of the Sonoff albeit with a different layout. Connections to mains are in the upper side, that provides a better isolation between the safe part and the unsafe part, whilst on the Sonoff you have hot tracks running all along the board. Like in the Sonoff it has live lines duplicated on both sides of the board and an extra of tin on the bottom. There are air gaps between the mains lines and the low voltage side, but they had to leave a bridge, probably to provide mechanical strength to the board.

On the bottom of the board you have several components including the ESP8266EX, a Winbond 25Q80DVSIG 8Mbit SPI Flash memory and an ASM1117-3V3 that provides regulated 3.3 volts to the ESP8266 and the flash chips from the 5V output of the AC/DC power supply. Whilst 1Mbyte on flash ROM is enough for most applications, even with OTA functionality (check my ESPurna firmware) some might find it a bit too short. If that’s your case there are cheap and easy ways to upgrade the memory chip to a 4Mbytes one.

There is a button attached to GPIO0 and two LEDs, a green one connected to GPIO13 like in the Sonoff and a blue one to the GPIO12, like the relay, so whenever the relay is closed the LED will lit blue. Close by the blue LED there is an unpopulated header perfectly labelled with VCC, RX, TX and GND lines. That’s everything you need to flash the ESP8266 onboard a custom firmware.

Software

ITead’s home automation products are managed through the eWeLink app for Android and iPhone. The goal of the app is to become a hub for different wifi home automation devices: switches, lamps, power strips, fans,… and the operation should be straight forward: set the device in pairing mode (AP mode), configure wifi credentials and control it.

I swear I have tried hard to use it. Several times. Even accepting weird permissions I would have not accepted to any other app (why should it ask for my phone number or my location?). But I never ever managed to make it work. I have not been able to pass the pairing step. Not even after giving the app permissions over my personal life. Impossible. I quitted. If anyone has a clue on how to do it, please let me know. Permissions and connection problems are common between the comments on Android app market. No one has commented yet on iTunes. Weird.

This is the furthest I got

But even thou the app had worked fine I wouldn’t use it. I’m not saying you shouldn’t use it. My case might not be yours. Why would I flash my own firmware? Basically to really own the device.

We are in the very early days of the IoT and we are not even sure of what it means. Companies are trying to capitalize the concept providing their users all-in-one solutions including the device, the app and the cloud (whatever that is). But why should anyone know when you set your livingroom lights in romantic mode? And what happens if the company shuts off? Greenwave by TCP or Revolv cases are well know. Google has a reputed history of closed services (not IoT related, true).

And what about interoperatibility? You can easily end up having to use an app to switch your reading lamp and a different one for your ceiling light! Even those that provide open cloud solutions have weak days: Phillips recently released a trial balloon about locking out 3rd party hardware from Hue brigde. Elliot Williams at hackday put it simply: “The 900-pound gorilla in the corner of the Internet of Things (IoT) hype that everyone is trying to ignore is interoperability”.

That’s why i would always prefer open APIs and protocols over proprietary ones. I’m not even talking about open/free source software or hardware but protocols. You don’t own a device and the information it manages if you cannot talk to it directly, without middlemen.

The great thing about the Sonoff or the S20 Smart Socket is that you can easily flash your own firmware on them. So now I can control it with through my MQTT local broker, add schedules, behaviours,… through my local Node-RED instance or rely on 3rd party cloud services like Blynk or IFTTT if I want to, because if they ever shut off, it’s no big deal.

Conclusions

From the end-user point of view the device is a great deal: cheap, nice, wifi-enabled. But the mobile app is a disaster and I would expect people returning their devices because of this.

From the hacker point of view it’s a even greater deal. You can easily flash a custom firmware and make it talk to your local services. It could have more flash memory. It could have more GPIOs exposed in the header to add sensors like a simple LDR to switch ON/OFF depending on the ambient light or a PIR to detect that someone’s near. Or maybe it could have a jack out like the new Sonoff TH 10A/16A.

I will recommend the S20 Smart Socket to anyone with the skills to customize it. For less than 12€ it’s an amazing device you can own.

The post S20 Smart Socket appeared first on Tinkerman.

Some weeks ago I received a parcel from Itead. Previously, I had written about the Sonoff and they were kind enough to send me two more of their home automation products for me to review: the S20 Smart Socket I wrote about two weeks ago and the Slampher.

The Slampher comes in a simple cardboard box with no documentation at all… just visit their wiki!

The Slampher is kind of a Sonoff RF that sits before any light bulb with an E27 screw. As you can see in the header pic of this post it adds quite some length to the group. It’s a bit bulky and might not fit in every lamp. Off course the board layout is different from the Sonoff and it uses a JST131U-800D 1A triac instead of a relay to switch the bulb. Aside from that they are equivalent.

The JST131U-800D triac in a TO-92 package is placed in the the center of the board

There are a number of reviews of the Slampher that focus in the basic usage or that go more in depth tearing it apart or flashing a custom firmware. As you can guess, I’m more interested in the later. I already exposed my reasons in my post about the S20 Smart Socket and this week it has become more apparent as a report from Bitdefender has uncovered a bug on a commercially available smart socket that would allow attackers to create a malicious botnet. An army of owned sockets!

We are only a few days away from the arrival of the ESP32 and the ESP6288 is still one of the kings of the IoT block, and a really a successful one. Itead choice of using Espressif chips on their home automation line of products make them a hackers dream.

There are a few firmwares available that will work on the Slampher, including my Espurna Firmware. Most of them have MQTT support and a web configuration portal. Some, like the Espurna, are light enough to support OTA with the 1Mb flash memory that the Sonoff or the Slampher have.

GPIO0 problem

The Slampher and the Sonoff RF both have a 8bit EFM8BB10F2G-A-QFN20 microcontroller (from the EFM8 Busy Bee family) by Silabs that listens to the radio module messages and handles the on-board button. That button is tied to GPIO0 in the Sonoff TH or the S20 Smart Socket and it can be used to enter into flash mode upon boot. Same things does not happen on the Slampher.

The EFM8BB1 is the little 3x3mm chip at the top right of the image, just by the testing pads.

The EFM8BB1 intercepts the button events so it can enter into “pairing mode” when the user double-clicks the button. In pairing mode it listens and stores a new radio code that will become the code to toggle on and off the switch from then on. But the curious thing is that if there is a single click event it just pulls down GPIO0 in the ESP8266 like the the button does in the non-RF versions. So Sonoff firmwares will work just the same except for:

1. You cannot use the button to enter flash mode in the ESP8266 (since it’s a user firmware event that pulls GPIO0 down and no user firmware is running at boot time).
2. You can’t use double click events on your firmware because these are intercepted by the EFM8BB1, unless they are more than about half a second away from each other.
3. You can’t use long click events since the EFM8BB1 pulls GPIO0 down only on button release for about 125ms.

Issues #2 and #3 you will have to live with them. My Espurna firmware uses double click and long click events to enter AP mode and to reset the board respectively. That will not work on the Slampher. I could extend the double click interval in the DebounceEvent library from 500ms to 1000ms, but it won’t be very user friendly.

Issue #1 has different solutions. Scargill suggests to move resistor R21 to R20, so the button is now attached to ESP8266 GPIO0 (check the schematic at Itead wiki). Problem is that you lose the ability to pair your remote. Off course you could pair it first and then move the resistor but chances are that in the long run you will need to pair it more often than flash it, because you have OTA.

Flashing the Slampher

So my solution is to momentarily shortcut to ground the unpopulated pad of R20 that goes to GPIO0 and power the device at the same time. It’s not easy, you will need some practice and you will probably have to do it more than once. But at the end you will have a customized Slampher with fully working RF support.

Short to ground the R20 pad that goes to the ESP8266 while powering the board to enter flash mode

Off course I’m assuming you have a stable OTA-able firmware and that you have a testing platform (I have a Sonoff just for that). Also, you can add a new button between the pad and GND to flash the device in a more comfortable way.

The Slampher has a 4 pins header that brings out everything you need to flash it (except for GPIO0), counting from the little white mark onwards: VCC, RX, TX and GND. You just need to wire your favourite USB to UART board (an FTDI-like) and you are ready to go. Just remember: the ESP8266 requires 3V3, not 5V! And connect TX to your programmer RX and RX to TX. Then you will need to handle the board with care with another ground jumper wire touching the R20 right pad (check the images) while you disconnect and connect you FTDI board or the VCC cable.

Somewhat hard to see but here you have my flashing set up… notice the additional black wire in the breadboard I use to pull down GPIO0 on boot

Radio control

The radio receiver chip is a SYN470R by Synoxo in a 16 pin SOP package. This is a ASK/OOK RF transparent link (an “antenna-in to data-out” as the manufacturer says). It needs a microncontroller to act as a logic decoder. You can configure the bandwidth and it has a WAKEUP pin you can use to wake up your controller when there is a radio signal.

First I tried to pair it with my Avidsen remote without success. Then I used another remote I have for Noru radio sockets and it worked! Kind of… The red LED in the radio modules blinked while pairing it but not all the buttons worked. Only ON1, OFF2, OFF3 and 8H buttons on my Noru remote actually work with the Slampher. Weird.

The Noru remote is the one on the left

Decoding the radio signals

So I reviewed my own post about decoding radio signals but instead of using my Bus Pirate I give it a try to the RCSwitch library first, using the basic receiver example and adding some code to output “normalized” data strings, I started decoding the 4 buttons of the remote Itead is selling. This is the code I used:

#include <RCSwitch.h>;

RCSwitch mySwitch = RCSwitch();

void setup() {
  Serial.begin(115200);
  mySwitch.enableReceive(0);  // Receiver on inerrupt 0 =>; that is pin #2
}

void loop() {
  if (mySwitch.available()) {

    int value = mySwitch.getReceivedValue();

    if (value == 0) {

      Serial.print("Unknown encoding");

    } else {

      Serial.print("Received ");
      Serial.print( mySwitch.getReceivedValue() );
      Serial.print(" / ");
      Serial.print( mySwitch.getReceivedBitlength() );
      Serial.print("bit ");
      Serial.print("Protocol: ");
      Serial.print( mySwitch.getReceivedProtocol() );

      char binary[25] = {0};
      char tristate[13] = {0};
      int count = 0;
      int tri = 0;

      unsigned int * timings = mySwitch.getReceivedRawdata();
      for (int i=1; i<49; i=i+2) {           binary[count++] = (timings[i] > 500) ? '1':'0';
          if (count % 2 == 0) {
              if (binary[count-2] == '0') {
                 tristate[tri++] = (binary[count-1] == '0') ? '0' : 'F';
              } else {
                 tristate[tri++] = (binary[count-1] == '0') ? 'X' : '1';
              }
          }
      }

      Serial.print(" Binary: );
      Serial.print(binary);
      Serial.print(" Tristate: );
      Serial.println(tristate);

    }

    mySwitch.resetAvailable();

  }

}

The output of the 4 buttons from the Itead remote is:

As you can see they are 24 bit messages where the first 20 are the same for the 4 buttons and then there is only one bit set for the remaining 4 bits. The 4 buttons in the Noru remote that work have only 1 bit set in the last 4. That’s why the remote Itead sells has only 4 buttons. I still don’t know if I can use Itead’s remote with the Noru sockets since I never managed to know the relation between button codes (between ON and OFF buttons that control the same socket). But they don’t look compatible…

Note: one funny thing is that there is another EFM8BB1 microcontroller on the radio module. What? Maybe the radio decoding is done in this second chip while the one in the Slampher board is just responsible for the button and the GPIO0?

Wrapping up

The Slampher might be a bit bulky and it won’t fit in all the lamps (it does protrude from the livingroom lamp cover at home) but it’s a fine device for home automation. My criticism to the eWeLink app and my concerns about really owning the device still stand. But I will no doubt tell you: go buy one, flash it with your own firmware and enjoy.

The post New firmware for the Slampher appeared first on Tinkerman.