Who here builds their own sensors (CHAT)

(Stuart Brown) #41

Thanks for that GuyCo,

Your code has given me many ideas to try and improve my project. I’m just learning C type languages and so far my project has been built up by finding snippets of code that are close to my needs then bludgeoning them to do what I need.

I’m trying to make a MQTT and one button controlled dimmer that uses PWM outputs to into a Meanwell LED dimmer like a LCM-25 or IDLV-45A. I have played with a Krida triac module, but decided to go for the Meanwell dimmer for the energy efficiency and ability to dim to zero (z-wave etc and standard ‘dimmable’ led drivers only dim to 30% at best). Also Australian regulations specify certain standards and voiding them will invalidate insurance policies etc and since this stuff is going into a new building the electrical inspection would fail with the Krida style equipment. Aiming to use a UNO with a hard wired Ethernet board.

(Martin Vasko) #42


  1. Board with atmega328
  2. Modbus RTU
  3. Cost efficient - yes
  4. C language, web
  5. Ds18b20, bmp180
  6. Maybe, some pics. I have github martin075

(M) #43

Sensor Boards i do mostly with atmega 328 and bmp180 or dht22 sensors.
The data is send via 433Mhz to a NodeMcu (ESP8266) with a 433Mhz reciever and
there translated by to different MQTT messages for every sensor (right now 8 different sensor boards).

I first tried to send all info in one MQTT Message but Openhab and the Rules where not very reliable for handling 8 different Sensors.

I first test my new sensor boards on a breadboard with all needed sensors and then design the pcb in eagle.
The cases for my sensors are also self made.

I started with programming skills and learned the rest.

(Rich Koshak) #44

Unreliable in what ways? It might be something that can be fixed or it might be something where the details can help other users avoid the same problems.

(M) #45

Hi Rich, no problem. A little inside in why i decided to go away from using Openhab rules for my sensor data:

The original problem was that the gateway i used transmitted every message
it got as a mqtt message to openhab, in one mqtt message. The data was
“encoded” to give a way from what sensor which data came.
So for 433Mhz to get some reliable data from my sensors i minimize
data packet lose, the data is transmitted more then once
(depending on the range in meters between sending and recieving: 10 to 15 times).
I used openhab for decoding the encoding data with rules.
For one sensor this worked most of the time (not so good if all 10 or 15 messages arrived).
But for now 8 Sensors the maximum execution or lineup of rules to be executed was the killer.
My sensors send the data between every 5 minutes - 10 minutes; also if the sensor itself measured not successfull the measurement and sending is repeated one minute later.
Openhab has a limit which adds rules to be exeuted in a line and execute them one by one. Normally a very good approach, but not for my use case.

So but how did i fix all this. First things first:
The gateway i use, needed to do some handling of the sensor data,
like is this a new message or is it a repeated message which came earlier (recieving time < 60s).
So i added a little code to the gateway that checks this.
This alone cuts the MQTT messages recieved by alot (from max 10/15 to 1).

But the gateway can do a lot more, so i programmed it to decode the encoded messages and generate for every sensorboard and every sensor own mqtt messages. These are mapped in Openhab to the corresponding values and nearly no rules where needed.
One rule is triggerd to save the time the last sensor value from each sensor board was recieved. This is used to send out a telegram message to me if there is a problem with one of the sensor boards.

Final words, or TLDR:
Use as much preprocessing as you could and don’t shift it all to Openhab. Openhab will thank you for this.

(Rich Koshak) #46

This statement is not correct. There is a limit of five Rules that can execute at the same time which may be the issue you ran into. However, you can give OH more threads through a parameter in runtime.cfg.

I’m not arguing that you should go back or revisit this issue. Honestly I wouldn’t use OH Rules to do this sort of processing either and so like you recommend in the TLDR, I would do this processing in the gateway or something else before the data gets to OH.

Another approach that may have worked (I don’t know what your message looked like) was you could have used a combination of a REGEX filter to only match against those messages containing data for the sensor the Item is associated with and whatever transform is appropriate to extract the value. That would avoid the Rule entirely, though it depends on the structure of the message itself.

I’m glad you got it to work.

(M) #47

Thank you for the clarification Rikoshak!
If anybody is interested in the starting problem and the solution i got to work,
(even if it is only as how to not do it, the backfire of a not well designed implementation i took over without thinking to much),
i post the link to the original thread a while back. Rikoshak helped there also, so he knows what he is talking about!
Problem with rules execution if messages appear very fast

By the way it is interesting to see what others are building for their sensors. Hope to see more interesting sensors here in this thread. A inspiration is allways welcome :slight_smile:

