I want the pages. I’d like to disable the new breadcrumb headers on the cards in those pages.
As far as I’ve seen (albeit only a very cursory look) there is no way to do so. This only useful under a very particular nomenclature setup (one where semantic names contain bare minimum information), so it’s not going to be a feature that every users needs or wants.
I think they might go away when you define a custom list Item widget for the Item. That seems to be the case for me at least.
I haven’t looked to see what’s different or if there is a new field or something to turn it on or off on a per Item basis but appears to be possible at least.
The first two use my custom List Item Widget (can be found in the marketplace) and the last two are completely unaltered defaults.
I hadn’t noticed that yet (just loaded up the milestone this morning). Defining new custom widgets for everything just to get rid of these is little bit of overkill even for my obsessive nature. Plus, that only fixes the property cards. On the equipment cards the breadcrumbs are in the header lines which we can’t impact with custom widget (to my knowledge).
This change avoids redundant labeling in the 3 model pages while allowing non-ambiguous labeling in all of them. I have not found another possibility to reach this goal without providing another metadata field to define various labels for each page.
I’ve had good feedback regarding the result of these changes from users in setups with dozens of equipment (several hundreds of points) and many similar equipment in various rooms (e.g. one thermostat per room), using only automatically generated pages (no custom widget).
As I wrote above, it relies on the assumption that you label the model without redundancy, or as you say, the bare minimum to fully define one location/equipment/point in relation with its parent. Bare minimum sounds good to me. No redundancy means less work in an initial setup and less work in case of change. In your case this means for example that “Master Suite” > “Master Bedroom” > “Master Bedroom Fan” groups would simply have to be defined as “Master Suite” > “Bedroom” > “Fan”.
There is always room for improvement but I personally think that ultimately openHAB should automatically provide the lightest but non-ambiguous labeling in all pages with the least amount of work for the admin and sensible configuration options as always in openHAB spirit. Therefore I’ll try to continue to propose PRs that improve labeling in other automatically generated pages (thinking about graphs), and also provide access to this labeling for vertical/functional groups.
There is no big issue to provide an option to keep the previous behaviour in the next milestone, and perform a few tweaks (remove the top level Location which appears to be identical in several setups).
Concerning the Properties page, again, I don’t think user-facing pages should display Item’s name except as a placeholder when a label is missing in the configuration.
All of this is my personal opinion and of course @ysc as both the maintainer and the author of the UI will have the final say wether we should revert to 3.2 behavior or go forward in this direction with configuration option to keep the old/new behaviour as an option.
I have no objection to the addition this feature, and you’ve done a good job with it. I merely think it should not be the default or only option, but an opt-in feature. As a default feature, it does something that, in some ways, is completely antithetical to OH’s design: impose a nomenclatural “ideal” on users. If a user chooses this kind of nomenclature, then this is a good option to have. Pre-supposing that all users prefer this is, IMO, a step backward.
As I’m sure it does to many users. I can, however, say with certainty (myself being one of them), not to every user. In fact, for me this is an active step backwards. The “redundancy” this is attempting to fix is not a significant issue for me or my users. A repetition of one or two words (e.g., “Master Bedroom”) in a header or footer is far less problematic when visually taking in an interface, than a long chain of verbiage, much of which is completely extraneous to the task at hand. It is distracting and more difficult to parse.
I do not want to take this feature away from users that do find it useful, I am only advocating that those users be able to opt in to it.
Yes, it is clear what you would like me to use as a nomenclature, but as I explained in the initial thread about this, that “simplified” version doesn’t work for me, and the only thing I am pointing out is that because it works well for you does not mean it is a universal solution. In my system it has several significant disadvantages:
This is actually less useful in terms of a natural reference. This is only the “fan”, if I am standing in the Master bedroom. In all other cases it is naturally referred to as the “bedroom fan” or even the “Master bedroom fan”. It is only the “light” when I am standing in the kitchen, otherwise it is the “Kitchen light” and if I am going into a natural user interface to interact with this device I am thinking about it in a natural way. Taking that information in from two sources is more difficult than reading it in a single label and it is extra difficult if I have to follow a long chain of extra text as one of those sources.
In all the custom widgets I have that aggregate similar devices, having each of them with the label “Light” or “Door” becomes completely useless. In those widgets it is essential (and continues to be sensible and natural) to have the labels contain that extra bit of information whether or not it is “redundant” with the equipment label. So I should rework all of my widgets to also traverse the semantic data in order to add some sensible label to the items being used?
The way I see it, this does not actually reduce any work, it just shifts that work (for example see above: widget development is now more difficult). The work has to go in somewhere and it should simply be a personal preference as to where not a one-size-fits all approach.
Thing is, this may work for auto-generated overview UI pages, but if I’m not mistaken it will not for voice skills, will it ?
Those access the label so you still have to make the label the “Master Bedroom Fan” there.
So your argument isn’t really valid as it won’t save the user from creating redundant descriptions. Same for custom UI pages: if the context doesn’t tell you the Fan is in the Master Bedroom then you don’t know which of your fans that symbol represents, and the default “Fan” label won’t help.
What’s more, voice, while not as “visible”, is more important than the (auto) web UI is because it is what people will use in the long run, in addition to custom UI. The auto-generated pages are nice to show to some friend but not really important to advanced users to live in the smarthome.
FWIW there have been extensive discussions in the past around this e.g. Semantics and Metadata for Alexa Skill - #6 by Celaeno1 .
I agree. As it is in 3.3.0.M1 is horrible and breaks my objective of not using sitemaps.
Thanks for the “@”.
I greenlighted this change because IMHO it was a genuine improvement with no drawbacks. Previously in the Equipment & Properties cards (but not the Location cards) you had the item’s name in the footers, because you often have Point items that are labeled “Temperature” or “Status” or “Open” and it’s difficult to tell them apart without a bit of context when they’re grouped together.
The item’s name wasn’t ideal because it’s technical information not normally suitable to present to end users. And displaying the whole model hierarchy also made sense for those cases where you have e.g. multiple corridors on different floors all labeled “Corridor”.
So I didn’t anticipate there would be so much backlash about this change, but that’s fine, especially in UI design it’s hard to get everything 100% right on the first try. It’s okay in my book to test the waters with these kinds of changes in milestone releases, as they are easily reversible.
I think the best course of action would be indeed to:
oh-home-page or at the oh-equipment-card/oh-property-card level)That’s why I’ve invested a lot of time during 2.x to 3.x migration to define “equipments” as suggested in the model structure.
See Unexpected alarm report (?) from Zwave device - #8 by tonus :
My Zwave BeNext AlarmButton is not recognized anymore by 3.3M2, whereas it was recognized correctly in 3.2.
Note that the definition had issues, but that’s addresses in this thread.
Hi,
in my Jython scripts I use the following code to send mails:
actions.get("mail", "mail:smtp:localhost").sendMail('test@example.com', 'subject', 'body')
This worked fine until, but after updating to the latest snapshot release I get the following error:
Error during evaluation of script 'file:/etc/openhab/automation/jsr223/python/personal/test_rules.py': java.lang.NullPointerException: java.lang.NullPointerException in /etc/openhab/automation/jsr223/python/personal/test_rules.py at line number 43
I assume, that the “actions.get()” fails, but I found nothing in the release notes which might be related. Does anybody have an idea, what might be wrong?
Juelicher
I have the same with zwave:abus_shbw10000_00_000.
It worked flawless with 3.3.M1. Now it claims:
UNINITIALIZED (HANDLER_CONFIGURATION_PENDING): @text/missing-or-invalid-configuration
I had the same with a Fibaro FGD212 Dimmer 2 after upgrading to 3.3.0 M2. After deleting and re-adding the thing, I got it back working. However, then it was complaining about a wrong configuration - very long message, this is just part of it:
Attempt to apply invalid configuration 'Configuration...
...{key=group_1; type=ArrayList; value=[controller, controller]}...
...This is most likely a bug: {group_1=Only 1 elements are allowed but 2 are provided.}
*<note: I have deleted the rest of the message between the ...>*
Even after deleting the zwave xml file, the above error was showing again in the logs. But at least the Dimmer is working now. Very strange, since I have multiple Fibaro Dimmer 2 nodes and this one was the only one showing that behavior.
@juelicher tried using a snapshot that’s a few days before M2 and actions.get worked. I tried to send an email with it and it worked. Then I updated to the latest snapshot (after M2) and it still works. Note I’m not using jython though. Do you have a stack trace?
I found the following debug messages:
2022-03-06 14:02:52.283 [DEBUG] [onfig.core.ConfigDescriptionRegistry] - No config description found for 'thing:zwave:device:gehirn:node36', using alias 'thing-type:zwave:abus_shbw10000_00_000' instead
2022-03-06 14:02:52.291 [DEBUG] [st.core.internal.thing.ThingResource] - Config description validation exception occurred for thingUID zwave:device:gehirn:node36 - Messages: {config_100_1=The value 0 does not match allowed parameter options. Allowed options are: [ParameterOption [value="1", label="Reset parametera 101 - 104"]], config_101_4=The value 7200 does not match allowed parameter options. Allowed options are: [ParameterOption [value="0", label="Disabled"]], config_102_4=The value 7200 does not match allowed parameter options. Allowed options are: [ParameterOption [value="0", label="Disabled"]], config_12_1=The value 10 does not match allowed parameter options. Allowed options are: [ParameterOption [value="0", label="Disabled"]], config_104_4=The value 7200 does not match allowed parameter options. Allowed options are: [ParameterOption [value="0", label="Disabled"]]}
2022-03-06 14:02:52.297 [ERROR] [rg.apache.cxf.jaxrs.utils.JAXRSUtils] - No message body writer has been found for class java.util.Collections$UnmodifiableMap, ContentType: */*
But the claimed validation exceptions do not fit to the documentation as found here https://opensmarthouse.org/zwavedatabase/1103/reference/ABUS-SHBW10000-BDA-EN-1-3-v2-.pdf :
e.g. for Parameter 101 the documentation states:
The interval time of the temperature report.
The value 0 disables the report.
- Adjustable from 0 - 2678400 in seconds
The value is always rounded up to the full
minute. (e.g. 62 seconds → value is rounded up
to 120 seconds)
(Hexadecimal: 0x00 – 0x28DE80)
While the debug message says:
config_101_4=The value 7200 does not match allowed parameter options. Allowed options are: [ParameterOption [value=“0”, label=“Disabled”]]
No, it is just the nullpointer exception in the log file, no trace. I updated from the previous milestone to the current one, with the previous milestone everything was fine.
I tested the mailserver (Postfix, running on the same server) by sending mails from the command line as user openhab and this also worked fine.
I could try downgrading openhab to the previous milestone, not sure how but somewhere in this forum is a description, I will try that out.
i am on openHAB 3.3.0.M2 - Milestone Build and i also use the exact same line for email in my jython scripts. i dont realize any problems sending emails. (but when i tried to use your line with just “subject” and “body” the mails where moved to spam immediately)
Very strange. I just did a downgrade to the previous milestone and still get the same error.
Just to be sure I checked my mails, until upgrading to milestone 2 I did receive mails from openhab… And there have been no changes in the configuration or in my scripts.
[Edit]
Not sure if this matters, I am using Zulu Java 11:
openjdk version “11.0.14.1” 2022-02-08 LTS
OpenJDK Runtime Environment Zulu11.54+25-CA (build 11.0.14.1+1-LTS)
OpenJDK 64-Bit Server VM Zulu11.54+25-CA (build 11.0.14.1+1-LTS, mixed mode)
Your issue is the mail binding. It‘s broken when sending mails due to class loading issues. Under some (not fully understood) circumstances it works, but most of the time it fails.
So the upgrade probably changed the order in which bundles are loaded or which class loader loads the mail bindings Action classes.