It doesn’t show up in either of my environments (one is latest 5.0.0 via Eclipse, the other is openHABian running 4.2.3), but I’ll have to try to debug that another day. I don’t see anything obvious in the logs either. Regardless, the point here wasn’t related to my installations, but the fact that it’s supposed to work
Yeah, sorry about that. I link left and right without thinking about the fact that it’s pinging people. I’m used to having to tag them specifically, like on GitHub. Maybe your contributions are “atypical” in some way that makes them extra relevant as examples in the marketplace
And if I can’t change it and you can’t change it ?
It is consistent. Every rule template on the Marketplace is in one place under a heading “Rule Templates”. Every block library is in one place under a heading " Block Libraries". Every UI Widget is in one place to under a heading called “UI Widgets”.
What I want is a heading called “Transformations” and anything that comes from the Marketplace
Transformations forum section appears there. Nothing more is needed. Then it will be 100% consistent.
I don’t care about the add-ons. I care about the stuff posted to the Marketplace > Transformations section of the forum. An add-on will never be posted there (if someone makes a mistake a moderator will move it).
Call it “George” for all I care at this point. When I open. Add-on Store → Transformations I want to see a subsection “George” with everything posted to the Marketplace > Transformations section separate from everything else on that page.
But I’m starting not to care anymore. You’re not going to do it. I’m probably not going to do it. If I do it I sure as heck going to call that subsection “Transformations” because that’s what those have always been called.
I generally don’t think there has to be a link between figuring out how things should be and the power to change it. There are lots of things in this world I can’t change, but that doesn’t mean that I don’t form opinions about how I think things should be. So, for me it’s first about figuring out how it should be, and then figuring out what can be done to make it happen.
In this case it could probably be changed, if the proposal was reasonable. I don’t know how the decision making process is for OH nearly as well as you do, but I assume that if a suggestion is realistic and good, and there are people that are willing to do it, there should be a chance to get things through?
If is only consistent if you “filter out” the other categories, and only focus on automation and UI. But, this isn’t really worth the time to discuss, to recap:
You pointed out that you didn’t like the way transformations are currently organized (or aren’t organized).
I though that should be easy to change, looked up the logic for it and tried to find a way to change it.
I am analytical by nature, so I did what I always do, I tried to find the “system” in what was already there so that I could make changes that is consistent what the rest. The fact that the rest isn’t consistent then came to the surface, as a biproduct of “my process”.
We have then gone down some rabbit hole where I’m not quite sure what we’re discussing anymore, it feels like we have somehow ended up if the typical “complain about/defend OH” dance yet again, even though I don’t have any strong views on how this should be organized at all.
I was merely trying to help make transformations on the marketplace something that works and is used.
I don’t quite get what you want, that is clear. What I thought I had understood that you wanted is to separate the transformation services from the transformations, whatever you call them. My simple point is that to do that, you must call them different things, or you will have two categories named “Transformations”. Or are you saying that transformation services shouldn’t be in the marketplace?
That’s up to you and everybody else. I can come up with the changes needed to achieve it, as long as it’s within my ability to figure out how to, and anybody can submit it. It could easily happen if we wanted it to.
I think we’re talking past each other here. I have not said that it can’t be called “Transformations”, I’m asking, if you want to separate the two “types” of add-ons when presented in the marketplace, what do you want to call the other category?
I just discovered that there are more inconsistencies, both installed and suggested add-ons don’t take the “subcategories” into account - so they will present everything from a scripting language to a rule templace simply as “Automation” (On the “main” page in the Add-on store).
I also found that the contentType for “transformations” has never been added, so that it will be shown as blank on the “add-on details card”. That a easy fix though:
If rather spend my time in something that I can change or influence.
When I go to Add-on Store → Transformations I want a subsection, let’s call it “George”. I don’t really care any more. Under “George” I want to see everything posted to Marketplace > Transformations on the forum.
A decent name could be “Transformation Configs” and the top section should be “Transformation Add-ons”.
I do not want to see any “bundles” there.
You’ve got it backwards. The top section remains unchanged. “George” is the bottom section.
There won’t be any bundles in the bottom section in the “George” suggestion I posted above, so I think the functionality is what you want. The only thing that remains are the names of the categories and the subtitles (I didn’t change the subtitles - they shouldn’t be the same either).
I agree that “Transformation Configs” would be suitable if it were only “fixed configurations” for transformation services. But, since a script transformation will also end up there, I think “Config” might be slightly misleading?
In any case, it’s no point in you and me discussing the names of the categories to death. I really have no say in the matter, and others should decide. Technically, the solution is there. If the PR I created with the fix for retrieving transformation configs from storage is merged as well, everything regarding transformations and the marketplace should work.
It should probably be noted that any transformations posted should have a “compatibility range” starting with whatever version of OH the “storage fix” is released in, as they simply won’t work (after OH is restarted) without the fix.
@Nadahar As you don’t want to agree with DCO, please create an issue highlighting the required code changes and ping me there once you are ready. I can then pick up your changes there once I find the time.
@rlkoshak I know I said that others should decide about the “naming” of the categories, but if we have to get to an agreement to make this happen, let me explain what my “issue” is with calling it “Transformation Configs”:
When navigating to Setting → Transformation, you get to a page called “Transformation”, where it says “n transformations”. What is listed there is actually what we now want to call “Transformation Configs”. This is inconsistent and confusing as I see it.
Transformations are performed by Transformation Services which are available as transformation add-ons. The relevant add-on needs to be installed via the Main UI or addons.cfg before use.
The core of the inconsistency is right there in the documentation, “Transformations are performed by Transformation Services which is available as transformation add-ons”. I think this perfectly captures the problem, the things you install are transformation services, which are for some reason “installed as transformation add-ons”, not “transformation service add-ons”. Transformations, the actual transformation of the value, is executed by using a transformation service, yet we opt to confuse by calling those transformation services too for transformations
I think introducing yet another term, “Transformation Configs” will just add to the confusion, when the same thing is called “Transformations” in other places. At the same time, we will list the transformation services as “Transformation add-ons”. I think that if concepts are to be renamed, it should be renamed everywhere, so that the same concept has the same name everywhere.
You are the first person I’m aware of who has ever expressed confusion by this. But if you want to take a crack at it, go for it. I won’t stand in the way.
But this is my main point.
the same thing is called “Transformations” in other places.
You can either remain consistent with “other places” or change it everywhere.
Go for it. It should only need to be changed in openhab-core, openhab-docs, openhab-webui, and openhab-addons. OH 5 is a time for breaking changes like these (if you change the class names or package names or the like).
People aren’t always so willing to admit when they are confused - many tend to “blame themselves” for not understanding/being smart enough, and is happy when/if they manage to figure out how things relate. I guess I’m very atypical in that way, but the way I see it is that if I struggle to get something, a lot of others will probably too. So, to me, it’s not “solved” as soon as I’ve figured it out, because it might be an unnecessary hurdle just lying there waiting for others to trip over.
So, either I’m the only one thick enough to have struggled with “what is what” regarding transformations and I’m making a fuzz about nothing, or it applies to others too but they don’t want to announce it.
If we are to rename “transformation service” to “transformation” and “transformation” to “transformation config”, a lot of changes are needed. But why? Wouldn’t it be much easier to call transformation services for transformation services the few places they aren’t? As far as I can tell, that would only require some minor changes in openhab-docs and openhab-webui.
Earlier you were saying that it should be consistent all the way down through the code.
Honestly, my give-a-care level for this has dropped below zero. Do whatever.
All I wanted was a separate category on the Add-on store page same as we have on the Automations page and it’s turned into this huge thing. I don’t have the bandwidth for this anymore. Make what ever changes you want and I’ll deal with the fallout on the forum when it comes. That will at least be later.
That wasn’t exactly what I meant to say. I meant to say that I think it’s desirable if everybody, on “all levels” (from core develoers to users) use the same terms for the same conceps.
I feel much the same way, which is why I said that somebody else should decide. I don’t want to “force” anything on others, I want consensus first and then implementation. This seems like it could be a tall order. Maybe a separate topic for the naming would be a better way?
The reason I’m “being stubborn” is because I don’t want to contribute to things becoming more confusing. I honestly think you’d have more explaining to do on the forum it we introduce a third term for this, that isn’t used consistently either.
I’m working on implementing dependecies. I’m spending a lot of time to do very little with Vue/F7, so I’ve decided not to put too much in to visual part at this time, and focus on getting the functionality working. IF this ever becomes anything, I’m sure I can get some help from somebody more experienced to get the visuals right.
I’ve captured a little video to show how it currently works. I’m not quite sure what’s the “right” way to handle when a user attempts to install an add-on with a missing dependency. As of now, it just shows the dependencies and trying to install will result in a error. That’s not intended to be the final solution though.
When capturing this video, my “test add-on” was defined as this:
Version: 0.0.1
DependsOn: ui-basik, org-smarthome-binding-tcpudp, ui-ui, binding-milllan
Keywords: test, debug
Countries: ; NO, SE,
License: GPL
Connection: local
LoggerPackages: com.example.test
Documentation: https://github.com/Nadahar/Mill-LAN-openHAB-Binding/blob/master/bundles/org.openhab.binding.milllan/README.md
Issues: https://github.com/Nadahar/Mill-LAN-openHAB-Binding/issues
I realize that it will probably be very rare that an add-on depends on more than one other add-on, but for the purpose of implementing it, I must handle that too, which is why it’s in the test. Also not that one of the dependencies are invalid/non existing, which is why it has no link in the video. The red ones are those that aren’t installed.
You seem to have specified a version range in your pom.xml, and since latest main is now a 5.0.0-SNAPSHOT it can’t resolve the dependencies.
This also explains why it won’t work on my production installation, since it’s running 4.2.3.
edit: I added the same range restriction to the title of your marketplace entry so that it won’t show up for installations that’s outside the range, as it will never work for those with these restrictions in the POM.
I’ve implemented more of the dependecy management. I’ve opted not to install dependencies automatically, as I’m a bit hesitant of doing things where it’s not certain that the user understands that it’s being done. It could always be changed of course.
?
