Ocelot

Не начинайте с Arduino - это не имеет с программированием микроконтроллеров ничего общего. По хорошему начать стоит с внутреннего устройства микроконтроллера. Лучший, но не очень дешевый вариант - микроконтроллер AVR (по сути та же Arduino, но без Arduino IDE) с отладчиком. Так Вы и остановить выполнение программы сможете и поглядеть где какие данные в регистрах, и даже какие сигналы на портах ввода/вывода. По AVR очень много информации как на английском, так и на русском.
Если хочется совсем почти ничего не затратить - тогда STM8 с отладчиком ST-LINK. Информации по ним меньше, зато дешевле чем AVR.
Паяльник нужен будет лишь изредка. Для начала все можно собирать на беспаечной макетной плате.

Как по мне, так чем с большими языками получится познакомиться, тем лучше. Это просто расширяет кругозор. В любом случае когда(если) в будущем станете профессиональным программистом на каком-то определенном языке, то вас не будет пугать код на другом языке.

vi/vim позволяют перемещаться по тексту кучей различных способов, кроме стрелочек.
Да и вместо стрелочек можно использовать hjkl

не ЯП. это файл конфига какой-то сборочной системы для С++
уж не make ли (*.mk)

В строке:
printf("%s", hash);
спецификатор шаблона %s обозначает строку, а строка в Си это "char *", а вы передаете ему в параметре простой char. Поменяйте спецификатор шаблона на %c.
И учите матчасть! www.cplusplus.com/reference/cstdio/printf/?kw=printf

Ну, вроде как, COM - последовательный порт. Это значит, что данные просто бегут по нему. Например, там скопилось 22, пока вы пытались его прочитать, пришло 22, а бывает, что прочитали быстро и успела дойти только одна цифра. Поэтому надо после отправки числа отправлять какой-то разделитель, чтобы потом понимать, где заканчивается предыдущий ответ и начинается новый.

Но если передаете только температуру, то я бы советовал использовать Serial.write(25). Он передаст один байт со значением 25 (0b00011001). В nodejs надо будет его просто распарсить.
Иначе же он приведет число к строке (2 байта: "2" и "5") и будет посылать их раздельно.

всё правильно говорится, с некоторыми оговорками. основные минусы
1) говнокод. если использовать родное приложение, прошивка получается крайне кривой. отсюда лезет убогость работы по скорости, убогость работы библиотек (совместная работа нескольких), убогость вырастающего на этом кале "программиста", убогость по работе устройства в целом.
2) отрешённость от железа, искажение представлений о его работе. крайне плохой инструмент для начала изучения контроллеров. самый бородатый и эпичный пример киселя в головах "программистов" - 99% уверены что у всех моделей ардуин (соответственно у их "центральных" чипов) есть аналоговые выходы.
3) отсутствие развития в изучении и стимула для самостоятельной работы, отупление пользователя в целом. digitalPin high работает равнозначно на uno- и на due-, тогда как первое это древняя atmega а второе это контроллер с ядром cortex-m3 и с кратким даташитом на 1500 страниц. купить камаз чтобы засыпать своему коту лоток.
4) очень странно, но наличие коммьюнити. просто из статистики имеется достаточное количество адекватных инженеров-пользователей этой платформы. также достаточно количество тех же инженеров не-пользователей, но работающих с этим железом за деньги. условно пару процентов пользователей производят скорее всего 100% всех модулей и/или библиотек + китайская штамповка ---> см п.3 но уже не касаемо железа, а всей платформы в целом. зачем что-то учить и изобретать если можно купить 3 готовых модуля, инклуд 3 библиотеки и "устройство" готово.
5) говнокачество. форм фактор андрунно не предполагает использование, отличное от настольного. в готовое устройство - не засунуть. в прототип который будет "надёжным" в эксплуатации - не засунуть. каких-либо кастомных схем не собрать - pls-pbs разъёмы при постоянном использовании разбалтываются и при большой схеме на бредборде можно часами шевелить провода ища плохой контакт. всё это можно помножить на хламовые компоненты из чины (кто у нас покупает оригиналы по 20 евро?)
6) искажение "имиджа" профессии. любой аутист соберёт вайфай замок с эзернет шилдом и блютус чайником за 13 минут, при том, что изготовление "взрослой" электроники займёт неделю или месяц. при этом в популистских статьях полученные результаты подаются как сопоставимые. т.е. дядя учился и работал 10 лет чтобы проектировать правильно и хорошо а школьник собрал аналог пока сидел на унитазе. при этом сравнить качество/функции/надёжность/технологичность забывают, и у дяди подпекает.
основной источник наездов это п.1, п.2, п.6.

в целом это интересная поделка для хобби и быстрого прототипирования. очень полезна во многих ситуациях.
также можно (нужно) посмотреть на отношение к этому у более развитых коллег из западных стран - там это преподносится именно как конструктор для хобби, никаких "инженеров" из этого кала не вырастает.
ещё достаточно показательный пример - сравнительно часто в проектах по фрилансу (на западе) встречаются задания вида "я сделал прототип и он работает. хочу перенести в реальное железо". это очень правильный подход.

Подойдёт?

Если реле для переменного тока, то фаза и ноль не принципиальны. Т.к. относительно ноля напряжение уходит и в плюс и в минус. Просто цепляете переменку, ничего от этого не умрет.
А вот то, что советуют поставить мост... если там тиристоры/симисторы внутри, то оно может потерять способность закрываться без перехода через 0.

Не понял кусок

два для постоянного (ноль и фаза)

Это вообще что было? На постоянке есть + и -. (Похоже речь ведь об управляющих контактах реле?)

Им не нужно попадать в "такт".
Частота обработки сигнала выше, чем частота передаваемого сигнала, так что приемнику не надо быть синхронизированным с передатчиком, достаточно поймать начало передачи, не обязательно с точностью до наносекунд. (тот же I2C на 400кГц, а МК ваш на 8МГц, он за время передачи одного бита еще что-нибудь успеет сделать)

+сейчас интерфейсы реализованные на периферии МК могут работать независимо от ядра, порой со своим тактированием и своими буферами для приема и передачи данных, вам останется только проверять или загружать эти буферы, а периферия сама будет отправлять-принимать данные (например USB который от 48МГц фигачит, в то время, как сам МК от 12МГц тактируется, аппаратный UART)

Вот очень хороший тутор по данной теме. Т.к. судя по посту вы и OpenGL не знаете.

Но вообще, без знания и опыта работы с нормальными 3D движками, браться за написание своего - это как собирать свой компьютер (покупать smd компоненты, плату, травить ее, паять все это дело и т.д.), муторно и абсолютно бестолково.

P.S. возьмите С++ и SFML и попробуйте накидай свой 2D движок. Это в разы проще и опыт какой-никакой появится. А перед тем как писать непосредственно 3D-движок, посмотрите что такое Unity и с чем его едят. На гитхабе есть самописные 3D движки, их код не мешало бы вам тоже посмотреть. А потом только браться за свой.