Markus do you know if your devices are of S3 or S5 or other? It is only written on the module itself where it writes PN like: ZMNHCD1 H1S5P1. Mine is this way, S denotes the module version whereas mine is S5.
Version numbers stamped on the box may of course not directly relate to the version reported by the device. The binding has a lot of difficult reading the box ( 
) so it uses the information that comes from the device.
There’s one other possibility and that is that Qubino are reporting the version in a different place and not in the primary version ID. Can you grab a log of the startup, but delete the XML file for the device first so we get all of the initialisation.
I am using 11 of these modules, so the debug file is a little bit large… What i meant for the printed version is that both the reseller and Qubino confirmed that S5 is the latest module firmware version they have and i got these modules only 3 months ago. Pity that the binding cannot read the label The thing is i never was able to make them work stable with OH2. That’s why i thought OH2 might have get the wrong database item.
Btw i reverted back to OH 2.1.0 stable version and these debug files are from 2.1.0 stable binding. And also Node3, Node6 and Node9 are stuck on STATIC_VALUES. These three nodes are the ones that have optional temperature sensors.
Thanks…
In reality, the database isn’t used for much of the low level communications. It sets the channels, and it sets the parameters, but the low level command class interaction isn’t dependant on the database.
Unfortunately the log starts just after the part I was looking for…
I expect this is fixed in the development version from what I see in this log (although I’m not 100% sure, but I see a lot of timeouts for the AGI class and this won’t happen in the development version).
Actually there are 2 files in the zip, zwave.log.1 is the starting one, zwave.log comes after that. You will find the Version parts in the ZWave.log.1 file.
Ah - so there is… Sorry - I missed that, but will take a look…
Ok, so there’s no more information in the version report than I’m already using -:
Starting from the 86 12 -:
3 is the library type,
4.5 is the ZWave protocol version
1.1 is the firmware version
1.0 is the hardware version
(68 is just the checksum)
Hi @chris, I am still having problem with the 2.1.0-snapshot version with nodes failing. My problem is that as well nodes like the Fibaro Universal sensor fail and this confuses my (complicated) rules. I was trying to go to the dev version 2.2.0-snapshot, but I am using openhabian and I couldn’t find out how to pick the version 2.1.0.201706302351, wget-ing the 2.2.0-snapshot does not work, going to the unstable release is version 0630xxx. Is there a download link I can us to get the JAR ?
Thanks !
As I mentioned on the other thread, the fact that the controller is reporting nodes offline is known and I’ll look at this at some stage. It’s not top of the list though.
The download link for the development version is at the top of the following thread.
Hi @chris, this is the 2.1.0-snapshot which makes my nodes fail too frequently for my system running reliably. Is there a 2.2.0-snapshot version (no security refactoring) with the fixed endpoints, which I could use for the moment ?
The version really isn’t relevant - I thought you were after the development binding…
The standard 2.2 snapshot is available for installation in the normal way if you’re using the snapshot runtime (ie PaperUI or HABmin). Note that if you’re swapping between the versions, you will need to delete all things and reinstall as the versions aren’t compatible.
Yes, I wanted to try the development version, but now I wanted to go back. You said the next build of the snapshot will have the fix for the endpoints ?
Yes, the master version also has this change to the database.
It looks like the builds on the master are not working at the moment so maybe the latest snapshot that’s been built won’t have this included… I’ve just triggered another build to see if it makes it through - let’s see…
Ok, the problems with the MiLight binding are resolved and the build is complete so the snapshot should be up to date…
Hi @chris,
let me reopen this discussion, I have a new issue with the Qubino Flush Shutter (ZMNHCD, v1.1), the problem is with the power reading which is vital for this module to correctly drive venetian blinds. I recently had to exclude and re-include one of my modules (got stuck) and since then this module is no longer reporting the power sensor readings. The binding seems to expose this endpoint and I see it in habmin being associated to my items, everything looks normal. But the power reading is never different from since the re-inclusiong.
I noticed that the XML after re-inclusion looks different from the XML of another such modules. The differences are listed below from a diff:
—> the new one has:
<switchTypePrimary>DOWN_UP</switchTypePrimary>
<switchTypeSecondary>DOWN_UP</switchTypeSecondary>
—> the other module has instead:
> <commandClass>BARRIER_OPERATOR</commandClass>
> <barrierOperatorCommandClass>
> <version>0</version>
> <instances>0</instances>
> <versionSupported>0</versionSupported>
> </barrierOperatorCommandClass>
> </entry>
> <entry>
...
> <meterScale>E_Power_Factor</meterScale>
248a258
> <meterScale>E_Pulses</meterScale>
256a267,276
> <commandClass>SENSOR_BINARY</commandClass>
> <binarySensorCommandClass>
> <version>0</version>
> <instances>0</instances>
> <versionSupported>0</versionSupported>
> <isGetSupported>true</isGetSupported>
> <types/>
> </binarySensorCommandClass>
> </entry>
> <entry>
I don’t understand what is going on and why the XML is not so different. Where are those changes coming from, any hint where I could look ? Was the database edited again ?
Many thanks in advance for your help, cheers, Markus
It’s kind of hard to know what that means without the full files, but it doesn’t look correct. I wouldn’t have thought that the device would use the barrier operator command class. You could try removing to reinitialise the device (in the thing menu in HABmin, select advanced and you should see a reinitialise device menu option). This should re-create the XML - if it still looks like this then we should take a look at the log during the initialisation.
Good guess, after re-init I see in the logfile:
==> /var/log/openhab2/events.log <==
2017-09-15 22:07:09.462 [hingStatusInfoChangedEvent] - ‘zwave:device:f224e042:node77’ changed from ONLINE: Node initialising: SECURITY_REPORT to ONLINE: Node initialising: APP_VERSION
2017-09-15 22:07:09.694 [hingStatusInfoChangedEvent] - ‘zwave:device:f224e042:node77’ changed from ONLINE: Node initialising: APP_VERSION to ONLINE: Node initialising: DISCOVERY_COMPLETE
2017-09-15 22:07:09.702 [hingStatusInfoChangedEvent] - ‘zwave:device:f224e042:node77’ changed from ONLINE: Node initialising: DISCOVERY_COMPLETE to ONLINE: Node initialising: VERSION
2017-09-15 22:07:12.805 [hingStatusInfoChangedEvent] - ‘zwave:device:f224e042:node77’ changed from ONLINE: Node initialising: VERSION to ONLINE: Node initialising: ENDPOINTS
2017-09-15 22:07:13.421 [hingStatusInfoChangedEvent] - ‘zwave:device:f224e042:node77’ changed from ONLINE: Node initialising: ENDPOINTS to ONLINE: Node initialising: UPDATE_DATABASE
2017-09-15 22:07:13.429 [hingStatusInfoChangedEvent] - ‘zwave:device:f224e042:node77’ changed from ONLINE: Node initialising: UPDATE_DATABASE to ONLINE: Node initialising: STATIC_VALUES
2017-09-15 22:07:13.674 [ConfigStatusInfoEvent ] - ConfigStatusInfo [configStatusMessages=[]]
2017-09-15 22:07:13.679 [ThingUpdatedEvent ] - Thing ‘zwave:device:f224e042:node77’ has been updated.
2017-09-15 22:07:16.346 [ThingUpdatedEvent ] - Thing ‘zwave:device:f224e042:node77’ has been updated.
2017-09-15 22:07:16.348 [ConfigStatusInfoEvent ] - ConfigStatusInfo [configStatusMessages=[]]
==> /var/log/openhab2/openhab.log <==
2017-09-15 22:07:26.410 [WARN ] [WaveAssociationGroupInfoCommandClass] - NODE 77: Group Name is too big; maximum is 25 characters 27
==> /var/log/openhab2/openhab.log <==
2017-09-15 22:07:35.722 [WARN ] [WaveAssociationGroupInfoCommandClass] - NODE 77: Group Name is too big; maximum is 25 characters 27
I don’t see this warning for another of the Qubino devices after a re-init of them…
Later there are more log entries…
==> /var/log/openhab2/events.log <==
2017-09-15 22:12:46.326 [hingStatusInfoChangedEvent] - ‘zwave:device:f224e042:node77’ changed from ONLINE: Node initialising: STATIC_VALUES to ONLINE: Node initialising: ASSOCIATIONS
2017-09-15 22:12:46.550 [ConfigStatusInfoEvent ] - ConfigStatusInfo [configStatusMessages=[]]
2017-09-15 22:12:46.553 [ThingUpdatedEvent ] - Thing ‘zwave:device:f224e042:node77’ has been updated.
==> /var/log/openhab2/events.log <==
2017-09-15 22:12:47.674 [ThingUpdatedEvent ] - Thing ‘zwave:device:f224e042:node77’ has been updated.
2017-09-15 22:12:47.675 [ConfigStatusInfoEvent ] - ConfigStatusInfo [configStatusMessages=[]]
2017-09-15 22:12:48.379 [ThingUpdatedEvent ] - Thing ‘zwave:device:f224e042:node77’ has been updated.
2017-09-15 22:12:48.383 [ConfigStatusInfoEvent ] - ConfigStatusInfo [configStatusMessages=[]]
2017-09-15 22:12:48.819 [ConfigStatusInfoEvent ] - ConfigStatusInfo [configStatusMessages=[]]
2017-09-15 22:12:48.819 [ThingUpdatedEvent ] - Thing ‘zwave:device:f224e042:node77’ has been updated.
2017-09-15 22:12:49.348 [ThingUpdatedEvent ] - Thing ‘zwave:device:f224e042:node77’ has been updated.
2017-09-15 22:12:49.349 [ConfigStatusInfoEvent ] - ConfigStatusInfo [configStatusMessages=[]]
2017-09-15 22:12:49.356 [hingStatusInfoChangedEvent] - ‘zwave:device:f224e042:node77’ changed from ONLINE: Node initialising: ASSOCIATIONS to ONLINE: Node initialising: SET_WAKEUP
2017-09-15 22:12:49.359 [hingStatusInfoChangedEvent] - ‘zwave:device:f224e042:node77’ changed from ONLINE: Node initialising: SET_WAKEUP to ONLINE: Node initialising: SET_ASSOCIATION
2017-09-15 22:12:49.378 [hingStatusInfoChangedEvent] - ‘zwave:device:f224e042:node77’ changed from ONLINE: Node initialising: SET_ASSOCIATION to ONLINE: Node initialising: DELETE_SUC_ROUTES
2017-09-15 22:12:49.382 [hingStatusInfoChangedEvent] - ‘zwave:device:f224e042:node77’ changed from ONLINE: Node initialising: DELETE_SUC_ROUTES to ONLINE: Node initialising: SUC_ROUTE
2017-09-15 22:12:49.386 [hingStatusInfoChangedEvent] - ‘zwave:device:f224e042:node77’ changed from ONLINE: Node initialising: SUC_ROUTE to ONLINE: Node initialising: STATIC_END
2017-09-15 22:12:49.389 [hingStatusInfoChangedEvent] - ‘zwave:device:f224e042:node77’ changed from ONLINE: Node initialising: STATIC_END to ONLINE: Node initialising: SESSION_START
2017-09-15 22:12:49.398 [hingStatusInfoChangedEvent] - ‘zwave:device:f224e042:node77’ changed from ONLINE: Node initialising: SESSION_START to ONLINE: Node initialising: GET_CONFIGURATION
2017-09-15 22:12:57.576 [hingStatusInfoChangedEvent] - ‘zwave:device:f224e042:node77’ changed from ONLINE: Node initialising: GET_CONFIGURATION to ONLINE: Node initialising: DYNAMIC_VALUES
2017-09-15 22:12:58.501 [ThingUpdatedEvent ] - Thing ‘zwave:device:f224e042:node77’ has been updated.
2017-09-15 22:12:58.501 [ConfigStatusInfoEvent ] - ConfigStatusInfo [configStatusMessages=[]]
Do you want me to put the binding in debug and put produce a logfile ? Should I do a hard reset of the module ?
M.
Well, I tried a to reset a few more of the nodes, some of them produce the same warning:
2017-09-15 22:24:17.490 [WARN ] [WaveAssociationGroupInfoCommandClass] - NODE 73: Group Name is too big; maximum is 25 characters 27
Too bad, seems this is not the problem. Hmmm…
Hi Chris,
after a couple of hard resets the module started reporting meter_watts values again, it seems that the module got stuck in a strange state somehow. Sorry for the noise, I never had this particular problem before with those modules (I have 20 of them).
M.