Hi, Dear Reader!

 

Just to note that we have had an exceptional first year!

More to come …

 

Thank you!

 

Espressif announced on 05/11/2015 the upcoming ESP32 chip:

 

While the specs are impressive a lot of questions a rise :

• Support – Espressif is a small company as far as we knew – would they be able to support both chips in the long term?
• Compatibility with esp8266?  – The new ESP32 will use the RTOS based SDK and most APIs are said to be compatible with the esp8266 SDK.
• Price – The price will be higher than esp8266  but not much higher.

Beta testing program is coming soon.

A Teaser of What to expect from our upcoming WiFi connected 2 channel relay board.

Web UI of the relay board

Main control screen and part of the configuration

Main control screen

Part of the configuration

Schedule editor

There are some products on the market of smart thermostats/controllers that rely on knowing the user Geo Location to act “smart” – is this really smart?

When user is at given location there are several methods to figure it out:

Active:

• Pinging an IP address presence
• Checking current WiFi network name
• Using arping to check mac address presence

Passive:

• Listening for specific packets

All above are good if you do not need an extra time to react and that’s the problem. You can shutdown all the lights when no one is present.

While working on a secure cloud for the gang of the esp8266 based devices we are developing we need SSL – real and secure.

And this August is the month of the SSL issues , it seems , but thankful to the Espressifs’ quick support they are on the way out.

SSL Memory Leak

The latest SDK v1.3.0 introduced a bug that simply didn’t call the disconnect callback of esp connections under some circumstances and that in turn leaked memory.  It’s not clarified but the case was when you had a tcp listener and ssl connection after the ssl connection is over, your tcp listener connections did receive disconnect callbacks anymore.  You can get the fix from bbs.espressif.cn

Hi,

I have signed the IoT Design Manifesto – if you are into IoT. You should too.

Here is the link Sign The Manifesto.

These are the highlights of it:

1. We do not belive the hype!
2. We design useful things!
3. We aim for the win-win-win!
4. We keep everyone and everything secure!
5. We build and promote a culture of privacy!
6. We are deliberate of what data we collect!
7. We make the parties associated with an IoT product Explicit!
8. We empower users to be masters of their own domain!
9. We design things for their lifetime!
10. In the End We Are Human beings!

 

During the past weeks i’ve worked on getting the FOTA upgrades work on the 2MB boards by Olimex.

The wonderful esp-link project by Thorsten von Eicken was a great example of  two things:

1. How to concatenate the espfs filesystem image with the firmware images.
2. How to properly write a new image to the flash.

It was a nice example to start with.

So after a lot of fiddling with  Makefiles, cgi routines and esptool  – i’ve finally got the OTA working.

Engineering Internet Of Things Secure network  for our upcoming IoT service.

Goals:

• Security
• Redundancy
• End to End Security
• Secure Firmware Upgrades

Threats:

• DoS Attacks
• DDoS Attacks
• DNS spoofing /don’t even think of DynDNS/
• Sniffing
• man in the middle

Security:

• Using a VPN -> takes the problem away and requires extra settup. Not user friendly. The only pro is that it can use an existing infrastructure if present. A Big NO
• SSL -> expired certificates , heavy overhead, often exploited. Closed source library, may already be hacked. NO
• AES all the Way. A big YES
• DoS/DDoS prevention – redundant MQTT brokers, with dns/firmware fallback

So Why AES?

Which goes where – when using a bootloader for FOTA.

The files:

• master_device_key.bin –  Obtained from Espressif Cloud
• esp_init_data_default.bin – Stores default RF parameter values
• boot.bin – bootloader
• user1.bin and user2.bin – user firmware
• blank.bin – blank settings , flash to get default parameters

1. 512KB

• master_device_key.bin 0x3E000
• esp_init_data_default.bin 0x7C000
• blank.bin 0x7E000
• boot.bin 0x00000
• user1.bin 0x01000
• user2.bin 0x41000

2. 1024KB Flash

• master_device_key.bin 0x3E000
• esp_init_data_default.bin 0xFC000
• blank.bin 0xFE000
• boot.bin 0x00000
• user1.bin 0x01000
• user2.bin 0x81000

3. 2048KB Flash

• master_device_key.bin 0x3E000
• esp_init_data_default.bin 0x1FC000
• blank.bin 0x1FE000
• boot.bin 0x00000
• user1.bin 0x01000
• user2.bin 0x81000

4. 4096KB Flash

• master_device_key.bin 0x3E000
• esp_init_data_default.bin 0x3FC000
• blank.bin 0x3FE000
• boot.bin 0x00000
• user1.bin 0x01000
• user2.bin 0x81000

 

Finding the Right Development Board

When developing IoT applications with the ESP8266, two key requirements immediately become apparent: you need sufficient flash memory for your application and firmware, and you need a board that fits comfortably on a breadboard for prototyping and testing.

I faced this challenge and needed to evaluate my options. Soldering additional flash chips onto bare ESP8266 modules wasn’t practical, so I researched alternative boards:

1. NodeMCU boards – These feature larger flash and breadboard compatibility, but come with integrated regulators and USB-to-serial converters that add complexity and bulk.
2. ESP-XX modules with adapters – While available, these adapters tend to be awkward and add unnecessary overhead for development work.
3. Olimex MOD-WIFI-ESP8266-DEV – A purpose-built development module with excellent specifications and clean design.

The winner: Olimex’s MOD-WIFI-ESP8266-DEV