| ESP | ||
|---|---|---|
 |
Chapter 3. Embedded Devices |  |
| ESP | ||
|---|---|---|
| |
Chapter 3. Embedded Devices | |
ESP's are SoC from Espressif https://www.espressif.com/en/products/socs
In most cases it is worth the money to take a ESP82xx module with a PCB preventing to deal with SMD and containing all the required things as USB connector, USB to serial converter chip, 3.3V voltage regulator.
Everything is on the chip has to be 3.3V so keep away the damaging 5V.
The virtual serial link of the USB device is used to download the firmware. Cheaper devices require a programmer hardware for that.
The ESP32 is a newer design with less open source support.
Tasmota has firmware for the ESP chips. The firmware has a webserver that allows to configure it. There is no need to write code or install development tools. See:https://tasmota.github.io/docs/
lsusb will show what USB to serial chip is used as: QinHeng Electronics CH340 serial converter. It might be that the kernel is missing that driver and ls /dev/tty* will not show it. In this case build a kernel with the CH341 module.
Opening in a web browser supporting Web Serial (as Google Chrome) https://tasmota.github.io/install/ allows connecting the ESP and downloading the a Tasmota firmware.
There are many different firmware version and variants around also in languages different from English.
The download finishes with connecting the ESP to the WLAN and then offering to open the ESP's webpage where the firmware can be configured.
OTA (Over the Air) updates are supported, to connect to a server and update itself.
Tasmota Web UI has spent a button to support the home automation system domoticz https://wiki.domoticz.com/Main_Page
Pressing the reset button for 40 seconds until the device's LED blinks rapidly will do a factory reset.
https://tasmota.github.io/install/ can also be used to have a console connection using USB and not using WLAN. Console commands can be sent or other gui commands as changing WLAN settings are possible.
Using a terminal with a serial link of 115200 baud gets the Tasmota prompt (pressing the reset button might be necessary).
Unfortunately it is not very clear what GPIOs the uploaded firmware supports, so try and error or deeper analysis in the firmware has to help.
A simple test is to select a module type as Sonoff Basic (brand of smart home devices created by ITEAD) and set GPIO4 to Relay and verify that the number 1 appears right to it this makes it as RELAY1. For multiple relays assign the numbers uniquely. Attach a voltmeter on this pin. Then go to the console and do POWER1 ON to turn it on and POWER1 OFF to turn it off.
If Tasmota turns on POWER and therefor POWER1 after reset or WLAN re-connect and this is not desired, then just use POWER2.
To attach a chip check https://tasmota.github.io/docs/Supported-Peripherals/ for its support and driver to be selected. As Example the Humidity Sensor DHT22 uses the AM2301 driver. Then select the GPIO pin (as GPIO4) to use the signal for the 1 wire DHT22 device.
STATUS <n> will tell something about the firmware
Reset <n> can be used to do a factory reset
<n>
defines what will be wiped off. 4 attempts to keep the WLAN settings 5 not.
PowerOnState will show what will be done after power on. 0 means all outputs off, 3 means restore as after power down.
To have networking support as for Home Assistant add the IP, username and password for the MQTT broker. In Home Assistant add an configurate first MQTT and then add Tasmota.
To turn power 1 on using mqtt send mosquitto_pub -h <IP of broker> -t "cmnd/tasmota_<last 6 chars of the MAC address>/Power1" -m "ON" -u <user> -P <pass>
Tasmota devices are discovered in Home Assistant and ready to be used.
Inside the MQTT parameters window the default topics as tasmota_<last 6 chars of the MAC address> can be changed to a more meaningful name as kitchen_light_1
Sometimes Tasmota does not behave as desired, this can be modified using rules.
Rule shows the configured rules as Rule1
Rule1 shows Rule1
Examples:
Rule1 ON Wifi#Connected DO Power1 OFF ENDON
Rule1 ON Mqtt#Connected DO Power1 OFF ENDON
Rule1 ON System#Init DO Power1 OFF ENDON
Commands:
Rule1 ON activates the rule
Rule1 1 executes the rule right now without required event
Rule1 Off or Rule1 0 deactivates the rule
Rule1 "" makes it useless, it seems that there is no command to remove it from the list
The log will show when the rule has been executed:
log: 00:00:00.135 RUL: SYSTEM#INIT performs 'Power1 OFF'
Shellys use as usual also ESP chips and have a nice case supporting 230Vac installations and all the required safety norms. They have a Shelly firmware that does and behave similar as the Tasmota firmware. If really desired, the Tasmota firmware could be downloaded to certain Shelly devices.
After factory reset (using a tooth peak press their button a couple of seconds until they flash) they create their own access point. It is best using a smart phone to connect to this WLAN using 192.168.33.1 and configure the device.
After configuration turn off the access point so not everybody can access it. It is also possible to keep the access point on but then set a password for the access point.
It can be accessed via web browser https://control.shelly.cloud or the Shelly App.
See https://shelly-api-docs.shelly.cloud/
export SHELLY=192.168.1.20 to not continuously have to type in the IP Address when working with curl
curl http://${SHELLY}/rpc/Shelly.GetStatus to check it on the console
curl http://${SHELLY}/rpc/Shelly.GetStatus curl -X POST -d '{"id":1,"method":"Cloud.GetConfig"}' http://${SHELLY}/rpc to get cloud info
curl -X POST -d '{"id":1,"method":"Cloud.SetConfig","params":{"config":{"enable":true}}}' http://${SHELLY}/rpc to set cloud
See https://shelly-api-docs.shelly.cloud/ and
Go to https://control.shelly.cloud/#/settings/user to get
The authorization cloud key (auth_key).
The auth_key does not expire, but can get revoked. Handle it as a password since it gets access to the users account and all device in the cloud
The cloud server uri as https://shelly-133-eu.shelly.cloud
The device id as cc8da244c471
It is a pure number and not shelly1minig3-cc8da244c471
To see if the cloud is in reached:
curl -I https://shelly-133-eu.shelly.cloud
ping -c3 shelly-133-eu.shelly.cloud
When working with curl export those things to not repeat them continuously
export=MmExMjYxxxxxxxxxxxxxxxxxxxxxxxxxxxxxC30
for the auth_key
export SHELLYURI=https://shelly-133-eu.shelly.cloud for the uri of the cloud server
export SHELLYID=cc8da144c474 for the unique id of the shelly device
The device must have the cloud enabled
curl -X POST "${SHELLYURI}/v2/devices/api/get?auth_key=${SHELLYKEY} -H 'Content-Type: application/json' -d '{"ids":["'"${SHELLYID}"'"]}' to see the device status
curl -X POST "${SHELLYURI}/v2/devices/api/set/switch?auth_key=${SHELLYKEY}" -H 'Content-Type: application/json' -d '{"id":"'"${SHELLYID}"'", "on":true}' to turn on its output
curl -X POST "${SHELLYURI}/v2/devices/api/set/switch?auth_key=${SHELLYKEY}" -H 'Content-Type: application/json' -d '{"id":"'"${SHELLYID}"'", "on":false}' to turn off its output
Usually Shellys are just used as input output devices. But certain devices allow to run scripts. The script language is similar to JavaScript.
See the tutorial https://shelly-api-docs.shelly.cloud/gen2/Scripts/Tutorial/
Features are https://shelly-api-docs.shelly.cloud/gen2/Scripts/ShellyScriptLanguageFeatures/
The script has an id number and can be managed with commands over the network see https://shelly-api-docs.shelly.cloud/gen2/ComponentsAndServices/Script or more human friendly over its web interface.
| |
|
|
| STM32 |
|
C and small microcontrollers |
