Changing the thing definition to UI solved the problem as expected.
Thanks!
But a real solution has to be found, we cannot accept having bindings becoming incompatible with thing definition in config file.
4 Likes
Help!! I just used openhabian to upgrade my system from 3.4.M2 to 3.4.M4 but unfortunately although the upgrade completed successfully, it seems that OH is not actually running on my system anymore; command sudo systemctl start openhab.service produces no result, and the OH web server is not running. => Suggestions appreciated!
System is a Raspberry Pi4.
EDIT: (solved) a cache clean and a hard power cycle of the Pi solved it.
What says systemctl status openhab?
Moderation reminder:
Please stay on topic and only discuss issues to affect everybody or many.
Open your own threads for anything else. Thank you.
It says the system is running.
It is definitely broken. I get this…
2022-11-13 22:09:52.696 [WARN ] [mon.registry.AbstractManagedProvider] - Could not update element with key systeminfo:computer:g24 in ManagedThingProvider, because it does not exists.
EDIT: … I get the above error when starting my system; however if I disable and re-enable the thing, then it goes online normally. (So @Mherwege you might just have a timing issue…)
The bug with systeminfo binding, which is in fact a bug in core framework, is not yet fixed in milestone 5, the PR is still in review.
Since upgrading tot M5 I see these messages in my openhab.log each time a JS file is loaded at startup.
2022-11-28 01:07:18.997 [DEBUG] [rg.openhab.automation.script.actions] - Successfully activated action org.openhab.core.model.script.internal.engine.action.AudioActionService@67265b as Audio
2022-11-28 01:07:19.001 [DEBUG] [rg.openhab.automation.script.actions] - Successfully activated action org.openhab.core.model.script.internal.engine.action.EphemerisActionService@1a930af as Ephemeris
2022-11-28 01:07:19.004 [DEBUG] [rg.openhab.automation.script.actions] - Successfully activated action org.openhab.core.model.script.internal.engine.action.PersistenceActionService@e19f3f as PersistenceExtensions
2022-11-28 01:07:19.008 [DEBUG] [rg.openhab.automation.script.actions] - Successfully activated action org.openhab.core.model.script.internal.engine.action.SemanticsActionService@4226b8 as Semantics
2022-11-28 01:07:19.012 [DEBUG] [rg.openhab.automation.script.actions] - Successfully activated action org.openhab.core.model.script.internal.engine.action.TransformationActionService@5d9009 as Transformation
2022-11-28 01:07:19.015 [DEBUG] [rg.openhab.automation.script.actions] - Successfully activated action org.openhab.core.model.script.internal.engine.action.ScriptExecutionActionService@106db89 as ScriptExecution
2022-11-28 01:07:19.018 [DEBUG] [rg.openhab.automation.script.actions] - Successfully activated action org.openhab.core.model.script.internal.engine.action.ThingActionService@1e7753a as Things
2022-11-28 01:07:19.022 [DEBUG] [rg.openhab.automation.script.actions] - Successfully activated action org.openhab.core.model.script.internal.engine.action.VoiceActionService@1e26244 as Voice
2022-11-28 01:07:19.025 [DEBUG] [rg.openhab.automation.script.actions] - Successfully activated action org.openhab.io.openhabcloud.internal.CloudService@1c21c3 as NotificationAction
2022-11-28 01:07:19.029 [DEBUG] [rg.openhab.automation.script.actions] - Successfully activated action org.openhab.ui.habot.notification.WebPushNotificationAction@199f06 as WebPushNotificationAction
Openhab seems to run ok.
Reading through the log messages, it seems like everything is fine.
Please note that your are on debug log level, normally you should be on INFO.
You can set this to INFO level by executing
log:set INFO org.openhab.core.model.script
in the openHAB Karaf Console.
Hi @florian-h05 , Thanks! I don’t know why I am on debug. Anyway, I thought it best to reports as these lines didn’t appear before and I havent turned on debug level logging.
1 Like
Just some positive feedback. For me the JavaScript (ECMAScript 2021+) scripts seems to run faster on M5 than before 
.
1 Like
I am running a 3.4.0.M5 version in a docker container as a test environment.
On this test environment, I have installed the Remote openHAB Binding and linked it to my production environment running M3.4.0.M4. As a result, I got 540 Things in my inbox on the test environment.
I have accepted a few remote-connected things of which 3 were switches. One a Homematic and 2 zigbee ones.
All my rules acting on switch operations are based on channel triggers. I was testing the remote channels triggers and realized that the triggers are issued twice:
2022-12-02 17:18:18.609 [INFO ] [openhab.event.ChannelTriggeredEvent ] - remoteopenhab:thing:192_168_3_200:deconz_switch_00212E00C488_04cd15fffe6f9d60011000:deconz_switch_00212E00C488_04cd15fffe6f9d60011000_buttonevent triggered 1002
2022-12-02 17:18:18.610 [INFO ] [openhab.event.ChannelTriggeredEvent ] - remoteopenhab:thing:192_168_3_200:deconz_switch_00212E00C488_04cd15fffe6f9d60011000:deconz_switch_00212E00C488_04cd15fffe6f9d60011000_buttonevent triggered 1002
2022-12-02 17:18:23.952 [INFO ] [openhab.event.ChannelTriggeredEvent ] - remoteopenhab:thing:192_168_3_200:deconz_switch_00212E00C488_04cf8cdf3c77c3a2010012:deconz_switch_00212E00C488_04cf8cdf3c77c3a2010012_buttonevent triggered 2002
2022-12-02 17:18:23.953 [INFO ] [openhab.event.ChannelTriggeredEvent ] - remoteopenhab:thing:192_168_3_200:deconz_switch_00212E00C488_04cf8cdf3c77c3a2010012:deconz_switch_00212E00C488_04cf8cdf3c77c3a2010012_buttonevent triggered 2002
2022-12-02 17:18:32.909 [INFO ] [openhab.event.ChannelTriggeredEvent ] - remoteopenhab:thing:192_168_3_200:homematic_HM_PB_6_WM55_3014F711A0001F58A992FB22_NEQ1001224:homematic_HM_PB_6_WM55_3014F711A0001F58A992FB22_NEQ1001224_5_BUTTON triggered SHORT_PRESSED
2022-12-02 17:18:32.911 [INFO ] [openhab.event.ChannelTriggeredEvent ] - remoteopenhab:thing:192_168_3_200:homematic_HM_PB_6_WM55_3014F711A0001F58A992FB22_NEQ1001224:homematic_HM_PB_6_WM55_3014F711A0001F58A992FB22_NEQ1001224_5_BUTTON triggered SHORT_PRESSED
Might be a bug, or I made a setup error, as this is my first contact with this binding.
I have also tested the behavior with the test environment being on 3.4.0.M4 and I see twice the channel trigger too.
Please check your logs on your production environment.
In case you confirm only one trigger in production env leads to both triggers in your test env, I will have a look in the remote openhab binding.
@mark_leonard_tuil A quick update on this:
The log messages are coming from the openHAB JavaScript library, not from openHAB Core or the addon itself.
The library is logging to org.openhab.automation.script+suffix, which logger is configured to provide debug logging from console.debug inside JS scripts.
I‘ll see how I can remove or change that logging to not confuse the user.
I’m just not sure why the messages are only logged since 3.4.0.M5 and not before.
Simply set org.openhab.automation.script.actions logging to DEFAULT or INFO, it’s set to DEBUG (I guess by accident)
From karaf console:
log:set DEFAULT org.openhab.automation.script.actions
Since the upgrade from M3 to M5 I get this
2022-12-02 17:14:57.671 [WARN ] [core.thing.internal.ThingManagerImpl] - No config description for 'channel-type:http:channel-config' found when normalizing configuration for 'http:url:2528d4c641:address'. This is probably a bug.
2022-12-02 17:14:57.761 [INFO ] [nding.http.internal.HttpThingHandler] - Using the secure client for thing 'http:url:2528d4c641'.
I only use one channel on the HTTP binding, and it appears to working OK.
- Platform information:
- Hardware: RPI4 8G
- OS: Raspbian GNU/Linux 10 (buster). OpenHABian
- Java Runtime Environment: openjdk 11.0.16
- openHAB version: 3.4.0.M5
Can you please check in the REST API if the channel-type config description is really missing (Developer-Tools → API Explorer → GET config-descriptions/{uri} → Try it Out → channel-type:http:channel-config → Execute)?
Looks like it’s not missing
{
"uri": "channel-type:http:channel-config",
"parameters": [
{
"description": "Transformation pattern used when receiving values. Chain multiple transformations with the mathematical intersection character \"∩\".",
"label": "State Transformation",
"name": "stateTransformation",
"required": false,
"type": "TEXT",
"readOnly": false,
"multiple": false,
"advanced": false,
"verify": false,
"limitToOptions": true,
"options": [],
"filterCriteria": []
},
{
"description": "Transformation pattern used when sending values. Chain multiple transformations with the mathematical intersection character \"∩\".",
"label": "Command Transformation",
"name": "commandTransformation",
"required": false,
"type": "TEXT",
"readOnly": false,
"multiple": false,
"advanced": false,
"verify": false,
"limitToOptions": true,
"options": [],
"filterCriteria": []
},
{
"description": "This value is added to the base URL configured in the thing for retrieving values.",
"label": "State URL Extension",
"name": "stateExtension",
"required": false,
"type": "TEXT",
"readOnly": false,
"multiple": false,
"advanced": true,
"verify": false,
"limitToOptions": true,
"options": [],
"filterCriteria": []
},
{
"description": "This value is added to the base URL configured in the thing for sending values.",
"label": "Command URL Extension",
"name": "commandExtension",
"required": false,
"type": "TEXT",
"readOnly": false,
"multiple": false,
"advanced": true,
"verify": false,
"limitToOptions": true,
"options": [],
"filterCriteria": []
},
{
"default": "false",
"description": "This specifies whether the URL is already escaped. Applies to the base URL, commandExtension and stateExtension.",
"label": "Escaped URL",
"name": "escapedUrl",
"required": false,
"type": "BOOLEAN",
"readOnly": false,
"multiple": false,
"advanced": true,
"verify": false,
"limitToOptions": true,
"options": [],
"filterCriteria": []
},
{
"description": "Content for state request (only used if method is POST/PUT)",
"label": "State Content",
"name": "stateContent",
"required": false,
"type": "TEXT",
"readOnly": false,
"multiple": false,
"advanced": true,
"verify": false,
"limitToOptions": true,
"options": [],
"filterCriteria": []
},
{
"default": "READWRITE",
"label": "Read/Write Mode",
"name": "mode",
"required": false,
"type": "TEXT",
"readOnly": false,
"multiple": false,
"advanced": true,
"verify": false,
"limitToOptions": true,
"options": [
{
"label": "Read/Write",
"value": "READWRITE"
},
{
"label": "Read Only",
"value": "READONLY"
},
{
"label": "Write Only",
"value": "WRITEONLY"
}
],
"filterCriteria": []
}
],
"parameterGroups": []
}
Anything else I can check?
No, I guess it’s a race condition, the thing is initialized before the channel state descriptions are loaded. You can probably ignore it.