New OH3 project

1

I’m starting a project to replace a nearly 20 year old AMX system. Evaluating open source alternatives. Is OH3 recommended for new designs?

My goals are to support whole house control including HVAC, AV, Lutron. I need support for control over IP, IR, dry contacts, EIA232, EIA485, BT. I also need to integrate standalone remote controls for AV to make the system very friendly to non-tech users.

I like the overall OH architecture. Would appreciate pointers to more example implementations. For example how to configure an AV system with a screen, processor and multiple sources, focusing on how to use groups and rules. Pointers to standard widgets I can use to set up device control, like an AppleTV, would also be helpful.

Thanks in advance for any help or advice

2

I don’t know how to interpret this question. OH is a platform upon which one can build a home automation system. So if that’s what you mean than yes. Truth be told, it’s probably best suited to new designs rather than working with existing designs.

This is probably the weakest part. OH is primarily focused on automation, not control. You can do it but it’s going to take a good bit of work. I’ve found the best way to consolidate and make AV systems easier to use is to get streaming devices (Roku, Google TV) and CEC enabled sound bars.

Start with the Getting Started Tutorial. That shows you how to go about constructing your bespoke home automation system. It starts with bindings/Things which is how OH connects to your devices. Moves on the Items and the semantic model which normalizes all your devices into a common language (i.e. Items). From there it spends a lot of time on the UI to build controls. Finally it covers rules which is how you define the automation behaviors.

There is no end-to-end tutorial for an AV system (for example). There are so many specific details involved such a tutorial that is exactly what you need would be impossible. You might find a tutorial for connecting to a Yahama XYZ123 amp and another for how to connect to an Epson Projector 567. Others that show how to build a rules to do this or that and still others for creating/customizing widgets. You will have to piece together individual documents and tutorials to develop your bespoke system.

As for widgets, there is the marketplace which has widgets and rule templates. But the standard set are documented at Component Reference | openHAB.

The big thing to realize is this is going to be a development effort. It’s not mere configuration. You will need to spend time and iterate over it as you build it same as if you were writing software or designing and building a chair.

1 Like
3

Rich,

Thank you for the quick response. Confirming some of what I gathered from reading the tutorials. I have a lot of existing gear I need to integrate. I have the impression AppleTV is a bit of a weak link. I may need to cobble something together using IR or BT rather than direct IP control if I’m reading the info correctly.

Will try to post some integration info as I learn more - for example how to control Aprilaire thermostats over EIA485 using an IP serial server as a bridge. Also exploring how to integrate a BT remote control using an RPi as a bridge.

Not sure I fully understand the difference between automation and control, but expect it’ll be clearer after I spend more time with OH.

My big question is really whether the dev and user community is very active, since that translates into ongoing new development.

Thanks!

4

The dev and user community is very active, but as with all things open-source, development ebbs and flows. The OH core is in constant development, but a binding maintainer can disappear at any time for any reason.

Automation means that when something happens, a rule is triggered and OH takes care of the rest. For example, a light switch is turned on and another light also turns on, but only if it’s a certain time of day. It’s about minimizing human intervention.

Control is the opposite: creating user interfaces so that humans can intervene at any time.

Ideally, your home-automation system balances both of these things. You want to automate anything that should happen 99% of the time, and have manual control over anything that needs to be flexible. You also want to be able to override automation in the 1% of times that you don’t want it.

The key is that your users should never have to fight your automation. For example, you could automate a TV such that every time it turns on it goes directly to a specific channel. However, that would be annoying if you only want to watch that channel 30% of the time. Automate to the point where decisions must be made by humans, and then provide simple controls for them to use.

I have a bedtime routine that shuts down my computers and turns off the lights in sequence, while also turning on my bedroom/bathroom lights. All I ever have to do is say, “hey Google, it’s bedtime”, and everything just happens without me needing to think about it.

I get that your solution needs to account for everything you’re already doing, but I think you’re probably overwhelming yourself right now. This is common when people have a lot of equipment that they want to integrate, because they don’t want to waste time on something that won’t meet their needs.

For this reason, I always recommend that people get started by setting up openHAB and then getting one very simple WiFi switch/outlet/bulb to work. Getting a quick win makes it much easier to grasp the concepts, which you can then apply to more advanced integrations. Starting with too many different things and too many complexities generally leads to frustration if/when something doesn’t work the way we think it’s supposed to, and makes it harder to troubleshoot (particularly when our pride gets in the way). It’s a longer path to your eventual solution, but getting the basics down will make it easier to visualize how all of your stuff will work in openHAB.

You can trial openHAB by installing it on pretty much any computer, so there’s no cost other than time. I don’t know how easy/hard it is to add Lutron devices, but I’d start with those to get your feet wet.

