@jimtng - thanks for adding the error message. Should I create an issue for the remaining problem that “An Item with this name already exists” is not initially shown?
I use the sonos binding to trigger actions by sonos alarms (turn on the espresso machine when the alarm starts in the morning, turn on lights).
This stopped working with the latest milestone. More precisely, it works after reboot and after a few hours openhab seems to miss sonos events.
The current workaround is to keep only one up IP v4 network interface on your OH server.
Here is the GitHub issue in case you would like to follow my investigations.
https://github.com/openhab/openhab-core/issues/4140
Thanks, I just got around to test your fix, and it works! 
It’s not that in my case. I have one ip interface up (plus the loopback device). I deactivated ipv6 which seemed to have a positive effect as the rules triggered by the sonos alarm worked for one more day before ceasing to work. I’ll try to increase the log level for the Sonos add in next. We’ll see if that provides any useful information.
JUPnP library is only using IP v4 so IP V6 can be enabled or disabled, it makes no difference for the Sonos binding.
By the way, I found yesterday the line in the JUPnP code leading to no events being received when several IP v4 interfaces are up. What is strange is that this line is there since 2015. I temporary fixed the problem for me by commenting this line. Needs to understand why this line was there and propose a clean fix.
We are not yet sure why it was working well until 4.1.1, maybe a timing difference at OH startup.
In case it is a timing problem at OH startup, it is possible that not everyone has the issue.
Thanks for double confirmation that it was definitely the new libraries that have fixed it for you. Please do not discuss it further in this thread, as its role is to track issues and not to discuss them, so open a new thread if you wish.
The newer changes upgrade the influxdb2 library from 4.3 to 7.0 so it is a big jump and is bound to contain some fixes in that alone, also and other libs are also changed. Best guess is that your system needs a compatibility change that is in one of those libraries whilst other users do not. Not going to try and explain or guess further as I do not use the addon.
I have a weird issue. I add via UI a new Thing MQTT generic. Then i add channels items etc. I saw that I made a mistake and I tried to edit it, but I can’t. Code nor via UI. I must delete complete the channel and add a new channel. I get this message via UI if I try to edit via UI:
But I add everything via UI. What’s going on? 
Upgrade to snapshot.
Bug in JUPnP library is hopefully now fixed.
We just need now a release of JUPnP v3.0.1 and OH 4.2 switching from JUPnP 3.0.0 to 3.0.1.
I am confident you can expect the fix to be included in 4.2 milestone 2 (and probably soon in 4.2 snapshots).
This new version will also include the addition of a new JUPnP setting to restrict the network interfaces to the ones you would like JUPnP to use. For example, you could then instruct JUPnP to use only eth0 interface even you have eth0 and wlan0 being up. For that create the file <OH root>/conf/services/jupnp.cfg containing this line:
org.jupnp:interfaces=eth0
The parameter accepts a comma-separated list of network interface names.
Can’t edit and save channels in things.
After upgrading from 4.1.0M3 to 4.2.0M1 i can’t edit and save channels in things.
When truing to configure channel i see lock in upper right corner an it says “Channel of Things defined in a .things file are not editable from this screen”, but i created things from UI, not from “.things” file
Read 3 posts above yours …
Influx ping Fault seems to be gone with snapshot 4021
On 4.2.0.M1 I’m not able to edit the code in things. More specifically, I cannot edit this in the screen:
label: Comando Leds Cave
thingTypeUID: mqtt:topic
configuration:
payloadNotAvailable: offline
payloadAvailable: online
transformationPattern: JSONPATH:$.state
availabilityTopic: anexo/button-cave/availability
bridgeUID: mqtt:broker:aveiro
channels:
- id: LinkQuality
channelTypeUID: mqtt:number
label: Link Quality
configuration:
unit: lqi
min: 0
stateTopic: anexo/button-cave
transformationPattern: REGEX:(.*linkquality.*)∩JSONPATH:$.linkquality
max: 255
- id: action
channelTypeUID: mqtt:string
label: Action
configuration:
stateTopic: anexo/button-cave
transformationPattern: REGEX:(.*action.*)∩JSONPATH:$.action
- id: BatteryPercentage
channelTypeUID: mqtt:number
label: BatteryPercentage
configuration:
unit: "%"
min: 0
stateTopic: anexo/button-cave
transformationPattern: REGEX:(.*battery.*)∩JSONPATH:$.battery
max: 100
- id: voltage
channelTypeUID: mqtt:number
label: Voltage
configuration:
stateTopic: anexo/button-cave
transformationPattern: REGEX:(.*voltage.*)∩JSONPATH:$.voltage
unit: mV
It’s a significant problem for me, I’m used to define mqtt things using copy/paste and this is no longer possible.
Using Firefox 124.0.2 (64-bit)
Edit: Reported in github Thing details: Code tab uneditable · Issue #2523 · openhab/openhab-webui · GitHub
Please try
openhab-cli reset-ownership
from the GNU/Linux shell.
Thanks. Is there another way ? I’m running OH in QNAP/QTS and openhab-cli does not exist.
The fallback code that is being used inside of openhab-cli is
chown -R openhab:openhab "${OPENHAB_HOME:?}" "${OPENHAB_USERDATA:?}" "${OPENHAB_CONF:?}" "${OPENHAB_LOGDIR:?}"
The variables contain the value for different directories to be taken into account.