I’ve run into a rather odd thing that is blocking me from being able to rename a specific ZWave item in the interface. The interesting thing, is that this happened before on a previous system as well - but long story short I had to re-setup everything on a new system. So I had fully scrapped the OH install and fully reset the ZWave stick. So I will provide some evidence of the same issue in a previous incident. Thankfully this time around, it’s only 1 specific item having an issue, whereas before it was a collection of around 8 devices.
So problem is, when using HABmin to view my Things, there is an item in the list showing as Z-Wave Node 31. When viewing its properties, I see the Label is Z-Wave Node 31. If I attempt to alter this Label, I get a confirmation in green at the top of the screen “Thing saved successfully”. The Thing however does not update, and upon a refresh of the page, it’s name is still Z-Wave Node 31. I made an attempt to do this with PaperUI, gives me, Thing saved, then, Error 500: Internal Server Error. I’ve attempted turning on Debug logs for ZWave and don’t see anything. I’ve tried seeing any of the OH messages, but I don’t see anything. I finally attempted using the API and I get something somewhat useful (I think), but I’m not sure if I could simply be making an error in my attempt to update this field with the API. I saw the similar 500 message, so I was hopeful.
{
"error": {
"message": "java.lang.IllegalStateException: Expected BEGIN_OBJECT but was STRING at line 1 column 1 path $",
"http-code": 500,
"exception": {
"class": "com.google.gson.JsonSyntaxException",
"message": "java.lang.IllegalStateException: Expected BEGIN_OBJECT but was STRING at line 1 column 1 path $",
"localized-message": "java.lang.IllegalStateException: Expected BEGIN_OBJECT but was STRING at line 1 column 1 path $",
"cause": "java.lang.IllegalStateException"
}
And finally … I had this issue before and what made me think it might be ZWave related @chris, is that the devices last time that had this issue, were a SPECIFIC class of devices only, but EVERY one of my devices of this class type, were stuck with this same issue:
You may have found a bug… (not sure if it’s a jsonDB storage service related issue (most likely), or Z-Wave Binding issue or a UI issue or it belongs in another area of OH2).
Did you try to rename the label manually in your /var/lib/openhab2/jsondb/org.eclipse.smarthome.core.thing.Thing.json?
I did not as I’m not aware of how to do so. Being that my enviro is pretty clean this time and without quirks, I’m kind of not wanting to manually do things that might break something. But if there is an easy tutorial with a low threshold of breaking it, I may try.
Do I understand correctly that you sent the “label”: “Garage Door” in the REST interface and got the error that shown below? If so, this is probably correct since it’s not sent as a Json string - you would need to wrap it as a json object I think (so add {}).
@chris FTW!!! Correctly closing those in braces seems to have produced a more meaningful result. The downside, I’m guessing it may have something to do even more with the ZWave binding!
The resulting output is below. Seems It’s giving me a “duplicate channels” message. I’m assuming somewhere in the linkage, this means the “thing” definition has maybe a duplicate line? And do to this it’s error’ing out before it can finish the rename? Sort of a chicken before the egg, and this case the chicken is a duplicate channel? This lines up similarly with something I had seen on the switch in question in the earlier issue - it had a duplicate Scene channel created for it, which could explain why those had the issue.
Looking into HABmin interface, I can also confirm (I thought this was weird) - there was originally only maybe 2/3 channels for the Linear device before. This time when I paired, it came up with 17 channels. Below is a screenshot outlining multiples of more than just 1 channel, one of which is the “alarm_system” channel noted in the error message from the API.
@chris - is this an erroneous update that has been made to the DB listing for the this device? (Linear NGD00Z-4 Garage controller)
Yes, I’m aware that there are some duplicate channels on some devices. I don’t plan to resolve this right now - it will require a major change to the database, and I also plan to change the channel naming in the binding to support dynamic channels which is now partly written. So, sorry, but for now we just have to work with it on the one or two devices that this impacts.
Unfortunately the garage door opener had a lot of channels added recently and probably most of them aren’t even supported .
Ok, well at least that helps confirm the issue. I hate when I just don’t know why something isn’t working as expected.
I wonder if @Dim idea will work. If I can take the app offline (shutdown service) and carefully inject the correct name, perhaps it will take it and not cause me an issue. I’ll def want to back it up first though in case it blows up in my face. The thing I hate is when trying to fix something and we get to a point where the inevitable suggestion is: Clear it and start fresh … again.
Is there any “documentation” dare I ask for doing so? I know it’s not the preferred way for people to go in and manually massage the data. But I’d feel better if someone was able to help guide me, preferably with some validated documentation. I’m ok digging into code and such, but I hate DB’s, and I’m pretty sure they hate me.
Yes, there is a section on the jsondb in the docs. It doesn’t go into the actual data in the file since this isn’t really relevant for the database (it is just storing the data it is given). However it will be pretty obvious what you need to change given it is just the label.
Weren’t any examples or info on WHAT to modify or WHERE
Started looking for various things and stumbled upon this - which referenced the initial change to the jsonDB usage
Come to find out this isn’t a big scary DB that needs a special app or connector to interface, it’s basically a flat file DB
So I found the specified location /var/lib/openhab2/jsondb/ - which may vary by platform I believe
cd /var/lib/openhab2/jsondb/ followed by an ls -la to see our contents
finding the file org.eclipse.smarthome.core.thing.Thing.json
printed out contents looking for the culprit cat org.eclipse.smarthome.core.thing.Thing.json | grep Z-Wave and found our offending line as expected
Made a quick backup sudo cp org.eclipse.smarthome.core.thing.Thing.json ~/
stopped OH sudo systemctl stop openhab2.service
a quick sudo nano org.eclipse.smarthome.core.thing.Thing.json to edit the file
CTRL+W to find “Z-Wave”
Made the edit, and a quick CTRL+X to exit and accept saving changes to the file
restart OH sudo systemctl start openhab2.service
After the restart, navigated to the HABmin interface, and was pleasantly delighted to see … Garage Door listed in my Things list instead of annoying Z-Wave Node 31.
Thanks @Dim and @chris. Glad I was able to get this pesky thing fixed. And glad I didn’t have to do it for the larger group of devices from before. Would have been a lot more finding and replacing. Now I just need to get back on the front door lock functioning again and I’ll be in solid shape. Thanks for the great work as always on the ZWave binding Chris!
As I said above, the json database store “stuff” - it doesn’t care about “what” it stores, so when this was written it didn’t go into the detail of editing things, or items or any other “stuff” that could be stored in it because it can store anything.
Of course, anyone can improve the documentation, although I’m not sure that putting additional information in the json database area is the right thing as I think it should be kept data agnostic, but maybe you could add an advanced configuration document ;).
Touche, you did indeed! I didn’t have a clue where to start and really just HOW to get integrated or working with it. I think that was the misnomer for me (I work in IT world, DB = tables, queries, etc). Once I found where it was and saw examples of people just outputting the contents I instantly warmed up as its just like digging through some code, understanding, copying, and mimicking.
I would agree though the documentation wouldn’t do justice by having that type of specific info, but I figured I’d leave the detail I did here in case someone does hit something like this.
after deleting and reseting the aeon multisensor i found several new nodes there and first it was not possible to delete them. Than i got rid of them but than the again paired sensor had the node id 7… as second device… so i tried to change the like mentioned above… its working but i still find this in the logs:
NODE 7: Command received zwave:device:b048abd2:node2:alarm_burglar → ON
so how and where to change also this first statement that there also appears NODE 2 ?
And: now openhab is showing me anower discovered device: “Z-Wave Node 7: ZW100 MultiSensor 6”.
So still missing some renaming in configs…
any idea?
Oliver
Ok, solved that way:
zwave serial controler hardware resetet via habmin
openhab2 service stopped
in all files in /var/lib/openhab2/jsondb/ all information regarding that node2 and node7 (in case you have mor devices you have to delete all zwave node’s exept the node1, the controler).
than openhab2 service restartet and all zwave device repaired - in my case only the multisensor…
now also all working included motion detection… strange why not from the beginning…
any further hints or corrections to that way are welcome!
now waiting for the raspbee integration to be able to test ikea led controling via that device on motion actions…
Anyway, this device seems to have to instances of the scene_number channel but with different associated classes. It seems that channels cannot be removed through your database UI, @chris, so how should I go about? Unfortunately, it’s not only the name that cannot be changed, but also Association groups, and I suspect that it is related.
I managed to get renaming to work by manually removing one of the duplicated channels from the Thing XML. Changing Association Groups does still not work, so I guess there’s another source for this error.
.
