A new version of the package VscpTcpClient (1.1.2) was published at 2020-09-08 20:31:00
Fixes problem with connect always using admin/secret as credentials.
Category: ESP8266
Mail delivery. That is the physical type. That land in a box. Outside. There is one problem with it. You don’t know when or if you get any. So quite often, especially when there is a blizzard, one walk out to the postbox to find that it is empty. And if you have mail almost every day like me one wounder. “Are they late or is there no post for me today?” This usually ends up in me taking another trip to the postbox later when the blizzard is even worse.
A flag – the American style – would be possible. Needing binoculars. The later a habit that also might disturb my neighbors. But now, after all I work with computer. Something more firmware + electronics is my way. A perfect topic for a VSCP howto.
So the problem is simple: I need a notification when mail arrives in my mailbox. It also need to be a VSCP based solution. After all, I came up with the damn protocol.
So I set out to do this.
I like to lean new things. I therefore decided to use Platformio and the esp8266 with the Arduino core for this project. En environment I have not been playing with before. For both there are plenty of “getting started” write-ups available on the net.
This was a design that needed a battery. I have previously noticed the deep sleep capabilities of the ESP8266 so it should work. The device should take only ~20uA when sleeping and about 70mA when doing it’s work. In this app, we talk about a device that just need to wake up for a short moment once (when mail arrives) or twice a day (when I collect the mail).
You have the different sleep modes for the ESP8266 in the table below.
For deep sleep RST and CH_PD on the ESP8266 should be connected together. RST needs a pull-up. Now when set to deep sleep a low pulse on RST will wake the device.
So I came up with this schematic
Nothing strange here. Notice that I added a 1-wire temperature sensor also to get the temperature reported also when the lid is opened. Eagle file are here.
There is suggestions around to use a one shoot at the input. I tested without and it looks like things work as expected so I skipped it. An input switch will bounce so the startup of the unit will probably be a bot chaotic. This will take more juice form the battery and I will change this later on if I find it to be a problem.
I also replaced the reed switch with a mechanical switch on the mailbox. I will probably change that back later on but it was a little harder to get the reed switch approach to fit mechanically and I did not have the time to fix it the way I wanted to when I mounted the hardware.
I never reached 20uA in deep sleep. Rather 200 uA but that is OK for this test (theoretically 260 days or ~8 months on two AAA cells). I will investigate this further when I get more time. But apart from that everything works as expected.
For the firmware you can find it here. It is written so it can be used both with VSCP and MQTT (JSON VSCP events is sent). There are switches at the top of the file to select the version to build. With large EEPROM both can be used simultaneously.
I wrote a general library for VSCP and Arduino with the thought that it can be useful for somebody. Full info is here.
The sample code connects to wifi, then it connects to a VSCP remote host or a MQTT broker. Then it sends five events and then go to deep sleep again. The events that is sent are
- Woken up – to indicate the mailbox lid is open. VSCP_CLASS1_INFORMATION/VSCP_TYPE_INFORMATION_WOKEN_UP.
- Current temperature (level I & floating point value). VSCP_CLASS1_MEASUREMENT/VSCP_TYPE_MEASUREMENT_TEMPERATURE.
- Current temperature (level II and string value). VSCP_CLASS2_MEASUREMENT_STR/VSCP_TYPE_MEASUREMENT_TEMPERATURE.
- Battery voltage (normalized integer). VSCP_CLASS1_MEASUREMENT/VSCP_TYPE_MEASUREMENT_ELECTRICAL_POTENTIAL.
- RSSI (level I string). VSCP_CLASS1_DATA/VSCP_TYPE_DATA_SIGNAL_QUALITY
The two versions of temperature events should be considered as a demo of level I and level II events.
So time to test. Put everything in a box and mount it in the postbox. Our postbox is located a bit from my house
I have a directional wifi antenna in that direction for some stuff in our garage so wifi is OK (-85 dBm) at the location.
I mounted everything a bit after midnight last night.
And now this morning
VSCP Works tells that something has happened at 05:14:44
And yes there is a small package in the mail. Demo accomplished. Might even be useful when connected to node-red so I can get a notification on my phone using Telegram. There may be a short write-up about that also later.
This same setup can of course be used for PIR sensors, window sensors and similar. One can even change the data sent from VSCP to some format. It’s a free world.
Enjoy!
In the last post I showed you how you can use cheap hardware to get a reasonable good power consumption test rig. In this post we are going to use this tool to improve the runtime of the ESPaper significantly. The short trial and error cycle possible with this tool will let us validate several […]
Source: 5 Hacks to Prolong your ESPaper’s Battery Run-Time • ThingPulse
ESP-Mesh reduces the loading of smart light devices on the router by forming a mesh with the smart light device.
ESP-Mesh reduces the loading of smart light devices on the router by forming a mesh with the smart light device.
Hi Sergey, thank you so much much for agreeing to this interview! Can you tell us a bit about your role at Mongoose OS? I am a technical cofounder and CTO of a company behind Mongoose OS, and set the overall technical direction for the…
Source: ESP8266 and ESP32: Interview with Sergey Lyubka from Mongoose OS
Serial port
Connect the USB cable to the board. You will get a new CDC serial port. You can check which one you get with
ls /dev/tty*
Normally you get /dev/ttyUSB0 or /dev/ttyUSB1 or the like. To make them usable for you you should add yourself to the dialout group
addgroup user dialout
where “user” is your username. You can also do this manually in the /etc/group file or
chmod a+rw /dev/ttyUSB0
if you like brute force.
Loading code to the ESP8266
The ESP8266 CPU can be booted in three different ways:
- Flash Mode: default booting mode. Firmware is read and executed from the flash memory. Pins need to be set to: GPIO15=0, GPIO0=0, GPIO2=1
- UART Mode: used to program our board (through a Serial-to-Usb adapter). Pins need to be set to: GPIO15=0, GPIO0=1, GPIO2=1
- SDIO Mode: loads firmware from an SDIO card? Pins need to be set to: GPIO15=1, GPIO0=0/1, GPIO2=0/1
The boot process is described here.
Switching from a mode to another requires to reset the module while the pin states listed is set.
With the nodemcu board and esptool flash uploader all this is handle automatically but if you have another board you must handle this yourself.
esp-open-sdk
You find it here.
Fetch it
sudo git clone https://github.com/pfalcon/esp-open-sdk.git cd esp-open-sdk
Install it
apt-get install make unrar autoconf automake libtool libtool-bin gcc g++ gperf flex bison texinfo gawk ncurses-dev libexpat-dev python sed git clone --recursive https://github.com/pfalcon/esp-open-sdk cd esp-open-sdk/ make
Error when building? See this post
This builds the standalone version of the SDK (Non FreeRTOS)
You should add the bin directory to he path
echo 'PATH=$PATH:~/development/esp8266/esp-open-sdk/xtensa-lx106-elf/bin' >> ~/.profile echo 'PATH=$PATH:~/development/esp8266/esp-open-sdk/esptool' >> ~/.profile PATH=$PATH:~/development/esp8266/esp-open-sdk/xtensa-lx106-elf/bin PATH=$PATH:~/development/esp8266/esp-open-sdk/esptool
I have installed the toolchain in
~/development/esp8266/
so change paths above for your installation folders.
Update it (when updates are available)
make clean git pull git submodule update
Firmware upload tool
You need the esptool.py to upliad firmware to the module, you find it here
Install with
pip install esptoolFirst code (blinky)
You find it here
cd ~/development/esp8266/esp-open-sdk/examples/blinky
Type
make
to build it. Remember that the paths above must have been set. You may get some warnings. No problem.
For your information. If you build from source code should be loaded like this:
bin/0x00000.binto 0x00000bin/0x10000.binto 0x10000
That is just what we do here. Upload to your module with
esptool.py --port /dev/ttyUSB1 write_flash 0x00000 blinky-0x00000.bin 0x10000 blinky-0x10000.bin
No need to press any buttons during flashing. It is handled automatically by the USB DTR circuitry.
Now we are ready to do some real work for our VSCP system with the ESP8266. If you rather prefer Arduino this howto may be the one you should go for instead of this one. Life is much simpler in the Arduino world. But the degrees of freedom is better if you do it all by yourself. The penalty for freedom is more problems of course. As always.
Another intro is here http://www.electrodragon.com/w/ESP8266_Open_SDK
esp8266 wiki is here.
Part 2 will follow.
Sonoff Basic is a WiFi smart switch that allows users to remote control the power of lights/electrical appliances via the App from anywhere.
I have had problems lately to build the esp-open-sdk on my main Debian machine with Jessie. Very annoying of course as I needed it but I haven’t had time to investigate the problem until today. I post the solution here i case it is useful for someone else.
The symptoms is that the build stops quite early in the build process spitting out something like this
[INFO ] =================================================================
[INFO ] Retrieving needed toolchain components’ tarballs
[INFO ] Retrieving needed toolchain components’ tarballs: done in 208.37s (at 03:41)
[INFO ] =================================================================
[INFO ] Extracting and patching toolchain components
[ERROR]
[ERROR] >>
[ERROR] >> Build failed in step ‘Extracting and patching toolchain components’
[ERROR] >> called in step ‘(top-level)’
[ERROR] >>
[ERROR] >> Error happened in: CT_DoExecLog[scripts/functions@257]
[ERROR] >> called from: CT_Extract[scripts/functions@982]
[ERROR] >> called from: do_binutils_extract[scripts/build/binutils/binutils.sh@38]
[ERROR] >> called from: main[scripts/crosstool-NG.sh@615]
[ERROR] >>
[ERROR] >> For more info on this error, look at the file: ‘build.log’
[ERROR] >> There is a list of known issues, some with workarounds, in:
[ERROR] >> ‘share/doc/crosstool-ng/crosstool-ng-1.22.0-60-g37b07f6/B – Known issues.txt’
[ERROR]
[ERROR] (elapsed: 4:12.94)
[04:15] / ct-ng:152: recipe for target ‘build’ failed
make[2]: *** [build] Error 2
make[2]: Leaving directory ‘/home/esp/esp-open-sdk/crosstool-NG’
../Makefile:132: recipe for target ‘_toolchain’ failed
make[1]: *** [_toolchain] Error 2
make[1]: Leaving directory ‘/home/esp/esp-open-sdk/crosstool-NG’
Makefile:128: recipe for target ‘/home/esp/esp-open-sdk/xtensa-lx106-elf/bin/xtensa-lx106-elf-gcc’ failed
make: *** [/home/esp/esp-open-sdk/xtensa-lx106-elf/bin/xtensa-lx106-elf-gcc] Error 2
Investigating the crosstools-NG/build.log (less crosstool-NG/build.log)
[DEBUG] ==> Executing: ‘touch’ ‘/home/esp/esp-open-sdk/crosstool-NG/.build/sr
c/.ncurses-6.0.patched’
[DEBUG] ==> Executing: ‘rm’ ‘-f’ ‘/home/esp/esp-open-sdk/crosstool-NG/.build/
src/.ncurses-6.0.patching’
[DEBUG] ==> Executing: ‘touch’ ‘/home/esp/esp-open-sdk/crosstool-NG/.build/sr
c/.binutils-2.25.1.extracting’
[DEBUG] Entering ‘/home/esp/esp-open-sdk/crosstool-NG/.build/src’
[EXTRA] Extracting ‘binutils-2.25.1’
[DEBUG] ==> Executing: ‘mkdir’ ‘-p’ ‘binutils-2.25.1’
[DEBUG] ==> Executing: ‘tar’ ‘–strip-components=1’ ‘-C’ ‘binutils-2.25.1’ ‘-xv’ ‘-f’ ‘-‘
[FILE ] tar: This does not look like a tar archive
[FILE ] tar: Skipping to next header
[FILE ] tar: Exiting with failure status due to previous errors
[ERROR]
[ERROR] >>
[ERROR] >> Build failed in step ‘Extracting and patching toolchain components’
[ERROR] >> called in step ‘(top-level)’
[ERROR] >>
[ERROR] >> Error happened in: CT_DoExecLog[scripts/functions@257]
[ERROR] >> called from: CT_Extract[scripts/functions@982]
[ERROR] >> called from: do_binutils_extract[scripts/build/binutils/binutils.sh@38]
[ERROR] >> called from: main[scripts/crosstool-NG.sh@615]
[ERROR] >>
[ERROR] >> For more info on this error, look at the file: ‘build.log’
[ERROR] >> There is a list of known issues, some with workarounds, in:
[ERROR] >> ‘share/doc/crosstool-ng/crosstool-ng-1.22.0-60-g37b07f6/B – Known issues.txt’
[ERROR]
[ERROR] (elapsed: 4:12.94)
The line
[DEBUG] ==> Executing: ‘tar’ ‘–strip-components=1’ ‘-C’ ‘binutils-2.25.1’ ‘-xv’ ‘-f’ ‘-‘
[FILE ] tar: This does not look like a tar archive
says it is a problem with a tarball and testing the binutils tarball under crosstool-NG/.build/tarballs shows it really is a problem with the tarball.
So after some discussions here is finally found a solution to the problem.
- remove the partly extracted binutils –
rm -rf crosstool-NG/.build/src/binutils* - remove flags –
rm crosstool-NG/.build/src/ .binutils-* - remove the bad tarball –
rm crosstool-NG/.build/tarballs/binutils* - Download binutils
- copy this tarball from the gnu link to
crosstool-NG/.build/tarballs - Continue with the build –
make
This will make things build. At least it did for me.
if the version of binutils is something else in your case you have other versions here. Select the tar.gz version