Ideas and Discussion: What Features Do You Want in openHAB 5.0?

[lsiepel (Leo)]

Can you be more specific? The homeassistent binding has had some serious development in 4.3.0.

[tcgerhard]

MainUI resets to the home screen when the orientation changes on my Android phone, and has as long as we’ve had MainUI.

[sihui]

@tcgerhard

MainUI

Nobody mentioned MainUI.
I can’t tell anything about MainUI as I don’t use MainUI on my phone

[hmerk (Hans-Jörg Merk)]

@nw378

Govee binding

What‘s wrong with the existing Govee Binding ?

[hmerk (Hans-Jörg Merk)]

@tcgerhard

MainUI resets to the home screen when the orientation changes on my Android phone, and has as long as we’ve had MainUI.

This seems to be an issue with the Android App as I don‘t see this on my iOS devices. Nothing openHAB 5 could change…

[Spaceman_Spiff (Sebastian)]

@Udo_Hartmann

faik most of the bindings are only configured as hardware is, not to change hardware, so for example, openHAB can’t setup a rollershutter channel to work in reverse mode, this is to be changed within the device itself. in openHAB you only have to follow the settings of the device.

But the issue is not limited to hardware changes but any other interaction in general.
Wouldn’t it be nice if you could click on a thing and then e.g. manually move your shutter up and down - just to troubleshoot or see how things work. Or have a button that opens the devices web server. Or a button that links to some kind of docs. Or any other bridge that requires some kind of pairing to be used directly from openHAB.

@Udo_Hartmann

so, is it worth the effort?

The golden question.
I think the separation between thing data and thing configuration is definitely worth it.
For everything else I’m observing (in my small bubble and by myself) that more and more is offloaded from bindings to mqtt / python because it’s more convenient but mostly because it’s more stable and better supported. So probably not. But who knows - “worth” is always in the eye of the beholder.

[hmerk (Hans-Jörg Merk)]

@Spaceman_Spiff

that more and more is offloaded from bindings to mqtt / python

Can you give examples apart from Zigbee?

[rlkoshak (Rich Koshak)]

@milo

so why not OpenHAB?

As always, because no one has volunteered to implement it.

@Andrew_Rowe

this is a home automation system, in other words it doesn’t move around

People have deployed OH on campers and boats. “Doesn’t move around” is not a given. I’m not saying we handle that very well right now either, but I don’t think we can just assume a fixed location.

@tcgerhard

A way to schedule things relative to Astro channel events, i.e., “30 minutes before sunset”

There are two ways to do this now.

1. Configure the Astro event channel with a -30 offset and use that channel to trigger the rule.

2. Link the state channel to a DateTime Item and use that item to trigger the rule using a Time is <Item> which, as of OH 4.2, supports an offset parameter.

@tcgerhard

A way to add “But only if” for each Then clause. This would simplify rules that have exceptions, i.e.,

In not sure that really helps anything. It feels like it just moves a great deal of complexity to UI rules. That sort of complicated if/else if/else logic is why script actions exist. If you need logic like that I think it’s better to use Blocky or code rules instead.

I’m all for making UI only rules more capable but that has to be measured against adding complexity that serves as a barrier to be users

@tcgerhard

it could even be as simple as exposing yaml that could be copied and pasted back.

I’m a little confused. You can copy and paste the yaml now.. Please elaborate.

@JimH

could not find an issue in Github (I’m a Github noob). Could someone point me to it?

https://github.com/openhab/openhab-docs/issues/2414

@Larsen

Option to add and edit tags of rules and items

For completeness…

There under “non-semantic tags” for Items.

There under Tags for rules. Scenes and even Scripts can now have tags added through the UI. Here’s for a Blocky Script.

[Spaceman_Spiff (Sebastian)]

Z-Wave, Shelly, SmartMeter (SML) are run through MQTT by me and I know multiple other persons who changed back from the Shelly binding to MQTT.
ModbusTCP, Weather Forcast and Pushover notifications are completely run in Python

[hmerk (Hans-Jörg Merk)]

Ok, If you prefer to use MQTT for those Bindings, your choice.
I don‘t have any issue with the Shelly Binding.
Don‘t see a reason for the SML Binding. Did a installation for a community member couple of weeks ago, no issues so far.
Same for ModbusTCP. Using in the same installation with a Protoss bridge and 4 ORNO meters attached to it. No issues.

[nw378 (Nico)]

Oh yes, there is a binding, I forgot.

But it doesnˋt work with all bulbs.

