Conecte de forma inalámbrica varios DS18B20 en una casa

Estoy planeando leer el formulario de datos de temperatura en mi casa usando varios DS18B20 y enviar todos los datos a una raspberry pi. Ya logré interpretar los datos de un sensor conectado directamente al pi, pero tengo problemas para encontrar una manera de conectar varios de ellos de forma inalámbrica.

He investigado productos como este par rx tx , pero no creo que pueda comunicarse de dos maneras y creo que el DS18B20 necesita enviar y recibir. También miré este transceptor , pero parece que usa muchos más puertos de los que quiero, y no estoy seguro de si puede transmitir la única línea de datos que necesito sin todos los otros cables/puertos. . Básicamente (creo) estoy buscando un transceptor que solo comunique el único cable que necesito sin todos los extras (si es que esto existe o es posible). Siento que me estoy perdiendo algo que es muy obvio, pero parece que no puedo entender qué. Aquí está la hoja de datos DS18B20 si ayuda. Gracias de antemano.

Tendrá que negociar el costo del hardware con el tiempo de desarrollo del software. Por ejemplo, un Bluetooth 4 mcu de $ 1.00 hará esto, a costa de cientos de horas de programación y aprendizaje, y diseñando una placa. Yo me inclinaría por comprar 5 Pi Zero W... $10 cada uno y ya sabes programarlos. Arduino y ESP32 están en algún punto intermedio.
Teniendo en cuenta que la ventilación de retorno de aire toma muestras de la temperatura del aire y brinda fácil acceso al cable telefónico, ¿por qué no hacerlo de la manera más fácil a un bus direccionable? Luego haga que un nodo inalámbrico recopile todos los datos para compartir.

Respuestas (5)

Si bien el protocolo de señalización DS18B20 requiere transmisión para consultarlo, no querrá pasar eso a través de un enlace de radio. En su lugar, tendría una MCU local en el nodo que consulta el sensor y luego transmite el resultado de forma unidireccional.

En este punto, es importante tener en cuenta que ya existen sensores de temperatura inalámbricos producidos. Por ejemplo, ambos dispositivos con su propia pantalla LCD que también transmiten una señal OOK en 433 MHz y sondas exteriores sin pantalla para sistemas de interior/exterior. A menudo, la codificación en el aire no está documentada y es propietaria, pero a menudo es fácil aplicar ingeniería inversa y se han publicado varias bases de código para la decodificación. La mayor preocupación puede ser si los nodos tienen números de serie únicos (probablemente, pero quizás no todos los modelos). Las colisiones no son realmente una preocupación allí, siempre que haya suficientes paquetes sin interferencias para obtener una tasa de actualización razonable. Finalmente, al igual que con los proyectos personalizados, la utilización de la vida útil de la batería es algo que puede variar, dependiendo de cuánto esfuerzo se haya puesto en ello.

Si decide hacer algo personalizado, estaría buscando una solución de bajo costo para MCU y transmisor de radio. Los transmisores de 300-433 MHz basados ​​en resonador SAW que vinculaste son una opción, y con un pin para el sensor y otro para la radio, puedes usar algunos de los MCU más pequeños de 6 u 8 pines. Sin embargo, si sigue esta ruta, considere usar un receptor más sofisticado en el pi: TI y SiLabs tienen ofertas que son radios de datos superheterodinos sintonizables "reales" muy superiores a los receptores regenerativos baratos.

Las radios de datos de 2,4 GHz mucho más sofisticadas también pueden ser económicas, pero generalmente requieren un bus SPI completo para controlar, lo que significa más pines MCU. Algunas de las combinaciones BTLE MCU/radio también pueden funcionar en modos patentados más simples, a veces compatibles con los protocolos aéreos heredados como el de nRF24, pero tienden a costar más que una radio y una MCU baratas. En el lado positivo, puede unirlos ya en un submódulo. También hay algunas combinaciones de MCU + radio de gama muy baja fuera de China que se encuentran en cosas como drones de juguete que podrían ser aplicables, si puede obtener la documentación necesaria para trabajar con ellos.

El ESP8266 y el ESP32 generalmente se consideran dispositivos WiFi, pero ofrecen algunos modos apropiados que usan solo la señalización de aire de nivel inferior sin las capas de protocolo más altas, lo que evita el costo de tiempo/energía de asociarse con una red solo para informar una lectura y comenzar de inmediato. de vuelta a dormir.

