During today i build a simple Arduino based doorbell which is in the same network as my openhab-server. I get the signal from the pushbutton and are able to read it in a Python instance. So far, so good…
Now i want to notify the Openhab-Server that someone pushed the button.
What is the best way to send a command to openhab via WiFi? Can i send any kind of push notification to openhab?
WIfi or Ethernet does not really matter. Check out the OpenHAB REST API
https://docs.openhab.org/configuration/restdocs.html#rest-api-examples and
and Triggering Items Using openHAB 2's REST API from Tasker
or just use mqtt.
mqtt binding on openhab-side and a client-library like PubSub in your arduino-sketch.
Aaaaah, thererefore the Rest-API is good for…THX
However, i managed to get what i want to have but there something is strange. When i send the command as string then the rule will be fullfilled, when i try to send the same output as variable nothing happens, even when the logentry ist the same
LOG:
2018-01-06 17:58:49.665 [ome.event.ItemCommandEvent] - Item 'Arduinodummy' received command ON
Here’s my Arduino Code:
/*
Button
Turns on and off a light emitting diode(LED) connected to digital pin 13,
when pressing a pushbutton attached to pin 2.
The circuit:
- LED attached from pin 13 to ground
- pushbutton attached to pin 2 from +5V
- 10K resistor attached to pin 2 from ground
- Note: on most Arduinos there is already an LED on the board
attached to pin 13.
created 2005
by DojoDave <http://www.0j0.org>
modified 30 Aug 2011
by Tom Igoe
This example code is in the public domain.
http://www.arduino.cc/en/Tutorial/Button
*/
// constants won't change. They're used here to set pin numbers:
const int buttonPin = 2; // the number of the pushbutton pin
const int ledPin = 13; // the number of the LED pin
// variables will change:
int buttonState = 0; // variable for reading the pushbutton status
void setup() {
// initialize the LED pin as an output:
pinMode(ledPin, OUTPUT);
// initialize the pushbutton pin as an input:
pinMode(buttonPin, INPUT);
// open the serial port at 9600 bps:
Serial.begin(9600);
}
void loop() {
// read the state of the pushbutton value:
buttonState = digitalRead(buttonPin);
// check if the pushbutton is pressed. If it is, the buttonState is HIGH:
if (buttonState == HIGH) {
// turn LED on:
digitalWrite(ledPin, HIGH);
Serial.println("ON");
delay(1000);
} else {
// turn LED off:
digitalWrite(ledPin, LOW);
}
}
…and my gniosu Python:
#import libaries
import serial
from openhab import openHAB
#connect to serial device Arduino over USB
ser = serial.Serial('/dev/tty.usbmodem1411')
#connect to openHAB-Server
base_url = 'http://192.168.188.36:8080/rest'
openhab = openHAB(base_url)
#chose item to react
item = openhab.get_item('Arduinodummy')
#receive input and send it to item
while True:
input = ser.readline()
# print(input) #works
item.command('ON') #works
# item.command(input) #communication works, but rule will not fullfilled
# item.command(ser.readline()) #communication works, but rule will not fullfilled
Hi @bsailer,
Seems like you´re quite close integrating your Arduino doorbell to OpenHAB. Nice!
This is bit of a long shot, but I see that you do Serial.println to the Serial port. Maybe you do not want the CR/LF and should try Serial.print instead? I guess this would need rewrite of how you read the characters in the Pyton code. Alternatively, you could strip CR/LF from the string sent to OpenHAB (or even send 1 for ON and 0 for OFF if this is a switch item)
Hi Martin,
i tried to change it to serial.print. Doing that i dont get any input from the serial library. In the Serial Monitor from the Arduino Software i get the ‘ON’ output as it should be. Maybe there’s something in the serial library wrong.
Anyhow, the communication via Python was only for my testbench. On Monday i will put that all on one of these little, small WebDuino Boards where i cant use Python if i want to run them stay alone.
If you are going to change the hardware to an esp8266 based device, like the webduino, you should consider changing to mqtt and a library like Homie.
There you can embed your sketch code and push it directly as topic over mqtt.
Homie looks good. Just had a short look onto it.
Will try it to get on Monday my hands on any ESP8266 device (which isn’t so easy in our “big” city of Graz).
Thx meanwhile for your sugestion.
@Confectrician has a good point with respect to mqtt/Homie. Works good and should consume less power
What is the benefit from mqtt over rest api and http commands? If your device can handle both things, which is the better one and why?
In my opinion it is rest api, because you can directly speak from esp8266 to openhab, without the need of an additional mqtt brooker between? Or am i missing something?
I my mind, there are many different factors that would decide if http/rest or mqtt is the way to go.
Like you say, there is no need for a broker if you use http/rest. On the other hand, mqtt is a light weight protocol on top of TCP/IP that is intended for “small” bandwidth applications and if you are running on battery, mqtt should drain less power as you would be able to enter deep sleep mode more rapidly. Also, if you need to send frequent messages over a shaky TCP/IP connection (GSM phone of radio) I would prefer mqtt. Also, if you have a (large) network of devices all sending data (maybe a bit off scope for OpenHAB) I would go for mqtt.
Although, for most applications I think it is a matter of what you know best, what equipment you have and the rest of your infrastructure in place (existing brokers or what not)
The benefit depends on your system and it’s needs.
One example:
In this doorbell scenario you may have to think about denouncing the push button to prevent it from sending rubbish to openHAB.
Homie brings an implemented debouncing class with itself.
You don’t need to implement that yourself or search for solutions related to this topic.
That’s only a small thing, I know.
But maybe there are other things that could help in a later usage it for the future planned projects.
That’s why I suggested he should consider using it.
Mostly the decision is based on many system related or personal factors.
So it is useful to at least think about the available options and not choose the first suggested one directly.
If he says " I looked at it and will stay on rest api because it fits my needs better", that’s perfectly fine.
But changing to mqtt after spending hours on implementing rest API first, because he didn’t know about it, would be inefficient.