# Wirelessly connect several DS18B20 across a house

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.

• You will have to trade hardware cost with software development time. For example, a $1.00 Bluetooth 4 mcu will do this, at the cost of hundreds of hours of programming and learning, and laying out a board. I would lean to the side of buying 5 Pi Zero W...$10 each and you already know how to program them. Arduino and ESP32 are somewhere in between. – tomnexus Mar 4 '18 at 4:31
• Considering air return vent samples air temp and gives easy access to string phone wire, why not do it the easier way to an addressible bus. Then have a wireless node collect all the data to share. – Tony Stewart EE75 Mar 4 '18 at 17:41

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. You're right, your thermometer IC "speaks" the bidirectional single-wire bus, and that's nothing you could just feed into these ultra-simplistic (and questionably legal) transmitters. They need to be "asked" for data, and you're in no way doing that. Also, these transmitters just do amplitude shift keying (ASK) of a continuously running, fixed-frequency oscillator. That means you can't have two of these transmitting at the same time, because there's no way to tell the two signals apart. Furthermore, all your sensors are identical, so even if you made that magically work and you'd be avoiding such collisions by sheer luck, then you still couldn't say which of your sensors was reporting. So, no matter what you do, you'll need a microcontroller to talk to your sensor on one side, and talk to some kind of RF hardware on the other. Ideally, that RF hardware should be a lot nicer than these 433 MHz abominations. These transceivers based on nRF24L01 that you posted are a lot better – although they're based on a chip that the IC manufacturer already marked "not recommended for new systems", they can actually do a lot more. You could get a cheap microcontroller (for example, an arduino or clone) that talks 1-wire to your sensor, and SPI to the RF board. Then, you distribute those around. Your central Arduino node then periodically asks each of your sensor nodes for data, and your at-sensor-site microcontroller then answers. • "then you still couldn't say which of your sensors was reporting" That’s incorrect, the DS18B20 have IDs. – Jonas Schäfer Mar 3 '18 at 17:02 • yes, but if no-one's asking them about that, they can't report it either. I'd subsume that all under "can't work without a local MCU to talk to them". – Marcus Müller Mar 3 '18 at 18:19 The 1-wire bus needs an MCU to talk to devices connected: - I'm having trouble finding a way to wirelessly connect several of them Each 1-wire sensor needs an MCU and, if you want to wirelessly connect multiple sensors, each MCU can also be used to drive (say) a local 433 MHz transmitter that single radio receiver can receive. That single receiver is common to all transmitters. 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. The local MCU can communicate with the DS18B20 and that local MCU can control a local radio transmitter. In other words, don't go trying to make a 1-wire radio transmitter - keep the 1-wire system local to each MCU and use the spare power of the MCU to control the transmitter how it needs to be controlled. Don't try and mix these protocols or you'll be asking for trouble and probably never get it working. I see it like this; you have multiple temperature sensors around your home and every ten minutes or so each one transmits a temperature value to a common receiver. That common receiver talks to your RaPi. Collisions will happen but given that a single transmission might be all done in 100 ms, the common-channel occupancy will be 1 second in ten minutes for ten sensors. You can add a bit of randomness to the timing of the transmission so that if data collides due to simultaneous transmission there is low probability this will reoccur. I designed a system like this that monitored a hundred or so freezer cabinets in a warehouse. Each transmitter blindly transmitted with a bit of randomness in the timing. Between transmissions the MCU and transmitter went to sleep and you could get about 1 year battery life from a small 9 volt battery. The system was looking for early detection of a faulty freezer cabinet. I used RF stuff from this company because they are reputable. • nice! A well-written answer from an expert on such systems warrants my upvote. Regarding the wireless link: Maybe OP wants to go for the plenty IEEE802.15.4 options that are available today that integrate RF & microcontroller; silabs' EM34x and EFR32G series seem interesting, so does ATSAMR21, as well as the TI competition – Marcus Müller Mar 3 '18 at 17:41 • @MarcusMüller thanks Marcus. I have a feeling that when the OP thinks about this he will realize that a blind transmit system lends itself for battery power (something he never mentioned in the question). Personally I'd buy several FM dumb transmitter and a dumb FM receiver and use the MCU for formatting the data into a packet that includes preamble, address, payload and checksum. FM stuff is usually better designed and made. – Andy aka Mar 3 '18 at 17:46 • well, certainly, for low density networks, aloha and spontaneous wake-up-and-do-stuff is fine, but I'm not sure that's what OP is after. Other than that, yes, from a complexity POV, simple FSK stuff is hard to beat. Then again, I'd go all overkill myself probably do the whole central node in software defined Radio, but that's just who I (and my institute) am. – Marcus Müller Mar 3 '18 at 18:18 • @MarcusMüller not sure what the institute is but as I've actually heard of it, it must be important. Do you own it? – Andy aka Mar 3 '18 at 18:24 Your DS18B20 sensor requires a local MCU to send/receive temperature values over the 1-Wire protocol. Rather than complicate the system by using oddball and very expensive radio transceivers, you should consider use of something like an ESP8266 which connects directly to a local WiFi, which is also trivially easily handled by the Raspberry Pi. You probably already have WiFi (2.4GHz capable) in your house so it's a no-brainer to connect the Raspberry Pi and your remote sensors to it. Follow a bouncing ball project such as this which points to the majority of the code required and is easily implemented in the Arduino dev environment. There are many GitHub projects you can search for too. If you are not into designing your own PCBs, you can get Arduino compatible boards such as this which cost only a few$.
You'll find multiple variants, some marked as Wemos-D1's other with no markings at all.

