I know, this is the 100th thread about zwave binding.
Here is my Setup:
Openhab 2.2 (on docker)
Addon org.openhab.binding.zwave-2.3.0-SNAPSHOT.jar
Aeon Labs USB Stick G5
TZ67 Wall Plug Dimmer
KFOB-C Remote-Control
Number ZwaveControllerStartFrames "Start Frames" {channel="zwave:serial_zstick:zStickController:serial_sof"}
Number ZwaveControllerFramesAcknowledged "Frames Acknowledged" {channel="zwave:serial_zstick:zStickController:serial_ack"}
Number ZwaveControllerFramesRejected "Frames Rejected" {channel="zwave:serial_zstick:zStickController:serial_nak"}
Number ZwaveControllerFramesCancelled "Frames Cancelled" {channel="zwave:serial_zstick:zStickController:serial_can"}
Number ZwaveControllerOOFBytesReceived "OOF Bytes Received" {channel="zwave:serial_zstick:zStickController:serial_oof"}
Number ZwaveControllerReceivedChecksumErrors "Received Checksum Errors" {channel="zwave:serial_zstick:zStickController:serial_cse"}
Dimmer ZwavePlug01Dimmer "TZ67 Wall Plug Dimmer" {channel="zwave:tkb_tz67_00_000:zStickController:node2:switch_dimmer"}
Number ZwavePoppSceneNumber "Scene Number" {channel="zwave:popp_009204_00_000:zStickController:node3:scene_number"}
Number ZwavePoppBatteryLevel "Batterieladung" {channel="zwave:popp_009204_00_000:zStickController:node3:battery-level"}
Here is the openhab.log logfile:
2018-03-13 14:37:24.255 [INFO ] [el.core.internal.ModelRepositoryImpl] - Validation issues found in configuration model 'zwave.things', using it anyway:
Provide a thing type ID and a thing ID in this format:
<thingTypeId> <thingId>
Provide a thing type ID and a thing ID in this format:
<thingTypeId> <thingId>
2018-03-13 14:37:24.258 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'zwave.things'
2018-03-13 14:37:24.581 [INFO ] [ing.zwave.handler.ZWaveSerialHandler] - Stopped ZWave serial handler
2018-03-13 14:37:24.589 [INFO ] [ing.zwave.handler.ZWaveSerialHandler] - Connecting to serial port '/dev/ttyACM0'
2018-03-13 14:37:24.605 [INFO ] [ing.zwave.handler.ZWaveSerialHandler] - Serial port is initialized
2018-03-13 14:37:24.611 [INFO ] [ve.internal.protocol.ZWaveController] - Starting ZWave controller
2018-03-13 14:37:24.612 [INFO ] [ve.internal.protocol.ZWaveController] - ZWave timeout is set to 5000ms. Soft reset is false.
2018-03-13 14:37:27.737 [ERROR] [serialmessage.SetSucNodeMessageClass] - NODE 0: SetSucNodeID command failed.
2018-03-13 14:37:27.933 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 1: Node found
2018-03-13 14:37:27.934 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 2: Node found
2018-03-13 14:37:27.934 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 3: Node found
2018-03-13 14:37:27.934 [INFO ] [age.SerialApiGetInitDataMessageClass] - ZWave Controller using Controller API
2018-03-13 14:37:27.935 [INFO ] [age.SerialApiGetInitDataMessageClass] - ZWave Controller is Primary Controller
2018-03-13 14:37:27.935 [INFO ] [age.SerialApiGetInitDataMessageClass] - ------------Number of Nodes Found Registered to ZWave Controller------------
2018-03-13 14:37:27.935 [INFO ] [age.SerialApiGetInitDataMessageClass] - # Nodes = 3
2018-03-13 14:37:27.936 [INFO ] [age.SerialApiGetInitDataMessageClass] - ----------------------------------------------------------------------------
Checking the PaperUI.
The Serial Controller is Online
The Plug and the remote Control is UNINITIALIZED - HANDLER_CONFIGURATION_PENDING.
I was working now more then 10h to resolve the Problem, but it seems i can’t find it.
Can anyone help me?
This error means that you have not provided all the configuration that is required to allow the handler to be initialised. There should be a log message saying what config is found and what is required, and form this it hopefully should be clear what is missing.
Thanks Chris for replying. I can’t find whats missing. I added the Logfile as Google Drive file.
I would realy appreciate if you would have a look into it. Maybe you find the missing Configuration.
I suspect it would have been before the log started.
One issue I do see in your configuration is that the zwave_nodeid should have the numbers without the quotes. So zwave_nodeid=2. I’m not sure if this will resolve it as there may be some normalisation done to resolve this, but it’s worth a try.
Nope, no Luck.
Do i need to Provide anything more the just the 2 files zwave.things and zwave.items?
Is any other manual configuration needed?
could the lines here be a Problem? And where to add them?`
2018-03-16 00:18:44.614 [INFO ] [el.core.internal.ModelRepositoryImpl] - Validation issues found in configuration model 'zwave.things', using it anyway:
Provide a thing type ID and a thing ID in this format:
<thingTypeId> <thingId>
Provide a thing type ID and a thing ID in this format:
<thingTypeId> <thingId>
No - unfortunately this is not possible. Manually created things are defined as “unmanaged” within ESH, and this means the UI can’t be used to configure them.
No - this is not possible. The binding doesn’t know if you have done this, so the only thing we can do is to configure absolutely every parameter, and this would cause thousands of additional requests on startup. This has been discussed elsewhere (but not sure where right now).
A device will keep its configuration until excluded or reset, so you can temporarily remove the manual Thing file, setup a managed Thing, configure the parameter, delete the managed Thing, then add the manual Thing file back. Not easy, but should work to configure a parameter! Another option is to use another software to configure the devices, link Zensys Tools.
It would be an interesting feature to add a StringType channel for the controller that would send raw messages.
There are lots of “interesting” things that could be done, but then they need to be supported, and I think adding hacks like this is bypassing the real issues -:
ESH doesn’t support configuration of devices (this is being addressed, but it has been on the todo list for a few years - some work was done 4 or 5 months ago, but it seems to have stopped again as far as I can see).
ESH doesn’t support changing configuration in rules
ESH won’t allow unmanaged things to be configured - even temporarily
Yes, we can bypass these issues by adding features into the binding, but I think adding hacks into the binding to work around system limitations is not nice, and every binding ends up implementing the same functionality in different ways.
I fully agree , except for calling it a hack. I can think of several other useful purposes for such a channel, in addition to being a workaround to this problem. But I can also understand your concerns about supporting it!