Hi,
with growing interest I’ve been following the development of @Dimitris design draft for a few days now.
As I am professionally involved with Vue.js I found the implementation in openHAB very promising, however the usage within openHAB is significantly different than how I have been using Vuejs so far.
I also have problems to find out where I can find documentation that explains the concept of the implementation and the interaction within openHABs a bit better and I don’t mean the stuff with Things, Models, Items and co, but rather website structure technically. How do I know which config parameters I can use for a page?
Currently I ask myself the question: How can I query the page:uid as an expression?
Have a nice evening and good luck with the implementation of @Dimitris design, which I like very much.
I believe that the variable is overwritten with every action, so you’ll have to be careful. If you want an action to change just one key in an object that has more than that, I suspect that you would still have to lay out all the object keys and just pass the unused one through for every action:
The OH widget system is a very trimmed down interface to the UI’s vue pages. A lot of the direct Vue capabilities that you are expecting are not available to the user via this system. It’s been intentionally developed to be low code and nearly exclusively yaml to be approachable by users with little to no coding experience. Besides basic yaml structure, there is access to rudimentary js expressions and a few workarounds for some more advanced features. You can see the source for the UI here: GitHub - openhab/openhab-webui: Web UIs of openHAB which should give you a better idea of where the custom widget system fits.
I have choose the "All " text instead of Home to avoid optical confusion with Home on upper Menu (double texting). Yes, “All (floors)” = “Home”!
Now I’m working on the Home Section trying to eliminate the tab bar (ONLY for this section). This is a very early draft, don’t take it seriously, but pls investigate if we can eliminate/ hide the tab bar if the user selects the Home.
@Nic0205 Yesterday, while reading @hmerk’s simple question re floors i realized that i haven’t done all my exercise before release the drawings…
My apologies: I hate to put even a small brake on the enthusiasm that lives here!
Note that i don’t have extensive knowledge /background in security systems. I created this with a very simple rule in my mind: Trigger (input) - Action (output).
Input:Item(s) state change
Output: Siren and or Notification(s) or an OH Rule.
Hi @hmerk
Here is a short description re layout / functionalities of the alarm page.
Header
Nav Bar: Home: Security
• Optional: Underline color express the state (green: stay, red: armed)
Middle part:
• Stay or Armed. - User can select only one of them.
• List of Items participated in the Alarm System (icon-Description-State)
Footer (output)
• Siren, Notifications, OH Rule (icon, Description, status) Light Grey: Not selected as output Colored: Selected as Output.
The Alarm system have two states:
Stay or Armed. - User can select only one of them (!)
For (ON-OFF) Items that participates in the system, the user will be able to choose what will happen in case the status one of them changes, either from OFF to ON, or from ON to OFF.
ON STAY MODE
Available Options:
Send a Notification (Siren and OH Rule is disabled for STAY mode).
ON ARMED MODE
Available Options:
Activate Siren AND OR
Send Notification OR
Run an OH Rule.
Exceptions:
When the user arms the system and not all Items report their state as OFF the system will arm activating selected outputs and excluding / ignoring (ON) Items and report them with a caution icon (next to ON-OFF ).
The Armed ICON changes to (!) together with the text (Armed with faults).
Optional: The OH can recheck with a timer (only through an OH Rule), and if the excluded items reports their state as OFF, then (magically) will be part of the alarm system.
So, the question is: Does this approach covers a simple alarm system?
No, it should have 3 states : Armed, Armed-Home and Away. This is what we see in several Alarm Systems. We could implement a config option to hide the Amed-Home Button.
Should be easy, as it is just a list of Items belonging to a group. Prerequisit will be to have the groups correctly set.
Siren, really ? What benefit do you see to show the srien state here ? You will hear it anyway…
OH-Rule - What do you expect ?
See above
No, it should be just a simple state option. Configuration of the Alarm System should be done in another place, best behind some kind of administration security.
If you mean changing from armed to disarmed should send a notification. This needs to be done with a rule, warching the state of the Security state item.
Everything that happens on an alarm should be built outside the UI in rules. So if motion is detected while security is armed, a rule should trigger the siren and send messages.
No, this should be user configurable. In my installation, arming the alarm is not possible if the terrace door or some windows are still open. openHAB will inform me about what needs to be closed.
Not from my perspective. The UI should be mostly a display for the alarm system, but configuration can be very individual and should be out of scope here. We do not want to restrict users.
Did you made already any effort on this? Just asking if it is worth for me to dive deeper in or just to wait a little bit until you finish your first attempt.
Small effort, but nothing to show yet really. I am struggling with the default widgets for Equipment, as we sometimes need multiple items in one widget…
Is there a chance to order the items in the array? I see that they are orderer in alphabetical way. But I want to order them based on the semantic-model meta-data-tag “Default Widget Order Index”.
Hoo boy! This seems like an easy question at first, but it turns out it is actually quite a difficult question you’ve gotten into here.
There is no method built-in to the repeater to sort the results. It can be done in a limited fashion by using the map property. That’s basically what the current system does; it uses the map property to reorder the array so that the one that corresponds to the selected menu index is first with wrapping of the index back around to the beginning of the array where necessary.
Theoretically we could just apply the js array sort method in the map expression before we do our custom reordering, but it turns out it is not much help here. By default it sorts an array alphabetically and if you want it to do anything more complex then you have to supply it with a custom sorting function. The problem is that the js expression system that the widgets use doesn’t currently have the add-on that allows functions installed so we can’t use any advanced array sort.
The other option would be, because these items are all in a flex box, to use the order property to tell the flex box which order to place the child items in, but this would be applied after we’ve reordered the array using the map expression, so it would undo whatever re-ordering was done to make the menu function.
So, the long answer is “no, not really any way to get additional ordering of the item.” But…that’s not a very satisfactory answer. Let me think for a while about whether there is a solution to this problem.
Guys, as promised, here is the next step from my side.
Prerequisits as before with some additions:
You need the widgets "Cell_Card_Light_2 and Cell_Shutter_Card_1 from the community (just for demo purpose, can be changed at a later step.
All light or rollershutter items need to be member of an according equipmment.
Limitations at the moment :
Only working if Thing from Bottom Menud is selected (visible: config needs to be extended)
I did not find a way to have more than one item (Switch/Dimmer e.g.) identified for one equipment to setup both for one widget (@JustinG Do you have an idea ?)
Therefore this is only working for simple lightswitch and rollershutter atm.
Resetting the selections when you go back to the home menu missing.
I’ve not found a good way to do this yet. If you take a look at the code for my favorites bar, you’ll see that my solution was somewhat brute force: just create a copy of every widget with the item, but then hide the all the widgets where the item type doesn’t match. It works in that situation because there are usually few enough widgets. I don’t know if it becomes a performance issue in with something like this.