New OH3 project

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.

@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.

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

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.

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.

From what happened when they shut down the Squeezebox line, I think we can be somewhat optimistic about their servers: Despite the SB line being shut down about a decade ago, is still online. I guess they’ll shut down the servers when nobody is using it anymore, and that probably won’t happen anytime soon.

1 Like

Don’t forget: logitechmediaserver is still under active development, stable version is 8.3.0 from nov/04/22.
And sqeezeboxes will not stop working even if is shut down.

Bit more investigating and it looks like the LIRC project is still active and commercial USB/IR dongles are available.

Now thinking more about automating around an MQTT message bus. Been a while since I used MQTT, but may be a nice way to provide another layer of device abstraction. And simplify development for devices without bindings.

One issue may be performance, especially for AV functions. I’m still wrapping my head around automation vs control. “Watch AppleTV” is a command that hides a bunch of automation (turn on the TV, AV Processor, Amp, (if they’re not already on). Switch inputs to the right port, set volume to something reasonable). It’s fine if that process takes 5 seconds. Then while watching if i hit “pause” I need sub 100ms response.

Climate should acknowledge a command immediately but it’s ok if it takes a few seconds to command all the devices.

Is OH3 on an RPi4 likely to provide that sort of responsiveness?

It definitely should be capable to do “immediate” response. It’s more up to the hardware, how long a command take to be executed.
I don’t use speech control in my home, but from my smartphone I’m pretty sure that the most of delay will be produced by telephoning with Langley, Fort Meade, or whoever needs to know what I’ve said…

Yes it does. If you want that voice-controlled however you need to have Alexa or Siri integration do the speech recognition for you, though.

I do have alexa-integration and it works fine for commands and stuff. What I do see, though (don’t have an impact on OH3) is delayed push messages on my Alexa App on my smartphone. But it works real-time.
sub 100ms is a bit sporty, you still have to tell “Alexa, stopp Apple TV”.

1 Like

All great feedback. For now I don’t care too much about voice integration.

Jumping to the other end of the OH3 stack:

For climate I have a serial port as the “Thing”. Thermostats for a zone are addressed via ASCII commands where each 'stat has an ASCII address - which I guess I represent as channels and items.

A zone in the house has one forced air 'stat and many radiant 'stats. I’d like to represent each zone in the UI with a single custom widget that only presents “Heat/Cool/Off” and “Set Temp/Actual Temp”. Then have a setting icon to open sub panels that represent day/night offsets and offsets for individual 'stats.

Any pointers to examples? First question is whether best practice is basic UI, HABPanel or something else.

I’m a little unclear on how to separate the business logic representing 'stat behavior from the zone configuration. And how to write the logic so I can instantiate it multiple times and populate it with the right stats.

Also looking for more examples on how to write custom widgets. Is it all YAML or is there an option to write widgets in HTML/CSS/JS? If there’s a way to populate a couple fields in a standard widget I’m happy to start there. But what I’m seeing is each widget is mapped to a single item - which can’t be right! Or I might be misunderstanding how to use hierarchy in the UI. But I have a strong preference to promote a basic multi zone climate view to a single page.

This is a little bit of a mix of both command and automation.

Fully automated would be if it knew when you wanted to watch Apple TV without you needing to do anything at all. That’s not always feasible but where it is it’s so much better. In my home, the only time that most of the family notices that something even is automated most of the time is when it fails to work. Then all of a sudden it’s “why aren’t the lights on?”

Unless there’s something going on like you’ve installed a bitcoin miner on your RPi 4 or loaded it up with so many services you’ve run out of RAM, any problems with responsiveness lies outside of OH 3 and the RPi 4. Some technologies can become overwhelmed if they receive too many commands too quickly, for example, Some cloud API calls could add significant latency.

But on a local network OH 3 and MQTT should be plenty fast enough, especially with QOS 0.

You might consider what is it you are hitting pause with in the first place. If you need to bring out your phone, open an app and start tapping on the screen to do common every day stuff like watching TV or turning on the lights, you will be getting the eye rolls. “How is this easier than just using the remote?”

Just because you can integrate it into OH doesn’t mean you must. Perhaps it makes more sense to kick off a TV watching session through OH (perhaps using a physical button or the like) but actually manually controlling the volume and pause and the like is managed through the Apple TV remote.

