I moved your conversation to your own thread as it isn’t about a general 3.3 issue.
I had a similar error after upgrading to 3.3 stable (from 3.3.M5) and none of my Things got loaded. Turned out there was some issues with channel definitions in jsondb/org.openhab.core.thing.Thing.json, in my case the channel definitions on one Thing referenced the ThingUID of another (previously deleted) Thing. In your case it seems like a channel definition have been duplicated.
I’m not sure how it got corrupted (I might have copied the thing from the API explorer to add another with a different name and then deleted the first at some point), or why it had worked up until now, or for that matter why it would stop all Things from loading. In your case however, I would check the stored definition of the Thing referenced in the error to see if the channel is listed twice.
Please send your thing-database (zipped) to github@klug.nrw. I would like to improve the parsing code (and will fix your database and send it back).
Regarding the other error: Please show the output of
config:list "(service.factorypid=org.apache.felix.fileinstall)"
2 Likes
openhab> config:list “(service.factorypid=org.apache.felix.fileinstall)”
Pid: org.apache.felix.fileinstall.07521984-77b6-42f0-9055-46bd700c4bc8
FactoryPid: org.apache.felix.fileinstall
BundleLocation: ?
Properties:
felix.fileinstall.active.level = 90
felix.fileinstall.dir = C:\openHAB2/addons
felix.fileinstall.filename = file:/C:/openHAB2/userdata/etc/org.apache.felix.fileinstall-deploy.cfg
felix.fileinstall.log.level = 3
felix.fileinstall.poll = 10000
felix.fileinstall.start.level = 80
felix.fileinstall.subdir.mode = skip
felix.fileinstall.tmpdir = C:\openHAB2\userdata/tmp/bundles
service.factoryPid = org.apache.felix.fileinstall
service.pid = org.apache.felix.fileinstall.07521984-77b6-42f0-9055-46bd700c4bc8
Pid: org.apache.felix.fileinstall.9cc86138-f145-41c5-a236-0e372d5fd656
FactoryPid: org.apache.felix.fileinstall
BundleLocation: ?
Properties:
felix.fileinstall.active.level = 90
felix.fileinstall.dir = C:\openHAB3/addons
felix.fileinstall.filename = file:/C:/openHAB3/userdata/etc/org.apache.felix.fileinstall-deploy.cfg
felix.fileinstall.filter = .*.(jar|kar)
felix.fileinstall.log.level = 3
felix.fileinstall.poll = 10000
felix.fileinstall.start.level = 80
felix.fileinstall.subdir.mode = skip
felix.fileinstall.tmpdir = C:\openHAB3\userdata/tmp/bundles
service.factoryPid = org.apache.felix.fileinstall
service.pid = org.apache.felix.fileinstall.9cc86138-f145-41c5-a236-0e372d5fd656
Sent the file to you. Everything has been configured through PaperUI and later MainUI. No text configuration for things.
config:delete org.apache.felix.fileinstall.07521984-77b6-42f0-9055-46bd700c4bc8
And the first error should be gone.
Many thanks. Removed this error.
Look at these two entries in your database:
{
"acceptedItemType": "Number",
"kind": "STATE",
"uid": {
"segments": [
"homematic",
"HM-Sec-Key",
"974dd991",
"OEQ0191425",
"0#RSSI_DEVICE"
],
"uid": "homematic:HM-Sec-Key:974dd991:OEQ0191425:0#RSSI"
},
"channelTypeUID": {
"segments": [
"homematic",
"HM-Sec-Key_0_RSSI"
],
"uid": "homematic:HM-Sec-Key_0_RSSI"
},
"configuration": {
"properties": {
"delay": 0.0,
"receiveDelay": 0.0
}
},
"properties": {},
"defaultTags": []
},
and
{
"acceptedItemType": "Number",
"kind": "STATE",
"uid": {
"segments": [
"homematic",
"HM-Sec-Key",
"974dd991",
"OEQ0191425",
"0#RSSI_DEVICE"
],
"uid": "homematic:HM-Sec-Key:974dd991:OEQ0191425:0#RSSI_DEVICE"
},
"channelTypeUID": {
"segments": [
"homematic",
"HM-Sec-Key_0_RSSI_DEVICE"
],
"uid": "homematic:HM-Sec-Key_0_RSSI_DEVICE"
},
"configuration": {
"properties": {
"delay": 0.0,
"receiveDelay": 0.0
}
},
"properties": {},
"defaultTags": []
},
If you look at the "uid" objects of both channels: both entries have the same "segments" but in the first one the "segments" and the "uid" are different. This is clearly a bug in the old implementation. During migration to the new storage format the "uid" is constructed from the "segments" entry, resulting in a duplicate channel UID after migration.
There are more of these entries and I’ll fix them in your database but I need your help (I have no knowledge about the Homematic binding). What channels are expected (homematic:HM-Sec-Key:974dd991:OEQ0191425:0#RSSI_DEVICE, homematic:HM-Sec-Key:974dd991:OEQ0191425:0#RSSI or both)?
I’ll also create an improvement for the thing provider that prevents the catastrophic failure you experience and just ignores an invalid thing. FTR: Prevent crash on invalid entry in ManagedThingProvider by J-N-K · Pull Request #3053 · openhab/openhab-core · GitHub
12 Likes
Exceptional ! @J-N-K , I’m amazed by the level of help/support you provided to @dk8pn . Bravo and thank you.
9 Likes
@J-N-K where you from? Let me buy you a big cup of coffee 
1 Like
Great analysis, i am impressed. Many thanks so far.
The homematic RSSI channel represents a virtual number for the “signal strenth” of the received 868 MHz RF signal (RSSI = Received Signal Strength Indicator). Basically this is of a 2nd level importance. I compared RSSI and RSSI_DEVICE with other homematic things. Both channels are present there. Either one or both are linked to the same signal strength item.
A very similar other thing has the following channels: “uid”: “homematic:HM-Sec-Key:974dd991:OEQ0191632:0#RSSI_DEVICE” and “uid”: “homematic:HM-Sec-Key:974dd991:OEQ0191632:0#RSSI”.
You mentioned more of these entries. Are all affected things/channels homematic?
Yes. And I believe there is an issue in that binding, since I also found “0#RSSI_DEVICE” channels with different channelTypeUIDs. I have left the system channels, which I believe is probably the newer one. In case that’s wrong please delete the thing and re-create it. The fixed database is in your mail.
Any other issues after you used that database?
6 Likes
Quick feedback:
Gave 3.4.0 snapshot #3020 a chance. Your modified database works out. 189 things are back and also all text file defined rules 
. Many thanks for your great support.
Can only follow up @Lolodomo: this is really exceptional, amazing and impressive. This is the beginning of a new love to openHAB at my side on Win10 
.
7 Likes
That entire binding is an issue… It dynamically tries to build the channels by creating the thing type and then hoping that the channels are populated in time before the thing itself is created. If that isn’t the case you end up with an empty (as in no channels) thing. I wrote a fix for that a while ago that basically just recreates the thing in case it has 0 channels hoping that the thing type is completed at that time which is at least preventing most errors, however apparently it can still happen that the thing type is created partially and then a thing missing some channels is missing. So IMO that binding needs a complete rewrite, or at least the thing-type shouldn’t hold the channels and that should be moved to the thing (especially since the current approach also causes issues with different firmware versions for Homematic devices, so if you have the same device with different firmware versions that offer different channels the binding breaks aswell).
What do you think about to rename the topic to e. g. „Issue with 3.3 and Homematic“?
1 Like
Would be better as the problem has apparently no link with Windows 10.
I had the same issue when upgrading my syno docker 3.3 M6 to 3.3 final.
After updating alle homematic items/things where online but devices not reacting to signals.
Updated to 3.4 snapshot and all devices worked again.
@Flole and others, should someone at least file an issue?
I think that the developer of the Homematic binding should have a look to @J-N-K comments above. My failure was a catastrophic one because i gained zero things due to that binding. Jan can provide the best explanation in order to resolve the binding issues.
This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.