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

[jimtng]

@somy

allows to run HA integration Python code directly on OH.

This would be awesome. It would close the gap of device support between OH and HA

[jimtng]

@somy

binding to allow integration to Home Assistant - or even binding allows to run HA integration Python code directly on OH.
This will immediately open OH to many more integrations already exists in HA. I have recently tried HA and am impressed by the support there - not only the number of integration but also exposed features and interactions between integrations.

@holger_hees do you think this is possible with the new Python3 add-on?

[holger_hees]

I don’t really know the “HA integration Python code”, but I guess that the pythonscripting binding is not the right usecase for that. It allows you to write rules and functions to be used in transformations services etc. It creates a context for each script type which is destroyed on reload and it does not have any permanent long running background tasks/threads etc.

But the graalpy package itself, can be helpful for this approach. You can write a new binding, which is using graalpy internaly together with the “HA integration Python code”.

A comparable usecase comes from @ccutrer. He is planning to use GraalPython with the MQTT Home Assistant binding, because the python implementation of the jinja template engine is much better than the java implementation.

To make it short. The Python3 add-on is not the right solution for this, but the technology behind (graalpy) could be.

[Pedro_Liberal]

Nothing is stopping you from doing this the right way already:
Setup home assistant.
Connect it to mqtt.
Create mqtt generic things using the mqtt topics in home assistant.

Or node red. Makes things a bit easier.

[somy (mai)]

Hi: I’m aware of this option, and in fact it’s quite simple to let HA to publish states to OpenHAB, however for two-way communication it’s a bit more involving and not to mention configuration of generic items are sometimes less straight-forward.
If a user starts to set up HA for an integration that OH doesn’t provide, there is a chance that he might just switch to HA after trying it out. HA is not like 3-5 years ago when a major release broke everything. Recently I tried it out and I’m now seriously thinking to move over (the reason why I try it is because lack of integration in OH for my needs BTW).

Edit: now I have learned jinja blended in yaml, my god I prefer dsl 10 times more.

[Udo_Hartmann]

To be honest, I’m tired of those “HA does provide xy, why openHAB doesn’t?” postings.
openHAB is openHAB, HA is HA. If it suits you better than openHAB, then use HA.

I’ve tried HA last month, and hell, no, not even https…
Not to mention the strange way to look at the hardware.
This is clearly not objective, as I’m used to openHAB, but why should I change, and more, why should openHAB change to be more like HA?

Both openHAB and HA have ups and downs, choose what fits better. Period.

[smitopher (Christopher Smith)]

@somy

Another crazy idea (don’t shoot me): binding to allow integration to Home Assistant
…
This will immediately open OH to many more integrations already exists in HA.

Depending on the maturity of the HA Matter implementation, that may already be available TODAY.

Using the matter protocol, HA and OH would allow each other to expose their non-Matter devices to each other.

The details for the OH side of things may be found at the OH Matter Binding READ.ME

This is a beta level OH add on but I’m using it in my home now.

For Matter devices, OH and HA would talk directly to the device and the device would tell BOTH of them if its state changes… no matter … what triggered the state change

[smitopher (Christopher Smith)]

Not that this is a good idea

Sorry @digitaldan

https://youtu.be/Nqk_nWAjBus?si=hPAXf4K_hpdbIPJ3

[somy (mai)]

@smitopher

Using the matter protocol, HA and OH would allow each other to expose their non-Matter devices to each other.

That’s a good point - indeed Matter is supposed to be platform independent.
Hope in the future it doesn’t matter anymore which platform to use in terms of device support.

[lo92fr]

Hello,

I was looking to another solution the evenning.
I will not say the name to avoid any conflict, but I see one more great idea.

I don’t thing that there is such feature (global feature I want to say) in openhab today.

This is about a media agregator / browser.

Today each addon that support media (music, video, …) handle them on their side.
For exemple, in spotify addon, there is basic support for playlist selection.
I’m not fully sure of what other addons can support or not.

The idea there would be to have a interface in core where addons could registered for media selection.

Each addon would register a root virtual device, and under this root device, some sort of collection: Album, Artists, Playlist, …

Ideally of course, we would need some sort of dynamic callback to get information from each addons when we really need it.

On the other side, UI, player card should be extend to enable browsing of media collection, and trigger playback on registered device.

We have already some registered device via Audio sink, but perhaps have also to look if addons like spotify can add their own sink using remote devices registered from them.

Of course, I don’t say this is specifically for 5.0. It’s a lot of job to be done to add such a feature.
But I would see it as a great new feature.

Laurent.

[Max_G]

@Udo_Hartmann

Both openHAB and HA have ups and downs, choose what fits better. Period.

Totally agree. I am not getting why people want to make a Skoda into a Volkswagen or the other way around. Life, cars, automation systems are never perfect. Chose what fits your requirements.

[aaronkhare]

I might be mistaken in my understanding, but if I have say 4 Equipment, ex. lights, in the Living Room, and need to control them with a group Item and configure them only using Main UI:

1. For power, I need 1 group with the 4 lights’ Switch items as Members; set the group’s Base Member Type as Switch; add relevant configuration for Aggregation Function
2. For brightness… I can copy the group, change the members to the lights’ brightness items and change the Type to Number with the relevant Aggregation Function
3. Repeat step #2 for colour, colour temp., COUNT for number of lights ON, and another for OFF, totalling 6 Groups… Right? (Not counting attributes like Link Quality etc. for diagnostic purposes)

