I'm at a crossroads

, , ,
1

I’ve been using OH for a few years now, and pretty pleased so far. Took me a while to warm up to OH3 UI, but recently I have transfered my item and things to UI based config, but my rules are still 95% DSL file based.

However… There some things I would like to connect to… My Brother Laser printer, Tuya smart bulbs (no luck so far), my IP cameras (again no luck) That is just current things.

After my failed attempts at these in OH, I looked at Home Assistant. All three of these devices were discovered and just worked!

A big one I’m looking at the Eagle 200 home energy monitor witch is in HA but an undetermined status in OH3

So I then started looking around HA and while the device discovery seems really good, when I started looking at automations, scenes, etc. I started seeing some really stupid design decisions… For example there is no Date specific triggers for automations. There is groups, but they are type specific. No mixing lights and switches without “helpers”. These are cludgey work arounds to make lights look like switches, etc… Very goofy, IMHO. OH3 seems MUCH more robust in organisation and usability

Now my crossroads… I want to stay with OH due to my (perceived) impression that it is more robust and well thought out, but I also want access to more bindings/integrations that HA seems to offer. Not to mention the LARGE amount of content/tutorials/ that are HA centric.

Is this possible? I was thinking of somehow using an Amazon echo or Google home to act as an intermediary between devices and OH.

How do you all handle devices that aren’t supported in OH?

2

I research the devices before I purchase them and I make sure they work in both HA and OH. Then if a device does not work in OH, but seems like the best fit, I’ll then write the support for the device myself.

Regarding Tuya I would caution the use of them, the are known to break the Zigbee rules and have issues with other Zigbee devices. In the case of WIFI products of theirs, you can sometimes install Tasmota onto them and that is the way to go, as you then get support in both HA and OH. BTW Tuya just dumped the support for the HA integration they were writing so that may affect your decision. If you did not know, there is also a Tuya binding in smarthomeJ here:
smarthomej/addons: SmartHome/J addons for openHAB (github.com)
All my Tuya stuff has been turned into Tasmota.

Which cameras do you own?

Lastly there are some people that run both and use MQTT to bridge between them. There is a post in the solutions part of this forum on how someone does it and a binding may have been written to help, but I am not sure on the details.

3

There are a couple of ways:
If it is just one way (e.g. Sensor/Meter) I check if there is a python → mqtt solution available. If not I check if there is a python library which supports the device. If the device offers a rest api it’s easy to integrate with some reading of the docs.

Before buying new devices I check that they either work with an open standard (e.g. ONVIF for IP-Cams) or that they have some kind of local API which allows access.

4

And now for the non-developer opinion. :wink:

I have Tuya WiFi devices that can’t be flashed with Tasmota, so I’m using the Smarthome/J binding. It works great, and most devices don’t require Internet access after they’ve been added.

I wouldn’t suggest using either of these services, as you’ll most likely be dissatisfied with the lag. I can’t speak to Alexa, but there’s always a delay with Google Assistant due to the polling period.

As the others have suggested, MQTT would be a reasonable bridge. And since you can run it all on your home network, the lag will be minimal.

I don’t have an opinion on HA, since I’ve never used it. Based on what you and others have said, I’m inclined to think that HA’s design reflects a very different perspective from OH. Hence why people move in both directions and declare the new one to be so much better for them. Both perspectives are valid.

Honestly, I would give HA a shot if it has all of the integrations you want/need, with an open mind toward how it’s designed. If you’re able to embrace that viewpoint, it may be a better fit in the long run. If not, then you can either stick fully with openHAB, or use an HA server as a bridge for a handful of items.

I’m less inclined to recommend running both OH and HA. There’s no doubt that it works, but the more you frankenstein your system, the harder it will be to update/maintain/restore over time. Personally, I would not welcome the added complexity. Others would be fine with it.

As with all things, there’s no perfect solution. It’s just a question of trade-offs.

If I want to integrate devices into OH then I make sure they’re supported in some fashion before I buy them. Alternatively, I buy devices knowing that they probably won’t work with OH. The Nest Protect is a good example: it doesn’t work with openHAB, and it doesn’t look like it ever will. But it’s an excellent smoke/CO detector and that’s all I need it to be.

I’m personally very optimistic about Matter/Thread, and hoping that it will eliminate a lot of these “what works with what” questions. However, I think that’s going to take awhile. I’m not going to rush out and buy a Matter device until someone figures out how it’ll work with openHAB. Once it does, there’s a good chance that I’ll lean toward only buying Matter/Thread devices.

2 Likes
5

You summed up HA vs OH pretty well imho.
HA is extremely good at how easy it is to add things and build nice pages.

OH is way mir robust on the Modeling and automation part. The additional layer of things and items makes you much more flexible. In HA a light is a light. In OH you have things with channels and items that you can freely combine.