(James Scott Jr) #48

I starting using OpenHab2, on RPi3 in the last year and started with GoogleHome, Phillips Lights, GE/Z-Wave wall switched and dimmer outlets. I’ve since added a Z-Wave thermostat and a couple of Sonoff’s behind outlets - using Tasmota.

Today I’m using ESP8266 NodeMcu modules with custom code I write using Arduino/IDE. The hvac sensors are ESP8266, DHT22 inside, DHT11 outside, and a microwave based presence sensor: RCWL-0516, all powered by a 5vdc wall brick.

My most recent suffering is related to my desire to use a MPU-6050 Gyro/Accel as a Garage-Door sensor. I want to use the Pitch from its Yaw-Pitch-Roll value to drive my OpenHab2 Rules. The challenge comes from needing to attach the resulting sensor to the door, which will require batteries.

Using the MPU-6050’s external interrupt pin to wake the ESP, results in a lockup from too many triggers on the RST pin of the ESP8266. This will require a hardware circuit of some sort to prevent external interrupts while active – working on an approach for this now.

The custom programming is not really that hard and a worthwhile hobby investment. MQTT, WIFI, OTA were all a lot easier than I had imagined. In contrast, the Raspberry Pi took real skill to accomplish the same things.

My observations related to Build vs Buy:

  1. Line voltage devices like outlets and light switches: buy Z-Wave device
  2. Temp/Humidity/Motion/Presence/Multi-Purpose Sensors: Build yourself and Save huge dollars
  3. Like a Smart Stock Trader or Poker Player: Know when to stop automating
  4. Add a voice assistant on one end and a UPS power supply on the other end!

Can share more details as needed.

(James Scott Jr) #50

I wanted to go beyond open/close feedback, and determine if the door was partially open and the direction of movement. Considered all the usual sensors, even tested a LIDAR to measure distance. Mpu-6050 is not CPU intensive and was easy enough to setup. The issue is power drain, since the chip runs full time, low power mode until door starts to move the. Full power for 25 seconds. Last 1 whole day on a pair of 1850s.

Mains, if buy gets within $10 I usually buy; so far most main solutions meet the buy side of my projects. I too am a software geek and much prefer to spend time on the system and interesting sensors like the mpu.

(James Scott Jr) #51

Do you really need those for garage doors?

Of course I do :wink: Got to play too!

(Rich Koshak) #54

Sounds like a good idea. @kai, who would be the right person to take to add a subsection to the Hardware section for discussions like theses?

(Kai Kreuzer) #55

Sure, why not, we don’t have yet many subsections at https://community.openhab.org/c/hardware.
What would be a suitable name? “Devices”? “DIY”?

(Kai Kreuzer) #57

I wouldn’t name it after any specific technology - this is simply… too specific :wink:

(Aaron) #58

Hi @Kai

DIY Sensors Design & Code Examples

(Kai Kreuzer) #60

Pretty long and we imho shouldn’t reduce it to sensors, but also include actuators - I’d therefore rather suggested “DIY Devices” (in contrast to the already existing “Servers”.

(Rich Koshak) #61

I agree with Kai. “DIY Devices” would be more inclusive. We can use tags to differentiate between different technologies like Arduino, ESP8266, etc.

(Aaron) #62

@Kai @rlkoshak

That’s fine it was only a suggestion

Different subsections would be nice

Begginers (no solder required and code ready wrote plug and play much like the openhab tutorials section)

Advanced (some solder required maby have too write some code)

Expert (anything above and beyond)

(Aaron) #63

Everyone else on this post

I have just grabbed a soldering iron from a freind and had a practice on an old pcb (not good)

I have tried desoldering it’s impossible with only a solder iron

Also some soldering not so bad not good

it’s been 10 years since I soldered last I’m going too have too practice some more and hopefully Improve this

Anyone offering any tips?

(Rich Koshak) #64

To desolder you need either a solder sucker


or some solder wick


to remove the solder once it is melted with the iron.

They are good to have around so you can fix mistakes you will inevitably make soldering.

A helping hands is also all but a requirement IMHO.

I’d look at Amazon (or your shop of choice) for a learn to solder kit. The device you make won’t to much (light up, maybe buzz or something) but it gives you some nice big pads to practice on before dealing with the teeny tiny little pads you find on sensors and microcontroller and the like.

(Aaron) #65

Thanks for that rich I already plan on getting all that equipment I have been doing some research :wink:

But I had not came across the kits I will have a look into it could be worth it for some practice

I’m also going too get a multi metre