When I hit Exclude under Tools for the Z-Wave Controller thing I get:
“Error sending action” in the UI, but nothing shows up in the zwave logs.
Actaully, when I got to any zwave thing and say try to “Heal the device” I get the same “Error sending action” in the UI.
Well, I guess nothing will show up in the ZWave log if there’s an error in the system as the ZWave binding won’t ever get notified.
It’s definitely working here though (I’m using the development version though), so I’m not sure what’s up. Are you really using the release version? If you’ve been swapping between the release and development version, then this might cause problems that could result in this.
Where can I find the development .jar for Habmin 2?
I am using 2.1.0.SNAPSHOT that was downloaded via paper.
There isn’t one - it’s just the normal snapshot.
Ok - I’m a bit confused as in the title you say you’re running 2.0.0 so maybe that’s some other part of the system.
To be clear - are you talking about HABmin, or ZWave when you say 2.1.0-Snapshot? I thought you were running the develpment version of ZWave?
Sorry, I understand why you would be confused! I am running 2.1.0.SNAPSHOT of openHAB and Habmin with the org.openhab.binding.zwave-2.1.0-SNAPSHOT.jar dated 201703151108. All of this is the same system and versions I send the logs to you last night.
Ok - I’ll take a look. I tested this on my main system a few minutes back and it worked fine.
One thing to take a look at - can you open the browser debugger- if you have Chrome - it’s here (Developer Tools) -:
Then send the action, and take a look at what errors are reported on the CONSOLE tab, and also look in the NETWORK tab - you should be able to find the transaction, click on this and view the data that HABmin sent - it would be good if you can copy that here.
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.
