RSS блога
Подписка
Простой беспроводной метеодатчик на Attiny13
Продолжая тему нетипичных вариантов применения микроконтроллеров серии Attiny, хочу поделиться дешевым и простым способом изготовления беспроводного датчика температуры и влажности для самодельной погодной станции.
Все они отличаются точностью и диапазонами измерения, но имеют общий протокол для обмена информацией с микроконтроллером:
Для работы с этими датчиками я состряпал простую и «ленивую» мини библиотеку, которая позволяет читать данные из DHT11 и DHT22 (AM2320):
Она не использует никакие прерывания, все взаимодействие происходит через простой bit-banging без какого-либо контроля корректности интервалов. Тем не менее код работает практически на любых МК, не завелось только на Attiny13 с частотой 600КГц — скорее всего причина в высоких накладных расходах. Собственно, сами методы получения данных с датчиков:
Передаем номер пина, к которому подключен датчик, и указатели на переменные, куда записывать результат. В случае успешного получения данных методы возвращают 1, в случае ошибки — 0. Параметр TDHT_READ_ATTEMPTS задает количество попыток чтения данных и должен быть не меньше 2, так как многие клоны датчиков выдают при первом чтении мусорные данные, и поэтому результат первого чтения отбрасывается.
Общая схема метеодатчика:
Обратите внимание, что контакты VCC у передатчика и датчика подключены не к VCC микроконтроллера, а к пинам — в целях экономии энергии они будут включаться самим микроконтроллером только в нужный момент времени. Для передачи данных, конечно же, будем использовать мою библиотеку TinyRF.
Attiny13, как и многие другие микроконтроллеры, имеет встроенные подтягивающие (pull-up) резисторы, но я столкнулся с тем, что на некоторых экземплярах МК они недостаточно «сильные» для корректной работы с датчиком, поэтому мне пришлось усилить подтяжку с помощью резистора на 10 кОм, включив его между PB0 и PB1 (VCC и DATA датчика).
Со включенной оптимизацией -Os код компилируется в 780 байт, чего достаточно для заливки в t13, и даже остается еще место для добавления каких-нибудь дополнительных фич (например, чтения уровня батарейки и отправки отдельными посылками). Фьюзы для прошивки следующие: -Ulfuse:w:0x62:m -Uhfuse:w:0xDF:m
В коде наибольший интерес представляют константы SENSOR_ID и SLEEP_MULTIPLIER, первая задает идентификатор метеодатчика (должен быть уникальным), вторая позволяет настроить период пробуждения для чтения и отправки данных.
Общий алгоритм работы следующий:
Благодаря программному управлению питанием датчика и передатчика в режиме сна через них нет никакой утечки тока. В режиме сна схема потребляет всего 7 мкА при питании от 5В, при чтении данных датчика — 0.9 — 3 мА, при передаче — около 10 мА. При периодах обновления, исчисляемых десятками минут, среднее энергопотребление близится к минимально возможному, поэтому такой датчик может очень долгое время (недели и месяцы) работать от литиевого аккумулятора даже небольшой емкости. Микроконтроллер и передатчик могут работать даже от одной 3-вольтовой батарейки CR2032, но вот DHT исключает такой вариант питания, потому что требует на вход минимум 3.3В. От 2xCR2023 питаться также не выйдет — выдаваемые ими 6 вольт выходят за рамки допустимых 5.5В как датчика, так и микроконтроллера, поэтому из батарейных вариантов питания здесь мне видятся только 3 элемента по 1.5В.
Открываем консоль, включаем метеодатчики, и если все было выполнено верно — наблюдаем вывод получаемых данных:
Так как передатчики никак не взаимодействуют между собой, то друг про друга они ничего не знают, поэтому их посылки могут периодически накладываться друг на друга. На практике это проявляется во временном увеличении интервала между получением данных с разных датчиков и для простых сценариев использования не сильно критично.
Областей применения для самодельного метеодатчика можно придумать множество. Единственное, что меня смущает и вызывает вопросы, — его работоспособность при сильно отрицательных температурах. Микроконтроллеры ATtiny имеют не самый стабильный внутренний генератор, который в неблагоприятных условиях может «поплыть» еще сильнее вплоть до невозможности взаимодействия с датчиком или возникновения некорректных таймингов при отправке данных по радио. Попытка заморозки работающего датчика в морозилке до -10ºC показала, что с таким небольшим минусом проблем в его работе не возникает, как будут обстоять дела с более низкими температурами — я думаю надвигающаяся зима покажет.
Измерение температуры
Atiny13/13A не имеет встроенного датчика температуры, поэтому необходимо использовать внешний. В самоделках в качестве датчиков наиболее часто используются простые и цифровые сенсоры температуры и влажности серии DHT11, DHT22 и их многочисленные китайские клоны (в моем случае — AM2320):Все они отличаются точностью и диапазонами измерения, но имеют общий протокол для обмена информацией с микроконтроллером:
Для работы с этими датчиками я состряпал простую и «ленивую» мини библиотеку, которая позволяет читать данные из DHT11 и DHT22 (AM2320):
TinyDHT.h
#ifndef _TINYDHT_H_
#define _TINYDHT_H_
#include <avr/io.h>
#include <util/delay.h>
#ifndef TDHT_DDR_REG
#define TDHT_DDR_REG DDRB
#endif
#ifndef TDHT_PORT_REG
#define TDHT_PORT_REG PORTB
#endif
#ifndef TDHT_PIN_REG
#define TDHT_PIN_REG PINB
#endif
#ifndef TDHT_ONE_DELAY_US
#define TDHT_ONE_DELAY_US 30
#endif
#ifndef TDHT_READ_ATTEMPTS
#define TDHT_READ_ATTEMPTS 2
#endif
#define _tdhtPinLow(pin) TDHT_PORT_REG &= ~(1 << pin)
#define _tdhtPinHigh(pin) TDHT_PORT_REG |= (1 << pin)
#define _tdhtPinToOut(pin) TDHT_DDR_REG |= (1 << pin)
#define _tdhtPinToIn(pin) TDHT_DDR_REG &= ~(1 << pin)
#define _tdhtGetPinValue(pin) (TDHT_PIN_REG & (1 << pin))
static inline void _tdhtPinChangeWait(uint8_t pin, uint8_t currentState) {
uint8_t counter = 0;
while ((!_tdhtGetPinValue(pin)) != currentState && ++counter < 255) {
_delay_us(1);
}
}
static inline uint8_t _tdhtReadRawData(uint8_t pin, uint16_t sensorDelay, uint8_t *raw_data_buffer) {
_delay_ms(sensorDelay);
_tdhtPinToOut(pin);
_tdhtPinLow(pin);
_delay_ms(20);
_tdhtPinToIn(pin);
_tdhtPinHigh(pin);
_tdhtPinChangeWait(pin, 1);
_tdhtPinChangeWait(pin, 0);
_tdhtPinChangeWait(pin, 1);
for (uint8_t i = 0; i < 5; i++) {
for (uint8_t j = 0; j < 8; j++) {
_tdhtPinChangeWait(pin, 0);
raw_data_buffer[i] <<= 1;
_delay_us(TDHT_ONE_DELAY_US);
if (_tdhtGetPinValue(pin)) {
raw_data_buffer[i] |= 1;
_tdhtPinChangeWait(pin, 1);
}
}
}
return (raw_data_buffer[4] == (uint8_t) (raw_data_buffer[0] + raw_data_buffer[1] + raw_data_buffer[2] + raw_data_buffer[3]));
}
static inline uint8_t tdhtReadDataDHT11(uint8_t pin, int16_t *temperature, uint16_t *humidity) {
uint8_t raw_data[5] = {0, 0, 0, 0, 0};
for (uint8_t i = 0; i < TDHT_READ_ATTEMPTS; i++) {
if (_tdhtReadRawData(pin, 1500, raw_data)) {
*temperature = (uint16_t) raw_data[2] * 10;
*humidity = (uint16_t) raw_data[0] * 10;
if (i > 0) return 1;
}
}
return 0;
}
static inline uint8_t tdhtReadDataDHT22(uint8_t pin, int16_t *temperature, uint16_t *humidity) {
uint8_t raw_data[5] = {0, 0, 0, 0, 0};
for (uint8_t i = 0; i < TDHT_READ_ATTEMPTS; i++) {
if (_tdhtReadRawData(pin, 2000, raw_data)) {
*temperature = ((uint16_t) raw_data[2] << 8) | raw_data[3];
*humidity = ((uint16_t) raw_data[0] << 8) | raw_data[1];
if (i > 0) return 1;
}
}
return 0;
}
#endif /* _TINYDHT_H_ */
Она не использует никакие прерывания, все взаимодействие происходит через простой bit-banging без какого-либо контроля корректности интервалов. Тем не менее код работает практически на любых МК, не завелось только на Attiny13 с частотой 600КГц — скорее всего причина в высоких накладных расходах. Собственно, сами методы получения данных с датчиков:
uint8_t tdhtReadDataDHT11(uint8_t pin, int16_t *temperature, uint16_t *humidity);
uint8_t tdhtReadDataDHT22(uint8_t pin, int16_t *temperature, uint16_t *humidity);
Передаем номер пина, к которому подключен датчик, и указатели на переменные, куда записывать результат. В случае успешного получения данных методы возвращают 1, в случае ошибки — 0. Параметр TDHT_READ_ATTEMPTS задает количество попыток чтения данных и должен быть не меньше 2, так как многие клоны датчиков выдают при первом чтении мусорные данные, и поэтому результат первого чтения отбрасывается.
Упаковка данных
Для передачи по воздуху данные датчика нужно предварительно и как можно более компактно упаковать в байты. Чем меньше пакет — тем больше вероятность его успешной доставки и меньше затраты энергии на передачу. Кроме того, пакеты длиной не более 32 бит (4 байта) можно принимать практически чем угодно с помощью библиотеки RCSwitch. В общем случае температура с датчиков DHT может принимать значения от -40°C до 80°C, влажность — от 0% до 100%. В итоге я решил использовать следующую структуру 32-битного пакета:- 3 бита — ID метеодатчика (значения от 0 до 7, позволяет адресовать до 8 устройств)
- 1 бит — знак температуры (0 — положительная, 1 — отрицательная)
- 10 бит — температура
- 10 бит — влажность
- 8 бит — контрольная сумма всех предыдущих значений, обрезанная до 8 бит
Собираем воедино
Для сборки метеодатчика нам понадобятся буквально несколько деталей:- Сам микроконтроллер ATiny13
- Датчик DHT11, DHT22 или AM2320 — выбираем в зависимости от требуемой точности и диапазона значений
- Передатчик FS1000A или любой другой идентичный на 433.92 МГц. Можно в паре с приёмником, он нам тоже ещё пригодится
- Конденсатор от 0.1 до 1 мкФ
- Опционально — резистор на 10 кОм. В общем случае не нужен, но я столкнулся с недостаточностью встроенной подтяжки пина на некоторых экземплярах микроконтроллера
Общая схема метеодатчика:
Обратите внимание, что контакты VCC у передатчика и датчика подключены не к VCC микроконтроллера, а к пинам — в целях экономии энергии они будут включаться самим микроконтроллером только в нужный момент времени. Для передачи данных, конечно же, будем использовать мою библиотеку TinyRF.
Attiny13, как и многие другие микроконтроллеры, имеет встроенные подтягивающие (pull-up) резисторы, но я столкнулся с тем, что на некоторых экземплярах МК они недостаточно «сильные» для корректной работы с датчиком, поэтому мне пришлось усилить подтяжку с помощью резистора на 10 кОм, включив его между PB0 и PB1 (VCC и DATA датчика).
Исходный код программы
/*
* WeatherSensor.cpp
*
* Created: 14.09.2021 15:13:19
* Author : SinuX
*/
#define F_CPU 1200000UL // 1.2 MHz
#define TRF_TX_PIN PB4 // Передатчик на 4 пине
#define TRF_DATA_SIZE 4 // Размер посылки 4 байта
#define TRF_RX_DISABLED // Исключаем приемную часть TinyRF для экономии места
#define DHT22 // Тип датчика: DHT22/AM2320
#define DHT_PIN PB0 // Датчик на 0 пине
// Контакты VCC датчика и передатчика
#define TX_VCC_PIN PB3
#define DHT_VCC_PIN PB1
// Множитель циклов сна (значения от 1 до 255) позволяет настраивать интервал отправки данных от 8 секунд до 34 минут
#define SLEEP_MULTIPLIER 5 // Просыпаемся и отправляем инфу раз в 5 * 8 = 40 секунд
#define SENSOR_ID 0 // ID метеодатчика (значения от 0 до 7)
#include "tinydht.h"
#include "tinyrf.h"
#include <stdlib.h>
#include <avr/sleep.h>
#include <avr/wdt.h>
typedef union {
struct {
uint8_t sensorId : 3;
uint8_t temperatureSign : 1;
uint16_t temperature : 10;
uint16_t humidity : 10;
uint8_t checksum : 8;
};
uint8_t dataBytes[4];
uint32_t data;
} TxData;
uint8_t volatile wakeupCounter = 0;
void sendData(int16_t temperature, uint16_t humidity) {
TxData txData;
txData.data = 0;
txData.sensorId = SENSOR_ID;
txData.temperatureSign = temperature < 0 ? 1 : 0;
txData.temperature = abs(temperature);
txData.humidity = humidity;
txData.checksum = txData.sensorId + txData.temperatureSign + txData.temperature + txData.humidity;
// Включаем передатчик и отправляем данные
trf_init();
PORTB |= (1 << TX_VCC_PIN);
trf_send(txData.dataBytes);
}
ISR (WDT_vect) {
// Если не настало время отправки - погружаемся обратно в сон
if (++wakeupCounter < SLEEP_MULTIPLIER) {
return;
}
wakeupCounter = 0;
// Временно отключаем ватчдог, чтобы он не сбросил МК в процессе получения значений
wdt_disable();
// Включаем датчик и пытаемся получить данные
PORTB |= (1 << DHT_VCC_PIN);
int16_t temperature = 0;
uint16_t humidity = 0;
uint8_t readResult = 0;
// DHT11
#ifdef DHT11
readResult = tdhtReadDataDHT11(DHT_PIN, &temperature, &humidity);
#endif
// DHT22
#ifdef DHT22
readResult = tdhtReadDataDHT22(DHT_PIN, &temperature, &humidity);
#endif
// Отключаем датчик и отправляем инфу
PORTB &= ~(1 << DHT_VCC_PIN);
if (readResult) {
sendData(temperature, humidity);
}
}
int main(void) {
DDRB |= (1 << TX_VCC_PIN);
DDRB |= (1 << DHT_VCC_PIN);
wdt_reset();
sei();
set_sleep_mode(SLEEP_MODE_PWR_DOWN);
while(1) {
// Отключаем пины, заводим "будильник" на 8 секунд и выключаемся
PORTB = 0;
wdt_enable(WDTO_8S);
WDTCR |= (1 << WDTIE);
sleep_enable();
sleep_cpu();
}
}
Со включенной оптимизацией -Os код компилируется в 780 байт, чего достаточно для заливки в t13, и даже остается еще место для добавления каких-нибудь дополнительных фич (например, чтения уровня батарейки и отправки отдельными посылками). Фьюзы для прошивки следующие: -Ulfuse:w:0x62:m -Uhfuse:w:0xDF:m
В коде наибольший интерес представляют константы SENSOR_ID и SLEEP_MULTIPLIER, первая задает идентификатор метеодатчика (должен быть уникальным), вторая позволяет настроить период пробуждения для чтения и отправки данных.
Общий алгоритм работы следующий:
- МК находится в выключенном состоянии и просыпается каждые 8 * SLEEP_MULTIPLIER секунд по прерыванию WDT
- Подает питание на датчик и с задержкой (1.5 сек для DHT11, 2 сек для DHT22) делает 2 попытки чтения данных
- Отключает питание датчика и, если данные были успешно прочитаны, включает передатчик и отправляет данные
- Снова уходит в отключку
Благодаря программному управлению питанием датчика и передатчика в режиме сна через них нет никакой утечки тока. В режиме сна схема потребляет всего 7 мкА при питании от 5В, при чтении данных датчика — 0.9 — 3 мА, при передаче — около 10 мА. При периодах обновления, исчисляемых десятками минут, среднее энергопотребление близится к минимально возможному, поэтому такой датчик может очень долгое время (недели и месяцы) работать от литиевого аккумулятора даже небольшой емкости. Микроконтроллер и передатчик могут работать даже от одной 3-вольтовой батарейки CR2032, но вот DHT исключает такой вариант питания, потому что требует на вход минимум 3.3В. От 2xCR2023 питаться также не выйдет — выдаваемые ими 6 вольт выходят за рамки допустимых 5.5В как датчика, так и микроконтроллера, поэтому из батарейных вариантов питания здесь мне видятся только 3 элемента по 1.5В.
Приемная часть
Так как посылка имеет длину 32 бита, то ее можно принять с помощью любой ардуины с библиотекой RCSwitch. Берем любой приемник на 433.92 МГц, подключаем его к Arduino и заливаем скетч (не забыв поправить номер пина данных в соответствии со своей моделью платы):Скетч приемника для Arduino Nano
#include <RCSwitch.h>
RCSwitch mySwitch = RCSwitch();
unsigned long lastValue;
union {
struct {
uint8_t sensorId : 3;
uint8_t temperatureSign : 1;
uint16_t temperature : 10;
uint16_t humidity : 10;
uint8_t checksum : 8;
};
byte dataBytes[4];
} RxData;
void setup() {
Serial.begin(9600);
mySwitch.enableReceive(0); // Receiver on interrupt 0 => that is pin #2
}
void loop() {
if (mySwitch.available()) {
unsigned long value = mySwitch.getReceivedValue();
// Получена новая посылка, отличная от предыдущей
if (lastValue != value) {
lastValue = value;
// Переворачиваем байты посылки
for (int8_t i = 3; i >= 0; i--) {
RxData.dataBytes[i] = (byte) value;
value >>= 8;
}
// Выводим на экран, если контрольная сумма верна
if (RxData.checksum == (byte)(RxData.sensorId + RxData.temperatureSign + RxData.temperature + RxData.humidity)) {
Serial.print("Sensor: ");
Serial.print(RxData.sensorId);
Serial.print(", Temp: ");
Serial.print(RxData.temperatureSign ? "-" : "");
Serial.print(RxData.temperature / 10);
Serial.print(".");
Serial.print(RxData.temperature % 10);
Serial.print("ºC, Humid: ");
Serial.print(RxData.humidity / 10);
Serial.print(".");
Serial.print(RxData.humidity % 10);
Serial.println("%");
}
}
mySwitch.resetAvailable();
}
}
Открываем консоль, включаем метеодатчики, и если все было выполнено верно — наблюдаем вывод получаемых данных:
Так как передатчики никак не взаимодействуют между собой, то друг про друга они ничего не знают, поэтому их посылки могут периодически накладываться друг на друга. На практике это проявляется во временном увеличении интервала между получением данных с разных датчиков и для простых сценариев использования не сильно критично.
Областей применения для самодельного метеодатчика можно придумать множество. Единственное, что меня смущает и вызывает вопросы, — его работоспособность при сильно отрицательных температурах. Микроконтроллеры ATtiny имеют не самый стабильный внутренний генератор, который в неблагоприятных условиях может «поплыть» еще сильнее вплоть до невозможности взаимодействия с датчиком или возникновения некорректных таймингов при отправке данных по радио. Попытка заморозки работающего датчика в морозилке до -10ºC показала, что с таким небольшим минусом проблем в его работе не возникает, как будут обстоять дела с более низкими температурами — я думаю надвигающаяся зима покажет.
Самые обсуждаемые обзоры
+58 |
3600
113
|
+139 |
2540
66
|
вопрос. вы этот датчик в морозилке пробовали? почему спрашиваю. когда-то давно пытался делать клон передатчика для станции AcuRite на Attiny. пришлось отказаться. частота внутреннего генератора (кварца то нет) сильно уходила от температуры и все delay() улетали.
ну и датчик полная шляпа — по T еще ничего, RH показывает погоду на марсе.
Аммиачная селитра теперь стоит дохрена, соль все же дешевле.
Вот BME280 да, для его обслуживания и tiny24 только-только…
ps: я лично голосую за стмку.
В итоге выкинул их все и переделал на Si7021 (тоже с Али). Этот уже года два-три работает более менее исправно. Хотя, кажется, что тоже немного занижает реальную влажность, т.к. в первый год эксплуатации летом я на нем видел и более 80%, а после этого больше 70 — 72 % не видел (каких-либо измерений не проводил).
Вот это простой датчик — а у вас еще паять нужно :) Но за статью плюс однозначно! Еще бы организовать вывод данных в Home Assistant для наглядности.
Бустер из чего-то типа BL853x и от одной банки? У TI вообще есть роскошные изделия с током в единицы uA без нагрузки, но китайчатина доступнее и дешевле.
велосипедыардуины со светодиодомметеодатчика с радиоканалом?На полном комплекте антиквариата attiny + 433МГц с китайским антикварным ощущометром DHT11?
Но. Зачем?
Да, ежели запитываете датчик от ноги контроллера, дайте ему хотя бы чуть-чуть в себя придти прежде чем данные считывать. Секунду-другую хотя бы.
Это есть
Я тут просто прямо сейчас на evaluation board c CC2652RB светодиодиком моргаю (в нерабочее время чисто экспериментов ради), так что просто разрыв технологий резанул ))
А тексас — он всё-таки тексас.
К тому же primary target как раз зигбя, а не BT.
Есть идея сейчас замутить pet project на абсолютно пустой нише — хочу сделать полноценный жирный беспроводной (да и проводной) хаб с поддержкой нескольких каналов zigbee, ble, z-wave и чего ещё в голову придёт, с гигабитным poe и может быть проводными 485 и KNX.
И чтоб у него нормальная поддержка сценариев, API с user management, веб-морда, приложения под ондроед/иось и поддержка всяких алекс/гуглов/эппл хоумов.
Набрал на маузере всяких eval китов, сейчас сижу играюсь.
Наверное типа, только лучше ))
Сам ни разу еще не ковырял их железяки, но по отзывам говорят что очень приятно их контроллеры конфигурируются
Во-первых у ребят сайт не очень часто обновляется, как можно заметить, но это ладно ))
Но.
Из беспроводных только BT4.
А с проводными большой вопрос с лицензированием интерфейсов, которые они используют — тот же KNX, они не члены ассоциации, а это ни разу не открытый стандарт. То есть для дома для семьи конечно играйся сколько хочешь, но вот продавать, указывая на сайте и в документации поддержку интерфейса — это ой.
Еще есть wirenboard- но его все пилят и пилят, а конца не видно:)) Хотя уже куча поколений вышло. Но там knx уже точно не лицензирован- т.е в плане софта можно скриптами дергать шину, но в плане поддержки етс-ки фиг вам понятное дело.
А с wiren я вообще удивлён что они живы — давно ничего не слышал.
По поводу моей задумки — у меня основная цель zigbee. Причём много каналов, чтобы без лимита устройств и без лагов.
cs-cs.net/news-spring-2021-afdd-inrush-smi-plc-sh-wiren
Zigbee, понятно. Я вот до сих пор не особо признаю решения на радио. Но это у меня горький осадок остался от нескольких проектах сделанных целиком на z-wave.
Ну живы — молодцы конечно. Но с другой стороны если за такое время не смогли найти инвестиции на нормальную достаточную команду разработчиков и интеграторов, или не смогли кому-нибудь крупному продаться, то по-хорошему надо проект в open source переводить. Не нравится что-то, мил человек? Пили pull request самостоятельно, будь любезен. Или issue создай хотя бы, и посмотри, все ли согласны с твоей идеей.
Зигбя — очень доволен. Раньше тоже скептически относился, но вот уже полтора года на практике — претензий нет. Лампочками забил уже почти два филипсовских хаба (у них лимит в 50 устройств). Идеально работают сами филипсы, ikea tradfri и на удивление лидловские
silver crestLivarnoLux. Но избавился ото всех innr (кому нужен ящик лампочек — отдам даром, самовывоз). Очень глюкавая прошивка, постоянно теряли свои команды и иногда чужие, ломая сеть. Как убрал все эти — идеально всё работает.Но это лечится, спишусь как будет время.
И зашёл почитать т-ща электрошамана (не встречал раньше) и реально залип. Чувак — король щиткового оверкилла)))
Ну и да, домашняя автоматизация на PLC в нашем веке — убейте меня кто-нибудь. Всему своё место.
Шаман, да, псих в хорошем плане, в плане электрики:))) Хотя, по оверкиллу, мне приходилось и покрупнее шкафы видеть, чем собирает Шаман:))) Но он то занимается шкафами для квартир и домов, а не для промки, так что да, пожалуй у него оверкилл по шкафчикам))) У меня на бывшей работе щитки, с количеством автоматов больше 5 штук почти всегда были размерами с 19 дюймовый шкаф на 42 юнита, а то и крупнее. Ну и сами шкафы обычно либо риттал, либо хорошие копии риттала:))) Про шкафы, куда с полей приходят сотни сигналов я вообще промолчу.
По плк в домашней автоматизации- ну пока knx будет дороже решения на плк, то проще плк и пучок кабелей прокинуть, чем на knx делать. Тем более те же силовые модули для knx все-равно обычно на дин рейку идут:))) Так что для тех же квартир и домов не сильная экономия по кабелям выходит.
Ну да, такие огромные шкафы на крохотные квартирки (да и даже на домики в 200 метров — тоже ничего такого) — это маньячество, конечно. Плюс не видно особых плюсов от их использования, выигрыша ни в комфорте ни в безопасности на таких масштабах они не дают никакого.
KNX лучше в плане распределенности, но я даже не о нём, а о той же зигбе. Задача автоматизации света, со сценариями, таймерами и всем чем угодно, решается на электрическом уровне одним двухамперным автоматом на линию света в комнате, всё. Ну а KNX уже только для кнопочек (опциональных, впрочем). Ну и да, плюс управление термостатами и всякие датчики-приводы, это на проводе, конечно.
В эти выходные торжественно запускаю первый и единственный пока фэнкойл (комната большая, огромная чугуниевая батарея не влезала под окно и стояла криво рядом, решил заменить на современный подход). Наколхозил к Sabiana Carisma родной контроллер для проводного пульта скрещённый с KNX контроллером Legrand, который рулится BTicino'вской панелькой, я таких уже несколько поставил. Посмотрим, как будет работать.
Я просто про щиты того товарища — у него 90% логики на PLC — это про свет. Ну а оставшиеся проценты — какой-нибудь релюшкой отрубать насос или перекрывать трубу или заслонку. Скучно.
Ещё видел управление всякими термостатами по модбасу, но это миллионом способов сделать можно, да и большой вопрос нужно ли вообще (и зачем тут в принципе контроллер, просто как избыточное передаточное звено).
Охххх. До вентиляции я, к сожалению, ещё не дошёл. Соответственно до увлажнения тоже.
В планах на будущий год.
Но у нас спасает то, что воздух и так вполне чистый и климат мягкий, так что мы окна летом вообще всё время открытыми держим, а зимой просто часто открываем. Так что это может потерпеть-подождать. Увлажнители — пока просто ультразвуковые с водой из фильтра обратного осмоса. Да и то только зимой когда минус.
В этом году пока запланировал ремонт в нижнем помещении, где у меня будет полноценная студия (пока временной пользуюсь). Там полуподвал по сути, так что вентиляцию наверное заложу какую-нибудь, каналы. Но про саму установку не уверен.
А ещё в этом году в планах на крышу солнечные батареи поставить на 6-8кВт и систему накопления энергии (типа powerwall или чего-нибудь такого). У нас до конца года ecobonus 50% действует, причём даже на нашу категорию дома (к сожалению ништяки типа бонуса в 110% нам не светят, как владельцам «люксовой» недвижимости по мнению итальянского правительства), так что с такой системой вполне можно будет уложиться тысяч в 10 (где-то 5 получаются панели с инвертором и установкой и столько же павербанка киловатт-часов на 15, а так по прайсу они в два раза дороже выходят, половину компенсирует правительство, причём сразу при оплате, а не вычетами из налогов).
А что по поводу руки не доходят — то тут и говорить нечего. Я даже и не знаю, стоит ли завидовать людям с кучей свободного времени. Сегодня после работы обнаружил что есть немного времени и можно потратить его на хозяйство — пошёл в саду добивать уютное место под ёлочкой: там была рядом старая чугунная распаечная коробка, где полностью в воде шли провода к воротам, плюс жуткий чугунный же встраиваемый светильник что теоретически должен был подсвечивать лестницу (но в реальности просто тупо всех слепил) — коробку отреставрировал, светильник выломал и сейчас цементирую туда новый аккуратный, плюс поставил там красивый фонарный столбик и розетки сделал — можно устроиться с ноутом уютно (как доделаю — сфоткаю). Так вдруг вспомнил, что начал это всё в июне. А уже сентябрь кончается. А работы там на полдня по-хорошему (ну плюс ждать пока цемент схватится). Куда время уходит?
Я вот например пилил себе тумбочку под инструмент. С одной стороны там не сказать что овер дофига времени по идее надо, но по итогу вышло аж 9 месяцев как я ее делал- то некогда было, то условия неподходящие, то еще что-то
Или может какой-то ещё вариант реализации посоветуете.
Микросервисы на кластере kubernetes — наш стартовый минимум. Нюк потянет. Но желательно жидкостное охлаждение.
1. Малая дальность. Даже используя дорогой приёмник, 30 метров сквозь стены уже сложно.
2. Если строить свою метеостанцию, то база получается сильно дороже готовых китайских. Все эти экраны, кнопки, корпуса не дешевые.
3. Если интегрировать в умный дом то как? Либо надо шлюз RF — MQTT делать, либо включать приёмник по USB и писать драйвер.
Вот по таким причинам использую неспортивный, но менее геморройный Sonoff + Tasmota.
Потом захотите что-то расширить, а некуда.
Remark
«1 бит — знак температуры (0 — положительная, 1 — отрицательная)
10 бит — температура»
ой. 11 бит в дополнительном коде.
Да, 5 вольт на передатчик это около 5 метров уверенной связи в условиях ж\б панельки.
А между повторами передачи пакетов вводить псевдослучайную задержку, которая будет достаточно уникальной у каждого МК (например, по его ID). Тогда даже в случае одновременного просыпания двух передатчиков оба пакета будет все же возможно принять.
Для температуры 7 бит «до градуса», 9 «до четверти градуса» — выше точности все равно не будет.
Вот нам и широкий ID, и тип, и флаг «батарейка садится»…
Или да, разделить пакеты по типам.
alexgyver.ru/lessons/naked-chip/
Есть конструктор прошивки homes-smart.ru/index.php/oborudovanie/bez-provodov-433-315mgts/besprovodnoj-datchik-temperatury-i-vlazhnosti-na-baze-radiomodulej-433-315
но он не работает
три в одном же — температура, влажность, давление
SHT31 заметно стабильнее.
Датчик живет один сезон. А потом раз в месяц снимать его на прожарку? Проще отказаться.
Досталась на обмен на какую-то околокомпьютерную железяку…
Проблема-ловит чей-то датчик, и видимо считает его главным, переключает автоматом канал на него.Хотя мой на 1м канале.Но этот чей-то датчик периодически пропадает, и станция висит на его канале(в данном случае 2м).Приходиться перебирать каналы, чтоб увидеть свой…
Можно задействовать сколько-то таких плат.
Вопрос только с адресами.
Насколько помню, в этих платах есть 4 варианта адреса.
А вам на 100 датчиков нужно больше адресов, чем эти 4.
Посмотрите, может там можно больше адресов использовать.
Зачем там 13, я планировал 85, мне нужно два дифференциальных входа и один выход, 85 для этого должно хватить.перепутал с 2313. 85 умеет 1-wire и i2c если приспичит
Дифвходы не нужны, нужна пара аналоговых (раз два датчика), один на запитку опорных резисторов (чтобы меньше жрало), один на ввод (прием опроса), один на вывод (модулятор ответа).
Диффвходы очень нужны для того что я делаю, с термисторов снимается падение напряжения, не спрашивайте зачем, так нада.
The hot wire technique excels at low to medium wind speed, and is the preferred technique for sensing indoor air movement, where the spinning cup anemometers typically seen on weather stations are ineffective. As an experimenters tool, the sensor is exquisitely sensitive, with a small puff of air being sensed at a distance of 18-24″.
Получается 20 устройств.
Для 485го есть двайвера с автопереключением Rx/Tx, тогда у мк заняты всего 2 линии.
И это… у вас есть живая библиотека для 1-wire-slave? Поделитесь?
В чем разница? Представьте себе здание с лифтом. И вверх, и вниз лифт везет вас с одинаковой скоростью — и привозит куда надо с гарантией. Это симметричный драйвер.
Теперь представьте, что вы лезете по стене дома. Вниз вас тянет притяжение Земли (односторонний драйвер), вверх вы ползете по стене самостоятельно. Если стена 1 метр (1 устройство на шине), скорее всего все будет работать нормально, на стену высотой 1 метр вы заберетесь без труда. Но если стена 50 метров (50 устройств на шине), вы точно уверены в своей способности гарантированно за строго оговоренное время залезть на эту 50-метровую стену раз хотя бы по 100 в день?
При десятках, не говоря про сотни, устройств на однопроводной шине у вас будет дичайшая емкость и многократные отражения, и вы ничего не сможете с этим сделать, кроме как радикально снижать скорость. И все равно будете ловить кучу помех, потому что в состоянии «все неактивны» длинная линия — это антенна.
Грубо говоря, когда вы едете в лифте, лифт четко вас везет. Когда вы ползете по отвесной 50 метровой стене вверх, вас может сбить вниз пролетающий мимо кирпич или просто порыв ветра.
bolid.ru/production/orion/ops-subsystems/spi2000a/s2000-vt.html
В принципе 768 р за готовый датчик на sht как по мне не настолько дорого, плюс при таком объеме вполне возможно что и скидка нормальная будет.
1. конденсатор надо ставить у каждого девайся в отдельности, а лучше там два, керамика и электролит, этож самоделка, так сделаем непревзойдённо!
2. питание через мины контроллера, это мовитон, надо полевики.