The power required is quite manageable:

You can power up, associate, logon, send data and powerdown in a second or so without any problems.
You can get project cases to suit the Arduino form factor for either mains (USB power supply mostly or battery powered options.
It's certainly not worth doing it any way that you can't use existing libraries to drive the project ...your development will simply be a nightmare.

The NRF24L01+ modules are easy to use and cheap, but you still need a local MCU to control them. You'll end up spending more money and time using them (and I've used lots of them) than using an ESP8266 solution. Nothing is simpler.

This makes your project a simple Web service on the Raspberry Pi and your remote sensors power up, connect and deposit time/temp values. What could be simpler.

Note If you are inclined to buy essentially out of the box solutions you could consider using the TI Simplelink sensors (ARM based), These are quite reasonable cost across several variants (\$30-40) that connect to networks such as BLE through WiFi. The WiFi version claims 3 months on 2*AAA batteries at 1 minute update rate, so should be a year or so at 5 min updates. I have not tried them, but there seems no reason to suspect they won't be reliable.

• If you use an ESP8266 in WiFi mode mains power will likely turn out to be needed for each node. On batteries using it in the lower level non-WiFi signaling mode probably makes more sense to avoid the time cost of actually associating with a network. You can then use another ESP8266 as the central mains-powered receiver communicating serially with the pi, and if desired then share the data with traditional network clients. – Chris Stratton Mar 3 '18 at 22:00
• @ChrisStratton, if you are using AA or even AAA batteries there is no real problem with battery power. You can make the batteries last for months. – Jack Creasey Mar 3 '18 at 22:40
• That's a lot of bulky battery for a temperature sensor, and your life calculations are doubtful unless you update very infrequently. The time required to associate with a WiFi network and speak IP protocols over it is going to mean several orders of magnitude more power consumption than actually needed to transmit a simple identity and temperature reading, even to do so with a direct low-level confirmation. – Chris Stratton Mar 3 '18 at 22:46
• @ChrisStratton, I'm not sure why you think it takes a long time to associate and get an IP address. You can certainly reduce what time it does take by assuming a hidden SSID (send no probes) and a fixed channel, and then you can eliminate DHCP (which I've found to be the longest delay) by allocating an IP address. You can also do SOAP webservices over UDP and eliminate TCP connection time (small as they are). – Jack Creasey Mar 3 '18 at 23:15
• @ChrisStratton, scanning the web I do see some folk's are suffering long connection times (2 seconds or so), but this can be avoided with the correct setup. This guy had a decent write-up of the problems he experienced: bakke.online/index.php/2017/06/24/… ...and I like his trick of writing the required info into the RTC ....I hard programmed mine in. – Jack Creasey Mar 3 '18 at 23:39

If you don't want to do everything from scratch you could use Fibaro z-wave nodes. I use a couple of DS18B20 together with a Raspberry in my home automation network.

What you need:

Razberry tranceiver board

Fibaro Universal sensor (it's made to interface the DS18B20)

And a 5 V supply to each node. Then you can download Domoticz or a similar Z-wave home automation application for the Raspberry.

In the end you will get a nice browser friendly interface to watch the sensors:

I have no humidity sensor, so the green line thing in the graph is a bit flawed.