We have been busy with research and development for several new products, which should be available for pre-order soon. Our focus is on:

  1. Developing new IoT products for smart homes and automation
  2. Creating custom kits to modify existing devices for plug-and-play integration with smart home technologies.

Below is a sample of two of these products, which will be available on the store soon, so check back soon!

Above: Prototype of an add-on board to turn a $60 off-the-shelf electronic lock into a wifi enabled smart lock. Our board uses a NodeMCU and a custom circuit to interface with the lock’s existing control board.

Above: Another prototype board to control our custom device on the left. This product is an IoT water control and data acquisition unit. Our design is a totally enclosed system which monitors and reports: water flow rate, total water usage, and water temperature. The product includes a motorized ball valve which can be controlled remotely and automated to close upon the detection of a leak or with other defined rules. Our design also includes a novel component: the entire unit is self-powered using a micro hydro generator, backup battery, and charging circuit. This product has been designed from the start for use with openHAB software.

We are designing several custom products to turn ordinary devices and appliances into “Smart” devices with plug-and-play add-on boards. These products are easy to install, plug into existing control boards on your appliances, and can be easily removed for any reason. Using a software platform such as OpenHAB, our hardware devices will allow you to gather data from all of the appliances and devices in your home. You can then create rules, build reports, etc. The sky is the limit. Stay tuned to the blog and check the dijit store often for new product releases.


OpenHAB is one of the most promising home automation solutions I have seen in years. It offers an open-source, vendor-agnostic, and cloudless solution to home automation (though a cloud service is available). The ability to integrate hardware and software from a large number of existing manufacturers, and other open-source projects, is perhaps it’s most valuable characteristic.

Many of the embedded hardware products dijit has developed and implemented can easily be integrated into OpenHAB.

This week, hack local (the hackerspace R&D arm of dijit) began testing various setups using products on hand. The first project involved setting up an openHAB instance on an O.G. Raspberry Pi model B, using the onboard GPIO for Maxim 1-Wire DS18b20 temperature sensors.

The goals of this project:

  • Stand up a functioning openHAB instance on a Raspberry Pi B.
  • Create a 1-wire network of temp sensors using a star topology.
  • Read multiple 1-wire temps from a single Raspberry Pi GPIO pin.
  • Develop hardware for a modular and “plug-and-play” solution based on this project.

Here is how we fared:

Step 1: Install and configure openHABianPi

To streamline installation of openHAB on the Pi, a custom distro ‘openHABian’ is offered here: https://community.openhab.org/t/openhabian-hassle-free-rpi-image/13379

The tag line reads: “Flash, plug, wait, enjoy”, and quite honestly that is exactly what our results were.

Download img file, flash to SD card, boot up Pi, wait approximately 45min, and we were off.

If our only objective were to have a running instance of openHAB on a Raspi, we would have been marking the project complete within the hour and enjoying beverages the rest of the evening. But alas, there was much work yet to be done. We now had a working openHAB with SSH access and many web UI’s to choose from:

Step 2: Build 1-wire sensor network

The first challenge was to stop referring to the sensors as Dallas 1-Wire, as Maxim Integrated bought out Dallas Semiconductor….oh…about 16 years ago. Anyway, with a handful of some Maxim DS18b20 temperature sensors, a spool of Cat-5, and a network topology map that appears to be written by a school kid (pulled right from the official Maxim website), we set out to build a hard-wired sensor network:

Because the temp sensors would be in separate rooms, and on 3 different floors, we opted for the star topology. We followed Maxims guidelines on the radius (distance from master to farthest node) and weight of the network, to reduce reflections and maximize timing. This will be important as we expand our 1-wire sensor network and add devices (contacts, switches, and iButtons).

From here, we connected our 1-wire sensor network to GPIO pin 4 on the RasPi. Below is our original breadboard testing version of the connection:

Note the 4.7k pull-up resistor. Only one of these is required in total (not each sensor).

Step 3: Reading Temperature sensors through GPIO on RasPi

After the physical sensor network was in place, we then began testing out the openHAB binding for 1-wire, which looked very promising. Unfortunately, this binding is designed to be used in cooperation with ow-server, a software package which facilitates 1-wire communication in linux. Unfortunately, the hardware connection to sensors for ow-server is limited to serial, USB, or network sockets/tcp. There is no current configuration for GPIO sensors that we could find.