Finalmente, si bien el esquema de modulación LoRa patentado ahora está recibiendo mucha atención para los informes de sensores de mayor alcance, vale la pena señalar que, a medida que aumenta la popularidad, aumenta la disponibilidad de kits de hardware programables de bajo costo, las radios Semtech pueden operarse hasta cierto punto en OOK o OOK más simples. Modos FSK y hable con otros dispositivos que los implementen. Sin embargo, estos todavía están en la clase de más de $ 20 por nodo, y parece que al menos en el rol de recepción puede que no sea posible activar un silenciador RSSI simple solo, sino que se requiere para satisfacer el detector de preámbulo del paquete o falsificarlo por establecer una longitud mínima y una tolerancia de error máxima.

Tiene razón, su termómetro IC "habla" el bus bidireccional de un solo cable, y eso no es nada que pueda simplemente alimentar a estos transmisores ultrasimplistas (y cuestionablemente legales). Necesitan que se les "pidan" datos, y usted no está haciendo eso de ninguna manera.

Además, estos transmisores simplemente modifican la modulación por desplazamiento de amplitud (ASK) de un oscilador de frecuencia fija en funcionamiento continuo. Eso significa que no puede tener dos de estos transmitiendo al mismo tiempo, porque no hay forma de diferenciar las dos señales.

Además, todos sus sensores son idénticos, por lo que incluso si hizo que funcionara mágicamente y evitara tales colisiones por pura suerte, entonces aún no podría decir cuál de sus sensores estaba informando.

Entonces, no importa lo que haga, necesitará un microcontrolador para comunicarse con su sensor por un lado y comunicarse con algún tipo de hardware de RF por el otro. Idealmente, ese hardware de RF debería ser mucho mejor que estas abominaciones de 433 MHz.

Estos transceptores basados ​​en nRF24L01 que publicaste son mucho mejores, aunque se basan en un chip que el fabricante de circuitos integrados ya marcó como "no recomendado para nuevos sistemas", en realidad pueden hacer mucho más.

Puede obtener un microcontrolador económico (por ejemplo, un arduino o un clon) que se comunique con 1 cable a su sensor y SPI a la placa de RF. Luego, los distribuyes alrededor. Luego, su nodo Arduino central solicita periódicamente datos a cada uno de sus nodos sensores, y luego responde su microcontrolador en el sitio del sensor.

"entonces aún no podía decir cuál de sus sensores estaba informando" Eso es incorrecto, el DS18B20 tiene identificaciones.
sí, pero si nadie les pregunta por eso, tampoco pueden denunciarlo. Supondría que todo bajo "no puede funcionar sin una MCU local para hablar con ellos".

El bus de 1 cable necesita una MCU para comunicarse con los dispositivos conectados: -

ingrese la descripción de la imagen aquí

Tengo problemas para encontrar una manera de conectar de forma inalámbrica varios de ellos

Cada sensor de 1 cable necesita una MCU y, si desea conectar varios sensores de forma inalámbrica, cada MCU también se puede usar para controlar (digamos) un transmisor local de 433 MHz que puede recibir un solo receptor de radio. Ese único receptor es común a todos los transmisores.

He investigado productos como este par rx tx, pero no creo que pueda comunicarse de dos maneras y creo que el DS18B20 necesita enviar y recibir.

La MCU local puede comunicarse con el DS18B20 y esa MCU local puede controlar un transmisor de radio local. En otras palabras, no intente hacer un transmisor de radio de 1 cable: mantenga el sistema de 1 cable local para cada MCU y use la energía adicional de la MCU para controlar el transmisor de la forma en que debe controlarse. No intente mezclar estos protocolos o se buscará problemas y probablemente nunca lo haga funcionar.

Yo lo veo así; tiene varios sensores de temperatura en su casa y cada diez minutos cada uno transmite un valor de temperatura a un receptor común. Ese receptor común habla con su RaPi.

Ocurrirán colisiones, pero dado que una sola transmisión puede realizarse en 100 ms, la ocupación del canal común será de 1 segundo en diez minutos para diez sensores. Puede agregar un poco de aleatoriedad al momento de la transmisión para que, si los datos chocan debido a la transmisión simultánea, haya pocas probabilidades de que vuelva a ocurrir.

Diseñé un sistema como este que monitoreaba alrededor de cien gabinetes congeladores en un almacén. Cada transmisor transmitía a ciegas con un poco de aleatoriedad en el tiempo. Entre transmisiones, la MCU y el transmisor se pusieron en reposo y se podía obtener aproximadamente 1 año de duración de la batería con una batería pequeña de 9 voltios. El sistema buscaba la detección temprana de un gabinete congelador defectuoso. Utilicé productos de RF de esta empresa porque tienen buena reputación.

