Twilio Studio — IVR and Chat Bots

Twilio Studio — IVR and Chat Bots

I’ve used Twilio for a while for pro­gram­mat­i­cal­ly send­ing and receiv­ing SMS mes­sages. There’s also a visu­al edi­tor called Stu­dio that can be used to make call and mes­sage flows:

It can be con­nect­ed to Twilio Autopi­lot to make AI-pow­ered bots. Tasks are trained with sam­ple phras­es. These sam­ple phras­es are vari­a­tions on what would be said to trig­ger an action e.g. ‘Call recep­tion,’ ‘Front desk,’ ‘Talk to a human.’

An exam­ple that comes to mind, is mak­ing a call han­dling sys­tem for an office. Rather than a voice menu that details each option fol­lowed by a num­ber, the caller could sim­ply say who they want­ed to talk to or what their request was about, and the sys­tem would han­dle it. This is far more respect­ful of the caller’s time com­pared to hav­ing them lis­ten to a long list of choic­es.

It works with SMS and voice calls, and seems a good way to build an IVR (Inter­ac­tive Voice Menu) sys­tem. TwiML can be used for more com­pli­cat­ed tasks, while still using Studio/Autopilot. The pric­ing is a lit­tle high­er than if you were to use a self-host­ed sys­tem, but there are so many com­pli­cat­ed func­tion­al­i­ties it seems well worth pay­ing the extra, as it would save time and reduce com­plex­i­ty.

I built a remote con­trolled car that used Twil­io’s cell­phone ser­vice. You can read about it here.

Mikrotik Script — Wake On LAN All Devices from DHCP

Mikrotik Script — Wake On LAN All Devices from DHCP

A lit­tle script to wake up all Mikrotik devices on your net­work that have a DHCP lease, using Wake On LAN.

It may be a good idea to set your DHCP lease expiry to some­thing long like 7 days. A short expiry may mean dynam­ic leas­es have expired if the device has been switched off for some time.

It should also wake up any devices with sta­t­ic leas­es, so you could also set all your devices as sta­t­ic in your DHCP.

1
2
3
4
5
/ip dhcp-serv­er lease
:fore­ach i in=[find] do={
:put ([get $i address].”,”.[get $i mac-address].”,”.[get $i server].”,”.[get $i host-name].”,”.[get $i expires-after])
:exe­cute { /tool wol interface=bridge [get $i mac-address] }
}

ESP32 E‑Paper Status Display

ESP32 E‑Paper Status Display

Using an ESP-32 board with an embed­ded E‑Paper dis­play, I cre­at­ed a gad­get that shows sta­tus infor­ma­tion from my web serv­er.

E‑Paper, also known as E‑Ink, only needs pow­er when being updat­ed, and uses no pow­er between updates. This means that the gad­get can be pow­ered for weeks from a recharge­able bat­tery.

The pur­pose of this gad­get is to put on my wall or desk, and show reg­u­lar­ly updat­ed impor­tant infor­ma­tion on my web serv­er, to keep informed of web site prob­lems and sta­tis­tics. The infor­ma­tion dis­played can be eas­i­ly changed, for exam­ple to the lat­est weath­er, news, cur­ren­cy prices or any­thing that can be accessed via the inter­net. E‑Paper means it uses a very small amount of pow­er and heat, com­pared to a com­put­er dis­play or tele­vi­sion.

You can view my code on GitHub if you are inter­est­ed in mak­ing your own.

ESP32 E-Paper Display
ESP32 E-Paper Display
ESP32 E-Paper Display
A HTML/JavaScript web interface and a Node/Express server, to control the robot drawing machine over the Internet.

A HTML/JavaScript web interface and a Node/Express server, to control the robot drawing machine over the Internet.

Using Node­JS and Express, I cre­at­ed a web inter­face to remote­ly con­trol the pen draw­ing robot ‘Line-Us.’ Avail­able from Cool Com­po­nents.

Line-Us robot
Line-Us robot

You can watch a video of it func­tion­ing here:

