@florian-h05 , did you ever make the changes in the referenced post? I was evaluating 5.0-snapshot #4702 and it seems that the Widget Order Index was very inconsistent when floating point numbers were used. For example, items tagged 0.83 would for sort ahead of 0.81, and Group items did not seem to respond to ordering at all, but rather were just sorted alphabetically. This was not the observed behavior in 4.3.5 which I basically just updated to 5.0-snapshot #4702 on a test docker. Any thoughts what I may be doing wrong?
No, forgot this, sorry.
I just did it: Allow float values for widget order by florian-h05 · Pull Request #3247 · openhab/openhab-webui · GitHub
1 Like
Since 2-3 weeks my test OH latest snapshot at synology nas docker does not start with the following log
Starting with openhab user id: 9001 and group id: 9001
Create group openhab with id 9001
Create user openhab with id 9001
adduser: Warning: The home dir /openhab you specified already exists.
Adding user `openhab' ...
Adding new user `openhab' (9001) with group `openhab (9001)' ...
adduser: The home directory `/openhab' already exists. Not touching this directory.
adduser: Warning: The home directory `/openhab' does not belong to the user you are currently creating.
Adding new user `openhab' to supplemental / extra groups `users' ...
Adding user `openhab' to group `users' ...
Adding user `openhab' to group `audio' ...
Done.
Adding user `openhab' to group `audio2' ...
Done.
Adding user `openhab' to group `audio3' ...
Done.
Adding user `openhab' to group `audio4' ...
Done.
Adding user `openhab' to group `audio5' ...
Done.
Adding user `openhab' to group `dialout' ...
Done.
Adding user `openhab' to group `dialout2' ...
Done.
Adding user `openhab' to group `dialout3' ...
Done.
Adding user `openhab' to group `dialout4' ...
Done.
Adding user `openhab' to group `gpio' ...
Done.
Adding user `openhab' to group `uucp' ...
Done.
Adding user `openhab' to group `uucp2' ...
Done.
Adding user `openhab' to group `uucp3' ...
Done.
Image and userdata versions differ! Starting an upgrade.
tar: Removing leading `/' from member names
You can find backup of userdata in /openhab/userdata/backup/userdata-2025-07-07T05-48-01.tar
################################################
openHAB Docker update script
################################################
The script will attempt to update openHAB to version 5.0.0-SNAPSHOT
Please read the following notes and warnings:
Important notes for version 5.0.0:
Warning: CORE: Persistence alias functionality has been improved, allowing defining aliases across strategies and filter criteria for a persistence service. Previous persistence configurations using aliases need to be reconfigured.
Warning: Automower Binding: Implementation of complete automower API causes several channels to be removed, changed or added. New channels will need to be linked, existing items need to be adjusted.
Warning: Guntamatic Binding: The Binding now uses channel groups and the dynamic status channels now have an index prefix to allow multiple channels with the same description. Existing Items will need to be adjusted.
Warning: Juicenet Binding: The Binding has been removed due to removal of public API. Suggested alternative is to use https://github.com/JuiceRescue/juicepassproxy with the mqtt.homeasssistent binding.
Warning: Jython Automation: Transformation service name is renamed from "PY" to "JYTHONPY". "PY" is now used for transformations of the new Python Automation add-on.
Warning: Linky Binding : The Linky binding was refactored to add new functionalities. You now need a bridge device for the Linky binding to work. See Readme.md for detailed upgrade instructions.
Warning: MQTT Binding (Home Assistant): Thing types and channel IDs for things created prior to 4.3.0 have been significantly restructured and simplified. Items will need to be re-linked. Delete and re-create your Things to also have a simplified Thing Type ID in your Thing IDs.
Warning: MQTT Binding (Home Assistant): All scene components on a device are now exposed as a single String channel, with the scene name or object ID as its value. Existing Items and rules will need to be re-worked.
Warning: MQTT Binding (Home Assistant): Devices that use custom payloads or states now have that abstracted, so users should only use the default payloads. Rules and UIs may need to be updated for some devices.
Warning: Semantic Tags: Some Point tags reclassified as Properties
Replacing userdata system files with newer versions...
Clearing cache...
Starting JSON database update...
[main] INFO org.openhab.core.tools.UpgradeTool - Already executed 'itemCopyUnitToMetadata' on 2025-05-21T09:39:32.270491400Z[Etc/UTC]. Use '--force' to execute it again.
[main] INFO org.openhab.core.tools.UpgradeTool - Already executed 'linkUpgradeJSProfile' on 2025-05-21T09:39:32.331666606Z[Etc/UTC]. Use '--force' to execute it again.
[main] INFO org.openhab.core.tools.UpgradeTool - Already executed 'linkUpgradeScriptProfile' on 2025-05-21T09:39:32.437929836Z[Etc/UTC]. Use '--force' to execute it again.
[main] INFO org.openhab.core.tools.UpgradeTool - Already executed 'yamlTagsListToMap' on 2025-05-21T09:39:32.634304443Z[Etc/UTC]. Use '--force' to execute it again.
JSON database updated successfully.
SUCCESS: openHAB updated from 5.0.0-SNAPSHOT to 5.0.0-SNAPSHOT
/entrypoint: line 119: exec: gosu: not found
Starting with openhab user id: 9001 and group id: 9001
/entrypoint: line 119: exec: gosu: not found
Starting with openhab user id: 9001 and group id: 9001
/entrypoint: line 119: exec: gosu: not found
Starting with openhab user id: 9001 and group id: 9001
/entrypoint: line 119: exec: gosu: not found
Starting with openhab user id: 9001 and group id: 9001
/entrypoint: line 119: exec: gosu: not found
Starting with openhab user id: 9001 and group id: 9001
/entrypoint: line 119: exec: gosu: not found
Starting with openhab user id: 9001 and group id: 9001
/entrypoint: line 119: exec: gosu: not found
Starting with openhab user id: 9001 and group id: 9001
/entrypoint: line 119: exec: gosu: not found
same here
I replaced gosu with su-exec in Replace gosu with su-exec in Debian images by wborn · Pull Request #466 · openhab/openhab-docker · GitHub . Maybe you can update the command/entrypoint in your files/UI somewhere?
1 Like
Just to make the developers aware of an issue Iâm seeing with at least the two most recent 0H-5.0-snapshots(#4723,#4725) and Remote openHAB Binding. Under OH 4.3.5 I am able to create a Remote openHAB Linked Thing from my Primary OH 4.3.5 server to my Remote OH 3.4.4 server and it is seen as ONLINE on the OH 4.3.5 server. Now using OH 5.0-snapshot as my Primary server, that Linked Thing shows âError.Commâ and attempting to create a new Linked Thing for any Remote Thing gives the same error. Essentially Thing creation using Remote openHAB is broken. This may have occurred in prior snapshots, but I never observed this issue prior to now. Remote openHAB Linked Channel Items are continuing to work well and new Linked Channel Items can be added without issue. I believe @Lolodomo had the lead for the Remote openhab Binding, but Iâm not sure that is still the case.
Please provide logs, I guess you will find something that can help.
And please show the full status displayed by Main UI, you certainly have more info than just âError Commâ. Do a screen capture.
@Lolodomo thanks for looking into this. I have attached a Trace/Debug Log for when I was attempting to bring the Remote Thing ONLINE by toggling the Enable/Disable and Save. I am also including a couple of screen shots of the Thing specifications. I hope this helps, but if you need more/different information please let me know.
Remote openHAB Log.txt (6.4 KB)
Are you sure to have setup properly the token parameter to access things from your remote server ?
Compare the definition of your remote openHAB main thing in OH4 abd OH5.
@Lolodomo All of my Remote Linked Items work fine, it is only the Remote Things that are OFFLINE (ERROR.COMM). I am running OH 5 in a docker just as I do OH 4 and OH 3. All running on the same server. My OH 5 is just an update of my OH 4 container so everything should have survived I believe.
The REST API to get remote things requires a proper token to be set.
So just check that you setup properly this token on your bridge thing in your OH5 server.
Just checked and they are the same;
OH 4 Token
oh.br0.QigLKomjthuG7kwF20YRUzrvlo4fUWFL2Yl1GysklrSb7Ck9wsl512xupNnOznViwVkh0OFyZsRFeZTA
OH 5 Token
oh.br0.QigLKomjthuG7kwF20YRUzrvlo4fUWFL2Yl1GysklrSb7Ck9wsl512xupNnOznViwVkh0OFyZsRFeZTA
I see no recent changes that could impact the used REST API.
Please try OH 5 milestone 3. If not working, try previous milestones.
If milestone 3 is working please try to identify in which snapshot it started to fail.
Of course you run Java 21 JVM 64 bit for OH 5?
Unfortunately the binding is not logging the cause of the exception. So we donât know why the REST API call fails in your case.
@Lolodomo just to followup I am running dockers on a 12 core 24 Virtual CPU Server 64 bit processors and 32 GB ram. I am pulling the containers from docker hub, so yes the containers have Java 21 and everything else in the installation is working the same as OH 4.3.5.
This morning I did as you suggested and tested OH 5 M3, but unfortunately it is also giving the same OFFLINE, ERROR.COMM for the Remote openHAB Thing. I also tried another approach to insure it was nothing related to the fact that I was upgrading from OH 4.3.5. Instead of performing a docker update. I created a clean OH 5 - snapshot install with no bindings or other config changes. Just plain vanilla install. I then added only the Remote openHAB binding and no other bindings. I then added the remote server and the Remote openHAB server went ONLINE. I then added a Remote openHAB Thing but unfortunately I got the same OFFLINE ERROR.COMM. Clicking th advanced box I saw that the âAuthenticate Anywayâ button was OFF. Enabling this feature brought the Remote openHAB Thing ONLINE, so at least now I know where to focus my attention.
SOLVED: For whatever reason, the Authenticate Anyway" button was OFF in my OH 5 upgrade from OH 4.3.5. I donât remember turning it OFF but nonetheless that was the problem.
Thank you for help. Very much appreciated.
10 posts were merged into an existing topic: openHAB 5.1 SNAPSHOT Discussion