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:
- make this opt-in as suggested (could be a parameter in the
oh-home-pageor at theoh-equipment-card/oh-property-cardlevel) - at least not display the whole model hierarchy but keep only the last (or last two) groups.
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.
Thanks for the insight, I was not aware of this, so there is nothing I can do right now.
I will lock into possible workarounds.
There’s a workaround in the github issue for this - I haven’t tried it myself, but maybe it could help: [Mail] sendMail and sendHtmlFail errors for UI rules · Issue #11838 · openhab/openhab-addons · GitHub
Since I updated to 3.3.0M2 I can not write modbus holding register anymore. Before with M1 it worked without problems.
I did not change anything in the configuration.
Bridge poller Roll_W [ start=35, length=30, refresh=1600, type="holding" ]
{
Thing data T_R0_Nummer [ readStart="35", readValueType="uint16", readTransform="JS(dimread255.js)", writeStart="35", writeValueType="uint16", writeType="holding", writeTransform="JS(dimwrite255.js)" ] }
The error is:
Thing 'modbus:data:SPS:Roll_W:T_R0_Nummer' changed from UNINITIALIZED to UNINITIALIZED (HANDLER_CONFIGURATION_PENDING): Fehlende oder ungültige Konfiguration.
I am a little surprised, because in the release notes does not say anything about changes in the modbus
binding.
Anyone got an idea?
Thank you.
I’m experiencing the same error with my Homematic devices. Interestingly, it doesn’t make a difference if I use the file-based config (that was working before) or add them via WebUI.
Could it be something more generic that changed in the config parsing between 3.3M1 and 3.3M2?
See Config validation preventing things initialising · Issue #2710 · openhab/openhab-core · GitHub and enable config validation for thing creation and update by J-N-K · Pull Request #2682 · openhab/openhab-core · GitHub. There’s more stringent validation added to this milestone release.