for simple unsecure tasks like temperature measure I want to use some cheap sensors with arduino and 433mhz RF. What I got to work until now is, to connect a temperature sensor to Arduino and write the temp with serial.println to serial connection and openhab receives it and display it to habpanel. this is working great.
what I’m asking me now is, what the best practice is to connect multiple sensors (via 433mhz RF) to one arduino RF “gateway” which is connected via serial binding? using regex, json transforms or something similar, maybe with including rules to detect which sensor transmitted a value?
RS485 is similar to your serial method you are using now but allows for multiple devices to speak down the same wires if you write a software protocol on top of the rs485 hardware layer. Modbus and many other protocols use rs485 if you wish to read up how it is done. I think openhab has a modbus binding so you could implement modbus and use that binding.
MQTT is different but designed to be used on small low power devices.
If you have one arduino gateway connected to your openHAB machine then it’s really up to you. You are limited to the serial binding for now. So I would suggest REGEX serial messages because the serial binding only accept REGEX transforms.
For example, you have 2 sensors sending RF messages to your arduino.
Get the arduino to send the string
sensor1:value
when a sensor 1 signal is received.
In the serial binding for Item1
use the transform REGEX(Sensor1:([0-9.]*))
thx. That would be the way I will try next. But I thought there could be a better way maybe with “simulating” things or something like that. but seems not so.
Forget 433mhz, just get an esp8266, which has a built-in WiFi, then you can be creative as far as updating OH. Either you use the REST API or use MQTT. An ESP8266-01 is approx $2 from AliExpress. So all you would need is the ESP8266 and a temp sensor (TMP36, DHT11, DHT22, DS18B20, etc).
If you want to use 433mhz, then you need to come up with your own “protocol.” Parse your data so you know which temp is from which sensor, then update OH accordingly. For example, have your sensors send JSON:
Delimiter would be easier and cheaper (process wise) to OH. You just split() the string, and now you have name at array[0], and temp at array[1]. REGEX is expensive in any language.
I feel the same way about wifi, but if it is only a single bridge that talks to your 433mhz radios and then uses a single wifi point to send and recieve the MQTT it is not a big deal. As mentioned an esp8266 is $2 and will connect to add on 433mhz radios if you wish to use it that way.
MQTT offers a lot in the way of auto resending packets that get lost and making sure a message gets delivered to a device that goes on and off line a lot.
Getting good support in and out of openhab with serial is going to be a LOT harder than using MQTT.
There are a number of good esp8266 projects that allow you to flash ready made firmware, open up a control panel and specify which IO a temp sensor is connected to and you are away.
That is what I did. Back when I wanted to control 433MHz items, I used a WEMOS D1 (ESP8266) based dev board and controlled the 433MHz emitter with MQTT messages.
I now use RFLink linked with a ESP8266 to control it with MQTT
You never mentioned anything about batteries and restrictions about the number of clients. Where will the sensors be that you don’t have access to an outlet?
And have you used deepSleep() on the ESP8266? They work wonders.
It would take less than 2 mins to write code to parse id,temp format. Serial is MORE used than MQTT, not just in IoT, but in multiple industries, for DECADES. I’m pretty sure he can get more help for it than MQTT, in and out of OH. But if OP has MQTT already setup then that’s a good route to take. Nothing wrong with REST API also.
Really? The OP wants to do multiple devices and if they wanted the same feature set as MQTT it would be a lot harder to implement acknowledge and auto resend of packets especially if devices are going into a deep sleep and not always reachable. For doing small quick and dirty projects serial is fine, but if you want to take it to the next level with serial it is going to be more work then simply going to MQTT which is why it has become so popular now that a $2 esp8266 is available.
Yes that will be a good way to go as MQTT is pretty cool as you learn the features it has. If your devices power down into sleep modes then when they wake up and connect to MQTT they get all the messages they missed whilst asleep. Your device can then send a message to the MQTT broker and power back down knowing the broker will ensure the message keeps getting sent again and again until it reaches the destination. If you keep using RF sooner or later you will get a collision of two devices that both want to transmit at the same time. How are you going to handle this? sure a simple temperature sensor getting a lost reading is OK, but other things you create you may want 100% reliable communication and this is where it gets much more complex.
I have the same thing happening in my RS485 bus as multiple devices speak down the same wires. When you need ACK and auto resend of lost packets it then makes things much harder.
There are many different ways to do things, so have fun
yea. why should I mention it? I wanted to understand how the best practise is to use serial binding. also for learning. however:
wifi is for me a no way for a stable communication. in germany the law regulate output power at 100mw maximum on 2,4ghz. thats not much on this high frequences… also, more devices you have in wifi network, it will get slower and slower. neighbours are also using wifi and it get more slower. microwave is starting and again more slower. and battery use…
so @matt1 for a nearly 100% stable communication I’m using zwave. but for things like temperature I want to go the cheaper way e.g. with arduino. so the described way with one esp8266 gateway accessing wifi and a rf receiver modul installed on this esp8266 to receive rf signals sounds like an interesting way for me. I believe in first step I’m going the serial way and learn how it works and after this I will play with an esp8266. Never worked with MQTT right now. Read a lot about it and the pro/cons to rest api and it sounds very interesting.
sorry I dont understand why this is important or I dont agree?!
what does it help to mention if I want to use a device with low power consumption when the question was regarding how the serial binding works and how best practise is for this?
We all have different backgrounds and come from different cultures which is why misunderstandings occur in a text format like this.
@DubZ
I am more of a hardware designer with experience in writting advanced RF and serial protocols from scratch on microprocessors so I went straight to the $100+ meal deal so you could choose where you wanted to go under that. For me, someone asking about “best practice” is they wish to know the highest end way to do something so they can choose how much they spend on the meal. When learning it is helpful to know what to avoid by knowing what may lay ahead. I have 60+ serial devices that I now have to get running in Openhab and hopefully my personal experience is useful.
One tip I have for you is if doing lots of battery devices, make sure you can send the battery voltage through to Openhab so you can get warnings the battery is getting low and needs to be replaced before the device stops working. This is why I did not go the RF route as a wired solution made a lot more sense as it carries power and the data in the one cable (for a new house build) and no batteries to go flat on 60+ devices. Well I do have a battery in the form of a UPS.
Be sure to post some pictures when you have some stuff running as I like to see what other people are getting up to as it sparks ideas in me.
Hi @DubZ Dubz, if you know how to address your 433-switches with an Arduino UNO + W5100 (and have or) want to install(ed) a MQTT brooker feel free to take a look at this topic. It is the result of my first steps with OpenHAB/MQTT/Arduino/433 combination; think the sketch is pretty straight forward and thus readable enough to include your own desired 433-libraries.
That’s the thing, right? OP’s question is very vague. He’s asking best practices… on what? It will all depend on the requirements. There’s best practices for batteries, best practices for wired, wireless, MQTT, serial, $10 budget, unlimited budget, time critical applications, latency, mesh network, security, protocols, etc, lol.