Complex scripts and rules in HA can be a pain. On the other hand, building awesome looking home screens is quite a bit easier with HAs system.

6

As for Brother lase printer - which model do you have? I found that lots of them are fairly easy to integrate with without dedicated binding, only by using SNMP binding itself.

7

I have a mixture of Hikvision and cheaper TPLink cameras. The Hikvisions are great within Openhab if you use the line crossing detection trigger for rules. I run the TPLink cameras through Motion on the same raspberry PI to trigger motion alerts and to convert the stream to display on the same web page of all my cameras.

image
image754×674 103 KB

I don’t think I’ll ever change from using classic sitemaps and coding rules just for the flexibility it gives you. I very rarely use the controls most of my interaction with OpenHab I try to automate or use Siri via the Homekit integration. I did try to adopt the OH3 UI but the classic sitemaps just feel much more solid.

8

If you have HA and OH running, you’re almost there. Use MQTT to communicate between the systems. HA has a feature called MQTT Statestream. Use that and a few (simple) automations on the HA side and you are up and running.

I run both for this exact reason. I treat HA as an additional “binding” that lets me integrate devices OH cannot.

1 Like
9

If you know, what’s “under the hood” and keep track of changes and “I did this with software/framework X”, it should be no problem using HA, OH and let’s bring it others as well.

The biggest “no-go” (at least in my opinion) is to use devices, that rely on proprietery hardware or cloud access only. These can be integrated in pretty much all environments, but either lack privacy or are at risk of discontinued - or both.

In my current use case of integrating my newly acquired Fiat 500e: there’s no “standalone” script available (e.g. there’s bluelinky for Hyundai/Kia and scripts for VW, Tesla, …), I’m currently on my way to use the HA-integration with UConnect (Stellantis cars) and just send out the values via MQTT and receive commands via MQTT also.
for me it’s only another way of “integrating” my smarthome data and commands. No big difference between integrating a Python/PHP/… script vs. using Home Assistang or another “software”…

tl:>dr;
I pretty much let all my smarthome data/commands/… run over MQTT. So I’m pretty much independent on how to utilize these. In theory I could also remove OH as my central smarthome hub with any given framework/software - as long as all integrations run over MQTT as it is right now.

1 Like
10

hehe - I wrote a whole bunch of paragraphs, but you summed it up in one sentence! :wink:

2 Likes
11

I have a MFC-7860DW. I’ll try the SNMP binding tonight. Thanks.

12

Some hints on snmp thing:

It may be disabled o default. Try to look settings in web configuration panel of the printer.

You may need a snmp browser, like snmp walker or sthng to browse all resources exposed by the printer. I bet it will be more than couple hundred endpoints :wink:

13

Yeah, I’ve tried the smart plugs with great success, but the tuya bulbs…nothing. I didn’t know Tuya pulled support. Interesting… In the past I’ve flashed Tasmota with great sucess, but the new Tuya stuff isn’t Tasmota compatible that I know of.

I have an old chinese piece of garbage which works in HA and my android Onvier app, but haven’t had ANY luck in OH. I am currently looking at the Reolink doorbell stuff as well as their NVR. Not sure if its in HA yet either.

14

Some things it’s not possible. For example, my electric company uses the EAGLE 200 to interface with, but OH doesn’t talk to it, AFAIK. Yes I could go completely custom, but… I also have a family, coaching, and work to take my time… As we all do! :grinning:

1 Like
15

THAT is interesting! I will check this out closer. I believe it is for reading the state from HA only, but mostly that is what I am looking for. Then I can run rules in OH from data received from HA.

16

It’s more that they never supported Tasmota in the first place. Newer devices have firmware that prevents OTA flashing or use Realtek chips that aren’t compatible with Tasmota.

Note that Tuya doesn’t sell directly to consumers–they’re purely a business-to-business company. If they have any concerns about Tasmota, I would guess it’s because their customers (the third-party companies who rebrand Tuya devices) complained about it. That would impact Tuya far more than folks like us flashing Tasmota. I’d be surprised if we make up even 1% of the global Tuya market.

Mine too (BC Hydro in Canada), but I live in a condominium so I can’t even get one. :wink:

17

Woohoo! I’m in Port Cquitlam, BC, just outside of Vancouver

18

It’s easier than that. For example, a switch Item can be linked to a MQTT topic thing that subscribes to the state topic from HA. You may have to map payloads (off=OFF, or some variation), but it works flawlessly. The rules come on the HA side, as you will need to use the payload from OH to change entities in HA.

19

I suspected that’d be the case, since the Eagle 200 is made by a local company. I’m in Victoria.

20

The Eagle is happier sending data than being polled in my experience. I set up a simple nodejs script and have it accept data from the Eagle and push that into OH. It’s worked well for me for years. I’ve never had an issue with it.

2 Likes