Sounds great, but please also consider real CalDAV calendars, not only Google calendars.
2 Likes
Thats not complaining, but a contribution to a simpler openHAB.
REGEX is indeed hard. It’s its own programming language (it was proven to be Turing Complete some years ago). I’d recommend maybe a link to one of the many tutorials out there and perhaps a tester. Though one problem a lot of users run into is that the way the REGEX transformation works is not standard. The transform needs to match the whole text and we need to use parens to define what part we want to return. Standard REGEX would just need to define the part of the text you want to return. And that is how the online REGEX testers work. That’s why we see so many postings along the lines of “It works in regex101.com, why not in OH?”
Given that this is an integration with an external service, it seems to me that it belongs in a binding. Obviously the CalDav binding will need to be replaced for OH 3.
In my opinion, I wouldn’t go out of your way to make this happen. If it’s easy to provide an API endpoint to allow bindings to post things to the schedule that seems reasonable, but like you say, if someone is using the CalDav binding then using a native calendar service makes sense to me.
Indeed. A lot of the “never cloud” users will want to be able to use OwnCloud or NextCloud calendars for something like this.
I like the scheduler a lot.
Now to bring up a bunch of tricky use case questions:
-
What about order? If two timers on an Item expire at the same time, is the order defined or undefined?
-
Timer loops? With two timers I could easily set up (deliberately or accidentally) a loop
-
That way you can influence (read: stop/restart) expire timers with a given ID or given tags.
This one is actually quite different from the way Expire Timers work and it makes me wonder whether it makes sense to do it. The Expire works like “when Item changes to a state that is not state x, set it to state x after the configured amount of time”. To cancel the timer one simply sets the Item back to the configured Expire state. Is there actually a use case where we would want to cancel the Timer without the Item going back to the Expired state? Maybe cancelling the Timers like this is overkill. Or maybe we we need only to support start/stop and not the Expire state behavior?
Obviously it would be a smoother transition for those of us who rely upon the current Expire binding. But part of me is wondering if we need to implement both use cases. Probably the answer is yes. Just throwing out the question a something to consider.
This raises a question. One important use case that is missing right now is personal alarm clocks. Here is a case where the biggest lack is the sitemap, and I’m not really intending to address that part of the problem here. But is there some way, assuming that a user interface is created to allow users to set the time, that they could set an alarm through this mechanism? I think the answer must be yes, but I can’t fit my mind around how. Is it as simple as just updating the DateTime Item tagged with “alarm”?
This post contains two parts, a whining part and a part about the alarm concept
Sitemaps and other things (mostly whining)
I agree. I have a concept for sitemaps replacement finished on paper and went to the information gathering phase to determine if I forgot any use-cases (OH Core: Sitemaps2 · Issue #1219 · openhab/openhab-android · GitHub, OH Core: Sitemaps2 · Issue #205 · openhab/openhab-ios · GitHub). Kai stopped that, because he want to push Proposal for a new Sitemap concept · Issue #5337 · eclipse-archived/smarthome · GitHub, which will, considering its complexity, finish around 2045.
I kind of expected that to happen and asked in Question: Sitemaps · Issue #594 · openhab/openhab-core · GitHub if the general idea is to have multiple concepts in the core repo. Because Yannicks card concept should IMO also be moved to the core, next to a sitemap2. Guess what, Nobody responded. I lost interest.
In https://github.com/openhab/openhab2-addons/pull/4979#issuecomment-466678902 and https://github.com/openhab/openhab2-addons/pull/4988#issuecomment-466803586 I don’t understand Kais position, or at least he is not explaining to me what his plan is for what goes into the core and what not. The new contributor of the later link is now confused of course. But -core and -addons2 use different build systems and IMO Kais request to move parts to the core (at this point in time) is such a great burden, that he will loose this new contributor in the end. He doesn’t seem to think about that.
I have "ab"used my OH2-addons maintainer powers to push https://github.com/openhab/openhab2-addons/pull/4943 in (which later on required Wouter to fix quite a few small bits and pieces in https://github.com/openhab/openhab2-addons/pull/4984) to prevent any discussion to happen there. This is in the context of a full MQTT HomeAssistant compliance PR and I don’t want to loose the contributor. I have seen PRs sitting in the repo for half a year and longer and I don’t want this to happen here. My consequence was of course, that I voluntarily left the OH2-addons maintainer group.
A lot of whining. I’m sorry. The TL;DR is: It should be easier for contributors. If that means that a bundle need to moved later on: That’s fine. If it’s known that the current situation doesn’t allow -core and -addons to be worked on in the same IDE session: Don’t require that from contributors. The maintainers team should internally discuss this urgently.
The alarm concept
I had exactly this use-case in mind. But I don’t see a UI coming in the near future. But its Yannicks nature to first develop behind hidden doors and then release something to the public. So he might have something already. Personally I’m using a Hue App and I’m setting alarms over there via the Hue emulation service, which lists me all NGRE Rules with the “alarm” tag. I expect a future OH UI to do the same. And also to support “Scenes” like the Hue App (which lists me NGRE Rules tagged with “scene”).
Expire timers
The order is undefined. But the average person sets up one of those timers and an expert should get that fact from the way the functionality is presented to him.
I think the resolution will be down to 1min, with all timed-out timers executing sequentially. There can be contradicting commands of course, I wouldn’t call them loops.
My use-case is the “light on, light off after a time, but motion sensor extends time”. And for that I needed a restart concept. A permanent on/off switch for example should stop any expire timer, while the sensor only restarts a running expire timer. If I just work with the item state, I cannot express that.
Cheers, David
2 Likes
I’m actually thinking of putting two alarms on one Item. One kicks off when the Switch changes to ON and sets the Item to OFF after a certain amount of time. The other kicks off when the Switch changes to OFF and after a certain amount of time changes the Item to ON. And so on forever. That’s what I meant by a loop.
Oh, true. That would be a limitation of this system. But the behavior is also very deterministic. A user should expect it, when setting it up that way, I guess. Not sure.
I think as long as we can documented it so this limitation/feature is covered we should be OK. I could see some uses for this actually. For example, what if I want a regular tick-tock event but the time between the tick and the tock is different from the tock and the tick. I’m not sure what a user would do with that but I’m always surprised by unexpected uses for stuff like this.
Because that was still on my design todo list, before I finish the app functionality wise.
Semantic tagging
I have shamelessly copied the help text from HABot Walkthrough (2/n): Semantic Tagging & Item Resolving and the image from https://github.com/eclipse/smarthome/issues/1093.
I think that this is prominent enough and that’s what I would expect from an OH UI. The semantic tags will be fetched from OH itself, so can be extended with future releases without touching the UI code.
Cheers, David
1 Like
Looks great. Have you given any thought on how to setup locations based on hierarchical relationships? How would the isPartOf be used to do this?
No not yet. But the current core API does not support hierarchical relationships. If you read through the eclise issue, there has happened that long discussion on how to implement semantic tagging. And the system we have in place now is actually quite good, apart from the missing hierarchy.
Friday weekly update
It’s this time of the week again.
Rule editor
BEFORE
AFTER
– 3-column mode
– Wide mode
– Wide mode. Multiple components per row.
I spend some thoughts on the rule editor. The Paper UI UX is not that bad actually. Three segments “When…”, “but only if…” and “then…” with the different rule components. Actions can be moved around (their position within the rule matters), everything else will be auto laid out.
I tried to color code the components with a different border color for each type. The output->input connections are not that visible this way though.
Free positioned rule components would of course also be cool, like in the former design. But rule sharing would be an Issue (with overlapping and hidden components) and rules cannot save their components relative xy position anyway.
Cheers, David
8 Likes
Order of execution? This is something I haven’t thought about before. Do Actions block and process in order, or in parallel?
When sharing Rules I would expect the first preference would be as a Rule Template. Second would be using the text version. I don’t know how useful the graphical view is for Rule sharing because at least in the But only if… and Actions there might be a good deal of information that is hidden in a dialog. Or are you planning on including the code in this view too?
I agree, I don’t like the lines for outputs in this view. But I do like over all approach. Since most of us have wider screens than tall, would three columns instead of three rows be better? It might be easier to track the input/output lines that way.
The location and color of the outline is pretty good. But perhaps an icon in the upper right corner of each box or something might improve. Lots of people are red/green blind rendering the distinction in color invisible for those users. If you go back towards a more free form positioning, the color coding I fear won’t be enough for some users.
I can definitely see myself using this to create Rules.
2 Likes
They process in order and blocking.
Cheers, David
1 Like
I want to add my opinion not as a programmer, but as a standard openHAB user.
Looking at the new openHAB study, it can be seen that it is made for users who are not familiar with programming, and who want to quickly and simply achieve the effect of using the application.
Looking at the new Items page by David, I have one point: less is more.
It means the settings can not be complicated. The fewer the elements = the better.
And don’t worry about advanced openHAB users - they still will use they favorite editors, because it is more natural for them.
I think a good example is HABPanel - that’s how new Sitemap should work. Adding elements in the sitemap and binding them with the appropriate items should be done directly on the sitemap page, as it is done in HABPanel.
The number of options you can choose for HABPanel elements is very limited, but sufficient. Thanks to this, it is easy to create a working panel very fast. And the effect is immediately visible.
For more demanding users HABPanel allows to create much more complex functions and appearance of elements, and more experienced users who care about delving into programming can tailor them to their needs. We know some nice themes of HABPanel - why sitemap could not look equally attractive ?
This is how the new openHAB should work (I think): very simply for standard users, with second bottom for advanced.
2 Likes
Here’s the problem with that. All those options are there for a reason. For example, if you want to use Google Assistant or Alexa, something a huge portion of non-advanced users do and will want to do, you gotta use tags. If you aggregate the requirements of all non-advanced users you will end up needing to support all of these options. So which subset of all these users do we throw to the wolves and say “sorry, better start learning because your requirement is considered advanced.” That is kind of the same situation we have now and it’s a problem, one of the problems this UI is attempting to address.
I understand the sentiment over all. And perhaps there are places where it can be applied. But for Items, I just don’t see a subset of parameters that would be “basic” and a set that would be “advanced”. Basic users will need to use all of the parameters.
And is 5 parameters really a problem? Only 3 of them are needed when creating the Item (name, label, and type).
As for the sitemap comments. There is a ton of work that needs to be done that can enable editing of sitemaps like that. There is a PR in progress but development on it has stalled out. Exactly what that would look like is still up in the air so it’s reasonable that David is not addressing it in this study. Keep in mind that the UI operates using the REST API and there currently isn’t any REST API calls for sitemaps.
1 Like
Maybe thats a good place to start then?
I do not fancy habpanel. In my opinion it´s standard setup/idea is outdated so much, so I´ll rather not use it… Except, I use it for for svg´s dashboards… Which means, I basicly use it as an browser. Thats it.
Sitemap is simple and powerfull, in my opinion. But it´s design is outdated as well. This makes sitemap useable for quick and easy non-fancy dashboard. And it gets the job done. Unfortunatly the way to create sitemaps is really bad.
I believe openhabs needs to turn everything upside down, and look at its design from this century. But this thread is not really about the dashboards, yet 
Like I said, there is a PR in progress but the development has stalled.
And we are back to one group of users demanding that we throw everything away and start from scratch and another group of users demanding that nothing change.
2 Likes
And I meant to write, “thats a good place to start from”, taken, another one will continue the developement ofcouse.
Demanding nothing change, isn´t really suppose to be an option.
If nothing ever change, there is no development either… No development in a smarthome system is never going to work for the future.
Therefore, demanding nothing change is really bad idea and should not be listen to or even maden an option.
The changes itself can ofcouse still become a target of discussion.
I’m a kind of power user of openHAB and yes it has advantages of the textual config for ‘advanced’ users, but if there will be an UI (like this study UI) I would use that instead of textual config.
Why? Because the config edited by this UI is stored in some human readable file (like json - but we talked about it in another post, if I’m right), I can still use some version control system, but I will also have an easily usable interface (where you can make less error - like typos, etc…) where I can anything I want.
The way you imagine this UI, would be only suitable for standard users. But that would mean that I would have to use it like PaperUI (using both the UI and config files) which is not very convenient and easily maintanable…
Agreed. My statement was supposed to highlight the unreasonableness of both positions. We have almost a decade of development, architectural decisions, and other decisions that we have to live with. We can’t just willy nilly scrap whole parts of the system all at once. Similarly we can’t just stay static and never change anything. It’s a balance that has to be struck. And that will mean that some parts of OH remain a bit behind “state of the art” in some areas. Each part needs to be addressed in turn and as there is a developer or two willing to work on it.
I actually didn’t mean to hit reply on that post. I was going to elaborate but I had to rush to go pick up the kid from school and accidentally hit “reply.”