As pointed out by @rlkoshak: That are your current options. I’ll check how we can improve the clean-up.
Edit: I did check that you can use the REST API to remove these items. So the API Explorer is the way to go.
Tried to install MQTT binding on 3.3M6 but this fails.
Other bindings working fine (shelly,tplink,…)
2022-06-14 17:07:37.765 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing 'openhab-binding-mqtt': Error:
Error downloading mvn:org.openhab.addons.bundles/org.openhab.binding.mqtt.homie/3.3.0.M6
Error downloading mvn:org.openhab.addons.bundles/org.openhab.binding.mqtt.generic/3.3.0.M6
Error downloading mvn:org.openhab.addons.bundles/org.openhab.binding.mqtt.homeassistant/3.3.0.M6
Error downloading mvn:org.openhab.addons.bundles/org.openhab.binding.mqtt/3.3.0.M6
Error downloading mvn:org.openhab.addons.bundles/org.openhab.binding.mqtt.espmilighthub/3.3.0.M6
My fibaro Roller shutter 3 stopped working after updating to M8.
It says
`HANDLER_CONFIGURATION_PENDING
{config_duration=Der Wert darf nicht größer als 254 sein.}`
(the value is not allowed to be over 254)
But I have no idea which value to change.
Any idea, @chris?
I think it will be related to this -:
<parameter name="config_duration" type="integer" min="1" max="254">
<label>Step duration</label>
<description><![CDATA[Sets the dim rate speed<br>Values from 1 to 127 are defined in seconds,
while values from 128 to 254 are defined in minutes.]]></description>
<default>255</default>
<options>
<option value="255">Device Default</option>
<option value="0">Change Instantly</option>
</options>
<limitToOptions>false</limitToOptions>
</parameter>
This is the config parameter that the error relates to, but this definition looks ok to me so I’m not sure what it’s complaining about unless the value is outside the allowable range of less than 0, or greater than 255. Can you check this to see what it’s set to? The default is 255 so this should be ok unless it was changed.
I was not able to find “Step duration” in the UI, also it was not defined in the Code panel of the Thing.
After adding config_duration: 255 to the Code panel it is working again.
I had not touched its config for at least some months and it worked fine until I did the update. Looking at the commits in the zwave-repo I don’t see why anything should break from these.
Note that this is channel configuration - not thing configuration, so you need to look in the channel for this configuration setting.
Hi Chris,
I have the same issue on several Things, e.g. the following
The configuration is as follows:
UID: zwave:device:7175b6a970:node80
label: "Z-Wave Node 080: FGWREU-111 Fibaro Walli Roller Shutter"
thingTypeUID: zwave:fibaro_fgwreu111_00_000
configuration:
config_34_4_0000000F: 0
config_11_1: 6
config_31_4_0000000F: 0
group_1:
- controller
group_3: []
group_2: []
config_153_1: 1
config_152_4: 150
config_154_2: 10
config_155_2: 10
config_150_1: 0
config_151_1: 1
config_12_1: 0
config_32_4_0000000F: 0
config_13_1: 100
config_156_4: 6000
config_35_2: 600
config_157_4: 6000
config_41_1: 0
config_65_2: 10
config_62_2: 3600
config_61_2: 15
config_40_1: 0
config_60_1: 0
config_33_4_0000000F: 0
config_30_4_0000000F: 0
config_24_1: 0
config_25_1: 0
config_66_2: 3600
node_id: 80
bridgeUID: zwave:serial_zstick:7175b6a970
Here is the channel config:
Changing it to 254 put the thing into online again.
I am wondering why this only now appears? Did you only implement that check now?
Does anyone know what the “Step duration” is for?
Cheers
Stefan
The problem relates to the rigorous checking introduced in 3.3M2. Since this is handled by the core, it is not a zwave issue. What needs to change is this in the DB? (edit: Actually I do not know where this needs to be changed) (change 254 to 255)
> <parameter name="config_duration" type="integer" min="1" max="254">
The 254 is being picked up by the checker as max, even though the default is 255. I had a similar problem with a different device where the default was outside the range the checker checked. (if that makes sense?)
Bob
Can you link to the file where this definition is made. In case 255 has a special meaning (and is outside of the defined range 1 to 254 it should be added as <option />. If this is the case and the check fails, it’s a bug in the checker.
I’m afraid I can’t. I don’t have the device and could not find this xml fragment. I just recognized what was going on from an earlier issue (3.3M2) that I fixed with a Z-wave DB edit.
Might have to wait for morning in NZ, unless one of the folks that have the device know.
Sorry
Bob
Had a brainstorm. File location is in the Zwave binding. Still don’t know if 255 has a special meaning, though.
src/main/resources/OH-INF/thing/channels.xml
Is the Ubuntu repo down?
$ sudo apt update
Hit:1 http://ppa.launchpad.net/mythbuntu/31/ubuntu focal InRelease
Hit:2 http://us.archive.ubuntu.com/ubuntu focal InRelease
Get:3 http://us.archive.ubuntu.com/ubuntu focal-updates InRelease [114 kB]
Get:4 http://us.archive.ubuntu.com/ubuntu focal-backports InRelease [108 kB]
Get:5 http://us.archive.ubuntu.com/ubuntu focal-security InRelease [114 kB]
Err:6 https://openhab.jfrog.io/artifactory/openhab-linuxpkg testing InRelease
502 Bad Gateway [IP: 34.139.10.89 443]
Fetched 336 kB in 10s (33.7 kB/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
W: Failed to fetch https://openhab.jfrog.io/artifactory/openhab-linuxpkg/dists/testing/InRelease 502 Bad Gateway [IP: 34.139.10.89 443]
W: Some index files failed to download. They have been ignored, or old ones used instead.
Apparently it was. Seems back up now
I just updated to M7
All of my Bali zwave shades failed to initialize
here a zwave log for one shade
any suggestions?
If there is the “handler” message, it is related to the last 24 hours of posts directly above yours. The quickest thing will be to edit the channel to 254 step duration (edit: based on subsequent posts setting to 254 would fall into the “bad idea” category 
), pending either a validator change or binding change.
Bob
The strange thing though is that I was on M6 already and did not encounter that problem
Agreed, and it is - this is as I posted in my message above -:
The limits are 1 to 254 (ie min/max) but 0 and 255 are options and we’re not limiting to options. So as above, I believe all values from 0 to 255 should be valid.
1 Like
You might not want to use 254 - this will set a dim rate of 254 minutes - 4 1/4 hours 
Additional checks were added in the core, but if I remember correctly this was in the previous milestone a few months back, so I’m not sure why this has just started now. I assume this is a bug in the core, but again, I’m not sure what changed, but this config definition hasn’t changed for 6 years according to GitHub.