E. g. this one: H600D has not the LAN-control button.

So I use the govee2mqtt container to control the bulbs via cloud.

[Larsen (Locke)]

@rlkoshak

For completeness…

I know that. But unfortunately it doesn’t work on Android phones as the Enter-key is not recognized. It’s more a regression than a feature so I raised an issue on github.

[Udo_Hartmann]

@Spaceman_Spiff

“worth” is always in the eye of the beholder.

fair enough

[Spaceman_Spiff (Sebastian)]

@hmerk

I don‘t have any issue with the Shelly Binding.

Can you restart your openhab instance and tell me the time it takes your water/smoke alarm to properly report the alarm back to openhab?

@hmerk

Same for ModbusTCP. Using in the same installation with a Protoss bridge and 4 ORNO meters attached to it. No issues.

Have you ever tried writing an uint16 value to modbus? Or accessing a device which is very slow and picky about preventing parallel requests.

@hmerk

Don‘t see a reason for the SML Binding.

Does that mean you don’t see a reason to use the SML binding or you don’t see a reason to not use the binding.

---

@hmerk

Ok, If you prefer to use MQTT for those Bindings, your choice.

I’m not using MQTT for the sake of MQTT or python for the sake of python.
It’s just that I have encountered issues and problems with the bindings that I do not have with a whatever_to_mqtt bridge or a python library.

[hmerk (Hans-Jörg Merk)]

@nw378

E. g. this one: H600D has not the LAN-control button.

How should openHAB change that ?

[hmerk (Hans-Jörg Merk)]

@Spaceman_Spiff

Does that mean you don’t see a reason to use the SML binding or you don’t see a reason to not use the binding

Don‘t see a reason not to use the SML Binding.
For the rest, I might not use every option/function you listed, so it is a bit more clear to me now. But i still don‘t see a big move torwads MQTT or python.

[nw378 (Nico)]

OH for sure cannot change the availability of the LAN-button.
But the possibility to control the things via the Govee-cloud could be added.

[smitopher (Christopher Smith)]

My SURE to be hated wishes
Refactor OH to use one of the Java Frameworks like Spring Boot or Quarkus.
Refactor OH to allow native builds of OH using GraalVM native complier
Refactor OH to be able to run in a horizontally scalable container framework like Kubernetes.

[Hans_Lree (DigiH)]

@lsiepel

Can you be more specific? The homeassistent binding has had some serious development in 4.3.0.

Full disclosure: having become pretty disillusioned and disappointed with the general development of openHAB, and OH3 in particular, when I tested it with looking to upgrade when it came out, and openHAB GitHub issues tracking and addressing, or the lack thereof, I’m still running OH2 here, and with realising that it’s best to rely as little as possible on particular bindings, I very early on turned to MQTT compatible implementation for all the Govees, Inkbirds, Qingpings, Xiaomis, SwitchBots, IR Trotec air conditioning units, 433MHz and 868MHZ rtl_433 weather stations and thermometers, MiLights/MiBoxers, RF Funksteckdosen and so on.

With everything manually textually defined, as I like to do it.

And thoroughly enjoying the stable long uptime, without any dot release update dramas

This MQTT versatility and independence of proprietary bindings also brought me to the OpenMQTTGatewat/Theengs project, actively contributing as best I can.

With that in mind, and the fact that the majority of home automation users these relying on auto-discovery I keep testing out discoveries for Bluetooth and rtl_433 devices regularly with different home automation systems, also implementing a requested feature for FHEM users, responding to Jeedom users requesting new features,as they do not support discovery, and making sure that HA discovery works as smoothly and nicely as possible.

My last OH4 test resulted in this

Problem with device_tracker and binary_sensor HA convention MQTT discovery for local Apple Watch, iPhone and iPad discovery

Hi all, Wanting to post a quick introduction and tutorial for our new Theengs Gateway feature of quickly and locally getting the presence status for Apple Watch, iPhone and iPad devices over Bluetooth, with an addition security relevant unlocked property, I found the following issues when using the homeassistant convention discovery from the Theengs Gateway created discovery entries, when adding them to Model. • Small issue for binary_sensor, which seems to be the only class which does not hon…

With no-one responding I assumed that proper HA MQTT discovery is not a high priority.

Feel free to continue the conversation there, if you think it might be worth it for me to try again with a later 4 dot release. It might get me out of my OH resignation a bit

[jimtng]

There has been a lot of work done on MQTT HA integration
https://github.com/openhab/openhab-addons/pulls?q=is%3Apr+homeassistant