Configure Z-Wave device through Rest-API

Hi,

I have a battery powered Z-Wave device which always shows as “Unknown Device”.
Once I configure the Thing manually I can link the channels and everything works as expected,
however I am not able to change any configuration parameters so this is not very useful.

@chris:
Is there any way to configure the thing through the rest api like I would do in the Thing file?
This way it would still be possible to change parameters.

Is the device defined in our Z-Wave database? If not that is the issue. OpenHAB should have made an xml file in the zwave folder under userdata. Posting that here could be helpful.

Manually creating Things files can be error prone and is discouraged. If I were going to do that anyway I would first discover the device and add the Thing and then use the API to see the preferred Thing configuration.

No - not if the device is not known. The binding requires information about the configuration before it can send configuration updates.

You should focus on why it’s unknown.

Just to clarify again so there is no misunderstanding:
the thing is in the binding database and if I configure the thing with a .thing file it works.

My question is if I can make the thing known to the z-wave binding.
E.g. add the “unknown device” and then do some rest magic so that the thing changes from “unknown device” to “device in database”.

It’s far away (not in direct range of controller) and has long sleep times which prevents the automatic initialization. If I dismount it, place it next to the controller and wake it couple of times by hand it works. It is however placed very hidden so I am looking for any solution which allows me to keep it in place.

If you are using things files, then there is simply no way at all to configure the device. This is blocked by openhab core.

Yes - that’s clear to me and that’s not what I am trying to do.

If I configure a device with a .thing file the binding somehow gets told what kind of device it is and what kind of channels are available. This happens through the device database. However it is not possible to configure the device since this is blocked by the openhab core.

So I am looking for a way to tell the binding without the use of a thing file (e.g. through the rest api) what kind of device I am using. If you want to put it that way I want to “set” the device type, but not hard coded through a thing file because this will block configuration.

The target functionality is configuration like a .thing file but with enabled editing of device properties.

I hope I have rephrased my idea so you understand what I am trying to do.

Sorry - I’m confused. You are not using a thing file? You are therefore using the UI? If so, what is the problem?

If you are using a thing file, then you define the thing type in the thing file. The channels then come from the database.

If you are using the UI, then the binding will select the thing type. The channels then come from the database.

You can’t define channels independent of the thing type.

Just to come back to this point - if the controller can’t communicate with the device to discover it, then it won’t be able to communicate with the device to do anything else.

If the device is sleeping, then wake it up so it can be discovered. This is only required once - once the discovery is complete, it doesn’t need to happen again. If the device has long sleep times, then you also won’t be able to configure it for this same duration (or longer if the communication link is poor).

If the device can’t really communicate as it’s far away, then consider making your network more robust by adding devices in between to sure up the mesh network.

1 Like

When I use the UI and automatic discovery the device only shows “unknown device”. I do not receive values because initialization is not completed
When I use .thing files I do receive values from sensor, but can’t change z-wave parameters of the device because it is blocked by openhab core.

This is the step I want to do through the rest api.
I realize that it might take a couple of days to get the config values through, but at least I have a chance to set them.

That is not the way the binding is currently designed. The Device does not contain all the channel information so the binding gets that information from its private local copy of the device database.

The only way I see for you to do things as you wish would be to fork the zwave binding and customize it to your situation. Since it is open source, you are free to to that.

Yes, I am aware of that.

All I am trying to to is tell the binding which device I am using.

@chris:
The Thing has the type UID configured as a property. (e.g. "thingTypeUID": "zwave:philio_pst02a_00_000",). Is it sufficient to set this thingTypeUID properly and the binding will take care of the rest?

If you need something while waiting for a build, this thread should help. It does not use the REST API though.

Sorry, this is still not what I am trying to do. The device is in the database, otherwise I wouldn’t be able to configure it manually.
I want to make the transition from “Unknown Device” to “zwave:philio_pst02a_00_000” through the Rest API because the binding does not do this automatically.

I understand what you are trying to do, I’m just not sure if you can do it. If the device is created by the binding through the discovery, then it is created with a generic thing type. It is then updated to the specific thing type later - this update is quite specific as it updates all the channels etc. I’m not sure if you just change the thing type manually that it will really work.

But if the device is waking up, then it will also initialise. If it only wakes up every couple of days then it will take some time to configure, but it should work still (and you seem happy with this for configuration, so it’s the same issue).

Personally, I would just manually wake up the device to allow the binding to initialise it. Even if you force the thing type, the binding will ALWAYS need to initialise the device, and if this isn’t happening, then it will still not work.