Probably not implemented in jsscripting
What I’d like to see are some “little helpers” in the UI:
- something like “copy&paste” for things/items/… as it would be possible to do in a text configuration.
- finding entities not only by name, but also by e.g. facets like “last changed”, some Semantic classification, …
- integration more easy manipulation on an item-basis, e.g. updating the value via text per click(?) within the detail-page of an item - instead of either having to configure the widget for it (if the item isn’t Number/boolean, you can’t manually change the value of it except via API)
- rename an entity
ad 1)
this would allow for a more convenient creation of things/items/… as today you have to click and type and click and type and click… for every similare or identical entity all over again. Normally you have a bunch of temp-sensors or others, which are identical, but are only on a different location - but behave exaclty the same. sometimes I came around only through painful processes, that I forgot to put a Unit or some metadata on the item and wonder why the rule won’t do for that other item… 
ad 2)
this would be so nice to find e.g. a thing if you searched for a channel in the thing overview or you do know the item is semantically a “light” or whatever.
ad 3)
how often do I need to update a text item or a date item and have to go to the API-explorer and update the item there and then go back to my previous task. Would be so easy to do that on the item itself.
ad 4)
sometimes I don’t get my naming conventions correct myself. Then it would be super cool, if I could somehow rename that entity and openHAB does all the other “foot work” on itself. like renaming it in the persistence and perhaps (one could dream) also replace it in rules or links between channels and items … I know, it’s complex. But would be super helpful.
1 Like
Could you describe a use case please?
As of now you can pass a complex json string already to any kind of item trigger and can pass it from one rule to another.
+1
I also noticed that sometimes a switch item offers a control to toggle its state on the items page - and sometimes not.
In general, YES, that will help a lot if you could simply change the state on the item page for all items.
I agree with you OH is OH and HA is HA… Since several years I’m a big fan of OH and have meanwhile 85 things and more than 80 rules running. So real doing what it should, an meanwhile stabile with 4.3.3.
But as our Android client of OH is not supporting Android Auto I have had the need this year, to install for a test setup HA. Why an hardcore OH user is using HA? HA supports with his Android client Android Auto and so I was able bring a small amount of shelly’s to the AA solution in my car, to open and close the gardendoor and the garagedoor from the car over a VPN tunnel when, the BT Handfree from the car is connected.
So there are reasons, why I have had a need to run OH and HA in parallel.
If the OH client would support AA, I would NOT have the need to use a other smarthome system.
1 Like
It’s not quite the same as you describe. But for Things there’s “Copy Thing” at the bottom of the Thing’s page which will generate a brand new Thing with all the same settings as the original, letting you change the properties for the new one.
There is a similar option for Items.
And of course you can always copy and paste on the Code tab of either.
That should get you most of the way there now.
I beleive the developer sidebar already searches the tags and you can search by tag in the search bars of the various pages (Items, Things, Rules). Rules have a “filter by tag” option.
lastUpdate is a new property being added to the Item. Once that’s added, it might be possible to implement a search on that.
Depending on the semantic tagging and the State Description properties (e.g. is read only checked) the default widget for most Items should allow editing.
But as you mention, you can also override the “Default stand alone widget” to one that allows editing of the Item through the UI.
Other options include the karaf console, ~Scratchpad~ script, and REST API.
I’m not arguing against adding this feature, just pointing out what’s possible now and that you don’t have only the REST API as an option.
Personally, the first time I need to edit the state of an Item I just change the “Default standalone widget” for that Item to an oh-input-card and maybe set the Type and Input Mode (e.g. if it’s a date time I’d choose “datepicker” foir the Type and “text” for the Input Mode, or if it’s a number I’d choose “numeric” for the Type). If it’s a Switch I’d choose oh-toggle-card. If it’s a Contact I’m out of luck. You cannot command Contacts.
2 Likes
The “copy thing” will only copy the thing, not the channels.
The “copy item” will also only copy the item itself, not the metadata and not the link to a channel.
Which brings me to my most common use case: Copy the whole combination of thing and channel for my MQTT-based Tasmota devices and then rename the Thing itself - after that copying the items in a new equipment named after the new thing…
THAT would be absolutely gold, but I understand that’s really too much to ask. but at least copying the thing including channels and copying items including metadata would make it easier to “only” link the copied items to new copied channels manually.
cutting and pasting code is ok for channel defintion of things, and I do that a lot, yes
the Dev Sidebar is useful, but does not include semantics, only UIDs, labels, locations for things or Name and label for items as far as I cold tell from my testing. no Tags or semantics or metadata. If it supported this, you could also filter for e.g. exposed items for amazon metadata or expiration timer or …
wow! I never used Type or Input Mode! 
That’s a real gamechanger here and exactly what I needed!
I’ve never used HA, or any other platform (apart from Homekit) but as you also mentioned
I believe if people suggest adding something that they don’t find in OH, it’s because they may not like having to run two (or more) different systems. Possibly, if they suggest an improvement to OH is because they prefer it as a solution, but would like to have that missing part so they can get rid of the other platform and decrease the complexity of their system.
If they found the other platform better they would not be here in the first place.
By the way, I’m not suggesting to make OH a copy of any other platform (call it HA, Homey, SmartThings, etc.).
3 Likes
The Channels are a part of the Thing. I just tested it with a Generic MQTT Thing and the Channels were copied too. Is this not working for you?
The way I do that is:
- Copy the Thing and give it the new name, ID, location and such. You can edit the main Thing properties before saving it.
- Navigate to the newly created Thing, click on the Code tab and change the topics and anything else that needs to be changed using find and replace
- Click on “add equipment to model” to create the Equipment and Point Items linked to the Channels. You set the name of the Equipment and the names of the Items will be generated from the combo of the Equipment name and the Channel name. Select the Channels to create Items for and link to.
It’s not as good as what you are describing because if you’ve added any Item metadata that won’t be included in the newly created Items. However the it’s better than creating everything all anew.
We may need to move to another thread because it does support all of those. It searches tags, metadata, uid, full content of rules, etc. There is very little the developer sidebar doesn’t include in the search.
I use Google Assitant but
Of course “ga” appears in lots of words so I get more than just the GA exposed Items, but those in the screen shot are almost all exposed through the “ga” Item metadata.
Sorry I haven’t read everything in this thread but I would just like to add that this would be even more useful if you could copy a group item and of all of its siblings together.
1 Like
It’s just a manpower issue really. I (as one of the Android app maintainers) have the exact same use case for AA as you have (garage door and garden gate control) and have therefore already briefly looked into what’s needed to support it. I listed my findings in the respective GH issue. Spoiler: it’s a lot of effort to implement, more than at least I can currently deal with. The HA guys likely have significantly more manpower (they’re backed by a company for starters) so it’s easier for them.
I’m curious though, what kinds of controls do they offer via AA? Do you have any screenshots for that? As I listed in the issue, the amount of controls available in AA is very limited.
3 Likes
Along the lines of the linked thread “manual trigger detection”, the general goal was to know if an item command was coming from a GUI interaction, thing channel or particular script. In my case I have different logic if an item is commanded via GUI or a script.
Even if it’s too much work to implement code on the GUI side, being able to do this in scripts is enough by process of elimination. I write all my scripts in ECMAScript 262 Edition 11, and would be handy if I could pass additional data when calling commands from a script. Passing a key/val object would be ideal as that allows for extending the usefulness, but even a single string is fairly capable, as you can pack/unpack a JSON string in scripts.
itemName.sendCommand(command, {'optionalkey': value});
or
itemName.sendCommand(command, source);
As mentioned above, it looks like there is some existing code, but I can’t seem to read/write the source property in events through JS.
Yes, to add features in openHAB is always welcome from my perspective, too.
It’s the “HA has, where openHAB don’t” part that I don’t like.
So better ask e.g. to get Android Auto working for the openHAB App without mentioning that HA already has this feature.
As I don’t have an iOS phone I’m not sure if Apple Car is supported by the iOS app, but even if, I wouldn’t suggest to buy an iOS phone instead “because it already supports the functionality” .
Just a general question: I assume HA operates differently (I encounter a lot of python when I glance at HA stuff) than OH? And that there’s nothing to be “learned” (technically speaking) from how HA tackles problems?
I’m amazed -again. Either I was blind last time I did that or I don’t know. Yes, with MQTT things the copy also copies the channels.
and YES, that would basically do it for my described use case:
- copy the thing including channels
- copy a group (aka equipment here) with all its child-items
- manually linking channels and items
Step 3 is less effort than going through each and every item to bring the metadata on par.
My suggestion for copying items would be to use a “prefix”, which differentiates items for two channels:
- Tasmota01_NAMEOFITEM
- Tasmota02_NAMEOFITEM
being “TasmotaXX_” the prefix you can use to (re)name the existing items while copying.
PS:
I’ll have a look on this. perhaps I missed something in my tests for that, also.
That is also a very common use case for me and a big pain to be honest when managing OH via GUI. For now I created a file config as template which I adapt to my new device Ina text editor and import this via the developer tools. But it would be really nice to have this all included in the user interface.
Apple CarPlay isn’t BUT CarPlay will automatically show a garage door opener when you approach home (if you have exposed it via the HomeKit binding, or it has native HomeKit functionality). I have my driveway gate set up as a garage door for this reason.
There are limitations with this approach though:
- If you have a two door driveway gate (pedestrian smaller section and then also requiring both gates to open when driving in/out ) and sometimes require one or the other eg stopping in the road and just letting pedestrians in and out. There is no way to switch between with one would appear
- If you have an automated garage door too and don’t always want the opening/closing linked
- No access to other functions eg checking to see if you locked the front door
An iOS CarPlay app would be nice but there is some functionality there already.
Yepp, that’s a whole other point 
openHAB is Java, HA is python, but for sure a skilled person can benefit from the sources to get an idea how to solve a specific problem.
From my perspective, HA is very different in question of UI for the end user as well as the admin of such a system.
My opinion ist completely the opposite.
It is really important to know and understand other solutions and what works there that could also make openhab better.
To look away and pretend nothing else exists, and everything has to be a unique idea on its own, doesn’t make it better.
If something works in HA well it is good to know for the developers as well, so you know it’s something that works and not necessarily new.
It would certainly help for OH developers to have a look at the other side.
To topic:
-I wish the thing - channel - item handling would get a little revamped, as HA seems to not need it at all.
-I have the model, so why do I still have to create lots and lots of Items Named Floor1_Bedroom_Bed_Sensor_Left_Presence
Effectively having to name it the same as the place I put it in the hierarchy.
I want to put a thing in it’s place in the hierarchy and just refer to its channels in an object oriented way like Floor1.Bedroom.Bed.Sensor_Left.Presence
-I wish OH would have more focus on marketing as in my opinion it’s the best system available. Or at least jump on thr back of HA and make HA standards a prime use case, e.g. Z2M (autodiscover is buggy) and ESPHome (only community add on available with limited support).
Thanks for openhab, it’s easily the best Open Source project I know of!
2 Likes
That’s not the point. It’s not about ignoring other solutions, but about complaining, that openHAB is not like HA.
Now, then use HA, but don’t try to let the developers change openHAB to be more like HA. There are very good reasons for the items as well as the things and channels. If you don’t like it, either get over it or use HA.
No you don’t have to. It’s up to you how to name an item. Please also keep in mind, that Items are the way to access functions of everything in openHAB. It’s here since the beginning of openHAB, tags came with openHAB2, and the semantic model is only here since openHAB3.
No, please don’t. The focus should be on making openHAB (even) better, not to promote.