Hi,
- Board with atmega328
- Modbus RTU
- Cost efficient - yes
- C language, web
- Ds18b20, bmp180
- Maybe, some pics. I have github martin075
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.
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.
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.
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.
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 
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:
- Line voltage devices like outlets and light switches: buy Z-Wave device
- Temp/Humidity/Motion/Presence/Multi-Purpose Sensors: Build yourself and Save huge dollars
- Like a Smart Stock Trader or Poker Player: Know when to stop automating
- Add a voice assistant on one end and a UPS power supply on the other end!
Can share more details as needed.
1 Like
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.
Do you really need those for garage doors?
Of course I do 
Got to play too!
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?
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”?
1 Like
I wouldn’t name it after any specific technology - this is simply… too specific
1 Like
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”.
I agree with Kai. “DIY Devices” would be more inclusive. We can use tags to differentiate between different technologies like Arduino, ESP8266, etc.
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)
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?
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.
1 Like
Thanks for that rich I already plan on getting all that equipment I have been doing some research
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
There are some good videos on YouTube for soldering for beginners.