¡lindo! Una respuesta bien escrita de un experto en tales sistemas justifica mi voto a favor. Con respecto al enlace inalámbrico: tal vez OP quiera optar por las muchas opciones IEEE802.15.4 que están disponibles hoy en día que integran RF y microcontrolador; Las series EM34x y EFR32G de silabs parecen interesantes, al igual que ATSAMR21, así como la competencia TI
@MarcusMüller gracias Marcus. Tengo la sensación de que cuando el OP piense en esto, se dará cuenta de que un sistema de transmisión ciego se presta para la energía de la batería (algo que nunca mencionó en la pregunta). Personalmente, compraría varios transmisores de FM tontos y un receptor de FM tonto y usaría la MCU para formatear los datos en un paquete que incluye el preámbulo, la dirección, la carga útil y la suma de verificación. Las cosas de FM suelen estar mejor diseñadas y hechas.
bueno, ciertamente, para redes de baja densidad, aloha y despertar y hacer cosas espontáneas está bien, pero no estoy seguro de que eso sea lo que busca OP. Aparte de eso, sí, desde un punto de vista complejo, las cosas simples de FSK son difíciles de superar. Por otra parte, me volvería loco, probablemente haría todo el nodo central en la radio definida por software, pero eso es lo que yo (y mi instituto ) somos.
@MarcusMüller no estoy seguro de cuál es el instituto, pero como he oído hablar de él, debe ser importante. ¿Eres dueño?

Su sensor DS18B20 requiere una MCU local para enviar/recibir valores de temperatura a través del protocolo de 1 cable.

En lugar de complicar el sistema mediante el uso de transceptores de radio raros y muy caros, debe considerar el uso de algo como un ESP8266 que se conecta directamente a un WiFi local, que también es fácil de manejar con la Raspberry Pi. Probablemente ya tenga Wi-Fi (compatible con 2,4 GHz) en su casa, por lo que es sencillo conectarle la Raspberry Pi y sus sensores remotos.

Siga un proyecto de pelota que rebota como este que apunta a la mayoría del código requerido y se implementa fácilmente en el entorno de desarrollo de Arduino. Hay muchos proyectos de GitHub que también puede buscar.

Si no le gusta diseñar sus propios PCB, puede obtener placas compatibles con Arduino como esta, que cuestan solo unos pocos dólares.
ingrese la descripción de la imagen aquíEncontrará múltiples variantes, algunas marcadas como Wemos-D1 y otras sin ninguna marca.

La potencia requerida es bastante manejable:
ingrese la descripción de la imagen aquí

