Electronic – Wirelessly connect several DS18B20 across a house

sensortransceiverwireless

I am planning on reading temperature data form across my home using several DS18B20s and sending all of the data to a raspberry pi. I have already managed to interpret data from one sensor directly wired into the pi, but I'm having trouble finding a way to wirelessly connect several of them.

I have looked into products such as this rx tx pair, but I don't think that it can communicate two ways and I believe that the DS18B20s needs to both send and receive. I have also looked at this transceiver, but it looks like it uses a lot more ports than I want to, and I'm not sure if it can transmit the single line of data that I need to without all of the other wires/ports. I'm basically (I think)looking for a transceiver that only communicates the one wire that I need without all of the extras(if this even exists/is possible). I feel like I'm missing something that is very obvious, but can't seem to figure out what. Here is the DS18B20 data sheet if it helps. Thanks in advance.

Best Answer

While the DS18B20 signaling protocol requires transmission to query it, you would not want to pass that over a radio link. Instead, you would have a local MCU in the node query the sensor, and then unidirectionally transmit the result.

At this point it is important to note that productized wireless temperature sensors already exist. For example, both devices with their own LCD display which also transmit an OOK signal on 433 MHz, and display-less outdoor probes for indoor/outdoor systems. Often the on-air coding is undocumented and proprietary, but often it is easy to reverse engineer, and several codebases for decoding have been published. The biggest concern there may be if the nodes have unique serial numbers (likely, but perhaps not all models). Collisions aren't really a concern there as long as there are enough interference-free packets to get a reasonable update rate. Finally just as with custom projects, sound battery life utilization is something which may vary, depending on how much effort was put into it.

If you do decide to make something custom, you'd be looking for a low-cost solution for MCU and radio transmitter. SAW-resonator based 300-433 MHz transmitters as you linked are an option, and with one pin for the sensor and one for the radio, you can use some of the smallest 6 or 8 pin MCUs. If you do go this route however, consider using a more sophisticated receiver at the pi - TI and SiLabs both have offerings which are "real" tunable superheterodyne data radios far superior to the cheap regenerative receivers.

Far more sophisticated 2.4 GHz data radios can also be cheap, but typically require a full SPI bus to control, which means more MCU pins. Some of the BTLE MCU/radio combinations can also operate in simpler proprietary modes, sometimes compatible with the legacy air protocols like that of the nRF24, but tend to cost more than a cheap radio and MCU. On the plus side, you can get them already joined together in a submodule. There are also some very low end MCU + radio combinations out of China found in things like toy drones which could be applicable - if you can get the necessary documentation to work with them.

The ESP8266 and ESP32 are generally thought of as WiFi devices, but offer some propriety modes using only the lower level air signalling without the higher protocol layers, thus avoiding the time/energy cost of associating with a network only to report a reading and immediately go back to sleep.

Finally, while the proprietary LoRa modulation scheme is now getting a lot of attention for longer range sensor reporting, it's worth noting that as popularity increases the availability of low cost programmable hardware kits that the Semtech radios can to some degree be operated in simpler OOK or FSK modes and talk with other devices implementing those. However these are still in the over $20 per node class, and it appears that at least in the receive role it may not be possible to activate a simple RSSI squelch alone, but rather required to satisfy the packet preamble detector or else fake it out by setting a minimum length and maximum error allowance.