I’m a rank beginner to OpenHAB2, and I’ve spent some time browsing through the documentation without finding the answer yet. I already know that OpehHAB2 and Mosquitto can be installed on a Raspberry Pi Zero W, but can that Pi Zero also be used as the “Item” in OpenHAB2? Basically the entire automation project (it’s rather simple) would be run on one Raspberry Pi Zero W ultimately using a cell phone as the control panel.
I have a use in mind for this, and in the interest of conserving power I’d like to run all of this on a single piece of hardware if that’s possible.
Yeah, I think that’s what I was asking. Thanks! I just wanted to verify that before investing any more money or (more important than the money) time into it.
If you will have more than a couple of bindings, more than a dozen Items/Things, and more than a couple hundred lines of Rules you will probably be very disappointed with the overall performance. You will be looking at 20-30 minute load times for OH, maybe longer. You will be experiencing high latency periodically as stuff gets paged in and out of RAM since the RPi 0 doesn’t really have enough to run it all.
You don’t provide enough information to say whether these problems will impact you but I would plan on needing to upgrade to at least an RPi 2 at some point.
Yeah, I didn’t exactly explain the usage. Basically it’s just 1 thing (the Pi Zero W itself) with 2 items if I have the nomenclature correct. I want to independently control two LED strips in a vintage camper that I’m rebuilding. it’s a very specific situation that likely won’t grow any larger than that, so hopefully this will be up to the task.
A little further down the road I do have another project in mind that’s a little bigger which will likely be based around a Pi 3B, but the Things will likely all be different devices.
If that is all you are after, I question whether OH is the right tool for the job. And I don’t understand why you would put a Mosquitto broker on it.
It sounds like you want to control these two LED strips using MQTT and the GPIO pins of the RPi. For a use case like that, an EPS8266 is far more suited to this job. If you use Tasmota or ESP Easy for your firmware and a NodeMCU all you need is a USB cable and a computer to flash the firmware and then you can configure the device through a web page interface and control the GPIOs through MQTT commands or REST commands or whatever you prefer.
This will be much more reliable, require much less power, and take up probably about the same amount of room as the RPi 0.
IMHO OH and a RPi 0 is way overkill for this use case. And depending on how much of a hurry you are in, you can get NodeMCUs direct from China for $1-$2 a piece. Otherwise they run about the same cost as a RPi 0. But even at the same cost, you get the reliability of a microcontroller versus a general purpose computer.
Thanks Rich for taking the time to clear things up a bit. As I mentioned, I’m a rank beginner…and not only to OH, but this sort of automation in general, although I have been kind of tinkering with ESP’s & other microcontrollers for a short while now.
As mentioned before, I’m not terribly proficient with coding a nice looking interface in HTML, so I was hoping to leverage that in OH for turning the LEDs on/off as well as dimming them via a browser on a cell phone. I’m not familiar with Tasmota or ESP Easy (although I have heard of ESP Easy), and I didn’t know that MQTT could be run without introducing another piece of hardware to be the broker (hence wanting to just run it all on a zero). If it’s reasonably easy to make a nice interface & do this with ESP Easy then I’m not opposed to going that route. I have a Wemos D1 Mini that could be used for this project.
I’ll do some reading on that topic and see what I can find. Meanwhile I’ll definitely come back to OH for another project a little later down the road.
MQTT is used to enable software programs and devices to communicate with eachother over the network. If everything is on the RPi 0 and everything is self contained, you don’t have anything to communicate so there is no need for MQTT in the first place.
Since you mentioned MQTT, I assumed you had some other machine from which you wanted to send commands to control your lights using MQTT. From what you’ve described that is not the case.
I’m not sure what UI customizations are available with tasmota or esp easy.
OK, maybe I should have asked a different question. A lot of this stuff is new to me, and I’ve been doing a LOT of reading lately on how I might accomplish this. I have all kinds of buzz words floating through my mind, and I’ve been trying to figure out which ones I should focus my attention on to find a solution. To my newbie mind it just seems like OH & MQTT was the way to go be.
So at the risk of the topic becoming unrelated to OpenHab, here’s a new statement of my requirements & preferences:
REQUIREMENT: Turn on/off & dim two LED strips independently by a web browser in a cell phone. I’d really like to have the LEDs respond in real time to being controlled in the browser (ie get brighter or dimmer as the “slider” is actually being moved).
PREFERENCE: Use as little hardware as possible…one device to control the LED strips plus a cell phone to render the HTML would be awesome.
I’m pretty sure that it can be done with an ESP web server using WebSockets, but I’ve not been able to make a nice looking slider that renders well in Safari or Chrome on my Android phone & performs reliably.
Hello! I am also learning OH and I would do the same project in another way, I will comment to give my opinion.
I would use to control the LED lights a simple arduino, and from there pass it with a communication protocol to OH (I am studying the way to do it, I am currently investigating how to do the communication via Modbus RTU Serial but I have not found the way to make it work, capable with other communication protocols is better), either to a normal server or an RP.
From the arduino you can control with OH in real time via its application and web interface, all the requirements that you are commenting
From anywhere in the world or only when both devices are on the same network?
An ESP8266 (NodeMCU is one choice among many) is basically an Arduino with fewer GPIO pins and WiFi built in so you don’t have to figure out how to get it to talk to OH or anything else. You can just use HTTP or MQTT or some other light weight messaging protocol.
Using a plain Arduino will mean more hardware and more cost to achieve the same result.
My intent is that they will be on their own little isolated network with no routers, so whatever hardware is used needs to be able to be an access point (such as ESP, Pi, etc).
Least amount of hardware would still be a NodeMCU. You may need to research how to customize the web page presented.
Though I gotta say, while this is an awesome learning project, from a human usability perspective, putting a pair of lights in a confined space that requires a phone connected to a wifi network to nowhere in order to control them is really bad. It is almost user hostile instead of user friendly. Please at least consider adding a physical switch or something that doesn’t take half a dozen steps to turn off the light.
Actually yes, I intend to also have a manual dimmer on each channel as well with SPDT switches in place to choose between manual & WiFi control. But honestly we rarely have cell service where we camp anyway, so it’s no big deal to have one always connected to the private network.
I would just buy one of the arilux controller with ir remote, it comes with an app aswell and can b eflashed with tasmota if you need to connect it to OH at later stage.
This is the least of my usability concerns really.
Based on personal experience, and from what I’ve read in human factors and industrial design books any time the steps to control a like start with:
Find the phone
open the right app
navigate to the light control
It is not a very usable system. This is one reason I’m so negative on smart bulbs and the like. Even if you had a little local LAN in your camper and everything did have internet access, I would not see this as a very human user friendly approach.