Puede encender, asociar, iniciar sesión, enviar datos y apagar en aproximadamente un segundo sin ningún problema.
Puede obtener casos de proyecto que se adapten al factor de forma Arduino para la red eléctrica (fuente de alimentación USB en su mayoría o opciones alimentadas por batería.
Ciertamente no vale la pena hacerlo de ninguna manera que no pueda usar las bibliotecas existentes para impulsar el proyecto ... su desarrollo lo hará ser simplemente una pesadilla.

Los módulos NRF24L01+ son fáciles de usar y económicos, pero aún necesita una MCU local para controlarlos. Terminará gastando más dinero y tiempo usándolos (y he usado muchos) que usando una solución ESP8266. Nada es más simple.

Esto hace que su proyecto sea un servicio web simple en Raspberry Pi y sus sensores remotos se encienden, conectan y depositan valores de tiempo/temperatura. Qué podría ser más simple.

Nota Si está inclinado a comprar soluciones esencialmente listas para usar, podría considerar usar los sensores TI Simplelink (basados ​​en ARM). Estos tienen un costo bastante razonable en varias variantes ($ 30-40) que se conectan a redes como BLE a través de WiFi. La versión WiFi reclama 3 meses con 2 pilas AAA a una velocidad de actualización de 1 minuto, por lo que debería ser un año más o menos con actualizaciones de 5 minutos. No los he probado, pero parece que no hay motivo para sospechar que no serán fiables.

Si usa un ESP8266 en modo WiFi, es probable que se necesite alimentación de red para cada nodo. En las baterías, usarlo en el modo de señalización no WiFi de nivel inferior probablemente tenga más sentido para evitar el costo de tiempo de asociarse realmente con una red. Luego puede usar otro ESP8266 como el receptor central alimentado por la red que se comunica en serie con el pi y, si lo desea, compartir los datos con los clientes de la red tradicional.
@ChrisStratton, si usa baterías AA o incluso AAA, no hay ningún problema real con la energía de la batería. Puedes hacer que las pilas duren meses.
Esa es una batería muy voluminosa para un sensor de temperatura, y sus cálculos de vida son dudosos a menos que actualice con muy poca frecuencia. El tiempo requerido para asociarse con una red WiFi y hablar protocolos IP a través de ella significará varios órdenes de magnitud más de consumo de energía de lo que realmente se necesita para transmitir una simple lectura de identidad y temperatura, incluso para hacerlo con una confirmación directa de bajo nivel.
@ChrisStratton, no estoy seguro de por qué cree que lleva mucho tiempo asociarse y obtener una dirección IP. Sin duda, puede reducir el tiempo que tarda suponiendo un SSID oculto (no enviar sondas) y un canal fijo, y luego puede eliminar DHCP (que he encontrado que es el retraso más largo) asignando una dirección IP. También puede hacer servicios web SOAP sobre UDP y eliminar el tiempo de conexión TCP (por pequeños que sean).
@ChrisStratton, escaneando la web, veo que algunas personas están sufriendo largos tiempos de conexión (2 segundos más o menos), pero esto se puede evitar con la configuración correcta. Este tipo tenía una descripción decente de los problemas que experimentó: bakke.online/index.php/2017/06/24/… ...y me gusta su truco de escribir la información requerida en el RTC... Yo el mío programado duro.
Es simplemente indiscutible que la asociación con un AP y el envío de tráfico IP es mucho más actividad de radio de lo que realmente se necesita para mover una lectura de identidad y temperatura. Si puede minimizar eso, genial, pero seguirá siendo mucho más costoso de lo necesario. Entonces, cualquiera que sea la duración de la batería que crea que puede obtener, tenga en cuenta que puede obtener muchas veces más del mismo hardware al no usar protocolos wifi.
@ChrisStratton, ¿costoso en qué sentido? La solución más económica (tiempo/esfuerzo, $$) parece ser WiFi. ¿A quién le importa cuál es el tiempo de encendido de la radio si la solución proporciona la duración de batería requerida? Así que estoy de acuerdo con usted, es indiscutiblemente cierto que la solución WiFi es potencialmente en órdenes de magnitud más que, digamos, un NRF24L01+... pero ¿a quién le importa si la solución proporciona una duración de batería adecuada? Si la solución REQUIERE baterías de botón, entonces WiFi no es el camino a seguir... pero si la solución cabe dentro de un estuche de proyecto que contiene 2-4 * AA o AAA, entonces WiFi se adapta perfectamente.
Costoso en reemplazar sus baterías con mucha más frecuencia de lo que realmente se necesita. Use su mismo hardware ESP8266, pero al enviar solo un paquete de radio sin procesar sin toda esa grasa innecesaria, puede usarlo de manera mucho más inteligente. Reemplazar las baterías no es solo un gasto de compra, es mano de obra, eliminación y posible tiempo de inactividad, todos los cuales tienen costos económicos para alguien , independientemente de si no son inmediatamente visibles para usted personalmente.
@ChrisStratton, estoy totalmente de acuerdo contigo. Ciertamente podría usar el ESP8266 sin sobrecarga de protocolo WiFi. Ahora, sin embargo, el OP tendría que desarrollar (o generar, y no veo ninguno) software para operar en ese modo. Entonces eso puede lograrse con menos facilidad. Claramente, podría operar un ESP8266 como maestro (puerta de enlace) para las otras radios de sensores sin la sobrecarga del protocolo, aunque sugeriría que sería un proyecto más desafiante. Es mejor pasar a NRF24L01+ en ese caso, pero ese es un proyecto bastante diferente.

Si no quiere hacer todo desde cero, puede usar los nodos z-wave de Fibaro. Uso un par de DS18B20 junto con una Raspberry en mi red domótica.

Que necesitas:

Placa transceptora Razberry

Sensor Fibaro Universal (está hecho para interactuar con el DS18B20)

Y un suministro de 5 V a cada nodo. Luego puede descargar Domoticz o una aplicación de automatización del hogar Z-wave similar para Raspberry.

Al final, obtendrá una buena interfaz amigable con el navegador para ver los sensores:ingrese la descripción de la imagen aquí

No tengo sensor de humedad, por lo que la línea verde en el gráfico está un poco defectuosa.

Conecte de forma inalámbrica varios DS18B20 en una casa
RespuestasAquíPolítica de privacidad1y, 0v