3 Likes
5

Because I can, here’s a snapshot of the forum statistics from the last month. It ebbs and flows but in general the activity has been pretty steady recently. When 3.4 is released in December I expect there to be a spike.

image
image2278×1686 412 KB

And here is a snapshot of some of the development activity on github.

image
image1982×1950 396 KB

Pay attention to the “updated” times. (I couldn’t find a better statistical view). Every repo in this screen shot has had at least some activity in the past 24 hours.

You can judge yourself but I’d say it’s a very active community.

I don’t really have anything to add to @rpwong’s explanation of automation and control. Home automation works best when it’s automation. When control is the focus you end up with eye rolls and “why can’t I just do it the old way?”

I’ll second the advice to start small. Resist the urge to do too much all at once. Once you get going, resist the urge to add stuff to OH just because you can. Be deliberate as you build your system. Make sure you are solving a real problem and that your solution is better than the traditional “dumb” way of doing things.

Finally, think about failure modes. What if OH goes down? What if the network is offline?

5 Likes
6

Thanks for all the helpful suggestions. Got one device connected to just prove out the framework.

For my first integration I want to control my climate which is reachable over RS232 (through an RS485 converter). I have ethernet RS232 and RS485 servers. It looks like I can use the Modbus binding for my 485 converter.

The simplest way to connect the RS232 converter would be to add drivers and pseudo tty ports to Haspbian, but I don’t see how to update drivers with the standard install. My serial devices are Moxa 5110 and 5130 which I use extensively for device control. Is it more natural in OpenHAB to develop a binding vs just adding the drivers? How do I start a shell to download and install the drivers? I have a console shell running via ssh if that’s the right starting point.

Asher Waldfogel

7

On Linux one typically does not need to download separate device drivers for tty devices (most devices really). A quick look at a data sheet for the 5110 shows

  • Linux Real TTY Drivers: Kernel versions: 2.4.x, 2.6.x, 3.x, 4.x, and 5.x

I don’t know exactly what kernel bullseye is running, but I’m pretty certain it’s a 5.x kernel.

There should be nothing to install. However, if there is something to install or something specific you’ll need to do, you’ll need to research how to get these specific devices working on Linux.

That’s not how it works. openHAB is going to use what ever interfaces the operating system makes available to interact with devices. You can’t get around a lack of drivers for the OS by writing an add-on. You’d need both.

In this case, assuming that these things speak modbus, you don’t need to write an add-on. Use the modbus add-on. And at least for the 5110 you don’t need to do anything more than just plug it in and find which device it appears as under /dev/tty (note, in Linux everything is a file. The files under /dev represent hardware (dev → deices)). When you plug in the device, a new file will appear under there.

Note, if you have more than one tty device plugged in you may have to do a little bit of work to create a “premanent” file that represents that device. Otherwise, they show up on ttyUSB0 or ttyUSB1 based on the first one it happens to see when the OH reboots.

8

The gap is the 5110 is on Ethernet, not USB so there’s no auto discovery. I have to manually load a Linux driver to support it. The Linux driver creates the pseudo tty devices.

The 5110 is an RS232 bridge.

It appears I can configure the 5130 (that’s an RS422/485 bridge) using the Modbus binding over TCP.

Is there an equivalent binding for RS232 TCP/IP serial devices? My plan is to use the Modbus device, but I’d like to validate control over RS232 first using the existing RS232 to RS485 protocol converters

FWIW i use Moxa because they write absolutely bulletproof drivers.

9

Don’t know. I prefer to stick to much higher level protocols and technologies. I doubt there is auto discovery for anything like these serial devices. Search the add-ons repository for RS232 and see what, if anything, comes up.

As for the drivers, how to install and configure those will be documented on the vendor’s site.

10

Understood and thanks. I guess the direct question is “how do I start a shell in the openhabian distribution?” Is there a way to load drivers from the console?

11

That’s a shell. You’ve already done it.
“shell” and “console” are synonymous in this context.

:person_shrugging: What do the instructions from the vendor say? If it gives you a bunch of commands, use that ssh session. That’s a shell. That’s a console.

It might be worth while going through a generic Linux tutorial to get a little more familiar with the terms and ways to do things in Linux. Working with low level protocols like this means you will be spending some time doing operating system level stuff which is beyond the scope of OH generally.

12

In question of drivers, see NPort 5100 Series - General Device Servers | MOXA, then filter to Linux Kernel 5.x, voila, one tiny .tgz. to download. Instructions inside. (README file)

13

