I have 2 Pi’s running OH 1.8, I’ve split the rules and bindings between them such that one sits in the background processing rules, doing Internet based APi queries and scheduling timers, and the other one runs the user interface and concentrates more on when this changes do that type rules. The bindings are shared between them.
After taking a look at OH2.0, and seeing the advantages of using the WEMO binding with my insight sockets, as well as being able to test the beta Nuki binding I’m considering moving the back end device to OH2.
This one hosts the alarm clock, so it has to be dependable. I’ve chosen this one rather than the main user interface Pi as that will be more work, and will need NGINX for authentication too.
Can OH2.0 be relied upon as a background server, or are there a few little bugs left to squash?
I’m happy to schedule a regular reboot a couple of times a week, if necessary, which I have to do with my main Pi to prevent it being unable to load part of the sitemap.
I cannot speak to individual bindings. I’ve found OH 2 core itself to be rock solid and every bit as reliable as OH 1.8. The quality and impact of individual bindings can, of course, change this solidity.
I reload my OH about once a week (I run in Docker and updating the image is part of my automated update scripts) and have experienced zero downtime. It doesn’t consume unexpected amounts of memory or CPU.
I am running the 2.0 Release in Docker.
There have been some reports in the past couple of weeks of OutOfMemory Errors but I think they have been reported on the 2.1 snapshot and the current suggested culprits are certain bindings, not the core itself.
Out of curiosity, what requirements/design choices lead you to running with this dual instance deployment? Reliability, too much load on the Pi, security (i.e. running the UI in a DMZ and the back end more protected), etc?
I do recommend the Migration Tutorial to guide your upgrade.
Thanks for the reply, that’s very encouraging
It started out when I upgraded to a Pi3, this left my Pi2 redundant, so I used it as a source of GPIO pins for expanding upstairs to monitor the doors, as it was way cheaper than going with something like Z Wave, it also allowed me to replace one of my cloud based Sensibo units that control the Heatpump with a copy of LIRC. The bedroom faces into the evening sun and needs cooling most nights, so this comes on automatically when needed, which was my initial reason for looking into OH.
As time has progressed and my system has expanded I’ve shared more of the load out to the Pi2 as I’ve ran into speed and stability issues with the Pi3 doing all the work by itself. This became especially noticeable after I created a 7 day, editable in the app, scheduler, which added an extra 192 items and a lot of code. I’ve also put all the scheduled timer type rules on the slave so they can run unmolested and I don’t get logs full of stack dumps if I accidentally edit the rules without cancelling all the timers first.
There are some significant problems with openHAB behind a reverse proxy, involving both https and proper mapping of URLs. At least for me, none of the UIs are working properly behind a reverse proxy.
I’m working on these now, but no promises.
If the RPi 3 is choking, you might want to look into the ODROID-XU4. At least in my experience, the ODRIOD-C2 is already superior to the RPi 3 in terms of stability and capacity. I purchase mine through the US distributor, Ameridroid, which I have no business interest in, other than as a consumer.
Thanks for that, due to the authentication hassles I may keep my primary as OH 1.9 and put OH 2.0 on my backend Pi. That way I get the advantages of the new bindings on one of them, together with experience running V2.0 ready for when security is built in. My Linux knowledge isn’t detailed enough (yet?) to reinvent too much of the wheel!
Whilst the Pi3 / Pi2 combination together with a few scattered ESP’s is adequate for now, its good to know more power, low power usage stuff is available
openHAB is reverse-proxied from a non-root directory.
As far as I’ve been able to determine having set up reverse proxies for OH and other services this cannot be done without changes to OH itself and the changes described in the linked Issue would not solve the problem.
If you reverse proxy as the root directory it works just fine.
The problem is the reverse proxy cannot add the non-root directory to URLs generated by the JavaScript in the web pages it is serving up. To support that OH would need to add a flag or somesuch to generate URLs and JavaScript that generates said URLs that include the non-root directory as part of the standard URLs. Of course, this would also mean that you can only access your OH through the reverse proxy. A change to jetty.xml would not fix this.
Based on what I’ve seen this would be non-trivial to support so I would expect it to be quite some time before it gets implemented. I would expect them to add authentication to OH 2 (thus eliminating the need for the reverse proxy entirely) before this gets addressed.
Funny, relative URIs work fine through a reverse proxy without any intervention, especially as they preserve the scheme – see further https://tools.ietf.org/html/rfc3986#section-4.2
I also wouldn’t trust Jetty exposed on the public Internet, but that’s another discussion entirely.
Agreed. Hence the existence of myopenhab.org for the non-technical users.
Agreed, because the reverse proxy basically does a find and replace on the URLs embedded in the HTML (if configured to do so). But it cannot modify URLs that are dynamically generated by JavaScript. Based on my experimentation that happens in BasicUI, ClassicUI, and PaperUI (I’ve not tested HABmin nor HABpanel). So unless OH serves up HTML with JavaScript that includes the non-root path as part of the URL the reverse proxy will not be able to serve up that UI on the non-root path.
Where ever it is performed it still doesn’t cause the JavaScript generated URLs to include the non-root path. It has been a long time since I did a deep dive into this. All I remember clearly is it cannot be made to work with dynamically generated URLs.
This is why Gogs, Calibre, and others have a reverse proxy flag that alters the JavaScript to dynamically generate the correct URLs. Otherwise, the static elements embedded in the HTML get modified to include the non-root path but the dynamic ones do not and only parts of the web page come across the reverse proxy.
Hi Jeff.
I am just in the concept phase of the homeautomation.
I own a Odroid C2 sbc and I would like to use it as OpenHAB server.
Do I have chances to connect the sensor network directly to it?
I wish that sensor network to be independent from the LAN/WLAN.
In this idea I think the use of RFM69HW (433/868MHz) would be a good choice.
(There is already a forum http:// homeautomation . proboards . com/board/2/openhab-rfm69-based-arduino built around this strategy/system.The gateway RFM69HW is tied to ArduinoUno+Ethernet_shield and this one communicates with the OpenHAB machine/server)
RFM69 has SPI connection.
What chances do I have to connect the radio module directly to the OpenHAB server?
I have read few topics related to serial communication (UART) with OpenHAB server.
I would like to eliminate the LAN from the sensor communication chain and make the server as gateway which communicaties directly with the nodes.
I know the C2 does not have SPI but it seems one FT232H breakout board will do the SPI_to_USB job.
Do you know somebody who managed to make a such working configuration (communication_device>SPI>openHAB_server (Rpi3/PC/odroid/Pine64)?
Pretty much none. When I set up my RFM69HW network I don’t think there was a Java version of the RFM69 library. And even if there were the likelihood it could be used with OH seems a bit low since all the RFM libraries I could find were licensed with GPL3 which I believe is incompatible with the Eclipse License. So, without a compatible library, one would need to reimplement the library and some more as an OH binding.
It will be far easier and far more flexible to run a Gateway and configure it and the network so it can only communicate on the localhost to OH. Thus none of your sensor network messages will ever leave the Odroid.
This would give you the same result with the only difference being that there is some software (i.e. the bridge) between OH and the hardware. But none of the sensor traffic will ever leave the Odroid, even if TCP/IP is used to communicate between the Gateway and OH.
Also be aware that you can encrypt the MQTT traffic (though I don’t think OH can use encryption with MQTT yet) and use ACLs to further constrain which clients can access which topics. Complete segregation is not the only option to securely publish the sensor data to OH.
I personally have an RFM69HW transceiver wired to a Raspberry Pi so I know that part if possible. I used and use a Python server to bridge between the RFM69HW and MQTT which OH talks. I used this library with my sensorReporter (the licenses are incompatible so I cannot release the code, but it is really easy to implement yourself).
Thanks Rich.
I still do not understand completely your setup.
Do you have a Rpi running OH and the same Rpi has a RFM69 radio attached? (This is what I wish)
If I still need 2 separate devices there is already a cheap solution for the Gateway: RFM69 > spi > ArduinoUno > spi > WizNet5100 shield > LAN > OHmachine.
So… the gateway is pretty cheap, no need to sacrifice a Rpi for that.
I am not good at linux. If I need some commands, I search on google.
My setup is as follows:
A Raspberry Pi with an RFM69HW transceiver wired to the GPIO. This RPi has a Python program that receives the RFM69HW messages and forwards them to OH over MQTT. A RPi that you already have that isn’t doing anything is cheaper than a new ArduinoUno. Plus I had other jobs for this RPi to do. It isn’t just an RFMHW69 Gateway.
A VM running on a server running OH and Mosquitto. OH receives the messages using MQTT.
I have is configured so the only client that can connect to Mosquitto unencrypted is OH and the connection is through a Docker net so this traffic never leaves the VM. The connection between my Gateway and Mosquittio is encrypted. I furthermore have ACLs set up so that only specific clients can publish or subscribe to their topics and no more.
But what I’m proposing for you is to host OH and the Gateway on the same machine (i.e. the Odroid) and configure the networking between the Gateway and OH so that this particular traffic does not and can not leave the Odroid. That will give you the isolation your desire with the minimum of effort.
Thanks Rich for explaining this.
I do not know how difficult will be to implement the setup on OdroidC2 since no SPI GPIO are present.
As I said, somebody recommended me to use FT232H breakout board over USB in order to have a good SPI communication…
(If this breakout board gets working, maybe I can use as OH server one Lenovo S10e netbook with broken screen I have. I do not know if it has enough computing power to it but for sure it is low power 
)
The reason for thinking of this setup for automation is to eliminate the LAN/WLAN from the communication chain. Routers/switches of the home network may fall due to power failure or lightning strike (I got 2 times the WAN port busted despite the good earth connection of the socket - my outgoing WAN connection is assured by a WIMAX antenna with PoE).
Anyway, the LAN is required for remote access.
offtopic:
Many hobbyists use the ESP8266 for the end nodes. This simplifies the system for sure.
I, personally, try to avoid use of standard Wi-Fi communication for sensors all the more so if there are actuators on the nodes.
Wi-Fi networks have issues: they are hack-able, can be jammed, interference with neighboring networks which are wrong set-up (same channel, high power).
I have more confidence on wired network but it is not possible every time and every where.
Should be powerful enough. Lots of people host OH on Raspberry Pi 2Bs and 3s (original Pis and Pi Zeros are not powerful enough).
I can’t comment on the FT232H breakout board and I have no knowledge or nor experience using the RFM69HW transceivers through SPI versus GPIO.
My recommended approach would achieve the same result. However, if you don’t have GPIOs or libraries to interface the transceiver with the Odroid that may not be really possible.
Another approach would be to attach an Arduino with the RFM69HW and use the serial binding to communicate with the Arduino over the USB serial connection.
RFM69HW’s encryption is actually pretty weak. You are mainly gaining security by unpopularity (i.e. not many people are trying to hack this network because no one uses it. A well configure WPA2 wireless setup is much more seccure and has more opportunities to discover and alert when/if someone tries to attack your network, none of which are present or possible in an RFM69HW network.
ALL wireless communicate can be jammed. RMF69HW provides no protection from this.
At least in the US, depending on your area the 315, 433, 868, and 915 MHz can be quite congested as well.
I can think of a lot of good reasons to use RFM69HW, I use them myself, but security and reliability are not among them. They are no more secure nor reliable to wifi. Some reasons to use them though include:
- energy efficiency, RFM69HW is WAY more energy efficient when compared to wifi
- range, RFM69HW can reach much farther than wifi, though be careful not to bump up against your countries regulations against powerful transmitters
- existing wifi network is congested with lots of devices already, moving sensors, particularly chatty sensors, could free up bandwidth for your other devices
- they are fun to figure out how to build and set up
Personally, if you need to buy a FT232H breakout board anyway, personally I would spend less on a Raspberry Pi zero ($5 versus the $20 for the breakout board), wire the transceiver to the Pi0’s GPIO and either let the Pi0 communicate with your OH server over the network or set it up using a USB connection:
I think in the long run you will spend less money and far less time.
The situation is not like this.
I can buy Arduino Ethernet shield with ~$4.
The FT232H breakout board is ~$7.
I already have one Arduino Uno and few Nano’s bought with ~$2.5 each.
I can buy RFM69HW with $2.5
(Think about all these are clones from China and there are free shipping to Romania)
While one Rpi0 costs $25 (Aliexpress), $11 (on Romania website stock 0)+shipping.
The $5 price is just advertised.
I guess it is a problem of availability. The last Pi 0 I bought only cost me $5 from a reputable supplier.
No matter how you slice it though, I still think using the USB serial connection and having the transceiver wired to an Arduino (since a Pi 0 is out of the price range) will be cheaper in the long run, particularly when you consider the cost of your time.
You are very lucky if you can rely on 433MHz devices. Around here they only work reliably in my garage in direct line of sight for around 5M, and even then my RFM69 based energy monitors struggled to communicate at that distance with their longer packets colliding with other devices. I need to send commands at least twice to ensure any measure of reliability with my remaining devices. The 433MHz radio channel is almost saturated around here with weather stations, security systems and various other sensors competing to grab the single channel, and it’s got a lot worse over the last couple of years. I’ve switched to ESP8266 devices and don’t have any problems with those as WiFi has a level of error correction, although the RFM69’s can have packet acknowledgments turned on if used between Arduino’s.
What size antenna are/were you using on 433MHz out of curiosity. I’m not far from several airports so I’m pretty sure 433 is impossible for me, but 915 MHz seems to be enough to cover my house (I think 915 is only legal in the US though), though just barely to reach the basement. I have lots of lost messages too for the farther away devices but it is just sensor data and missing a reading here and there is no big deal.
I keep reading all these blog postings of people passing messages using these things over miles. I’m not sure how they do it…
But yes, as a wireless protocol, WiFi will be just as if not more secure, be better able to deal with noise in the environment, and be far easier to configure and use.
The RFM69 python library I use on my Gateway also supports acks, for what its worth.