Twitter and Facebook are two primary social networks that I regularly use.
Despite many arguments against synchronizing contents across different accounts, I still think it's beneficial to repost my tweets onto my Facebook timeline.
There are already many solutions to achieve cross-posting between Twitter and Facebook, but they are not ideal, because I'm very picky on what I want:
- I want to cross-post from Twitter to Facebook, not the other way around.
- I want to tweet with native Twitter clients, not through a third party website or app.
- I don't want those tweets created by my Swarm check-ins to be re-posted onto Facebook, because Swarm app can directly post to Facebook.
- For plain text tweets, I want them as plain text Facebook status updates, without a link to Twitter which could only confuse my Facebook friends.
- If I tweet a photo, I want that photo to be uploaded to Facebook, instead of posting a link on Facebook.
- If I tweet a link to some webpage, I want Facebook to display a preview of the webpage.
IFTTT is one of my favorite online services.
It allows me to create a recipe for certain automated actions.
The name "IFTTT" stands for IF This Than That, where This could be "posting a new tweet", and That could be "posting a Facebook status".
However, IFTTT does not allow filtering: I couldn't specify conditions like "the tweet is not posted by Swarm", which is necessary to achieve my goals.
Therefore, I need a more advance solution to repost my Twitter feed to Facebook.
This year the world is greeted with Losant, an Internet of Things platform that allows makers to connect their sensor devices, collect data into the cloud, and take actions through workflow execution.
While neither Twitter nor Facebook has anything to do with IoT, Losant workflow has some great capabilities that makes it suitable for non-IoT usage:
- trigger execution from a timer or an HTTP request
- parse and stringify JSON
- send HTTP request to any server
- store execute state in a variable
One of my favorite electronic elements is the photoresistor, an element whose resistance decreases with increasing incident light intensity.
I played with a photoresistor as part of an electronic building blocks toy kit when I was in elementary school, and made a geocaching trackable out of that experience.
But I want a deeper understanding of the photoresitor: what's the correlation between its conductivity and the light intensity?
Recently I acquired some Witty Cloud boards.
This board is built around an ESP8266 microcontroller; a photoresistor (aka Light Dependent Resistor, LDR) is connected to the analog input port of the ESP8266.
With one line of code in Arduino (
analogRead(A0)), we could read the light intensity as a number between 0 and 1023.
However, what's the unit of this number, and how does it translate to the standard units such as lumens?
I couldn't find any formula for this translation, because it does not exist.
Adafruit explains photoresistor readings nicely:
The readings taken are not in any useful units of light intensity.
Photoresistors are not carefully calibrated sensors.
If you wanted to make a light meter, with absolute measurement of light intensity in meaningful units, you would need to create a lookup table that related readings with readings taken from a properly calibrated light meter.
Losant is a simple and powerful IoT cloud platform.
Sensor devices, such as the Losant Builder Kit, can connect to their MQTT broker over the public Internet, and report state in real time.
Based on those state reports, the software running in the cloud (call "workflows") can take actions such as sending an alert over email or text message, or deliver a command to be executed on an actuator device over MQTT.
One important question to ask is: how stable is this system?
There are many elements in this system that can fail:
- Losant MQTT broker
- workflows in the cloud
- connected device (sensor or actuator)
- power supply to the connected device
- the Internet connection
Hopefully, the good folks at Losant has deployed enough redundancy for their MQTT broker and machines to execute workflows, and the user is careful enough when modifying the workflows.
A failure is more likely to occur in the connected device, its power supply, or Internet connection.
Failure in any of these three elements will result in the device being disconnected from the Losant MQTT broker.
Thus, we can find out how stable the system is from the cloud end: monitor MQTT connection from a workflow.
Brent Crawford has designed a workflow to alert the owner when a device has been offline for more than 10 minutes.
While it's useful for a device deployed in the field, it's unnecessary for me to receive alerts because my device is right across the room and I can just glance at an LED that indicates its connectivity.
I'm more interested in the history of device uptime.
Losant is a simple and powerful IoT cloud platform.
The platform provides a MQTT broker that sensor devices can connect to and report state in real time; the reported states are stored in the cloud, and can be visualized in several formats.
Recently, Losant sent me a Builder Kit which contains an ESP8266 WiFi chip on Adafruit Feather Huzzah, a TMP36 temperature sensor, and some other components.
Following the official instructions, 1.5 hours later, my room temperature shows up on a webpage.
I'm excited, and I decide to leave it running continuously so that I can monitor the activities of @TheTucsonHeat.
However, Losant platform shows the device as "offline" from time to time, and sometimes it never comes back online unless I press the hard-reset button.
This is mostly because of the bad WiFi in my apartment: 1000ms huge delay, 10% or more packet loss, etc.
Since MQTT is based on TCP, it's severely affected.
To make things worse, our WiFi connects to the Internet through two levels of Network Address Translation (NAT) gateways; it seems that the ESP8266 sometimes is unable to detect the TCP connection to Losant broker is broken, and thus does not take recovery actions.
As a computer networking student, the first thing coming through my mind is the end-to-end principle: the reliability of an application should be ensured by the end hosts, not by the network.
To test whether my temperature sensor remains connected to Losant, I should send a message to the Losant platform, and let the platform send back a reply.
And that's the idea of LosantPingPong: an end-to-end connectivity test between a connected device and the Losant platform.