Please don’t start with that.
As @rpwong well suggested you should setup something simple first to get the OH basics right.
Yes the Modbus binding is the right one for this use case but it is complex to get it right and even more so if it doesn’t work out of the box because your remote bridge device does not support Modbus/TCP.
(That’s about one of the hardest integrations possible. Just did one such myself, and it took months, and I’m a OH pro. Taking this route as a beginner will warp you directly to frustration).

As you’re still very much thinking in how you’ve built your old installation and keep talking about “drivers” I wouldn’t think you have gotten that OH concept fully right.
OH needs no drivers. It talks the device protocol through bindings and does so via either IP or a plain serial interface.
So all you need when you want to attach a RS485 cable is a serial port and the OH host’s OS to have a generic serial driver, but any Linux has it so no need to mess with that. If you want to keep using your converters you might need to install a driver to simulate a remote serial interface locally, yes.
BUT: don’t try to move 20yr old concepts of your existing installation to use “direct wiring” (eventually tunneled via Eth) over to a new OH system at all cost, that’ll do more harm than good. There’ll be issues with timing, retransmissions and such.
Figure out how to attach your device to OH easiest before thinking if to reuse any of your gateway/tunnel converter hardware.
(BTW RS485 is downwards compatible to RS232 so both bridges should do with Modbus/TCP binding. If one of them does not, then the device behind is probably not Modbus and you should look for a different OH binding).

That statement on concepts also applies to the server. A good time to spend some thoughts on that is before you start implementing on the HW or even OS basis of your old server.

Are you coming from Home Assistant ? Then you really shouldn’t be reusing your server as-is.
Get us the details please.
If you meant to say openHABian, you can install drivers just like on any Debian.

14

just to add my 2 cents:

  1. try to find a “native” openHAB binding for your device
    if there’s no binding -
  2. does your device offer a HTTP/MQTT/…-API? use that with http/mqtt/…-Binding
    if there’s no local API -
  3. look out for others with that same device on the internet: best place is of course github.com and find a way to use that
    if there’s noone using your device on github
  4. write your own integration depending on your skills and interface type
    4.1 with an existing openHAB binding like serial, modbus, …
    4.2. with whatever vehicle is best (ESP32, python/php/… script, …)

Let me state an example:
My heating controller uses RS232 for read-outs and commands.

ad 1: there’s no binding for it
ad 2: there’s no API
ad 3: there was noone on github using it
ad 4.1: I don’t know if it’s even possible to use serial binding and convert the hex-byte-code
ad 4.2: so I wrote my own python script ( with the help of an internet blog using similar hardware, I found on accident.). The script runs on a Raspberry Pi zero right beside the heating controller. It sends the information (temperatures, states of valves, etc) via MQTT to openHAB and reveives commands (vacation state) via MQTT and relays it to RS232.

I did the same for my gas and whirlpool S0-Counter, but with an ESP32.

For a start into openHAB world I also highly recommend with a native openHAB binding to understand the concept of openHAB (e.g. weather binding and your Lutron devices) and working slowly from

  1. “I can control my blinds, if there’s rain/frost/storm outside”
    to
  2. “I can talk to my RS485 devices and automate them”.

good start!

15

Thanks everyone. All good ideas and I’m already looking at the MQTT approach.

Couple early learnings:

  1. The standard Openhabian release is so stripped down it’s hard to load and build 3rd party drivers. I reflashed my Pi4 to generic PiOS 32 bit, and found the current release of the Moxa driver doesn’t build with the latest kernel headers. Have reached out to Moxa for support

  2. Lot of suggestions to redesign the building. My project is to migrate away from a legacy AMX system. Most of the equipment was installed in the era when RS232, Modbus and some telnet was cutting edge. I don’t want to replace that equipment yet so I have to integrate it on its own terms. My AV equipment is newer and some of it has supported network bindings, but even there I have some pieces - like HDMI switches - that have RS232 control. So that has to work.

  3. Raspberry Pis are very scarce this year. That slows down testing and implementing some good ideas for Pi-based MQTT integrations.

  4. Whatever I do needs to be supportable. I don’t expect to look at the code every day or week so there needs to be enough documentation I can figure out what I was trying to do in the first place

  5. All the responses show there’s an active community. That’s reassuring

16

That’s by design really. But you should be able to install the missing compilers, build tools, and headers.

It might be possible they don’t support ARM. That’d be odd though but who knows. If these are really old maybe they were built before RPis and their ilk became popular. Moxa support should be able to help with that.

I don’t read it like that. I think all the suggestions are to not try to do the hardest thing you can do with OH as the first integration you attempt. OH is big, it’s complicated, and it requires a steep learning curve. So the suggestion is to find something simpler and easier, perhaps even something that doesn’t require any hardware (e.g. one of the weather bindings, Astro, etc.) first to get some experience with openHAB under your belt.