If OH touches it does not mean that OH is the only way to use that device. In fact, it’s better (IMO) when there are other ways to control a device. The system is more robust that way (escalators verses elevators).

I think most in OH 3 are using MainUI. BasicUI is, as the name implies, basic. There’s not a lot of capability or customization available there. HABPanel is much more flexible but also requires a ton more work to build a panal. HABPanels are also not dynamic. If you have a tablet and a phone, you’ll have to build separate panels for each. They don’t handle scaling based on screen size very well. MainUI provides a medium point where you can get the basics with very little work but you have a high degree of customization available.

I’ve a similar simple widget for my single thermostat (I’ve not put it on the marketplace but can if someone wants it). It combines three Items actually letting me set the mode of the HVAC between heat, cooling, and off, set the target temp and is shows the current temp.

This could be expanded to apply an Action to one of these subwidgets to open a panel to show additional widgets.

But, you also might get everything you need through the semantic model. There are three tabs in MainUI that automatically get populated based on the semantic model: Locations which shows all your devices and Items based on where they are physically located, Equipment which groups all your Equipment of the same type together, and Properties which group all your Items based on what property they represent (e.g. Temperature).

Maybe you don’t need to do much of anything to get a UI that works close to what you want.

“Behavior” is going to be handled by rules (see the Getting Started Pages on Rules).
“Configuration” is going to be stored in Items (see the Getting Started Page on the Semantic Model).
“Zones” will usually be represented through the Semantic Model (see the Getting Started Page on the Semantic Model).

Don’t do that. Write one rule that handles all your thermostats. There are lots of techniques but in general it involves:

  1. Putting the triggering Items into a Group
  2. Naming your Items so when you have the name of one Item, you can build the names off all the other associated Items (see Design Pattern: Associated Items)
  3. Once you have the names of the Items, the rule can run through its logic for that thermostat.

Another option is to use one of the rules languages that support libraries and put the logic into a personal library function called by multiple rules.

Rules can call each other and pass “arguments” so you can achieve some reuse like that.

Finally, you can create a rule template and instantiate multiple rules based on that one template. But there really isn’t a way to install a template unless it’s published to the Marketplace.

It’s all YAML. It’s built on the F7 framework and there is some ability to do some CSS. But for the most part you are configuring and combining custom OH and/or F7 building blocks.

There is a webview widget but there really isn’t much that you can’t get with the build in blocks. But you don’t need to write a custom HTML page to do this in MainUI.

See Pages - Custom Widgets | openHAB.

In fact, please review/rereview all of the Getting Started Tutorial as most of the answers to these questions should become answered there.

You can also integrate OH3 with other things like NodeRed which would then give you control to other devices like the AppleTV through OH3.

Nearly all of my OH3 info is pushed to my AppleTV and other Apple devices.

I also use NodeRed to push my camera feeds to my AppleTV

Check out Global Cache for Network IR & RS232.

It has a binding for openhab GlobalCache - Bindings | openHAB

Currently using a Global Cache product to control TVs and devices throughout my home and devices connected to the HDBaseT matrix.

I’ve managed to connect a device with discoverable channels to the UI that I can turn on and off. Very basic.

I’m struggling with the Serial Bridge. I have a bank of thermostats that are addressable over RS232 with commands like

SN#Command? for queries and SN#Command=Value

Checking the room temp on the 3rd thermostat:


Adjusting the setpoint in the 5th 'stat is:


I’ve set up a THING as the serial bridge. I am just not seeing how to set up channels through the UI. Is each thermostat a separate channel? I assume I want each 'stat and Zone represented as an item. And then I want a bunch of commands I can send: query the room temp, command the mode and setpoints.

Is there a video or more instruction on how to set all this up through the UI? I assume I need transformations to insert and extract 'stat ID and command (like string for TEMP or string for MODE).

Step 1 is I’d just like to query the setpoints and room temps and present those in the UI.

I’ve read the tutorials and they are more text config oriented than UI oriented. Am I trying to do something that’s beyond the UI capabilities?

Please mind the posting rules and open a new thread.

How to ask a good question / Help Us Help You - Tutorials & Examples - openHAB Community

Sorry. My perspective is this is all part of the “new user, how do I get started” thread.

It is, but at this point your original questions have been answered. Future readers will benefit more from separate threads, and you’ll benefit from being able to categorize/tag those threads so that others with expertise will see them.

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.