Just for reference, I’m seeing updates with just ON/OFF presses for the DZMX1. At first I thought something was wrong, but then realized HAIL must have been removed from the logging.
@chris, did you figure out what is wrong with the current version of the binding and the DZMX1 and DZS15?
Is this the issue with the initialisation? If so, then no, I don’t know. I don’t see why it’s only these devices, and I can’t currently see why ESH isn’t providing the information. I can’t find any problem in the binding - it provides the information for all devices other than the controller.
I need to spend some more time on it, but at the moment I don’t have the time so it might be next week unfortunately.
Hm, ok. I’ll try to remove dimmer from controller and add it back. If it works for you it should work for me to, I guess.
OK. There were a blizzard of posts about it. In case some got past you… 2.4.0.201807152304 works, but anything since has the initialization problem. If it’s an ESH issue, then it was driven by some change in the binding since that build.
Maybe - I don’t know yet and I don’t like to make assumptions.
Maybe there is al issue in ESH as well as the change in the binding. Probably around this time I changed the thing type in the discovery code, but that doesn’t change the fact that the config provider should provide the configuration for ALL ZWave devices and I can’t really see how this can not be the case.
I should add - please feel free to review the code. It doesn’t hurt to have another set of eyes -:
if (!"thing".equals(uri.getScheme()) && !"thing-type".equals(uri.getScheme())) {
return null;
}
ThingTypeUID thingTypeUID = new ThingTypeUID(uri.getSchemeSpecificPart());
// Is this a zwave thing?
if (!thingTypeUID.getBindingId().equals(ZWaveBindingConstants.BINDING_ID)) {
return null;
}
List<ConfigDescriptionParameter> parameters = new ArrayList<ConfigDescriptionParameter>();
if ("thing-type".equals(uri.getScheme())) {
if (uri.getSchemeSpecificPart().equals(ZWaveBindingConstants.CONTROLLER_SERIAL.toString())) {
return null;
}
parameters.add(
ConfigDescriptionParameterBuilder.create(ZWaveBindingConstants.CONFIGURATION_NODEID, Type.INTEGER)
.withLabel("Node ID").withMinimum(new BigDecimal("1")).withMaximum(new BigDecimal("232"))
.withAdvanced(true).withReadOnly(true).withRequired(true)
.withDescription("Sets the node ID<BR/>"
+ "The node ID is assigned by the controller and can not be changed.")
.withGroupName("thingcfg").build());
return new ConfigDescription(uri, parameters, null);
}
This checks that it’s a ZWave binding request, and it’s a thing-type request, and if so, it returns the parameter node_id. I don’t see any way that this differentiates between specific devices - only ZWave thing types in general.
I’m happy to be shown otherwise though.
We also should think about whether there’s anything unique about these two devices. The only thing I see in common is that they have no config parameters and no association groups.
Can anyone see anything else these have in common, and that’s also uncommon among other devices?
I don’t know if this information useful or no but just in case :
zwave_class_basic BASIC_TYPE_ROUTING_SLAVE
zwave_class_generic GENERIC_TYPE_SWITCH_MULTILEVEL
zwave_frequent false
zwave_neighbours 1,7,8,9,10,11,12,13,14,15,17,20
modelId DZMX1
zwave_version 0.7
zwave_listening true
manufacturerId 001D
manufacturerRef 1B03:0334
dbReference 196
zwave_deviceid 820
zwave_nodeid 6
zwave_lastheal 2018-07-20T06:08:54Z
vendor Leviton
zwave_routing true
zwave_beaming true
zwave_secure false
zwave_class_specific SPECIFIC_TYPE_SCENE_SWITCH_MULTILEVEL
zwave_manufacturer 29
zwave_devicetype 6915
zwave_class_basic BASIC_TYPE_ROUTING_SLAVE
zwave_class_generic GENERIC_TYPE_SWITCH_MULTILEVEL
zwave_frequent false
zwave_neighbours 1,6,10,12,15,16,17,20
modelId DZ6HD
zwave_version 1.13
zwave_listening true
zwave_plus_devicetype NODE_TYPE_ZWAVEPLUS_NODE
manufacturerId 001D
manufacturerRef 3201:0001
dbReference 556
zwave_deviceid 1
zwave_nodeid 14
zwave_lastheal 2018-07-20T06:08:59Z
vendor Leviton
defaultAssociations 1
zwave_routing true
zwave_plus_roletype ROLE_TYPE_SLAVE_ALWAYS_ON
zwave_beaming true
zwave_secure false
zwave_class_specific SPECIFIC_TYPE_POWER_SWITCH_MULTILEVEL
zwave_manufacturer 29
zwave_devicetype 12801```Are the most recent changes checked in? I’d like to diff the version that works and one of the latest.
Never mind… I needed the right repo.
Just thinking out loud here…
So, I just looked though all my devices. I don’t have any devices that have no config parameters AND no association groups. Could there possibly be an edge case somewhere that’s exposed by this characteristic?
May I ask why in my example DZMX1 doesn’t have association groups, but DZ6HD has ?
No - but there are no changes in this code that you have referenced, other than the fact that I added some logging that you all said did not show up.
Anyway…
I think I know what the problem is, and I think it’s an issue in ESH. I don’t think ESH is using the ZWaveConfigProvider, or at least it’s not using it for normalisation on startup. Clearly it is used later since otherwise there would be no configuration provided for “internal” config.
The reason it worked before is the zwave:device thing that was previously used has the node_id config defined in the XML, so it doesn’t need the ZWaveConfigProvider for this configuration.
So, my take on it is the change in the binding seems to have exposed a bug in ESH. My guess is that possibly the normalisation that is done on startup is done before the ZWaveConfigProvider is registered.
I don’t really have a lot of time to look into this right now. I will see if I can quickly find where the normalisation is done in ESH, otherwise I’ll just have to raise an issue.
I also think that this explains another problem that has been reported a while ago by someone using text configuration of things (I can’t find the reference right now) - it was the same issue that node_id was the wrong format if I remember correctly. Given that text definition of things bypasses the zwave:device configuration, this would seem to explain that problem as well…
edit: I think it was this -:
I logged this issue a while back. Not sure if related. The title says Boolean, but I think it applies to all types.
Yes, but why is it happening with just these two device types?
I can’t believe out of 800 devices, there’s just these 2 - I’m not sure what they have in common - maybe it’s as you said, and it’s because there’s no configuration… I’m not sure without finding the code in ESH to see what it does on binding/thing initialisation.
Either way, I’m pretty sure what I wrote above is the basic cause - some of the exact detail of why it’s happening I don’t know without seeing the code…
From a quick read, it looks like it could be the same problem.
I’m going to update the database exporter to add a static definition of the node_id configuration. Hopefully this will get things working again. I suspect that this may not be the only problem that this issue is causing though as the ZWaveConfigProvider is providing a lot of other configuration than just this.
Logs are in a ticket on your site,
Thanks. I’m not sure it helps actually. I can’t tell if this is cause or effect - ie there’s no node ID, but we already know that - that’s the problem.
I have updated the binding and added another log entry which may help. Can you see if you can grab a log with this version?
Thanks.
Sent. Everything looked fine until I deleted/rediscovered.
@lolodomo I don’t think so. I’m successfully running several ST814’s in my network using a Gen 5 stick. But, I’m still running the binding from the master branch, not the dev branch.
@mhilbush: thanks for the advice. I was finally able to get my ST814 ONLINE.
As the temperature channel was not updating, I updated the configuration using Paper UI keeping everything by default except setting “openHAB controller” for association groups / reports. It made no change but the next day I discovered that the temperature was updated a little before 10pm. After a next day I can confirm that the temperature is updated only once per day before 10pm.
Is there one setting I should adjust to get an update as soon as the sensor detects a change of temperature ?
In Paper UI, I see the following settings that could be important (I did not set them):
6 - Auto report time
7 - Auto report temperature
8 - Auto report humidity
Edit: I set the parameter “Auto report time” to 60. Will see whatr will happen.