I decided to add a 5th camera to the live stream of my plants (not) growing. This new camera captures the outdoor sky/clouds, and serves as a natural reference to what time of day is it, since I do not overlay any date or time indication in the sources. As I write, it is dark outside – not the best timing :).
In the past, instead of a live stream, my option was to build time-lapse videos. To assist in the process, I coded solutions that build automatic time-lapse videos from images datasets, with configurable quality. When using these tools, I usually build 24 hours videos, but I could request the output of a larger or shorter time span – for example, I have enough material to construct months-long files. The key reason why I have not been doing so, is that I have moved much of the raw data to the cloud, which is not as instantaneously readable, as local physical volumes. When I started playing with these media and doing these easy, fun, observations, one key reward was being able to promptly unveil whatever had happened in the past x hours.
I will adapt my solutions to the new cloud storage and automate the process again. Until then, the live stream should be available with some regularity.
It is live from my place, but it is all fully automatic. I am not monitoring the Twitch room and feedback, if any. It is an experiment, to check how reliable the stream can be, and what kind of interactions it can ignite on self-motivated spectators.
Four of the vases – the ones on upper-right corner of the video stream – are trying to grow Chili seeds, since yesterday. I read that it is hard to do it, with temperatures below 30. The temperature in the room where the plants are, is below that, so there is a high chance of failure. It is very probable that nothing will happen for many days.
The plants are on artificial light for ~8 hours/day. The rest of the time, they live with whatever ambient light the room gets, which can be very irregular. When the room gets dark enough, the plants will remain visible with infrared lighting.
In an effort to have something on camera, due to the difficulty in growing Chili, I have also planted Dill and Mint.
Today, my Twitch login process was one of the most ridiculous web interactions ever! As usual, Twitch sees every new browser session (cookies cleaned, no memory of the previous visited sites) as a “new device” and forces the user to provide a 6-digit code, to complement the user-password challenge. Unfortunately, those 6-digits came via email, and sloooowly, with a latency of minutes between the code request and the arrival of the corresponding email message. Maybe due to this latency, every time I entered the correct code, Twitch reacted as if I was writing the wrong number. Very frustrating.
At some stage, I finally succeeded and took the opportunity to change my Twitch security settings:
I decided to enable two-factor authentication (2FA), which means a second authentication challenge, after the user-password. First, I provided a phone-number, which indeed got associated with the account, but future logins will require not a SMS sent to the phone number, but a code generated by the “Authy” app, Twillio’s (twillio.com) equivalent to “Google Authenticator”.
When I first started using 2FA, SMS seemed the best option: I controlled the number, it required no extra app, so it was simpler, and that was – and is – something of great importance!
Unfortunately, as many are bound to find, sooner rather than later, SMS is now considerably insecure and more prone to failure than using time-sensitive security apps. The top reason SMS has failed me in the past, was phone-network operator restrictions, temporary phone-network traffic issues, and/or other reasons strictly under the phone-network operator control: there were situations when I needed a SMS in 30 seconds, and it would never arrive that promptly. That was the day when I quit SMS for app-based 2FA. The data comes from an operator agnostic network – the Internet.
Nowadays, SMS should be a second choice, relatively to Authy and equivalents, not only because of not depending on one specific phone-operator network, but also because the system is more vulnerable, with increasingly more documented SIM-card hijacking events.