Only once you are a little bit comfortable with OH pursue RS232 , RS485, and Modbus type integrations. Those are going to be hard no matter what and trying to pursue that at the same time as learning OH concepts and how they all work is going to make it exponentially more challenging to reach your end goal.

And as you learn how OH works and other options you may have available for integration, you may find alternative approaches might be better than marching down the direct integration between OH and the RSXXX interfaces directly. But maybe not and that’s OK too.

OrangePi, BananaPi, Pine64 and I’m sure many other SBC makers might be alternatives while RPis continue to have their supply chain issues.
Or perhaps you can get started on some of these with an old laptop/desktop sitting in the closet doing nothing or on your main computers in a VM or the like. One of the great things about OH being a Java program is it’ll run just about anywhere that has sufficient resources.

From an OH perspective:

  • take advantage of automatic discovery of Things where possible
  • use names for Items that have meaning to the users of your home automation (“LivingRoom_Lamp” is a much better Item name than “ZwaveNode002Fibaro0234WallSwitch_Switch1”).
  • in the UI take advantage of documentation fields: location, name, description
  • in text configs take advantage of comments
  • where feasible, install and configure stuff from the marketplace instead of coding things yourself
  • use source control (yes, source control can be done even for managed configurations done through the UI) to track your history of changes

Beyond the OH perspective, look into one of the many “infrastructure as code” options. I know this is throwing new things to learn on top of new things to learn but it’s amazing how freeing these can be. I run all sorts of services: Plex, Nextcloud, Mosquitto, Zabbix, Librephotos, Vaultwarden, etc. I couldn’t tell you how I installed and configured any of them from memory. But because I use Ansible, I don’t need to. It’s all there in my playbooks. And what makes it even more wonderful is that if I need to do it again, I still don’t need to remember how to do it from memory. I just need run the playbooks again.

17

@awald, I fully agree what @mstormi and @rlkoshak said above. I migrated my rs232/485 converters (Moxa Nport 52xxx) under Homeseer home automation software to OH3 with rs485/tcpip converters (Moxa Mgate) nearly a year ago and I’m really happy with OH3 even though the learning curve was rather steep as mentioned above but it was worth all the effort. I’m still trying to learn how to integrate InfluxDB+Grafana to OH3. As @mstormi mentioned above it can be somewhat difficult to integrate Modbus devices to OH3. Each manufacturer seems to have their own implementation for their Modbus protocol so you need to know the Modbus register map for your devices. I was very lucky when I started to integrate my Modbus devices to OH3 because @rossko57 walked me through the Modbus integration. I also tried to use Modbus serial integration but I noticed soon that Modbus tcpip is lot faster. I have bought my Moxa Mgate (3170, 3180, 3480) units mainly from Ebay I have been really happy with Moxa products. Good luck with your project.

18

Just to close out the driver issue, I opened a trouble ticket with Moxa yesterday that their drivers wouldn’t build on Raspberry Pi OS (kernel 5.15.61). By end of day Moxa sent me a link to a new driver source that I built and installed. Can’t say enough good things about Moxa’s tech support and product quality. Remote serial ports are now exposed as /dev/ttyrXX.

Will definitely run some experiments on serial vs IP integrations when I get to this. Moxa also supports TCP modes and I’m sure this will be yet another interesting project. I have enough test equipment I should be able to see what’s going on when I get to that.

I’m taking seriously the advice that Modbus is a tricky integration, but I wanted to verify connectivity before moving forward with other aspects of OH3.

Speaking of connectivity, is there a best practice for remote IR connectivity? Serial or Ethernet is fine

1 Like
19

Harmony Hub used to be the gold standard I think but Logitech dropped support for them and I’m not even sure if you found one in eBay that you could get it set up.

I know of no other commercial offering but I’m sure there are some niche offerings by av/conference room companies. you’ll have to research what’s available there and whether it can be integrated with OH.

I know some people use diy systems using RPis and/or ESP microcontrollers and ir leds.

20

They haven’t turned the servers off, but there’s no telling when that will happen. I have two Harmony Hubs that I use every day, and when the end comes I’ll probably just upgrade my nine-year-old TV and use its remote.

If we’re lucky. Logitech will send out one last update to make the Hubs standalone…but I’m not betting on it.

@awald, I think the best solution right now for IR control is an RM4 Mini. I bought one to test (in preparation for the Harmony Hub’s demise), and I’m using it for IR control of a cheap LED string light through openHAB. The binding is unofficial and hasn’t been updated in a long time (the developer disappeared), but it works flawlessly with OH 3.3.

If you buy one, make sure to get it with the temperature/humidity sensor in the USB cable.

Here’s the binding.

And here are the instructions for getting IR codes into openHAB. You need to do this if you want to send commands directly from openHAB.