Not to be deterred, and not wanting to re-invent the wheel, we were able to track down a RasPi GPIO implementation on a German blog here: http://www.itbasic.de/openhab-onewire-sensoren-einbinden/

This method utilizes the Exec Binding in openHAB, and runs a script to poll the sensors and format the output. We modified the script to get output values from our temperature settings in ‘Murican, otherwise known as Fahrenheit. Ironically, Fahrenheit was a Dutch-German….but, I digress… Here is our modified script:

wert=`cat /sys/bus/w1/devices/$1/w1_slave | tail -n1 | cut -d '=' -f2`
wert2=`echo "scale=3; $wert/1000 * 9.0 / 5.0 + 32.0" | bc`
echo $wert2

The next step was to get the RasPi to communicate with our temp sensor network and implement this script within openHAB.

The latest RasPi kernels have built-in driver support for 1-wire, using dtoverlays in /boot/config.txt. We leveraged this by adding the following line to our Pi’s config.txt:


After a reboot, we confirmed the RasPi could see our temp sensors by heading here :

$ cd /sys/bus/w1/devices

If the w1 directory does not exist, the 1-wire driver was not loaded, and config.txt is likely to blame. Note that the config.txt that comes with openHABian contains 3 sections for the various version of RasPi’s: 1, 2, and 3, so the correct section must be modified for the corresponding RasPi version.

The 1-wire temp sensors each have a UID (28-xxxxxxxxxxxx) that is displayed in this folder. This UID is used to poll each sensor in the script:

$ onewiretemp.sh 28-xxxxxxxxxxxx

We placed the script in the appropriate folder for openHAB at ‘/etc/openhab2/scripts’. Manually running the script confirms our sensors are communicating with the RasPi and our syntax is correct:

pi@openHABianPi:/etc/openhab2/scripts$ sudo bash ./onewiretemp.sh 28-xxxxxxxxxxxx

Step 4: Creating the openHAB items, things, sitemap, etc.

After confirming all temp sensors were reporting in terminal using the script, we then installed the Exec Binding, and created the appropriate openHAB files for our things.

In openHAB’s Paper UI (http://192.168.blah.blah:8080/paperui/index.html), the Exec Binding can be installed by navigating to:

Add-ons>Bindings>Exec Binding


Once the binding was installed, we then created our custom files for the temp sensor readings:


exec:command:onewiretemp1 [command="bash /etc/openhab2/scripts/onewiretemp.sh 28-xxxxxxxxxxxx"]
exec:command:onewiretemp2 [command="bash /etc/openhab2/scripts/onewiretemp.sh 28-xxxxxxxxxxxx"]
exec:command:onewiretemp3 [command="bash /etc/openhab2/scripts/onewiretemp.sh 28-xxxxxxxxxxxx"]


String onewiretemp1Value "Temp 1 is [%s °F]" {channel="exec:command:onewiretemp1:output"}
String onewiretemp2Value "Temp 2 is [%s °F]" {channel="exec:command:onewiretemp2:output"}
String onewiretemp3Value "Temp 3 is [%s °F]" {channel="exec:command:onewiretemp3:output"}

It is important that you specify “output” for the channel that links the item to the thing. Other value options will not work with this ‘script method’ we have chosen.
And finally, some sample sitemap entries:

Frame label="Environment" {

Text label=”Temperatures” icon=”temperature_hot” {
Text item=onewiretemp1Value
Text item=onewiretemp2Value
Text item=onewiretemp3Value
Text label=”Temp Charts” icon=”line-incline” {
Chart item=onewiretemp1Value period=d refresh=300
Chart item=onewiretemp2Value period=d refresh=300

We are still playing around with the chart features, and displaying a color which represents the value of the temperature sensor (i.e. if temp is equal to or below 65 color is blue, over 70 is orange, over 80 is red, etc.).

Step 5: Testing the UI display

Testing with openHAB’s Basic UI demonstrates that we now have a fully functioning temperature sensor network, displaying live temps from 3 levels of our test house:

…it’s cold here in the winter….


That’s it! There will be lots more to come on openHAB hardware setups such as this, so stay tuned.

Next steps and product ideas:

We are taking the lessons we learned from this project and creating a modular 1-wire hardware setup using rj-45 connectors, patch cables, etc., to simplify the physical connections from 1-wire sensor to openHAB hardware such as the RasPi. The goal will be to provide a “plug and play” hardware solution to compliment the amazing openHAB software.