Changing items metadata very frequently

Setup, Configuration and Use Items & Sitemaps
21

There is no direct attack, of course, but sometimes apologies are about what you didn’t do, instead of what you did. In this case, I think Jan would have a legitimate claim that you disreagrded/didn’t pick up on his obvious frustration. Rich’s description of the events is colored by his frustration with the outcome as well, but he is essentially describing the same thing. Jan said more or less directly, “the time I would put into this feature isn’t worth this drama,” and your next post did not attack him personally or professionally, but did fail to acknowledge that what you were posting was the source of that drama he was referring to.

100% valid, and I agree with many of the points you put forth in that issue and follow-ups that you put in Jan’s PR.

What I’m saying is that the when Jan signaled exasperation there’s no evidence that you took the time for introspection. It doesn’t really look like you tried to find that “huge place for compromise”. I read many of your comments as saying, “let me help you get your contribution to match exactly what I see as the only solution.” Not many would truly interpret that as help. And that comes back to what Rich is saying, I think. What you posted should, instead, have summed to “let’s get this to a place that, even if not exactly what I was expecting, sets everyone off in the right direction, with the chance to reach (eventually) something special in the long run.”

Edit:

I’ve only been on these boards extensively for maybe 5 or 6 years. But even in that time alone, I can think of a couple of situations where clashes that started out as reasonable “philosophical differences” such as this escalated to sufficient bad blood to cost OH excellent contributors. I’d hate to see that happen here in either the case of you or Jan.

22

I have never suggested that. Parameters that have a default value are optional because if omitted the default is used. So you would have to set only one parameter and additionally only those that changed:

It’s exactly the same amount of configuration you have to do.
Just that instead of spreading the configuration over several items it’s in a central place and you get the benefit that not every rule has to do the metadata validation and a nice user facing parameter input dialogue.

Really - the UoM discussion? Where people were essentially commenting “I didn’t read the whole thread and didn’t understand the issue in detail but how about this and that?” Where I tried my best to keep every one on the same page and up to date and in the end everybody (including me) was extremely annoyed that the discussion was running in circles? Because yet another person asked a question or made a statement that had already been answered multiple times. That UoM discussion?

Also his resentment was not clear at all. We’ve had a discussion shortly before on another issue where I suggested that metadata should not exist alone but be bound to the item. I’ve attributed his comment “If it’s that discussion again, no.” to the merge of item and metadata because one could understand the suggested configuration format in that way. But just because the file format provides an option to configure it in a certain way (a way that it already provides now) does not mean the underlying data structure has to be the same as the file format. That’s what I tried to make clear with the next comment.

I fully agree that this is how things should work and have stated that multiple times. It would be a great benefit for all users. I even suggested that it should be a shared core functionality that should do the (de-)serialisation of the yaml so the core, UI and file based is always in sync.

I feel like we’re running in circles again and these discussions are extremely exhausting and stressful for me. I think all has been said and nothing new or good will come if we continue.
It’s been made clear that my ideas and suggestions are an active hindrance for the openHAB development so I’ll refrain from making them in the future.

23

No, no, no, no no. Please don’t. Ideas and suggestions are never a hindrance.

In that case, I apologize for any part in causing stress. I agree this is approaching running in circles again, but I had some hope we would escape that for a while there.

This all comes back to the old saying:

Communication isn’t about what you say. It’s about what they hear.

If you are hearing that your ideas are not appreciated, then that is on us. Your ideas have driven many wonderful advancements to OH. Your contributions stand on their own. I’m trying to work towards a solution where your ideas again flow and move OH.

Jan’s not blameless here either (but he’s also not on this thread, or at least hasn’t made his presence known), and could have done a better job with the “what they hear” part. On the other hand, my impression from interacting with him over these years is that he is a pretty easy-going, level-headed guy and the fact that he got to the point where he lashed out about killing file config altogether is a huge red-flag about just how far off course communication had gotten in that thread.

It only takes one person so say “let’s find the points we all agree on…” instead of “I agree, but you’re wrong…” for everything to get back on track. It could be any of you…

Edit…

If I had a nickle for every time I’ve heard “I agree, but you’re wrong…” in faculty meetings…

24

No, they are not and please do not refrain from making them.

However, I think the way you present them can be problematic at times. As @JustinG indicated, you don’t leave room for compromise in how you state things and when your suggestions are rejected, if you don’t agree, you continue to argue for it.

That in itself also causes stress and and exhaustion. And that stress and exhaustion is why Jan quit the YAML PR. No one wants that. I don’t want that. I don’t want you to have that.