I found a few topics on this forum mentioning this approach, also referencing the fixed bug with COUNT ([MainUI] Group:Number:COUNT("string") is not possible in MainUI · Issue #956 · openhab/openhab-webui · GitHub).

It would be nice to instead be able to use one Group for all selected equipment (ex. lights’) attributes. For example:

1. Create a group Group_Lights_LivingRoom
2. Select the Things corresponding to each Light
3. It will automatically import all Items from Linked Channels (only?)
4. Then in the group you can set, I don’t know, maybe Metadata, to select “sub-groups” of each attribute (switch, brightness etc.)
5. Consequently the group Group_Lights_LivingRoom can now have multiple Types (each referencing a diff. sub-group) with corresponding Aggregation Functions etc.

It’s a bit less work (#1), but imo the real value is (#2):

1. Saves steps when repeating this process for each room, for each equipment type
2. When you add new equipment (ex. lights) to a room, you only need to add & configure the Thing in one corresponding group, and all attributes + rules/expressions get updated automatically
3. (Bonus) You have fewer group Items related to the same group of equipment – helpful when you’re trying to reference the right one for a rule/expression

Notes:

• This would mean that rules/expressions would need a way to reference the new “sub-groups” Metadata though
• Maybe the Thing selection isn’t the right approach, but off the top of my head I couldn’t think of another way to automatically import all the Points of an Equipment
• Can the “sub-groups” creation within a group be automated (already?) by detecting the semantic tags of member Items…? This would super-charge #2 above so you only need to add the Thing to the group

If this already exists within Main UI (sorry! ) using a different method (ex. Blockly), kindly link me to where I can read up more If not, then I think this would be huge for newcomers, and a bonus for setups that start small and/or grow over time

Edit: Grammar fixes, and added the Bonus #3

[jimtng]

@aaronkhare

if I have say 4 Equipment, ex. lights, in the Living Room, and need to control them with a group Item

You could do this using semantic model

Example (in jruby)

# get all the Lightbulb equipments
lightbulbs = LivingRoom.members.equipments(Semantic::Lightbulb)

# send an ON command to all the items with semantic Power
lightbulbs.members.points(Semantics::Power).on

# command all items with ColorTemperature tag (It's a dimmer in my setup)
lightbulbs.members.points(Semantics::ColorTemperature).command(100)

# Set all dimmer items to control brightness
lightbulbs.members.points(Semantics::Light).command(50)

# There is no RSSI semantics, so we just use a plain tag
signal_levels = lightbulbs.members.tagged("RSSI").map(&:state).map(&:to_f)
logger.info "Average signal levels: #{signal_levels.sum / signal_levels.count}"

[aaronkhare]

Awesome! Thanks for sharing, I knew the Semantic model would come in clutch Can this approach be used with widget expressions, too?

Also, can it be done using only UI, and with Blockly rules instead? Asking for friends and family that want an openHAB instance with a UI-friendly configuration, so I’ll have to test that first for them

Edit: If you’d rather I create a new topic for that, or if a mod wants to move this convo, please let me know

[jimtng]

@aaronkhare

Also, can it be done using only UI, and with Blockly rules instead?

It probably can, but you’d have to ask others who are more familiar with blockly.

[Johnno (John)]

A few posts up, in regards to comparisons to home assistant: there are definitely some back end features that OpenHAB could really benefit from.

I run an instance of HA as well to keep up to date with it and experiment with it’s event and data structure, and how it goes about scripting.

I’ve been reworking some of my JS scripts which implement functionality along the lines of this post:

Design Pattern: Manual Trigger Detection

Edit: Updates for OH 4 Please see Design Pattern: What is a Design Pattern and How Do I Use Them for details on what a DP is and how to use it. Problem Statement Sometimes you are in a situation where you want to know where a certain command came from but there is no way built into the binding or the device to tell the difference between a manually initiated command at the device or a command initiated by a rule or the sitemap. For example, when one wants to override a Rule’s behavior when a l…

One nifty feature in HA is the ability to pass in an arbitrary dictionary of keys into various services (forgive me if I forget the correct terminology for everything…) from memory it’s ‘attributes’: {}

OH has a similar feature in the form of “context” being passed into scripts, but the idea could be expanded to the trigger and event system. For example it would be very helpful to be able to pass in an object with an arbitrary list of keys along when sending a command.

Then if a rule is triggered by ItemCommandTrigger, those keys could then be accessed in a similar way to scripts using ctx[‘key’]

[jimtng]

@Johnno

it would be very helpful to be able to pass in an object with an arbitrary list of keys along when sending a command.

Then if a rule is triggered by ItemCommandTrigger, those keys could then be accessed in a similar way to scripts using ctx[‘key’]

This is already available for a while (6+ years) in the form of a String data called source. One can send a command and provide any arbitrary data in the “source”. This was implemented in jruby

[Johnno (John)]

Is something implemented in ECMAScript 262 Edition 11?

I assume that’s like the built in event.itemName?

I’m thinking along the lines of an optional argument that would work without breaking existing functionality. Something like:

itemName.sendCommand('ON', {'optionalkey': value});

[jimtng]

Source is just a string

[Johnno (John)]

Ok, I’m not sure how to implement what you’re talking about. I can see that events have a source property. I set up a rule to trigger if an item receives a command. In a script I called the function event.getSource(), but it always returns null (if manually toggled), and if the item is commanded with another script, there’s no event so it will throw an error. Adding another argument to sendCommand doesn’t pass anything to the source property.