Emulation and Spoken Alarms
In part two of his article, Brian describes integrating custom IoT gadgets with Amazon Echo using emulation to receive spoken alarms. In part one, he used emulation and Arduino Cloud services as a middleman.
In Part 1 of this article, I described two different methods of designing a custom IoT device that could easily be integrated with the Amazon Echo smart devices by making use of the Alexa speech recognition feature. One method involved the emulation of a commercial Alexa-compatible device, the Philip’s Hue smart light bulbs. The second method used the Arduino Cloud service as a “middleman” between the custom IoT device and the Amazon Alexa cloud server.
In this article, I’ll describe another custom IoT device that uses the emulation method. To conclude the series, I’ll describe an IoT device that can notify your Echo device of an alarm condition, allowing you to receive spoken warnings, and notifications to your cellphone or tablet.
TRICKY THERMOSTAT
I became very interested in electronics when I was about 10 years old. I don’t recall how I justified it, but, as a teenager, I remember taking a thermostat off the wall at home, to see how it worked. Figure 1 shows one of these old round Honeywell thermostats, with its cover removed.
This is a picture of the old Honeywell thermostat like the one I investigated as a teenager. (Image source: Wikipedia).
How it operated was fairly obvious: There was a bimetallic strip wound in a spiral shape. At one end of it was a glass enclosed mercury switch, oriented horizontally. Turning the temperature-setting dial must have adjusted the other end of the spiral, I believe. As the room temperature changed, the spiral would wind/unwind and the mercury switch would tilt, opening and closing the switch contacts. I also recall seeing another small dial that was not visible from the outside but can be seen in the foreground of Figure 1. Later, I found out this was called an anticipator adjustment and it existed to counteract the tendency for the room to continue to heat up somewhat, even after the furnace’s burner was shut off by the thermostat. This dial was marked off in Amp units, I believe likely to match the current draw of the relay that the thermostat switched. This was 50+ years ago, but I think that the anticipator dial was associated with a small resistive heater. This could “trick” the bimetallic spiral into thinking that the room was warmer than it actually was, thus performing the anticipator function, mentioned earlier. If this heater were switched on/off by the thermostat’s contacts, it would also provide what is called hysteresis in the instrumentation field. Hysteresis is needed to eliminate rapid thermostat switching, when the temperature fluctuates slightly around the setpoint. If you watched the mercury switch, it was obvious that it flipped from on to off with just the slightest change in position of the bimetallic spiral. It isn’t good for the furnace burner to be cycled on and off rapidly- thus the need for this hysteresis.
Recalling this experience in my youth, it occurred to me that a programmed “set-back” function could be added to a modern thermostat in my home. Where the old Honeywell thermostats switched 24 VAC, at only the low current needed to operate the furnace control relay, I have electric heat and such thermostats must switch 240VAC at up to 20A.
The electric heat thermostat, in the room that I was interested in, contained a bellows and an adjustment screw coupled to the temperature dial. The high-current, 240VAC power switch that was activated by this bellows, was totally enclosed in the plastic rear section of the thermostat (fastened to a junction box in the wall). It occurred to me that I could glue some low-value resistors inside the decorative front cover surrounding the bellows assembly to act as a small heater.
This is a modern thermostat meant to control baseboard electric heat. The high current switch is completely enclosed in the brown plastic rear assembly. The bellows which activates it is visible in the center..
During the time that I wanted the thermostat to set back (for example, lower the room temperature), I would only have to supply power to those resistors mounted inside the front cover. When they heated up, they would fool the thermostat into thinking the room was warmer than it actually was. I chose the value of the resistors empirically and initially adjusted the voltage feeding them, using a DC bench supply. With power applied to the resistors, I wanted to observe the thermometer (contained in the thermostat), reading 5°C hotter than the actual room temperature. This would implement a roughly 5°C set-back when the resistors were powered up. My aim was to be able to use a small wall adapter to supply this power. I had plenty of them around between 3V and 15V. It turned out that a 4.5V 1.5A adapter I had on hand was perfect for the job. I used four series-connected 1.0Ω 1W resistors in the thermostat itself (as the heater) and an additional external 1.0Ω resistor, in series with the 4.5V wall adapter. Figure 2 shows the thermostat rear assembly and Figure 3 shows the front panel, with the four resistors mounted.
This shows the four 1W resistors that I am using as a heater to “trick” the thermostat into thinking the room is somewhat warmer than it really is.
To control the power to this wall adapter, I wanted to use Alexa to manage the daily temperature set-back periods. In this room, I was already using an Alexa-compatible TP-Link KP2000 Smart duplex wall receptacle- for another purpose. This product allows individual remote control of each of its two receptacles, using Alexa. So, I just plugged the 4.5-V wall adapter for my set-back thermostat, into the KP2000’s unused socket. This TP-link receptacle requires you to add the Kasa Skill to your Alexa profile. To control the temperature set-back periods, it was simply a matter of adding a new Routine to my profile and setting the on/off times appropriately. When I know in advance that I am going to be using this room (a music studio in my basement), I can quickly turn off the set-back function, with a voice command or from my cellphone’s Alexa app, 10-15 minutes before I plan to use the room.
ALEXA TRIGGERS
The last category of gadgets that I tackled were ones that would send a message to my Echo devices, acting as a trigger for some action that I wanted my Echo devices to perform. These messages could occur at a random time: Think of an alarm for example, as opposed to an IoT device that is periodically polled by the Echo device. Such an alarm message can be programmed in the routines section of the Alexa app, to perform many different functions. A few such functions, that I thought would be useful, are as follows:
- Send a notification to my cellphone and iPad tablet.
- Make a custom, meaningful voice announcement on one or all my Echo devices.
- Turn on a light bulb or other electrical device.
- Use Alexa routines can generate social media posts as well.
Except for the Arduino Cloud-based IoT device example in Part 1, the device examples communicated with the Echo device directly. That is, the custom IoT device implemented a webserver, configured to emulate a commercial IoT product, i.e., a Philips Hue smart bulb. The Echo needed the “Skill” for that product loaded and enabled. Then it would “discover” these custom IoT devices over my home’s Wi-Fi network.
In the case of Alexa triggers, the process is somewhat more complicated. To start with, Amazon has wisely decided that it would not let its Echo devices respond directly to incoming messages from any random device that you might connect to your WiFi network. You can readily see that this could lead to many bad outcomes, particularly if outside acters managed to gain access to your home WiFi network.
For Alexa triggers to work, the trigger message must be sent to the Amazon Alexa server directly. For this message to be properly routed to your specific Echo device, the trigger message must include a “key” of some sort, to tell the server which specific Echo device to send the trigger message to. To generate this key, your Amazon account information must be provided to prevent outside actors from being able to access your Echo devices maliciously.
Furthermore, the Amazon server must be able to authenticate the source of this incoming trigger message and not just the validity of the message itself. In other words, the server or device sending the trigger message must be able to complete an authentication routine using credentials, recognized in advance, by Amazon. It’s certainly possible for an individual with competency in security protocols to design an IoT device that meets the stringent criteria necessary to access Amazon’s Alexa API. However, for the average DIY individual, it’s much easier to find a server, run by a third-party, that provides a “middleman” service between that individual’s custom IoT device and the Amazon Alexa server.
Since this “middleman” server must be able to link the trigger messages that you are sending to your personal Echo device, it follows that your Amazon account information must be involved in some way. The fact that you own and use Echo devices means that you trust Amazon with personal information, including credit card information. However, you might be disinclined to give an unfamiliar company, acting as the “middleman”, access to your Amazon account information. I know I initially was so disinclined.
Amazon solved this trust problem by “linking” your Amazon account and that of the third-party middleman, in the following way: When you set up an on-line account with the third-party “middleman”, at some point in that procedure, you are re-directed to Amazon’s server. Once you successfully login to the Amazon server, Amazon will then send back to the “middleman” (the identity of which Amazon has previously established), whatever authorization keys are needed. This authorization will:
- Establish the identity of the “middleman” server.
- Identify your specific Amazon account as the destination for the trigger message.
- Specify an IoT device from which the message originates.
When I searched for “Alexa Trigger” skills from the Amazon Alexa cellphone app, I came up with a few possibilities. The first ones listed were:
- IFTTT Trigger by mkZense.
- Virtual Routine Trigger.
- URL Routine Trigger.
- Webhook Routine Trigger (similar to the mkZense offering, but based in Germany).
I’ve had previous experience using the IFTTT cloud service with earlier IoT devices I had built. That experience wasn’t so positive: features that I used, that were initially free, were later migrated over to a paid, monthly subscription plan. Nevertheless, I first investigated the IFTTT Alexa Trigger skill, as it looked promising. The company is mkZense, and they allow you to open a free account which allows you to define a couple of triggers. As mentioned earlier, setting up this free mkZense account is done using the Alexa cellphone app and adding the IFTTT Trigger Skill to your Alexa profile. This signup initially takes you to mkZense’s website but also involves being redirected back to the Amazon site, where you must login with your Amazon account username and password. This links the two accounts. As part of this procedure, you will be prompted to enter descriptive names for the number of triggers you want to set up.
With the free mkZense account set up, you next go to the IFTTT website and set up an applet that integrates the MkZense service with Amazon’s Alexa service. The mkZense service has videos describing how to do this and claim that you can create an IFTTT applet without a paid ITFFF subscription. While this may have been possible when they posted the video, this is no longer the case. You don’t discover that you need a paid account until you reach the end of the IFTTT applet configuration. This was disappointing to say the least, but I noticed that mkZense has a paid subscription plan that bypasses the IFTTT service completely and allows for an unlimited number of triggers. Since this cost only $5 per year, and can be paid for using Amazon Pay, I decided to sign up and proceed this way. Note that if you initially add or enable the free mkZense Skill, you must disable this skill in the Alexa app and start over again, selecting the paid subscription. Once you have subscribed, you will receive an email at the email address associated with your Amazon account. This email will contain a Webhook access token, which is a long string containing hex characters.
What is a Webhook? A Webhook is a unique internet URL composed of the URL of an operational webserver, combined with an access token which points to a specific “webpage” on that webserver. When you access that specific URL, the server recognizes that access and performs some relevant action. In this instance the server is run by mkZense and it will send the proper trigger message to the Amazon Alexa server. The Alexa server will in turn pass this message on to your Echo device. Following is an example of the mkzense Webhook URL that you might get in that email:
https://mkzense.com/webhook/alexa/7a09384635ef1f37c4d671b9c7724151901957/TRIGGER-NAME
You can see the mkZense webserver address followed by “webhook/alexa/” and an access token. At the end is the word TRIGGER-NAME. You must replace this with one of the actual trigger names that you supplied. In case you have forgotten them, your registered trigger names are listed at the end of this email message.
You must next set up a Routine using the Amazon Alexa app. When setting up this routine, for the WHEN condition, you would select the Smart Home section, where you should see entries for all the triggers that you defined when you added the “IFTTT Trigger” Skill to your Alexa profile. Select the applicable trigger device. Then, in the “ALEXA WILL” section you can choose such actions as Notification, Announce, etc.
At this point you can test out the proper operation of this webhook by cutting/pasting the URL into your PC’s web browser’s URL address field. When you access this URL, your Echo device should perform whatever task you have defined in the Routine that you set up for that trigger. Also, your web browser should display something that looks like the following:
“SUCCESS::north-america:YOUR_EMAIL_ ADDRESS.com:TRIGGER-NAME”
The message returned is formatted in JSON file format and will be displayed in JSON format, if your browser supports displaying that format.
For your IoT gadget to be able to trigger the desired Alexa Routine, it must be capable of performing a “GET” request to the trigger’s URL. In my case, I was adapting water leak detectors, that I had built in the past, to connect to Alexa. Those detectors were built using Espressif’s ESP8266 MCU and I program these devices using the Arduino IDE, with the ESP8266 board support package added.
This is a block diagram of the program running the water leak detector. It sends a message to the mkZense server via a webhook. That gets passed on to the Amazon Alexa server and ultimately sent to my Echo devices.
A block diagram of the program flow needed to implement this is shown in Figure 4. I’ll discuss circuitry later, but for now, if either a water leak is detected or the battery voltage is found to be getting low, the ESP8266 will log in to my home WiFi access point (repeatedly if not initially successful). It will then send the “GET” request to the Alexa trigger URL shown earlier (but edited-for my privacy). To do so requires the “ESP8266HTTPClient” library, which can be obtained using the Arduino Library Manager. Listing 1 shows the snippet of code needed to send this request, as well as the code which checks for the success of this procedure.
This is a snippet of code that performs a GET request to the URL of the mkZense webhook, which acts upon that webhook access by forwarding the alarm message to the Amazon Alexa server.
Note that in the third line, the long trigger URL is not completely shown, but the full URL, as described earlier must be used. The line containing httpCode= http.get(); performs the actual GET request and returns the httpCode variable. The http.getString() routine fetches the JSON result string, sent by the host webserver. I use the indexOf function to search for the “SUCCESS” string in the JSON response and increment the repeats variable if it’s found. If successful, I will send this GET request NUM_REPEATS more times, at 5-minute intervals, to maximize the chance that I will hear Alexa when she announces the water leak. In any case, several notifications will be sent to my phone or iPad.
If unsuccessful at reaching the mkZense server after NUM_RETRIES attempts, the loop will be exited, and the on-board buzzer will sound until the battery dies. This beeping will also occur if the mkZense server is reached and the Alexa skill is triggered on the Echo device(s).
LEAK ALARM CIRCUIT
Figure 5 is the schematic of the water leak alarm. Battery power is applied at CN1 and can either be a 3.7-V LiPo cell or 3 AAA cells in series. The battery voltage is regulated down to 3.3-V by a MIC5323-3.3 LDO regulator, which was chosen for its low quiescent current value. The water leak electrodes are two 1” wires spaced about ¼” apart. One of them is connected to Vcc through a 1 Meg resistor, the other to GND, and each electrode has a 10k resistor in series with it to protect the ESP8266 against static discharge. When the electrodes sense water, the voltage across the electrodes will drop from Vcc down to less than the Vcc /2 logic threshold of the ESP8266’s IO14 digital input pin. The ESP8266 spends most of its time in deep-sleep mode. Every 20 minutes, it wakes up and checks the leak electrodes. It also measures the battery by monitoring the voltage divider consisting of a 2.2 Meg and 470k resistors, which are connected directly across the battery. While not used in this project, a Qwiic connector is connected to pull-up resistors and IO4, IO5- to allow an I2C sensor (humidity, temperature etc.) to be attached. Port IO12 drives a 2N3904 transistor to drive a small piezo beeper. This beeper must contain its own driver- the Digi-key 668-1456-ND for example. The ESP8266’s Rx and Tx UART pins are connected to terminals to allow connection to a PC, using a USB-UART cable. This is needed to program the ESP8266’s flash and is handy for debugging purposes.
This is the schematic diagram of the water leak detector, which sends its alarm signal to my Echo devices. The Echo devices can be configured to do several things when triggered by this alarm signal, including sending notifications to both my cellphone and iPad.
Figure 6 is a screenshot of my computer screen, taken while measuring the unit’s power consumption using my Joulescope power monitor. During the 20 minute deep-sleep interval, the unit draws 92uA, comprised of the ESP8266 deep-sleep current, the quiescent current of the MIC5323-3.3 LDO, and some passive resistance loads. The ESP8266 program takes one second to monitor the battery voltage and check for leaks, and if both are OK, it immediately returns to a deep-sleep state. During this interval, it draws an average of 29.7mA. Using these figures, I estimate the battery life to be about one year, assuming a 2000 mAh LiPo battery.
This is a screen capture of the PC program that acts as the user interface to my Joulescope power monitor. I measure a deep-sleep current of 92 uA and an average operating current of 29.7 mA for the 1 second interval when the program is actually running.
CONCLUSION
I hope that you found this two-part article helpful as an introduction to integrating your own custom IoT devices to the Echo/Alexa smart home system. I suspect that there are many other ways of doing this, using either an emulation of a commercial Alexa-compatible device, or some other cloud service that is already linked to the Amazon Alexa server. If you are more ambitious and skilled, you can also obtain your own account on Amazon’s server, figure out how to do the necessary authentication procedure allowing access to the Alexa API, and develop your own IoT gadget that isn’t an emulation or needs a third-party server to act as the “middleman”.
I briefly “toyed” with using an ESP32 MCU (as well as a Particle Photon 2) with the Edge Impulse AI cloud platform for “on-chip” voice recognition purposes. That seems to involve a lot of effort to achieve even very limited word recognition: granted, it’s completely self-contained on the MCU itself. Unless you have access to a large library of spoken word samples, from a variety of different people, it’s going to be speaker dependent. In contrast, the speech recognition capability of Alexa is quite remarkable, in my opinion. The extremely short time that it takes for your verbal commands to be sent to the server, recognized and the appropriate action taken, is also quite remarkable.
RESOURCES
Arduino | https://www.arduino.cc
DFRobot | https://www.dfrobot.com
Espressif | https://www.espressif.com
mkZense | https://mkzense.com
SOURCES
Espalexa Arduino library (github): https://github.com/Aircoookie/Espalexa
Arduino library reference document: https://www.arduino.cc/reference/en/libraries/espalexa
Alexa Skill- IFTTTrigger-Alexa-Actions by mkZense https://mkzense.com
DFRobot FireBeetle ESP32-E module (DFR0654) : https://www.dfrobot.com/product-2195.html
Espressif ESP32-Wroom-02 module (datasheet) : https://www.espressif.com/sites/default/files/documentation/0c-esp-wroom-02_datasheet_en.pdf
PUBLISHED IN CIRCUIT CELLAR MAGAZINE • JANUARY 2024 #414 – Get a PDF of the issue
Brian Millier runs Computer Interface Consultants. He was an instrumentation engineer in the Department of Chemistry at Dalhousie University (Halifax, NS, Canada) for 29 years.
