Clock widget - background color can not be set using Configure widget
After 4.3 upgrade all my Clock widgets no longer assume the background color set using Configure widget.
To change the background I need to use stylesheet inside YAML.
stylesheet: |
.col > div {
color: black;
background-color: lightgreen
}
True, but I need the latest versionā¦ Or is the latest version in the marketplace the most recent version? I donāt think it is?
Only Markus will knowā¦
Hmm, some issues with Hue binding after updating from OH 4.2.3. I define everything in .things file and use bridge-api2 like this:
Bridge hue:bridge-api2:001788fffea7e2a6 "HueBridge" [ ipAddress="192.168.1.31", applicationKey="xyz" ] {
Thing hue:device:001788fffea7e2a6:fce7c646-80e8-4ea5-9563-cc66558e7e43 "StaircaseMotion" [resourceId="fce7c646-80e8-4ea5-9563-cc66558e7e43"]
}
Bridge thing says:
2024-12-17 21:39:05.783 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'hue:bridge-api2:001788fffea7e2a6' changed from UNINITIALIZED to INITIALIZING
2024-12-17 21:39:05.790 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'hue:bridge-api2:001788fffea7e2a6' changed from INITIALIZING to UNKNOWN
2024-12-17 21:39:05.937 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'hue:bridge-api2:001788fffea7e2a6' changed from UNKNOWN to OFFLINE (COMMUNICATION_ERROR): An unexpected exception occurred: Error opening HTTP/2 session -> java.lang.IllegalStateException: No Client ALPNProcessors!
Same issue if I add Bridge via UI.
Perhaps pax-web-jetty-http2-jdk9 feature was again removed like in #3814. (openHAB 4.1 Milestone discussion - #44 by wborn)
I made this bash script:
!/bin/bash
#sudo openhab-cli console -p habopen "feature:list -i | grep openhab-transport->
#UPGRADE=$(sudo openhab-cli console -p habopen "feature:list -i | grep openhab->
UPGRADE=$(openhab-cli console -p habopen "feature:list -i | grep openhab-transp>
TEZOEKENTEKST="openhab-transport-coap"
if [[ "$UPGRADE" =~ "$TEZOEKENTEKST" ]]
then
echo "was al geĆÆnstalleerd"
#echo "OpenHAB is geĆ¼pgraded. Sommige bindings zijn misschien niet meer>
else
sudo openhab-cli console -p habopen feature:install openhab-transport-c>
echo "net geĆÆnstalleerd"
sudo systemctl restart openhab.service
echo "opnieuw opgestart"
fi
And this rule in openHAB:
configuration: {}
triggers:
- id: "1"
configuration:
startlevel: 100
type: core.SystemStartlevelTrigger
conditions: []
actions:
- inputs: {}
id: "2"
configuration:
type: application/javascript
script: >-
var coapinstalled =
actions.Exec.executeCommandLine(time.Duration.ofSeconds(300),
"/bin/bash", 'bin/bashscripts/openhabcoap.sh')
//console.log("coapinstalled = "+coapinstalled)
type: script.ScriptAction
The echo parts are useless, of course, Iāll replace them with mailx notifications.
But I would assume this would work? Or wonāt the bash script wait long enough for Coap to be installed, before restarting openHAB?
Edit: Hmm, itāll break on the sudo partā¦
24 Hours into the upgrade from 4.2 to 4.3.
Very quiet log. Things are running smooth.
Had to put in the work to re-setup 45 Wiz bulbs but am liking the new binding.
Appreciate the help converting me from the traditional On off switch and Dimmer to using everything off the Color channel.
Everything on my wish list is doneā¦ now if we can crack the z-wave barrier and get to 700/800 series communication we will be set. I know the work that has to go into that, so i can live with 500 for now. But i think OH 4.3 is 99.9% of what i want.
See ZWave - Bindings | openHAB. 700 and 800 are already supported although 800 series only in the classic mode, not long range.
Man i have been asleep. I happen to have a 700 stick right hereā¦ looks like im not getting any rest for the next few hours
@florian-h05 With a bit brighter mind, I now tried to set the logging levels before pressing the play button. That worked. Shouldāve thought of that earlier of course 
Iāll try to check later today, but I assume the same goes for my laptopā¦
Edit:
Aha, I now found out that my earlier understanding that that cog wheel leads to a filter of the logs presented, is wrong. In reality, it changes the actual log level in openHAB. (In hindsight, the cog wheel would be a strange icon for a filter, so that makes senseā¦)
But I didnāt want to change the log levels. This is of course my own fault, but maybe there are other idiots like me, who misread the situation, and unknowingly change the actual log levelā¦ So maybe an easily visible warning of the repercussions of changing anything in that menu, is not a bad idea?
Iām using the same dongle and no issues with the update, so it would appear the problem lies elsewhere. Maybe a serial port issue?
Hello,
I upgraded today from OH 4.0.2 directly to 4.3 using the update mechanism from openhabian. Update run through without any problem, however the Webinterface on Port 8080 is not coming up. I checked in the logs and got the following error messages:
2024-12-18 10:17:36.155 [WARN ] [org.apache.felix.fileinstall ] - /openhab/addons does not exist, please create it.
2024-12-18 10:17:36.254 [ERROR] [org.apache.felix.fileinstall ] - Cannot create folder /openhab/userdata/tmp/bundles. Is the folder write-protected?
2024-12-18 10:17:36.261 [ERROR] [org.apache.felix.configadmin ] - [org.osgi.service.cm.ManagedServiceFactory, id=48, bundle=18/mvn:org.apache.felix/org.apache.felix.fileinstall/3.7.4]: Unexpected problem updating configuration org.apache.felix.fileinstall.af6d4b0a-c87f-448f-9a15-52aa522243d1
java.lang.RuntimeException: Cannot create folder: /openhab/userdata/tmp/bundles
at org.apache.felix.fileinstall.internal.DirectoryWatcher.prepareDir(DirectoryWatcher.java:647) ~[?:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.prepareTempDir(DirectoryWatcher.java:627) ~[?:?]
at org.apache.felix.fileinstall.internal.DirectoryWatcher.<init>(DirectoryWatcher.java:179) ~[?:?]
at org.apache.felix.fileinstall.internal.FileInstall.updated(FileInstall.java:250) ~[?:?]
at org.apache.felix.fileinstall.internal.FileInstall$ConfigAdminSupport$Tracker.updated(FileInstall.java:380) ~[?:?]
at org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.updated(ManagedServiceFactoryTracker.java:159) ~[bundleFile:?]
at org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.provideConfiguration(ManagedServiceFactoryTracker.java:93) [bundleFile:?]
at org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceFactoryUpdate.provide(ConfigurationManager.java:1266) [bundleFile:?]
at org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceFactoryUpdate.run(ConfigurationManager.java:1210) [bundleFile:?]
at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:122) [bundleFile:?]
at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:84) [bundleFile:?]
at java.lang.Thread.run(Thread.java:833) [?:?]
Any suggestions?
I realize another issue using screen.viewAreaWidth of custom widgets.
I did a simple test with a stripped down version of my custom widget:
uid: Cell_Test
tags: []
props:
parameters:
- description: HEX or rgba
label: Backgroundcolor
name: bgcolor
required: false
type: TEXT
- description: Page which will be opened as popup
label: Page ID
name: page
required: false
timestamp: Dec 18, 2024, 11:42:39 AM
component: f7-card
config:
title: = (screen.viewAreaWidth)
I integrate this into a test page:
config:
label: test1234
sidebar: true
blocks:
- component: oh-block
config: {}
slots:
default:
- component: oh-grid-row
config: {}
slots:
default:
- component: oh-grid-col
config: {}
slots:
default:
- component: widget:Cell_Test
config: {}
masonry: []
grid: []
canvas: []
When loading the page, I see the wifht of the browser windows. When I start changing size, it disapperas. Even F5-Reloading does not bring it back. I have to re-enter the full URL.
Bug report generated: [Main UI] screen.viewAreaWidth not updating / working Ā· Issue #2929 Ā· openhab/openhab-webui Ā· GitHub
Clock widget - no longer clickable
After 4.3 upgrade Clock widget have no action when you click over it.
In my case I used to to go to a new page when click over Clock widget.
Iām guessing this is a Docker install. Double check the file permissions on the files/folders mounted as a volume to /openhab/userdata. Make sure the user OH is running as (what ever you pass into the USER_ID environment variable or uid 9001 if you are not setting your own user ID).
Thank you Rich your answer. It is not a docker installation. It is an openhabian installation on a rasperry pi. I even used the openhabian configuration tool to do the upgrade as shown in the screenshot.
Any other ideas?
Unless something has really changed, there is no reason for OH to be writing to /openhab/userdata. That folder is /var/lib/openhab. Maybe these are the samba folders?
Note that itās also complaining about /openhab/addons which shouldnāt be there either but in /uisr/share/openhab/addons.
OH apparently doesnāt know where and how itās installed. Beyond that I canāt help too much. Maybe open a new thread and someone whoās an expert in openHABian can help.
Just a question from a unknowingly user. I found the place in the UI, where to configure the new logger
but I do not understand what to do know. As I understand, what one can see in the picture above, is what is set in the karaf-console
Platform :Windows 11 Pro
Java: zulu21.38.21-ca-jdk21.0.5-win_x64.msi
OH: 4.3
Web: Edge
In the new version of OH there is a problem with admin view to configure/define new rules, new things etc. the view is looking like āstill loadingā, only close and open brower again helps to re-view page.
Why?
It looks like on the pictures:
There is a new Log Viewer built into MainUI. This new viewer can be accessed via Developer Tools ā Log Viewer.
This log viewer will show all the logging events currently configured to be generated based on your logging configuration. You can filter whatās being shown.
If you need to change the logging level of a specific logger, click the gear icon at the bottom right and you will get a list of all the loggers currently configured. Find the one you want to change the level for, click the level (e.g. Error) and select the new level. This will change the level for that logger everywhere including your log files and the karaf console.
For example, if you want to see in events.log and in the log viewer when your rules are running, find the openhab.event.RuleStatusInfoEvent, click āErrorā and select āINFOā.
tl;dr, this isnāt a new logger, itās just a viewer with the ability to adjust your logging levels all in one place. It is going to reflect exactly what you see in the Karaf console as well as in log4j2.xml because itās all the same config.
As far as I can tell there is no way to create a new logger through the UI yet.
Never mind. If you enter the name of the logger you want to add it looks like it will add it. Clicking the X will remove it.
It looks like the docs for it havenāt been merged but when they are youāll find them under Developer Tools - Overview | openHAB
thank you again! just migrated off the old 500 stick to a 700 stickā¦ all works well with noticeably faster response time
