When I try to Heal:
PUT http://maggie.robotics.net:8088/rest/things/zwave:device:controller:node16/config 409 (Conflict)
When I try to Exclude:
PUT http://maggie.robotics.net:8088/rest/things/zwave:serial_zstick:controller/config 409 (Conflict)
So that’s the error coming back, but what’s it sending? I’m wondering if there’s some sort of security enabled?
The other thing to check is the general OH logfile (I’m not sure if that’s the same as where you have the ZWave stuff going). Sometimes if it doesn’t allow something to happen in the REST interface, it might log something.
openhab.log:
2017-04-08 15:09:40.026 [INFO ] [ome.io.rest.core.thing.ThingResource] - Received HTTP PUT request for update configuration at ‘things/zwave:device:controller:node16/config’ for an unmanaged thing ‘zwave:device:controller:node16’.
2017-04-08 15:10:32.339 [INFO ] [ome.io.rest.core.thing.ThingResource] - Received HTTP PUT request for update configuration at ‘things/zwave:serial_zstick:controller/config’ for an unmanaged thing ‘zwave:serial_zstick:controller’.
Ah… so it looks like this is because I have configured textual .things.
Is there a way to do it manually other then the UI?
No - that’s not implemented, and probably isn’t something I would want to implement as it’s potentially dangerous. I would prefer to keep this a manual task only.
I thought though that the framework had been changed to allow configuration to be sent to things that are configured through text files - have you tried a recent runtime or are you using the release version? @kai - can you confirm this (or not)?
It’s been several weeks, let me upgrade and give it another shot. Find anything in the logs I sent?
No - not really. I’m just trying to finish something off and will then try and configure things here to see if I can reproduce the problem.
My guess is no, I just tried with #858, the last good build on cloudbees from March 31st.
2017-04-09 13:09:24.344 [INFO ] [ome.io.rest.core.thing.ThingResource] - Received HTTP PUT request for update configuration at ‘things/zwave:serial_zstick:controller/config’ for an unmanaged thing ‘zwave:serial_zstick:controller’.
It looks like this should be implemented - if it doesn’t work then it could be a bug in ESH.
To quote from the issue tracker →
that means you can now update the configuration of a thing that is defined in a config file ?
Yes, this is exactly what it means.
Thanks, updated the ticket since it does not look like it is working.
that means you can now update the configuration of a thing that is defined in a config file ?
Yes, this is exactly what it means.
No, as per Simon’s comment on the issue, this feature is only meant for updates through the bindings themselves (which are done on every startup again), but not for user-driven changes that would be lost after a restart.
Hmmm - that seems like bad news. Why was this restriction added?
The problem I have is that we don’t want to have to send hundreds of configuration values to a device each time the binding starts. Some configuration values (in Z-Wave devices at least) perform actions - if we send them every time the binding starts, then the action gets implemented (eg resetting a counter). Without the ability to manually send configuration to a thing, even if the data is lost, we can’t control devices…
Ok, so I know what your next comment will be ;). This is related to configuring devices, and not the thing handler. Ok, this is true, however as there is no alternative at this time, we have to use this system to configure devices.
However, I would suggest that even for a thing handler, allowing a user to configure it for the duration of the session is still useful as it means they can make temporary changes, and then write them into the text files once they are happy with their configuration…
Or maybe I’m missing something ;).
I agree that it would be really helpful to enable temporary update of thing configuration. That was my initial understanding of what will offer the PR and that was a great news.
Then what would be the correct way of setting the thermostat form C to Fahrenheit? I have textual zwave config working with the only remaining issue being that my stats are in C rather then F.
This is a different issue - for this you need to be able to define definitions for channel configuration and I’m not sure where this is defined in the text files.
So I understand that technically this is a channel config, but do people really want to have thermostat_setpont_heating to F and set thermostat_setpoint_cooling to C? Why not for now just use config_scale setting on the Thing to set all channels?
Maybe this could be done - it’s more complicated and I’m not sure how to do it without it being a hack since it’s the command classes that have the configuration (same as in OH1). But yes, we could hack something together and it would solve the problem that you have right now.
However, we have other channel level configuration in ZWave that does need to be at channel level (inversion of certain data for example), and people are using these today as well (although not with text files I assume). Ok, yes, I guess I could hack something together to solve those problems as well, but I’d tend to argue that the system is meant to do this and it doesn’t, so we should try and have a solution.
Got it.
I propose to remove this limitation -:
Justification/use case for this: Even if a thing is not managed - ie it’s configured through text files - the user may want to update configuration for the duration of the session. Currently this is impossible - configuration of the thing must be undertaken through the text file, which means the thing is reinitialised (removed, and re-added).