And my pro­jec­t’s source code is avail­able on GitHub:
 
 
The robot is avail­able to pur­chase here:
 
Anonymous Traffic Survey Cameras

Anonymous Traffic Survey Cameras

Manual Traffic Surveys

Many peo­ple in the UK may be famil­iar with see­ing groups of peo­ple, or some­times a parked vechi­cle, clear­ly dis­play­ing a sign say­ing ‘Traf­fic Sur­vey.’ These peo­ple are employed to keep a tal­ly of the num­ber of vehi­cles using a road, and the types of vehi­cles. This infor­ma­tion is impor­tant for plan­ning infra­struc­ture, help­ing more effi­cient pro­vi­sion of trans­port capac­i­ty for cars, trucks/lorries and bus­es.

Pressure Sensors

Pressure-sensitive Traffic Data Collection System (from www.surveymarketing.co.uk)
Pres­sure-sen­si­tive Traf­fic Data Col­lec­tion Sys­tem (from www.surveymarketing.co.uk)

Many will also have seen tem­po­rary pres­sure sen­sors across roads, linked to a data col­lec­tion box attached to a street lamp. This sys­tem also pro­vides use­ful data on the num­ber of vehi­cles using a road.

By using two pres­sure sen­sors, its pos­si­ble to fair­ly accu­rate­ly record the num­bers of vehi­cles pass­ing in two direc­tions. How­ev­er, there may be some inac­cu­ra­cies when vehi­cles pass simul­ta­ne­ous­ly or almost simul­ta­ne­ous­ly. A 15-minute time peri­od may have an inac­cu­ra­cy of 10% (http://www.windmill.co.uk/vehicle-sensing.html). For roads with more than two lanes, accu­ra­cy would be even less and the sys­tem prob­a­bly would­n’t be fea­si­ble.

Electronic Sensors

Piezoelectric Sensor Dug into Road
Piezo­elec­tric Sen­sor Dug into Road

There are also elec­tron­ic solu­tions dug into roads, which I’ve noticed on approach­es to traf­fic lights. These may be used to alter tim­ings of traf­fic lights depend­ing on traf­fic, and it seems they could also be used for traf­fic sur­vey data col­lec­tion. You may have noticed traf­fic lights chang­ing as you approach them, and a sys­tem like this may be detect­ing the mechan­i­cal ener­gy of your vehi­cle pass­ing over sen­sors. I expect there are also mag­net­ic ver­sions of these sen­sors, that sense the metal­lic body of a vehi­cle. Some­times motor­cy­cles in the US do not trig­ger these sys­tems at auto­mat­ed inter­sec­tions, caus­ing prob­lems, and some state laws allow­ing vehi­cles to pass if a sen­sor fails to detect a vehi­cle’s pres­ence.

Video Surveys

Scout Pole­mount Traf­fic Sur­vey Cam­era

I’ve noticed what seems like a new tech­nol­o­gy recent­ly, with a video cam­era mount­ed on a street light, and a data col­lec­tion box attached to it. After research­ing it, these are video cam­eras that record con­ven­tion­al HD video for a peri­od of 3 to 7 days. The mod­el I saw in use also has advanced fea­tures like remote man­age­ment and event alerts sent via mobile cel­lu­lar net­works (LTE), allow­ing set­tings to be changed and noti­fi­ca­tions of prob­lems with­out hav­ing to trav­el back to where the unit is deployed.

Computer Vision (CV)

I expect com­put­er vision tech­niques (e.g. OpenCV) are lat­er used to analyse the num­bers and types of vehi­cles pass­ing:

Anonymity and Privacy

I expect there are strict rules in place to pre­vent ANPR (Auto­mat­ic Num­ber Plate Recog­ni­tion) being used, as this may vio­late the pri­va­cy of dri­vers. How­ev­er, if there are not, I expect trav­el time sur­veys could be made by cal­cu­lat­ing how long a com­mute takes for indi­vid­ual dri­vers, and how they change over time. Per­haps if this was cal­cu­lat­ed anony­mous­ly, it would be a usable tech­nique.

While there have been com­pa­nies that have mon­i­tored cell­phones with Blue­tooth and Wi-Fi ser­i­al num­bers, often the gen­er­al pub­lic have expressed con­cerns over pri­va­cy. An exam­ple hard­ware provider for this is http://www.libelium.com.

In con­clu­sion, I found it inter­est­ing to research what these cam­eras and oth­er equip­ment I see are used for, and expect it is an inter­est­ing field analysing queues of videos for traf­fic data.

Page Speed Load Time Optimizations

Page Speed Load Time Optimizations

Here are a few impor­tant ways to speed up page load­ing times, togeth­er with the improved record­ed times for com­par­i­son on a typ­i­cal Word­Press web site. While Word­Press is hard­ly an opti­mized web appli­ca­tion, it does ben­e­fit from the same speedup meth­ods as most web appli­ca­tions.

I used Google Chrome Devel­op­er Tools to time net­work trans­fers and page load times. There are var­i­ous web-based tools avail­able as well:

Initial speed — 1.412 sec (TTFB 0.12 sec)

This was the speed on a fresh install of a Word­Press web site on a small VPS run­ning Nginx and PHP-FPM.

Enabling GZip compression — 1.326 sec (TTFB 0.13 sec)

Using com­pres­sion on net­work trans­fers can great­ly reduce file sizes, espe­cial­ly for text-based files such as HTML, CSS and JavaScript. The CPU over­head on mod­ern servers is neg­li­gi­ble, and can be cached if required.

PHP Opcode cache — 1.299 sec (TTFB 0.124 sec)

PHP scripts are typ­i­cal­ly com­piled to byte­code on demand. By caching this com­pli­ca­tion with OPcache or APC, page load times and serv­er load can be sig­nif­i­cant­ly reduced. APC did include a fast key/value cache, which has now been replaced by APCu.

WordPress Cache — 0.733 sec (TTFB 0.122 sec)

There are many Word­Press cache plu­g­ins avail­able, which reduce the amount of PHP code that has to be run on every request. Some caches can gen­er­ate flat files, which are sig­nif­i­cant­ly faster, and can be used with Nginx.

Nginx FastCGI Cache — 0.731 sec (TTFB 0.119 sec)

Nginx is able to use a fast memory/disk cache to cache requests to PHP-FPM, fur­ther reduc­ing page load times and serv­er loads. This can be very ben­e­fi­cial on web sites with high load.

There are many oth­er ways to speed up page load times, includ­ing depen­den­cy con­cate­na­tion and mini­fi­ca­tion and image opti­miza­tion. It is also impor­tant to opti­mize client-side JavaScript to allow the user’s web brows­er to dis­play con­tent quick­ly.

AnyCast DNS

An ini­tial vis­it to a web site requires a DNS lookup. Tra­di­tion­al­ly DNS has no way to send requests to the geo­graph­i­cal­ly clos­est serv­er, but this is pos­si­ble with Any­Cast DNS. This fea­ture is avail­able on many providers includ­ing Ama­zon’s Route 53, Google’s Cloud Plat­form and Microsoft Azure. It func­tions by allow­ing mul­ti­ple servers dis­trib­uted through­out the world to have the same IP address.

By using Any­Cast DNS, I was able to reduce an ini­tial DNS request from 93 mil­lisec­onds to 18 mil­lisec­onds. Com­bined with hav­ing an opti­mized web serv­er geo­graph­i­cal­ly close, even an ini­tial vis­it to a web page can be dis­played instan­ta­neous­ly.

Before Any­castDNS

After Any­castDNS

Conclusion

Sub­tract­ing the round trip time to the serv­er of 0.116 sec­onds, these opti­miza­tions reduced the effec­tive Time To First Byte to 3 mil­lisec­onds. On a busy serv­er, these opti­miza­tions will make a sig­nif­i­cant dif­fer­ence to the capac­i­ty of the serv­er.