In general I like your ideas and they move OH forward. I only push back when the idea breaks my stuff.

Yes, and despite the efforts of you, and me, and others, the discussion went off the rails. It didn’t go off the rails because of you and you did great work trying to keep it on track yet it was pretty much a nightmare.

And if you recall, he almost gave up on that PR too. I can’t blame him for not wanting a repeat of that.

I’m not sighting your behavior on that UoM PR. I’m sighting the overall experience which you were trying to mitigate on that PR and for which I’m grateful. I did not intend to mean your behavior on that PR was anything but exemplary.

At the end of it I think your idea to make rule parameterization in the UI is a good one. It should be pursued. I only disagree with that replacing the way I use Item metadata.

I think you vastly overestimate how much is actually going into the Item metadata and vastly underestimating the amount of work that would be imposed on the end users of the Threshold Alert rule template if they were forced to instantiate a separate rule per Item.

But that’s OK. Just don’t break my stuff by insisting I can’t use Item metadata the way I currently do and it’s all good.

I spent a lot of time on the Threshold Alert rule template. I implemented it at least a dozen different ways. I don’t reject your idea because I don’t understand the idea of parameterizing on the rules. I don’t reject your idea at all. In fact I always implement my rule templates that way first. But it invariably either makes the template essentially impossible to implement, or makes it become too much work for the users of the template and I need to resort to Item metadata.

I’ll say it again, I’m not against the idea of parameterization of rules. I am only against making my rule templates worse by not allowing them to use Item metadata. Your proposal is a good one but not sufficient in my use cases.

Just to put some real numbers to it, lets take the most extreme of my instances of Threshold Alert.

  • Number of Parameters: 16
  • Number of Parameters that are not the default: 11 (3 are always required, 6 would be required for the rule template to do anything useful)
  • Number of Items: 18
  • Number of Items with metadata: 0

Total parameters defince 11.

If I had to create a separate rule for each Item given the non-defaults I’d have to set 198 parameters.

Those 16 parameters on the rule do have a nice user facing dialog.

image
image771×670 107 KB

and the metadata is very simple:

value: " "
config:
  alertDelay: PT30M

I’ve not tagged him and I’ve been uncomfortable both ways (tagging him or not tagging him). I feel like it’s unfair to talk about him but at the same time I don’t want to rope him back into a discussion he clearly doesn’t want.

25

I just would like to make sure that there is no misinterpretation regarding what happened to the mentioned PR. @Spaceman_Spiff and me disagreed on the way YAML should look like. I prefer “closer to code” while @Spaceman_Spiff prefers “closer to a good model”. This is a conceptual disagreement, but has nothing to do with “bad blood” or something along these lines. I do appreciate his contributions and we had good and close collaboration in the past (e.g. regarding websockets).

Changing from DSL to YAML has no personal benefit for me. I don’t use textual configuration and most of you probably know that my personal opinion is that textual configuration should be completely removed. Therefore my suggestion/PR was purely “service” and the amount of time and effort I am willing to spend on something like that is limited. I had (and still have) the impression that the overall interest was not very high (counting by the number of participants in the PR) and if 50% don’t agree with my proposal it’s not worth the effort.

26

I was busy with other projects at the time and didn’t catch up with the PR until after the fact.

If it helps, I’m strongly in Rich’s camp on this one. I probably wouldn’t use the feature either but the possibilities it opens up are tremendous and I’m really excited to see the number of incredible features it would lead to eventually.

So, how about 66%? Does that cross your threshold :wink:

27

I’d just add, having the support for YAML by itself isn’t what I’m excited about. I’m probably not going to change over to them either.

But it’s the stuff YAML files would enable that gets me excited and it’s all stuff that would come later.

  • what you see in the UI is what you see in the files
  • import/export (move between file based and managed easily)
  • UI widgets/pages in files?
  • building “modules” that include Items, Things, UI Widget, transformations all in one file (makes it easier to share on the forum and elsewhere), maybe even supported on the marketplace
  • Multiple rule templates in one file
  • support for rule templates from files (no need to publish to the marketplace first)
  • making changes don’t necessarily lead to breaking changes with the versioning; upgrades become much easier for end users
  • no more FUD about file support going forward
  • easier to support changes to the file formats for the developers

YAML file support is a necessary first step for many (but not all) of these I think.

28

There are more tricks such this, for example GitHub - seaside1/omatic: openHAB State O-Matic use thing properties, which happen to end also in json storage to retain its own state.