Hello dear Community developers,
I have now been reading wiki’s for a few days and installed OpenHAB 1.8.2 to my raspberry pi (b rev2). I have some ideas and been browsing through examples, but came here to ask expert level advice to make the start a bit easier, as I’m in a kind of hurry…
I have these connected to Raspberry through gpio (and usb)
light dependant resistor with ad/dc converter mcp3008,
dht22 temp/hum sensor,
usb-cam
an AC -remote outlet controller (those 433Mhz)
I have come to conclusion that from OpenHAB’s perspective I could use
exec commands binding
gpio binding
python calls / scripts (dunno how it’s best described or are both possible ) straight from rules
mqtt binding
Light level and temp/hum both are accessible with python in raspberry, returning the value to command line. What I’d like to ask, is how would you tackle these issues, if I want
have a Temp, Hum and Light level viewed as number value at the moment, single line for each
make graphs for every of these attributes
simple rules, which would call gpio according to boundary levels set for every measured attribute
security cam I believe to be simple
Basically…, is it best to implement MQTT to get both the simple numeric value and also the graphs or should I just go e.g.with mysql database for graphs and call python to view the single numbers in separate? Also remembering here, that how it is easy also to create rules to follow sensor measures…? Let’s say.: “if light level is 200/1000 -> turn on remote outlet”
These questions might seem unrelevant to post here, but I have not been able to compare different ways on my own. Coding, these various message protocols, unix etc is a bit new to me. Thank you!
From your description I’m not sure I think you understand how OH works.
For this discussion, OH has four main sections:
Items : represent a “thing” in your home automation such as a temperature reading or a light switch
Rules: logic (i.e. code) that executes when a defined event occurs (e.g. temperature Item changes, certain time, switch changes state, etc.)
Persistence: stores and restores the state of Items, enables charting
Sitemap: defines the user interface
Given this your questions don’t make complete sense in terms of how OH actually works. First I’ll address some of your statements individually then describe what I would do.
I caution you that home automation is rarely something that that can be achieved quickly unless you really know what you are doing. Being a beginner and also in kind of a hurry concerns me, particularly since you appear to be using a lot of DIY electronics as opposed to off the shelf sensors and actuators. DIY is going to be particularly challenging for you unless you are willing to spend tons of time experimenting, researching, and debugging. I’ve spent hours and hours and hours trying to help some “I found some stuff on the internet and pasted it in” types only to fail.
This is often a fallback choice when all other options fail. Be aware that if you install OH using apt-get, the OH server is running under a separate and limited user so getting permissions right is a challenge for many users.
This is a great choice if you are running OH on the same machine as the sensor/actuators. However, frequently where one needs to run the OH server and where the sensors/actuators reside are far apart so this frequently is not a completely uniform approach.
Also, for actuators the GPIO binding can be a problem when the Pi reboots some of the pin initialize to high which can trigger your actuator before OH can reset it to low.
This shows a slight misunderstanding. You can indeed call python scripts from OH, using the Exec binding. However, what I think you are referring to (the JSR223 binding) is the ability to write OH rules using python instead of the default Domain Specific Language (DSL). But you are not “making calls” to python, everything is python.
One of the preferred choices in home automation. However it is not the only one. A lot of people prefer using HTTP REST which is also supported using the HTTP binding, sendHttpGetRequest and sendHttpPostRequest actions, and OH’s native REST API.
There are two main approaches: pull or push.
For pull, create a Number Item for each with a binding (Exec to call your existing python scripts, GPIO binding, set up a server that OH can poll for updates using HTTP, etc, from the rest of OH’s perspective it doesn’t matter what) and put those two Items on the sitemap.
For push, write a script that pushes updates to OH using MQTT, REST, etc. On the OH side create Number Items with a binding configured to receive the updates. Again a sitemap with the two Items.
Set up persistence. You have a host of databases to choose from. You can use the native OH charting, though it is a bit primitive and inflexible, or if you use one of the non-embedded DBs (i.e. not rrd4j or db4o) and some external tool to graph.
I would not choose rrd4j if you need to store completely accurate data for long periods of time.
See above. You can trigger a rule based on a change in an Item, use an if to see if the change crosses a boundary, and then perform some action. To my knowledge there are no GPIO actions so the only way to switch a GPIO pin is by sending a command to an Item bound to a GPIO. And from that perspective the Rule has no idea what that Item is bound to, only that it is a Switch or a Number.
This almost completely outside the scope of OH. In some circumstances you can put a webview to an IP camera’s feed on your sitemap but if you want anything more you need to use some other software package (e.g. Zoneminder, motion, etc.). However, at least with Zoneminder there is a way to get motion events and other events from Zoneminder into OH.
This question doesn’t make much sense but I’ll try to make some sense out of it. If everything you will ever need to support will be on the same Raspberry Pi, don’t bother with the MQTT. However, if you ever plan on expanding to have sensors and/or actuators that are wired to some other Raspberry Pi or Arduino go ahead and set it up with MQTT now so your interfaces to OH are more uniform and consistent.
As I said above, charting is handled using persistence. Once persistence is set up and your Items are getting values their values will be saved to the configured DB. There is a charting service built into OH or if you are using something like MySQL you can use external charting.
I don’t know what you mean by “Call python to view the single numbers in separate”.
rule "Turn on remote outlet"
when
Item LightLevel received update
then
if((LightLevel.state as DecimalType) > 200) Outlet.sendCommand(ON)
end
Now to how I would implement the above. For the most part I kind of already have. In my setup I have several Raspberry Pis running python scripts which report changes in state on the GPIO pins (as well as some other stuff) to OH which is running on an old laptop using MQTT. I have some actuators which OH uses WebIOPi’s REST API to trigger. I have, or am in the process of setting up, some IP cameras connected to Zoneminder and I’ll create some Items to get motion events using OH’s HTTP binding and Zoneminder’s REST API.
Thank you for the response, it covered more than I could have imagined and was just the kind of answer I was looking for. I really appreciate your time and effort. I think I can get forward and will forget the mqtt for a while.
So you mean basically, that HTTP and persistence are enough to display the data I described before?
It appeas my questions and description of the situation didn’t really cover the whole image and my technical background, but I think I’ve got the idea of the OH pretty well. I will get back to you or to related forum threads if I am facing any new headache. Cheers!
) straight from rules